TAP 1.1 authentication

Thu Aug 30 14:55:23 CEST 2018

> On 2018-08 -29, at 18:14, Patrick Dowler <pdowler.cadc at gmail.com> wrote:
> 
> In our case, authentication allows for a variety of more subtle things to happen. In most  of our tap services:
> 
> - authenticated users can use a custom param to send output to a vospace
> - authenticated users may be able to see rows which have restricted access (some telescopes have proprietary metadata)
> - authenticated users can make use of the UWS job listing feature (we only let people list their own jobs)
> 
> In our catalogue tap service some tables are public and some are proprietary so:
> 
> - authenticated users see additoonal tables they have access to
> - vospace outout as above
> - job listing as above
> 
> In principle, people could have private VOTable(s) in vospace and use them via TAP_UPLOAD as well; that requires authentication (so the tap job can retrieve the table).
> 
> We've been down the road of trying to have multiple resources in the past; the main issue is that it is more confusing to users because they have to pick the right resource --  the VOSI capabilities approach already works fine and the details of auth only really effect s/w devs. There is just an "itchy bit" because the TAP capability is not exactly a single thing. It is one kind of "job" that is executable with two different "invocation patterns". I think we have come down to a mechanism that makes sense, maintains compatibility, an works programmatically, and hides as much of the auth details from the user as possible.

As far as I can see what you say only strengthens the argument for having two resources - the "TAP service" is quite different in each case -  much more functionality is available to the authenticated user.

Your argument is that the “user” finds it easier to make a decision on which URL to pick by looking at a list of Interfaces in a Capability and deciding to pick the one marked as needing authentication over the unauthenticated on based on no information about the differences, as opposed to being able to look at the descriptions of two resources, where the extra functionality could be described as in your reply.

Anyway my argument is not that there have to be two Resources registered (that is a stylistic choice), but that only the baseURL be registered as the accessURL rather than the pattern that is shown in http://www.ivoa.net/documents/TAP/20180416/PR-TAP-1.1-20180416.html#tth_sEc2.4

I know that this is rather late in the TAP 1.1 RFC, but I feel that it is worth fighting against this extra complexity as TAP is such an important service for the VO (and Mark T has the same opinion as me on the RFC page).  It seems to me on reading the reasoning in  http://wiki.ivoa.net/internal/IVOA/IvoaGridAndWebServices/UWSRegExt.pdf that the problems really stem from the decision to register the sync and async endpoints separately, but I do not see any advantage operationally in doing that, and it potentially adds noise that confuses users.

So the bottom line is that an authenticated TAP service does not have to be registered as two Resources, nor even two Capabilities within single Resource, but could be registered as a single Resource with a single Capability with two Interfaces (one for each or authenticated or not) and still be equally discoverable if the URL pointed to is a baseURL

Then the regtap query 

SELECT ivoid, access_url, security_method_id
FROM rr.capability
NATURAL JOIN rr.interface
WHERE standard_id like 'ivo://ivoa.net/std/tap%'
  AND intf_type='vs:paramhttp’

would return unique tuples, so I do not see that the arguments for UWSRegExt really hold true, as I do not see how adding more access_urls per registration decreases the chance of simple minded queries producing more than one access_url per Resource. Also that same query should work for other types of services just by changing the standard_id comparison. 

I think that the question whether the best way to register the intf_type is “vs:paramhttp” is a another issue -  I do not think that the introduction of a new interface type should be taken lightly - the vs:paramhttp has taken on the meaning of “standard compliant interface” up until now and is widely used, but perhaps in the case of something like TAP we do need a new type "vs:stdInterface” to indicate that that the URL needs to be interpreted as the base URL (this is an area where the access_url/@role could potentially be relied upon - though the issue is that the original VOResource model was perhaps too complex and allowed for different parts of the model to contradict each other)

A final point in favour of the single base URL for a TAP service is that the sentiment in software development has moved strongly in the direction of "convention over configuration” the changes from TAP 1.0 to 1.1 registration seem to be moving in the opposite direction. It has been pointed out elsewhere in this thread that it is rather nice property to be able so send someone the URL of an unregistered TAP service and their client be able to use it simply, immediately knowing all of the relevant sub-paths - TAP 1.0 allowed that - with TAP 1.1 you would have to send the URL of the capabilities end point and then the client would have to parse that returned file, and then it would have to decide whether to use the authenticated or unauthenticated Interface - in the TAP 1.0 world if you had known that you wanted to point your colleagues to the authenticated version of the unregistered TAP service you would just send them the base URL of the authenticated service.

> 
> --
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada
> 
> 
> On Wed, 29 Aug 2018 at 05:53, Paul Harrison <paul.harrison at manchester.ac.uk> wrote:
> 
> 
> > 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.
> 
> 
> 
> 
> 
> 
> 

Dr. Paul Harrison
JBO, Manchester University
http://www.manchester.ac.uk/jodrellbank

-------------- 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/20180830/6099a8b1/attachment.p7s>