TAP 1.1 authentication

[Mark Taylor]

Hi TAP people,

back on this one again.  I'm preparing some comments on
PR-TAP-1.1-201808-30 which I will post shortly, and I still find
the model of endpoint organisation described in section 2.4
(arbitrarily-named endpoints referenced in the capabilities
document rather than well-known endpoints hanging off a,
possibly authentication-specific, base URL) unwieldy and leading
to various annoying, though not insurmountable, problems.

That brings me back to these comments:

On Mon, 27 Aug 2018, Markus Demleitner wrote:

> On Thu, Aug 23, 2018 at 04:19:47PM -0700, Patrick Dowler wrote:
> > 2. DALI <http://wiki.ivoa.net/twiki/bin/view/IVOA/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
> > <http://wiki.ivoa.net/twiki/bin/view/IVOA/DALI> also specifies that the
> > capabilities resource must be named /capabilities (relative to the base).
> 
> Just to remind everyone: The reason for that restriction was that
> validators, TAP clients, and probably quite a few other components
> need to access the capabilities endpoint.  *Assuming* all they have the
> the access URL of an endpoint, the only way they can sanely reach
> the capabilities from that is (I think) the sibling rule.

I will note that in writing TAP clients or validators I've never
had the need to use this sibling rule. The reason is that the
clients are given, and keep track of, the TAP base endpoint
(e.g. http://dc.g-vo.org/tap) rather than an access endpoint as such
(e.g. http://dc.g-vo.org/tap/sync), and from that they know where
to get the capabilities document (just append "/capabilities").
So I don't use the sibling rule for capabilities, but I do use a 
'child rule', to locate capabilities and also the other endpoints
in the TAP "bundle" such as sync, async, examples and tables.
That also means I don't need to bother looking at the capabilities
document (apart from its TAPRegExt-specific content).
The suggestion in the current TAP 1.1 PR will mean this child rule
doesn't work any more for authenticated TAP access: you will be
able to locate capabilities from just knowing a given URL,
but you will no longer be able to locate sync, async, tables
endpoints in the same way.

Pat went on to say:

> the only way to go the bundle way is for TAP-1.1 to violate DALI-1.1
> and/or retract that bit from DALI (admit mistake; issue erratum).

I don't think that's true; I don't see why catering for multiple
security methods has to break either the child rule or the sibling rule.
If you have e.g.:

  <capability standardID="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>
    </interface>

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

  </capability>

you can still make the sibling rule work by providing a
http://example.net/myTAP-auth/capabilities endpoint as well as
http://example.net/myTAP/capabilities.  These auth-specific
capabilities documents can be accessible without authentication
to avoid breaking Pat's point 3:

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

and could in fact have identical content (e.g. just redirect)
to the unauthenticated capabilities document.

Then there's no need to register all those sync and async
endpoints explicitly and no need for UWSRegExt.

The rest of the capabilities document could look substantially
the same as the current example, but with the additional rule
(analogous to the constraints already in TAP 1.0) that the other
declared auth-specific endpoints (tables and examples as well
as capabilities) MUST be located in the standard positions
relative to the corresponding auth-specific TAP base URL.

Then the 'child rule', as well as the sibling rule, works.

I think this is more or less what Paul was saying.

To summarise: duplicating the capabilities document at auth-specific
endpoints means you don't need to break the sibling rule, and
hierarchical endpoint naming can be preserved, which I contend
(and Paul has also argued) is a Good Thing.

Am I missing something?

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/