WD-DALI-1.1-20160415

[Patrick Dowler]

> I was being a bit imprecise - it's more the fact that the securityMethod
> is attached to the interface elements for individual services
> that I was complaining about.

But in HTTP securityMethod *is* attached to specific URLs and it isn't
until you get to the interface element that you have a URL.

> However, thinking about it, the TAP service as a whole has a capability
> as well as all its sub-services, so something like:

Well, one thing that is changing between TAP-1.0 and TAP-1.1 is that
the standardID(s) for 1.1 are for the individual capabilities, which
are:

TAP#sync-1.1
TAP#async-1.1

and that non-versioned one that applies to the base URL is TAP-1.0
only. In future the service as a whole does not have a capability. The
document is already a group of capabilities of a service. A service
provider can retain the TAP-1.0 base URL capability and nothing in
DALI-1.1 or TAP-1.1 breaks that compatibility. However, it is
currently not possibly to correctly describe what some providers need
to provide

One aspect that maybe hasn't been mentioned is that DALI specifies
that all resources have to be siblings of the VOSI-capabilities
resource so that clients can find it from any known interface url
(started with DataLink, pulled up to DALI as a standard practice).
Since /capabilities is one of the resources under the TAP base url,
describing the base url is not sufficient (essentially, it was wrong
to do that in 1.0 but we were lazy/rushed/uninformed at the time).

Trying to keep the single TAP base URL concept and the "sibling of
VOSI-capabilities" means the only viable option is to have a complete
duplicate service for every securityMethod. On the other hand,
VOResource already allows service providers to describe multiple
interfaces for a single capability and in our experience in CADC and
CANFAR this is the correct conceptual model and it works. I'm not
saying it isn't more complex because it is, but it is only as complex
as it needs to be and it isn't nearly as complex as it looks at first
glance.

For a standard TAP service with anonymous access, things will look
more or less like they did before.

>   <capability standardID="ivo://ivoa.net/std/TAP"
>               xmlns:tr="http://www.ivoa.net/xml/TAPRegExt/v1.0"
>               xsi:type="tr:TableAccess">
>     <interface xsi:type="vod:ParamHTTP" role="std" version="1.0">
>       <accessURL use="base">http://www.cadc.hia.nrc.gc.ca/tap</accessURL>
>     </interface>
>     <interface xsi:type="vod:ParamHTTP" role="std" version="1.0">
>       <accessURL use="base">https://www.cadc.hia.nrc.gc.ca/tap</accessURL>
>       <securityMethod standardID="ivo://ivoa.net/sso#tls-with-certificate" />
>     </interface>
>     <interface xsi:type="vod:ParamHTTP" role="std" version="1.0">
>       <accessURL use="base">http://www.cadc.hia.nrc.gc.ca/tap-auth</accessURL>
>       <securityMethod standardID="http://www.w3.org/Protocols/HTTP/1.0/spec.html#BasicAA"/>
>     </interface>

I should note that /tap-auth is *not* in our current VOSI-capabilities
document for TAP-1.0 because we comply with DALI-1.1 "siblings"
restriction. I did take the liberty of including the https interface
because I think in spirit it is a sibling resource accessed via
different wire protocol. Obviously the text has to make this more
clear.

With this approach there is now a complete duplicate service because
it now needs VOSI resources to be a TAP service:

/tap/async
/tap/sync
/tap/availability
/tap/capabilities
/tap/tables

...

/tap-auth/async
/tap-auth/sync
/tap-auth/availability
/tap-auth/capabilities
/tap-auth/tables

-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada