<div dir="ltr"><div class="gmail_default" style="font-size:small">I am in the process of re-wording the text about auth and UWSRegExt and while I was at it I made a comment in the TAP11 RFC page concerning auth endpoints in a TAP service in response to Mark's idea of thinking of "bundles" of resources. I include it here as well for discussion:<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><p>These items from my DAL mailing list post of 2018-06-13 is the primary obstacle to this bundle concept:
</p><p>
2. <a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI" class="gmail-twikiLink">DALI</a>-1.1
specifies (Section 2) that all endpoints in a service must be siblings
of the VOSI-capabilities resource (except VOSI-availability); further, <a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI" class="gmail-twikiLink">DALI</a> also specifies that the capabilities resource must be named /capabilities (relative to the base).
</p><p>
3. VOSI-1.1 specifies that VOSI-capabilities must be provided with
anonymous access and such capabilities must not include a securityMethod
</p><p>
So, you have a base URL and a single anonymous child
{baseURL}/capabilities and all the TAP endpoints (eg sync and async
query execution) have to be siblings of that (i.e. direct children of
{baseURL}). That is just a flat list of interfaces and can't be
presented as a bundle with current VOSI. Somewhat ironically, before
that <a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI" class="gmail-twikiLink">DALI</a>-1.1
restriction the CADC TAP service used to place the username/password
auth endpoints under a "subdirectory", so it used to be /tap/auth/sync
and /tap/auth/async and now it is /tap/auth-sync and /tap/auth-async so
everything is a sibling of /tap/capabilities... that is quite natural
from a service deployment point of view and more or less conforms to the
bundle and defaults approach described above. But the community thought
it was a good idea to be able to navigate(?) from any endpoint to the
capabilities endpoint. Either (flat or bundle) works fine if you use the
capabilities the way that our cadc-registry client lib does (it is just
cosmetic). But: the only way to go the bundle way is for TAP-1.1 to
violate <a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI" class="gmail-twikiLink">DALI</a>-1.1 and/or retract that bit from <a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI" class="gmail-twikiLink">DALI</a> (admit mistake; issue erratum).
</p></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></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, 13 Jun 2018 at 11:49, Patrick Dowler <<a href="mailto:pdowler.cadc@gmail.com">pdowler.cadc@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-size:small"><div class="gmail_default">TAP-author-hat: on</div><div class="gmail_default"><br></div><div class="gmail_default">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. <br></div><div class="gmail_default"><br></div><div class="gmail_default"></div><div class="gmail_default">1.
VOResource defines the capability/interface/accessURL/securityMethod
stuff in the VOSI-capabilities documents; all of that usage conforms to
existing RECommendations<br></div><div class="gmail_default"><br></div><div class="gmail_default">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).<br></div><div class="gmail_default"><br></div><div class="gmail_default">3.
VOSI-1.1 specifies that VOSI-capabilities must be provided with
anonymous access and such capabilities must not include a
securityMethod<br></div><div class="gmail_default"><br></div><div class="gmail_default">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.</div><div class="gmail_default"><br></div><div class="gmail_default">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.<br></div><div class="gmail_default"><br></div><div class="gmail_default">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. <br></div><div class="gmail_default"><br></div><div class="gmail_default">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.</div><div class="gmail_default"><br></div><div class="gmail_default">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. <br></div><div class="gmail_default"><br></div><div class="gmail_default">Pat<br></div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 12 June 2018 at 06:58, Mark Taylor <span dir="ltr"><<a href="mailto:m.b.taylor@bristol.ac.uk" target="_blank">m.b.taylor@bristol.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi DAL.<br>
<br>
On Tue, 12 Jun 2018, Mark Taylor wrote on thread "Home of the UWS Registry Extension":<br>
<br>
> I still have my doubts about whether this approach is a complete<br>
> or optimal solution to the problem of TAP services with multiple<br>
> security methods, but this may not be the best place to air<br>
> those concerns.<br>
<br>
I have written up my thoughts on this on the TAP 1.1 RFC page<br>
<a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/TAP11RFC#Comments_from_Mark_Taylor_2018_0" rel="noreferrer" target="_blank">http://wiki.ivoa.net/twiki/bin/view/IVOA/TAP11RFC#Comments_from_Mark_Taylor_2018_0</a><br>
<br>
My comments include a call for service providers who are expecting<br>
to have to provide authenticated TAP services in the future to look<br>
at the relevant parts of TAP 1.1 and assess whether the current PR<br>
fits their requirements. If that's you, please take a look.<br>
<br>
Mark<br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk" target="_blank">m.b.taylor@bris.ac.uk</a> +44-117-9288776 <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~mbt/</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="m_2540799420631197275gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div>
</div>
</blockquote></div>