WD-DALI-1.1-20160415

[Mark Taylor]

Pat,

On Mon, 18 Apr 2016, Patrick Dowler wrote:

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

I agree that VOResource design is not helping here.
 
> 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.

>From a service point of view, I can see that's not problematic.

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

... but when writing clients, it looks to me like that approach will
make for a pretty rotten user interface.

Obviously, I'm thinking about this from the point of view of topcat's
TAP client.  Just in order to build the GUI as soon as the user
has chosen which TAP service she wants to talk to, I'm hitting
these endpoints:

    /sync
    /tables
    /capabilities
    /examples

The question of which securityMethod I can actually do is not
very clear.  In some cases it depends on asking the user
for credentials interactively, which they may or may not be
able to provide.  For instance if one of the listed securityMethods
is HTTP Basic Auth, I can attempt to use it by asking the user
interactively for username/password.  Similar for TLS-with-password
I guess?  I don't understand how other securityMethods like
SAML, OpenID, Cookies etc work, but my guess is it's not very
easy to look at a URL and say: I can/cannot authenticate against
this, without effectively trying it.

So: as far as I can see if I adopt your approach of looking for
capabilities I want to use and picking an interface based on
the securityMethod that the user chooses, what I have to do is
present the user with the following questions (pop-up dialogues?
a set of multiple different menus somewhere for services whose
names the user most likely doesn't even understand?)

   TAP sync queries:
      do you want to use anonymous, HTTP basic auth, or TLS-with-cert?

   Tables metadata:
      do you want to use anonymous, HTTP basic auth, or TLS-with-cert?

   Examples:
      do you want to use anonymous, HTTP basic auth, or TLs-with-cert?

.. and then they get to see the information about the TAP service
they've selected.  If they later want to use async, they have to
answer the same thing again about the async endpoint.

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

I'm not trying to be difficult here, possibly I'm missing something.

You have seen the existing topcat TAP GUI - can you sketch out
what the user interface would look like based on the assumption
that there is a set of TAP-related service endpoints each with
its own independent list of securityMethods, that have to be
chosen independently?

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

Yes, I get that part of it.

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/