TAP 1.1 authentication

[Paul Harrison]

> On 2018-09 -12, at 13:35, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
> 
> Then there's no need to register all those sync and async
> endpoints explicitly and no need for UWSRegExt.
> 
> The rest of the capabilities document could look substantially
> the same as the current example, but with the additional rule
> (analogous to the constraints already in TAP 1.0) that the other
> declared auth-specific endpoints (tables and examples as well
> as capabilities) MUST be located in the standard positions
> relative to the corresponding auth-specific TAP base URL.
> 
> Then the 'child rule', as well as the sibling rule, works.
> 
> I think this is more or less what Paul was saying.

Yes - this is what I am saying (and at first I did not realise that you had said it before me in the RFC) - it seems much easier to me, and more in keeping with the “spirit” of the original registry data model anyway.

> 
> To summarise: duplicating the capabilities document at auth-specific
> endpoints means you don't need to break the sibling rule, and
> hierarchical endpoint naming can be preserved, which I contend
> (and Paul has also argued) is a Good Thing.

I still think that it is better to do this way not only from the point of view that it keeps things simple, but also that it allows for the possibility that the /tableMetadata endpoint content should be different for the authenticated service anyway.

> 
> Am I missing something?

An argument that might be used is that for the original SimpleXX v1.0 services there is an established use of the 'sibling rule' to find the capabilities endpoint (though there was no technical reason why a “child rule” could not have been adopted instead)

As far as I can see if you are handed a URL as a client and you have no idea what it is pointing to then you can try both the child and the sibling rules to find the capabilities endpoint to find out what service it is. In reality you will most often know what service the URL represents and your client can do the right thing (child for TAP 1.0, sibling for SIA 1.0 - though of course if you know what the service is then you don’t need to find the capabilities endpoint!)  - it should be noted that this is the *current* state of affairs anyway, TAP 1.1 is trying to introduce a new more complicated regime where you have to always read the capabilities endpoint to understand what to do, and blurs the distinction about what *the* URL of a service is that I can cut and paste into an email/twitter message etc. The only sensible answer then is that the capabilities endpoint is *the* URL, but then there is an asymmetry with searching a registry for a service where it is wasteful finding the URL of the capabilities endpoint of a service rather than directly the service endpoint….

I actually question whether there is any value in putting the VOSI endpoints themselves in the capabilities endpoint content and registering them - it seems superfluous (apart from /availability, which could be a redirect anyway by modern DALI conventions) as they are supposed to be fixed anyway. 


Paul.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20180912/4c684b7c/attachment-0001.html>
-------------- 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/dal/attachments/20180912/4c684b7c/attachment-0001.p7s>