TAP 1.1 authentication

[Patrick Dowler]

TAP-author-hat: on

I won't go into all the details of the current usage, but I would like to
point out the relevant specs and clarify what is being "proposed" and what
is just being used.

1. VOResource defines the capability/interface/accessURL/securityMethod
stuff in the VOSI-capabilities documents; all of that usage conforms to
existing RECommendations

2. 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 also specifies that the capabilities resource must be named
/capabilities (relative to the base).

3. VOSI-1.1 specifies that VOSI-capabilities must be provided with
anonymous access and such capabilities must not include a securityMethod

4. Practically, web servers and application servers typically implement
authentication and applications declare which endpoints (paths) require
authentication (overly simplified); cases involving challenge-response (eg.
http basic or digest) essentially have a different accessuRL... there are
other configurations that lead to a different accessURL.

5. In TAP-1.0 we recommended by example that people define an interface
where the accessURL was the base URL of the service and clients could
append the standard /async or /sync path components to generate the
endpoint URL themselves; RegTAP makes some discovery recommendations
(example queries) that involve finding a capability with the TAP-1.0
standardID.

6. The conceptual problem is that authentication is orthogonal to
functionality but VOResource is heirarchical. VOResource chose to include
authentication (securityMethod) at the leaves of the model, which is kind
of like tagging... that choice is probably the most loosely coupled and
flexible one that could have been made.

And finally: when you take all these restrictions into account and  you
want to tell clients how to authenticate, you end up with a  flat list of
interface(s) with the different accessURL/securityMethod combinations. When
you apply that to TAP specificially, you have some TAP-sync interfaces and
some TAP-async interfaces and the client needs to be able to tell which one
is which.

The *only* thing being proposed is a way to tell the difference between the
backwards-compatible base interface (#5), the additional async interfaces,
and the additional sync interfaces. We need 3 distinct values to
differentiate and since the interfaces behave differently the decision
(Santiago splinter) was to invent 2 new interface types.

Pat


On 12 June 2018 at 06:58, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:

> Hi DAL.
>
> On Tue, 12 Jun 2018, Mark Taylor wrote on thread "Home of the UWS Registry
> Extension":
>
> > I still have my doubts about whether this approach is a complete
> > or optimal solution to the problem of TAP services with multiple
> > security methods, but this may not be the best place to air
> > those concerns.
>
> I have written up my thoughts on this on the TAP 1.1 RFC page
> http://wiki.ivoa.net/twiki/bin/view/IVOA/TAP11RFC#
> Comments_from_Mark_Taylor_2018_0
>
> My comments include a call for service providers who are expecting
> to have to provide authenticated TAP services in the future to look
> at the relevant parts of TAP 1.1 and assess whether the current PR
> fits their requirements.  If that's you, please take a look.
>
> Mark
>
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
>



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20180613/8fb126e3/attachment.html>