<div dir="ltr"><div style="font-size:small" class="gmail_default"></div><div class="gmail_default" style="font-size:small">In our case, authentication allows for a variety of more subtle things to happen. In most of our tap services:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">- authenticated users can use a custom param to send output to a vospace</div><div class="gmail_default" style="font-size:small">- authenticated users may be able to see rows which have restricted access (some telescopes have proprietary metadata)</div><div class="gmail_default" style="font-size:small">- authenticated users can make use of the UWS job listing feature (we only let people list their own jobs)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">In our catalogue tap service some tables are public and some are proprietary so:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">- authenticated users see additoonal tables they have access to</div><div class="gmail_default" style="font-size:small">- vospace outout as above</div><div class="gmail_default" style="font-size:small">- job listing as above</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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).<br></div><br><div class="gmail_default" style="font-size:small">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.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">--<br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 29 Aug 2018 at 05:53, Paul Harrison <<a href="mailto:paul.harrison@manchester.ac.uk">paul.harrison@manchester.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On 2018-08 -27, at 13:21, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br>
> <br>
> Hi all,<br>
> <br>
> On Thu, Aug 23, 2018 at 04:19:47PM -0700, Patrick Dowler wrote:<br>
>> 2. DALI <<a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI" rel="noreferrer" target="_blank">http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI</a>>-1.1 specifies<br>
>> (Section 2) that all endpoints in a service must be siblings of the<br>
>> VOSI-capabilities resource (except VOSI-availability); further, DALI<br>
>> <<a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI" rel="noreferrer" target="_blank">http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI</a>> also specifies that the<br>
>> capabilities resource must be named /capabilities (relative to the base).<br>
> <br>
<br>
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.<br>
<br>
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….).<br>
<br>
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.<br>
<br>
Does this work, or have I missed something?<br>
<br>
Cheers,<br>
Paul.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div>