WD-DALI-1.1-20160415

[Patrick Dowler]

I appreciate that the base URL concept looks a lot simpler and we
tried to us that concept within CADC and CANFAR... but eventually had
to move toward the one proposed. The first sore spot is that
VOResource places securityMethod under interface under capablity. That
means that for one "feature" defined by a standardID you have one
capability and one or more interfaces (possibly) differing by
securityMethod.

(possibly: I suppose you could list multiple interfaces as a way to
provide redundant access).

So, in my opinion trying to use the base URL and all fixed names is
thinking about capabilities in the wrong way: it conflicts with the
VOSI-capabilities (VOResource) model and it leads to a more complex
conceptual model in the long run. Plus, with optional capabilities you
still need VOSI-capabilities to see if they are supported anyway.  Our
CADC + CANFAR system has ~15 interacting web services and just using
base URLs and known paths was a #fail we are still trying to undo.

more below...

On 18 April 2016 at 05:25, Mark Taylor <M.B.Taylor at bristol.ac.uk> wrote:
>   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.

I think this is thinking about the problem in the wrong way. There is
no concept of "this tables resource goes with that sync resource".
There is one VOSI-tables capability and one TAP-sync capability and
they go together. The fact that each can be accessed via various
authentication methods does not in any way change that.

As a client, all you can/should do is look for the capability you want
to use and then pick an interface based on which securityMethod you
can actually do. If there are choices then the user has to pick what
they want to do.



>      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.

I think if you look at it as just a set of related capabilities it
doesn't look all that complicated. When you add securityMethod into
the mix it is just a matter of which you can and cannot actually
perform and whether or not the user wants to use one or remain
anonymous. These are choices only the user can make.


Now, as to why the user might chose to be anonymous vs authenticate,
that depends on what they are accessing. In CADC services we have some
proprietary data and some proprietary metadata so authenticating may
allow the user to see more content than an anonymous user. That is our
problem to implement correctly and while there is currently no way to
convey to users that some magic is happening in the authorization --
and hence why they might want to chose authenticated access -- I thin
that's out of scope for what we have here: describe how to access the
service in an authenticated way.


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