<div dir="ltr"><div class="gmail_default" style="font-size:small">I have had some time to think about this and also talk with Brian, who is doing the work on this one. Here are my thoughts.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">0. I'm think more broadly than just TAP because whatever we decide on should be a useful addition to other services as well; at CADC we have ~35 RESTful web services which would end up using this; admittedly, that isn't 35 different pieces of s/w but it is 35 configured and deployed services that our ops staff manage; so I'm looking for something we can write once and configure the same way and it will work the same way in all instances <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1. In principle, all endpoints would respond with these headers saying how one could authenticate (optional or mandatory with a 401 response code); I agree that a standard bootstrap endpoint to poke will make client writing much easier so I agree that the feature is required<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">2. Although some endpoints have to function without auth (VOSI-capabilities and VOSI-availability at a minimum), both of these can accept authenticated requests (and usually ignore caller identity); in theory someone could extend VOSI endpoints to do other kinds of actions and that could require authentication (we have done that at CADC)... but the main point: I think the concept of fine-grained auth (these endpoints require auth, these endpoints support optional auth, and these ones don't have auth) is complex without any real value. Clients can get away with the much simpler view of "access service endpoint(s) anon" or "access service endpoint(s) with these credentials" in all cases I have encountered. <br></div><br><div class="gmail_default" style="font-size:small">3. We will have to standardise a few things: the "ivoa" challenge with allowed props, the standard #tls-with-password form post, and the well-known endpoint that is a quick request to get challenge headers; the first two will naturally go into SSO (imo: 2.1). W.r.t the above points and thinking about writing the spec, the bootstrap endpoint could be specified in SSO or VOSI. Brian's prototyping showed us that it was simple to get the challenge headers (or the x-vo-authenticated header) into every response and that should happen anyway, so the bootstrap "authcheck" endpoint is really a no-op endpoint. I'd prefer to rely on an existing endpoint rather than make up a new thing... and when I think about the spec alterations I immediately get to my proposal below</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">Proposal: I think the headers belong in all responses (SSO text) and clients should bootstrap by calling the /capabilities endpoint (VOSI text). It's general metadata about how to call the service: some in headers, some in the body. The spec change would be to specify that the capabilities should return challenges (or x-vo-authenticated). I'd also add that capabilities should support http HEAD for clients that only want the auth challenges. I'm not sure exactly how capabilities will evolve in future, but it will be an endpoint to describe the service and these headers are always legit in such a request. From an implementation pov, it was easy to add this in our cadc-vosi library and rebuild and deploy services (Brian did have to make a small change for HEAD support). It's an endpoint that's already included by other standards, it isn't changing the concept of "capabilities" and seems like the right place to recommend to client writers.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Aside: At least for client use, I agree that securityMethod in capabilities docs will probably fade away; how capabilities actually evolves is a different issue and I have some "use cases" in that direction coming...<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"></div><div><div dir="ltr" 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" class="gmail_attr">On Wed, 23 Jun 2021 at 06:31, Mark Taylor <<a href="mailto:m.b.taylor@bristol.ac.uk" target="_blank">m.b.taylor@bristol.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Pat (and GWS),<br>
<br>
from the GWS auth telecon yesterday I understand you're sceptical about<br>
the requirement for an authcheck endpoint that I'd like to see,<br>
so this is to try to persuade you that it, or something doing a<br>
similar job, is (IMO) required. I agree that as a service endpoint<br>
it looks kind of dumb since it apparently doesn't do anything,<br>
but I can't see how a client like topcat is going to do a good<br>
job of authenticated access - especially optionally authenticated <br>
access - to TAP-like services without it.<br>
<br>
I discussed the requirement in my talk at the Nov 2020 interop,<br>
see slide 6 of:<br>
<br>
<a href="https://wiki.ivoa.net/internal/IVOA/InterOpNov2020GWS/auth.pdf" rel="noreferrer" target="_blank">https://wiki.ivoa.net/internal/IVOA/InterOpNov2020GWS/auth.pdf</a><br>
<br>
The basic problem is that I (topcat) need to know before starting <br>
to access a service, for instance prior to metadata acquisition<br>
as well as to user query submission, what kind of authentication<br>
is appropriate. That information could come from the content <br>
of the capabilities document (securityMethod details), but we <br>
seem to be moving away from that model to conveying the <br>
information by WWW-Authenticate challenges instead (which I support).<br>
<br>
So the question is how to provoke such a WWW-Authenticate challenge.<br>
I'd be quite happy to use one of the existing endpoints if it could<br>
be relied on to do the job, but none of them seem to fit, at least<br>
without some additional standardisation.<br>
<br>
If you're unconvinced that I need this information, I can try<br>
harder to persuade you. If you think I can get it from existing<br>
endpoints, I'm happy to consider suggestions. Otherwise - authcheck!<br>
Or similar. I don't care what it's called, but Markus has<br>
implemented an endpoint with that name<br>
(<a href="http://dc.g-vo.org/tap/authcheck" rel="noreferrer" target="_blank">http://dc.g-vo.org/tap/authcheck</a>) so it'll do if nobody<br>
comes up with something better.<br>
<br>
If we can agree it's required, we can tackle the details of the<br>
requirements (endpoint name, what standard specifies it,<br>
which HTTP methods must be supported, whether it's mandatory<br>
for anon-only services, etc).<br>
<br>
Mark<br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bristol.ac.uk" target="_blank">m.b.taylor@bristol.ac.uk</a> <a href="http://www.star.bristol.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bristol.ac.uk/~mbt/</a><br>
</blockquote></div>