TAP 1.1 authentication

[Patrick Dowler]

On duplicating the VOSI-capabilities deployment: sure you can do that but
it makes the service deployment more complicated and means service
providers have to write more tests to verify their service is working
correctly. And when they register the service in an IVOA registry, which
accessURL do they put? Obviously any would do since they are redundant, but
someone has to document that and people have to understand that. It's
smelly and it is not in the spirit of the DALI sibling rule which is that
service endpoints are flat and not heirarchical.

On describing VOSI endpoints in the VOSI-capabilities doc: for services in
general you need to do it because VOSI-availability is optional and has an
arbitrary accessURL, VOSI-tables is optional (and there are use cases for
both anon and auth). I agree that the VOSI-capabilities capability in the
document is redundant (you know the url because you git the document) but
that capability *does* have to be in the IVOA registry so we always just
include it  in the doc for completeness (heh - tap_schema describes itself,
gcc in written in C, so why not here :-)

I will think about and respond to the main point. separately.

Pat

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


On Wed, 12 Sep 2018 at 09:17, Paul Harrison <paul.harrison at manchester.ac.uk>
wrote:

>
>
> On 2018-09 -12, at 13:35, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
>
> Then there's no need to register all those sync and async
> endpoints explicitly and no need for UWSRegExt.
>
> The rest of the capabilities document could look substantially
> the same as the current example, but with the additional rule
> (analogous to the constraints already in TAP 1.0) that the other
> declared auth-specific endpoints (tables and examples as well
> as capabilities) MUST be located in the standard positions
> relative to the corresponding auth-specific TAP base URL.
>
> Then the 'child rule', as well as the sibling rule, works.
>
> I think this is more or less what Paul was saying.
>
>
> Yes - this is what I am saying (and at first I did not realise that you
> had said it before me in the RFC) - it seems much easier to me, and more in
> keeping with the “spirit” of the original registry data model anyway.
>
>
> To summarise: duplicating the capabilities document at auth-specific
> endpoints means you don't need to break the sibling rule, and
> hierarchical endpoint naming can be preserved, which I contend
> (and Paul has also argued) is a Good Thing.
>
>
> I still think that it is better to do this way not only from the point of
> view that it keeps things simple, but also that it allows for the
> possibility that the /tableMetadata endpoint content should be different
> for the authenticated service anyway.
>
>
> Am I missing something?
>
>
> An argument that might be used is that for the original SimpleXX v1.0
> services there is an established use of the 'sibling rule' to find the
> capabilities endpoint (though there was no technical reason why a “child
> rule” could not have been adopted instead)
>
> As far as I can see if you are handed a URL as a client and you have no
> idea what it is pointing to then you can try both the child and the sibling
> rules to find the capabilities endpoint to find out what service it is. In
> reality you will most often know what service the URL represents and your
> client can do the right thing (child for TAP 1.0, sibling for SIA 1.0 -
> though of course if you know what the service is then you don’t need to
> find the capabilities endpoint!)  - it should be noted that this is the
> *current* state of affairs anyway, TAP 1.1 is trying to introduce a new
> more complicated regime where you have to always read the capabilities
> endpoint to understand what to do, and blurs the distinction about what
> *the* URL of a service is that I can cut and paste into an email/twitter
> message etc. The only sensible answer then is that the capabilities
> endpoint is *the* URL, but then there is an asymmetry with searching a
> registry for a service where it is wasteful finding the URL of the
> capabilities endpoint of a service rather than directly the service
> endpoint….
>
> I actually question whether there is any value in putting the VOSI
> endpoints themselves in the capabilities endpoint content and registering
> them - it seems superfluous (apart from /availability, which could be a
> redirect anyway by modern DALI conventions) as they are supposed to be
> fixed anyway.
>
>
> Paul.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20180912/6566c0c0/attachment.html>