WD-DALI-1.1-20160415

[Markus Demleitner]

Hi,

On Mon, Apr 18, 2016 at 10:14:24PM +0100, Mark Taylor wrote:
> 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.

Now that you mention it: I'm currently overhauling VOResource in
preparation for having DOIs (and ORCIDs), fixing some minor
annoyances on the way.

While I want to be careful not to break anything that already works,
I'd like to mention that

  select distinct(ivoid) from rr.res_detail where detail_xpath like '%securityMethod%';

just yields

 ivo://sao.ru/community
 ivo://sao.ru/vospace-service

-- both of which look a bit orphaned to me.

So, I'd say if you have better ideas, a point could be made that the
securityMethod design should be changed.  The
service/capaility/interface model, on the other hand, is probably
sacrosant at this point.

However, I've always had the feeling securityMethod wasn't a terribly
useful piece of metadata in the first place -- as present now, it
doesn't help in discovery I'd say, since you cannot tell by its
presence whether you'll be able to access the data.

And I've always been a great fan of using authentication that doesn't
work against HTTP.  Now, in HTTP, if there's a resource that needs
authentication lists the supported authentication methods in the
headers of the 401 response (WWW-Authenticate, 14.47 of RFC 2616).
You can even include WWW-Authenticate in a 200 response to indicate
that clients that can authenticate get to see more.

So, my (not terribly strong) feeling would be that Mark's

> 
>     /sync
>     /tables
>     /capabilities
>     /examples

endpoints should simply spit out the proper headers -- they can still
redirect to more specialised endpoints if that makes the software
design simpler.

A client must/could, if it sees a WWW-Authenticate together with a
403/{200,301,303} response from either of these endpoints, ask the
user  if she wants to authenticate once and cache the response --
which I think is a reasonable UI.

No discovery is involved; if later people want to assess from the
registry whether a service likely has data readable by them, we'll
have to figure out something going beyond vr:securityMethod anyway.

Admittedly, I've always shyed away from even trying to show different
users different tables on my TAP endpoint.  So, it's quite likely I'm
overlooking problems here.  But it's a nice dream, no?

Cheers,

         Markus