<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/<wbr>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/<wbr>bin/view/IVOA/TAP11RFC#<wbr>Comments_from_Mark_Taylor_<wbr>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">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/~<wbr>mbt/</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_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>