WD-DALI-1.1-20160415

[Mark Taylor]

On Mon, 18 Apr 2016, Markus Demleitner wrote:

> Hi Pat,
> 
> On Fri, Apr 15, 2016 at 08:38:59AM -0700, Patrick Dowler wrote:
> > Relaxing the restriction on VOSI-tables allows one to have both
> > anonymous and authenticated resources. We have some case where project
> > catalogues are served via tap but only visible to authorised users;
> > only the tables the user is allowed to query show up in the
> > VOSI-tables or tap_schema output (how: my problem :-). This is just to
> > allow the freedom to do that.
> 
> So, what you're proposing is essentially something like
> 
>   <capability standardID="ivo://ivoa.net/std/VOSI#tables">
>     <interface xsi:type="vs:ParamHTTP">
>       <accessURL use="full">.../tap/run/tables</accessURL>
>     </interface>
>     <interface xsi:type="vs:ParamHTTP">
>       <accessURL use="full">.../tap/run/tables-auth</accessURL>
>       <securityMethod standardID="ivo://example.com/auth#divination"/>
>     </interface>
>   </capability>
> 
> I see how this could work.  I suspect it would help to have such an
> example somewhere in the standard to explain the intention.
> 
> Ah well, I guess in the long run TAP clients won't be able to ignore
> cabiblities once they want to run a query, so perhaps requiring them
> to parse it to figure out where to pull table metadata from doesn't
> really hurt.

I can see how Pat wants to use this, but, like Markus's initial
reaction, I don't like this move away from standard locations
for service endpoints.  (I've ranted about this to Pat and Severin
before now in relation to TAP 1.1, but since it's relevant here
I'll comment again).  Two reasons:

  1. Previously a bundle of related services was defined by a single
     string (base URL) with a list of short well-known strings
     appended to it (tables, availability, capabilities, examples, ...).
     This is moving to a situation where the bundle of services is
     defined by a (moderately complicated) XML document that you
     have to parse.  The loss of convenience is marked.
     I spend quite a lot of time finding a TAP base URL in the
     registry and then pointing curl or browsers or custom code
     at, e.g., http://base-tap-url/tables, and under this scheme
     you can't expect that to work.

     If you're writing a small client looking at just table
     metadata, having to parse a capabilities document rather than
     just append "/tables" to a known URL is annoyingly more effort. 

  2. Usage like the example Markus envisages above works well
     enough if you are thinking about a single endpoint.
     But (e.g.) a TAP service is represented by a bundle of
     related endpoints.  Having looked at the above capabilities
     snippet you know where to find the /tables endpoint for
     auth#divination.  But it's not so straightforward to
     work out what /sync (or /async, or /availabilities, or
     /examples, ...) endpoints correspond to that.  In practice,
     probably you look for capability elements with the required
     standardID which have interface/securityMethod descendents
     matching those for the tables endpoint, but there's no
     guarantee that such elements exist.
     If they don't, well you probably have to
     fall back to an unsecured one ... or maybe you should give up
     and refuse to talk to the service ... or look for a
     similar-but-not-identical securityMethod ....  It's all
     annoyingly complicated and underspecified.

     At CADC's request, I have actually implemented this in topcat
     (not in public release - not sure yet if I will include it
     in future).  It works for CADC's TAP service, but the
     implementation is not very elegant or robust.
     It's also not complete; e.g. getting taplint to understand
     services described like this would take significant extra effort.

To handle multiple alternative authentication methods, I would
much rather see a registration that maps different authentication
methods to different base URLs, where each base URL has the set
of well-known endpoints hanging off it in the way we're used to.
Notionally like this:
 
   securityMethod default:
      -> TAP base URL:
             http://abc.org/tap/
         Service endpoints:
             http://abc.org/tap/tables
             http://abc.org/tap/sync
             http://abc.org/tap/async
               ...

   securityMethod ivo://example.com/auth#divination:
      -> TAP base URL:
             http://abc.org/tap-auth/
         Service endpoints:
             http://abc.org/tap-auth/tables
             http://abc.org/tap-auth/sync
             http://abc.org/tap-auth/async
               ...

and not like this:

   tables service endpoint:
      securityMethod default:
          http://abc.org/tap/tables
      securityMethod ivo://example.com/auth#divination:
          http://abc.org/tap/tables-auth

   sync service endpoint:
      securityMethod default:
          http://abc.org/tap/sync
      securityMethod ivo://example.com/auth#divination:
          http://abc.org/tap/sync-auth

   async service endpoint:
      securityMethod default:
          http://abc.org/tap/async
      securityMethod ivo://example.com/auth#divination:
          http://abc.org/tap/async-auth

     ...

However, I haven't given any thought to the details of where or
how you would specify that.

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/