TAP 1.1 authentication

[Paul Harrison]

> On 2018-09 -13, at 00:01, Patrick Dowler <pdowler.cadc at gmail.com> wrote:
> 
> 
> On the whole topic of base URL vs usable endpoints:
> 
> I have been convinced for a long time that the whole approach we took in TAP-1.0 (8+ years ago) was wrong. We did specify that TAP has both sync and async query execution but we tried to pretend that it was one thing instead of two things. VOSpace has several different endpoints that behave differently and they are separate capabilities. If sync and async were just treated as separate capabilities from the start we would not have this problem and we don't have this problem with any other services. 
> 
> On Wed, 12 Sep 2018 at 09:17, Paul Harrison <paul.harrison at manchester.ac.uk <mailto:paul.harrison at manchester.ac.uk>> wrote:
> > and blurs the distinction about what *the* URL of a service is 
> 
> In my mind this idea is wrong and has always been wrong -- there is no *the* URL of a (TAP) service that is directly usable (eg that you can POST to) --  but we (DAL-WG and TAP-1.0 authors) had to make compromises to get TAP-1.0 to REC. We got the cardinality of service-capability-interface-accessURL wrong. It is more complicated than that because you have to just know to append one more special strings to the path to create usable URLs. That makes TAP special, which is sad when VOSI-capabilities is perfectly capable of describing endpoints so you don't need bespoke solutions and knowledge and we have proven that one can write and use a generic capabilities client to work out all the details. 
> I am not arguing that it is impossible to comply with VOSI and DALI and keep a facade of "the URL" in TAP-1.1, but all the things needed to do that and avoid fixing the mistakes of TAP-1.0 make TAP more special and bespoke and less like the standard patterns in other services and the spirit of upstream standards. That means more text, more unforeseen consequences of that text, and less flexibility to use other standards to the fullest. It also means more code specific to TAP. 

If we take the “functional" approach that I was advocating earlier in this thread and use curl as a lowest common denominator “dumb” client then only the ParamHttp interface type accessURL fits the bill as an endpoint that you can POST to and get the answers back directly - there is already the precedent of the WebBrowser interface type for which at best it is might be possible to scrape the web page to see how to resubmit the parameters to get the answer and the UWS async interface similarly does not directly give the answers after the initial POST. Therefore my argument is that having to make a trivial addition to the starting URL is much less than the effort of getting the final answer out, and there is not the uniformity of “directly useable” URLs amongst the VO standards that you are suggesting.

What I do agree with is that it is anomalous to label the base URL interface of the TAP service as paramHTTP as that should stand for the “curl usable” interface - again earlier in the thread I suggested that a new interface type be created called “std” that simply means the URL behaves as described in the standard e.g. as for TAP 1.0

> 
> If you still disagree with my claim that there is no "the URL to a TAP service" and there doesn't need to be one, then stop reading now because the rest is about how to fix things.

Well I do and as Mark has pointed out as well as the arguments presented above registry searches become much more difficult with more interfaces registered.

> On 2018-09 -12, at 18:49, Patrick Dowler <pdowler.cadc at gmail.com> wrote:
> 
> 
> On duplicating the VOSI-capabilities deployment: sure you can do that but it makes the service deployment more complicated and means service providers have to write more tests to verify their service is working correctly. And when they register the service in an IVOA registry, which accessURL do they put? Obviously any would do since they are redundant, but someone has to document that and people have to understand that. It's smelly and it is not in the spirit of the DALI sibling rule which is that service endpoints are flat and not heirarchical.
> 

I really do not believe that it makes deployment more difficult (but anyway these suggestions are also at least equally motivated by making life easier for clients of the services). There are two separate (but identically structured) trees one authenticated. You could argue (and we are!) that you just run the same integration test suite twice pointing at two different base URLs….

The registration is simple as Mark showed (with the proviso, as above, that I agree that vs:ParamHTTP is not really appropriate)


 <capability standardID="ivo://ivoa.net/std/TAP <ivo://ivoa.net/std/TAP>">

   <!-- Unauthenticated TAP base URL -->
   <interface xsi:type="vs:ParamHTTP" role="std" version="1.1">
     <accessURL use="base">http://example.net/myTAP</accessURL> <http://example.net/myTAP%3C/accessURL%3E>
   </interface>

   <!-- Authenticated TAP base URL -->
   <interface xsi:type="vs:ParamHTTP" role="std" version="1.1">
     <accessURL use="base">http://example.net/myTAP-auth</accessURL> <http://example.net/myTAP-auth%3C/accessURL%3E>
     <securityMethod standardID="ivo://ivoa.net/sso#BasicAA <ivo://ivoa.net/sso#BasicAA>"/>
   </interface>

 </capability>

searches in the registry can be simple and only one URL returned if you specify that you do not want authenticated - this is all without breaking any ‘rules’ and keeping current practice. 

Paul.

p.s. Another suggestion that I am slightly loath to make as I think it seems a bit hacky - TAP 1.1 could always specify that the baseURL redirects to the sync endpoint - then there could even be no argument against vs:ParamHTTP as the interface type in the above capability.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20180913/3259d524/attachment.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/20180913/3259d524/attachment.p7s>