TAP 1.1 authentication

[Paul Harrison]

> On 2018-08 -27, at 13:21, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> Hi all,
> 
> On Thu, Aug 23, 2018 at 04:19:47PM -0700, Patrick Dowler wrote:
>> 2. DALI <http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI>-1.1 specifies
>> (Section 2) that all endpoints in a service must be siblings of the
>> VOSI-capabilities resource (except VOSI-availability); further, DALI
>> <http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI> also specifies that the
>> capabilities resource must be named /capabilities (relative to the base).
> 

I think that the single base URL with multiple children principle is worth keeping, and it seems to me that the TAP 1.1 proposal of registering the TAP sync/async endpoints separately for a single service is causing all sorts of problems/contradictions.

Taking a step back then I think that the main reason for having an authenticated version of the service is that it can serve a potentially different set of (proprietary) tables - this means that it would potentially have a different set of VOSI metadata anyway, so it would be sensible to have a completely separate URL tree for the authenticated service. In the existing registry model this would mean two separate sets of capabilities (which naturally provides the grouping), one with the authenticated access and the other without - it might also make sense that for the authenticated service even the VOSI endpoints require authentication (the data might be so proprietary that even the metadata should not be exposed….).

The only question then would be whether to put the two capabilities into one resource, or have two separate resources - either would be acceptable I think, though I would possibly go for two resources with a relationship between them and a differing description as to the public/proprietary nature of the access.

Does this work, or have I missed something?

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/dal/attachments/20180829/7af8abfc/attachment.p7s>