TAP 1.1 authentication

[Markus Demleitner]

Hi all,

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.

*If* we decide the sibling rule is badly raining on our parade, we
can of course retract the assumption and say the clients have to use
other resources than just the service's access URL.

Three mechanisms come to mind:

(a) Use the registry.  *If* all resource records properly declared
their capability endpoints, you could, from an access URL, determine
a corresponding capability endpoint using a RegTAP query like

select dest.access_url as cap_url
from rr.capability
natural join rr.interface as dest
join rr.interface as src using (ivoid)
where
	src.access_url='http://dc.zah.uni-heidelberg.de/tap'
	and standard_id='ivo://ivoa.net/std/vosi#capabilities'

-- this currently has unwelcome interactions with auxiliary
capabilities, but that could be fixed immediately by restricting
src's standard id.

I'm not a big fan of requiring a registry interaction for service
use, though; the most striking reason at this point is that at least
I want to let people run unregistered services and use them with our
VO tools.  There are several legitimate reasons to do that (and a lot
others).  Hence, I don't like it.

(b) We could go back to the ancient designs and have every service
respond to a REQUEST=getCapabilities request with a redirect to the
capabilities URL.  My gut feeling is that we'll regret that, and
there are some worms here, too, in particular when we're talking
about authentication (as in: to do that request, a client has to
figure out the securityMethod; but it needs the capabilities already
to do that).  And of course it would require that we touch all of our
DAL standards.

I don't like it either.

(c) We don't pass around access URLs but instead ivoids and
standard ids (which then assumes all capabilities with the same
standard id are equivalent).  With an ivoid and the registry, clients
could immediately figure out a capabilities URL.

This breaks the majority of our discovery queries, APIs, and again
restricts operation to registered services.  Again, I don't like it.

So -- as far as my creativity goes, I think the sibling rule is by
far the least evil.  Not sure whether that's my lack of creativity or
if that's the structure of the problem.

Grouping interfaces within a VOSI capability, on the other hand,
doesn't sound like an insurmountable problem.  In the context of
associating tables and capabilities, VizieR has reported comparable
problems.  I *think* one could relatively easily solve this by
attaching a group_id attribute (or perhaps a group_tag element) to
select VOResource element (interface, capability, table would
probably be enough; perhaps schema) and then declare semantics like
"capabilities and tables in one group mean 'this capability gives
access to this table'" or "more than one interface in a group means
'related interfaces exposing the same data with different
modalities'".

We won't win a beauty contest with this, of course.

         -- Markus

PS: ceterum censeo top-posting is a curse inflicted upon the world by
Outlook.