WD-DALI-1.1-20160415

[Marco Molinaro]

Dear all,
maybe I jump in late and a bit off-topic...

It seems to me that here we are mixing: multiple tables endpoints,
authenticated access and data policies.
The first thing is asked for having different endpoints for
authenticated and anonymous users, exposing privacy-covered meta-data
the first ones, full public meta-data the latter.

Wouldn't it be cleaner to have a unique endpoint that, if secured,
accepts "anonymous" users to serve only public content?
This will put everything on the shoulders of the service, the client
having only to alert the user of the possible authentication required.

If service is public: not issue.
If mixed data policy is in place: ask credentials and, if anonymous,
return only public content.
If strict privacy is the case: ask credentials, maybe warn the user
and return no results in the case.
If we want to keep public and private totally separate: well, that
looks to me like two different resources.

I know, maybe VO standards are not exactly ready for this, and server
side it may require some business logic changes, but I feel it would
be better and easier to understand for the user.

As an aside: relaxing /tables name could be ok to allow multiple
endpoints, but for the "primary" one, maybe it's better to keep it
fixed (it can be made normative in the service protocol specification,
e.g.), otherwise: why are we asking to have TAP_SCHEMA to be name
TAP_SCHEMA? (sorry: joking...).

Cheers,
    Marco

2016-04-19 13:22 GMT+02:00 Mark Taylor <M.B.Taylor at bristol.ac.uk>:
> On Tue, 19 Apr 2016, Markus Demleitner wrote:
>
>> 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.
>
> 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.
>
> However, thinking about it, the TAP service as a whole has a capability
> as well as all its sub-services, so something like:
>
>   <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>
>
> could be used to indicate bundles of related endpoints that share
> a securityMethod and correspond to a TAP service (set-of-endpoints).
> That doesn't stop the individual endpoints being listed explicitly
> as well in the capabilities document, but as a TAP client I'd probably
> ignore those (a client only interested in, e.g., availabilities,
> would still use them).
>
> --
> 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/