RegTAP 1.1 PR

[Paul Harrison]

> On 2018-09 -27, at 12:21, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> On Thu, Sep 27, 2018 at 11:42:09AM +0100, Mark Taylor wrote:
>> On Wed, 1 Aug 2018, Markus Demleitner wrote:
>>> I've uploaded a Proposed Recommendation for RegTAP 1.1 to the
>>> document repository.  Here's the changelog since WD-20171206:
>> 
>> I have a comment/query on the RegTAP 1.1 PR, concerning security method IDs.
>> The change log in appendix E.2 says:
>> 
>>   "securityMethod/@standardID is now included in interface in a
>>    security_method_id column. Consequently, the
>>    /capability/interface/securityMethod/@standardID res_detail key
>>    has been removed (but services can of course still provide it)."
>> 
>> This removal of a standard key could be seen as a backwards compatibility
>> violation.  In practical terms, a client now has to know whether it's


> Ye-es.  However, I don't think there has ever been such a key in the
> registry, and there certainly is none now -- the whole securityMethod
> business is quite obviously an example of specification without
> implementation, which usually results in trouble.  As is the case
> here.

Well TAP 1.1 is trying to add them (in an unfortunately pattern in my opinion).

Resource 1.0 and Resource 1.1 have exactly the same /capability/interface/securityMethod/@standardID 
attribute and general capability/interface structure and although there were not any registrations with security model, as discussed in 
http://mail.ivoa.net/pipermail/grid/2018-September/002976.html the capability/interface model did have a solid foundation.


> Anyway, since there's probably never been a securityMethod row in
> rr.res_details, I can't imagine that any actual code does anything
> sensible with such rows.  I'd dearly like to get rid of them, though,
> because they talk about interfaces, where res_detail is only designed
> to go to the capability level.  It's therefore doubtful if any actual
> code even *could* do something sensible with it if it tried to.


> 
>> talking to a RegTAP 1.0 or RegTAP 1.1 service in order to know where
>> to look for the security method ID information, so if it's not 1.1-aware
>> it may not find security method information that a RegTAP 1.1 service
>> is providing.  For backward compatibility reasons, I would therefore
>> suggest that the res_detail key stays put, and a SHOULD is introduced
>> to encourage 1.1 services to duplicate the security_method_id content
>> from rr.interface in rr.detail.
>> 
>> What do you think?

I agree that 1.1 services SHOULD still put in the /capability/interface/securityMethod/@standardID res_detail key to allow for backwards capability

> 
> My reasoning was that both VOResource 1.0 and RegTAP 1.0 are
> insufficient to support registry-based discovery of services with
> restricted access, and hence neither should be used when dealing with
> them.  That was also the reasoning behind the
> non-quite-ok-for-a-point-release changes to securityMethod in
> VOResource 1.1.

I do not think that it is true that version 1.0 was insufficient - and as far as I can see the only thing in 
VOResource 1.1 that has changed in a non-quite-ok-for-a-point-release fashion is only having
1 security_method per interface - but I think that this is OK in the VOResource model - perhaps
register multiple interfaces with the different security methods if necessary - 
*but* the TAP1.1 pattern for registering breaks the  interfaces-in-a-capability-are-equivalent
model property which allows this (though in truth the “WebBrowser” interface already did this).

This does leave open the question of what pattern is recommended if people want to register multiple
security methods - I have to admit that I am mildly sceptical as to whether there is any value
in specifying the exact security method, but only whether an endpoint it authenticated or not, and leave the
exact type of security method to be discovered by initial client handshaking - this is how
most of the internet works.

> 
> In that sense my hope has been that if you need to work with
> securityMethod, you can already rely on the 1.1 versions of the
> underlying standards.  I give you we're not quite there yet for the
> whole VO, but: how hard would it be to structure your discovery that
> you simply disable all authentication-related functionality when you
> talk to a RegTAP 1.0 service?

In practice given the small number of RegTAP services and registered service instances with securityMethods,
I think that this is broadly true that the 1.1 pattern will quickly take hold as the dominant pattern that clients assume.

Cheers,
	Paul.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1905 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20181004/bb38797b/attachment.p7s>