TAP 1.1 authentication

[Patrick Dowler]

On the whole topic of base URL vs usable endpoints:

I have been convinced for a long time that the whole approach we took in
TAP-1.0 (8+ years ago) was wrong. We did specify that TAP has both sync and
async query execution but we tried to pretend that it was one thing instead
of two things. VOSpace has several different endpoints that behave
differently and they are separate capabilities. If sync and async were just
treated as separate capabilities from the start we would not have this
problem and we don't have this problem with any other services.

On Wed, 12 Sep 2018 at 09:17, Paul Harrison <paul.harrison at manchester.ac.uk>
wrote:
>
and blurs the distinction about what *the* URL of a service is

In my mind this idea is wrong and has always been wrong -- there is no
*the* URL of a (TAP) service that is directly usable (eg that you can POST
to) --  but we (DAL-WG and TAP-1.0 authors) had to make compromises to get
TAP-1.0 to REC. We got the cardinality of
service-capability-interface-accessURL wrong. It is more complicated than
that because you have to just know to append one more special strings to
the path to create usable URLs. That makes TAP special, which is sad when
VOSI-capabilities is perfectly capable of describing endpoints so you don't
need bespoke solutions and knowledge and we have proven that one can write
and use a generic capabilities client to work out all the details.
I am not arguing that it is impossible to comply with VOSI and DALI and
keep a facade of "the URL" in TAP-1.1, but all the things needed to do that
and avoid fixing the mistakes of TAP-1.0 make TAP more special and bespoke
and less like the standard patterns in other services and the spirit of
upstream standards. That means more text, more unforeseen consequences of
that text, and less flexibility to use other standards to the fullest. It
also means more code specific to TAP.

If you still disagree with my claim that there is no "the URL to a TAP
service" and there doesn't need to be one, then stop reading now because
the rest is about how to fix things.

When you realise you made a mistake, the first thing to do is "stop doing
it". Ok, we also need some backwards compatible support for users/clients
:-)

We made a mistake when we said the accessURL for TAP services was the base
and not the usable endpoint(s). In a previous revision of WD-TAP-1.1 we did
define versioned standardID values so one could have a separate capability
for sync and async and this could live along side the old standardID for
TAP-1.0 (which could have the base URL in accessURL). That worked exactly
as well as the interface type mechanism (proven: we implemented both) and
did not require any new stuff and did not break clients (e.g. topcat), but
it would have a side effect of causing some recommended service discovery
queries (RegTAP) return different results (not wrong just different
cardinality). The interface type approach was an agreed way to avoid the
service discovery side effects.

Whether capability types (multiple standardID for TAP-1.1) or interface
types (UWSRegExt note) is better is quite subtle. For the former:
- it is a different type of service endpoint -- a different API -- in a
service with multiple APIs
- you can still use the TAP-1.0 standardID to tell old clients about the
base URL and let them do magic
- you can have different TAPRegExt metadata (eg limits) for sync and async
- con: you have to duplicate common TAPRegExt metadata
- generating a usable URL from registry lookup down involves a convenience
method like: getEndpoint(resourceID, standardID, securityMethod)

For the latter:
- the difference between sync and async is in the behaviour of the REST API
and not in the kind of job; tagging interfaces directly matches that
"different interface to a query job"
- con: introduces new interface type tags (but RegTAP recommended queries
ignore them because they use say ParamHTTP)
- you can still use the TAP-1.0 interface type to tell old clients about
the base URL and let them do magic
- generating a usable URL from registry lookup down involves a convenience
method like: getEndpoint(resourceID, standardID, securityMethod,
interfaceType)

Both of these approaches work, but personally, I liked multiple standardIDs
more than multiple interfaceTypes. Some people didn't (RegTAP compat) so we
discussed and compromised.
Why do I prefer multiple standardIDs? It matches the spirit of "capability"
in upstream standards. It lets you make sync or async (or both) optional
and you have a way to describe which are provided. This exact approach
thing is in REC-SODA-1.0 (sync and async).



Aside: There is some debate still about how much of the capabilities
content should go into the registry vs only in the served document. Suffice
to say: some goes in the registry - and clients that want to do special
stuff will have to check the document if they want to know all the possible
options. TAP-1.1 is not creating this scenario - it already exists because
anyone can put more content in the doc than the registry entry for any
service -- by design!

--
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/863a4e5d/attachment-0001.html>