TAP 1.1 authentication

[Paul Harrison]

> On 2018-09 -13, at 00:01, Patrick Dowler <pdowler.cadc at gmail.com> wrote:
> 
> 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.

I read on with comments not related to whether is is a good idea to register sync/async separately
> 
> 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).
> 
> 


As far as I can see, what that is lost from what you would have originally preferred is the possibility of having different TAPRegext metadata for the sync and async endpoints - but you do not get this with the compromise UWSRegExt proposal anyway - all that you get is to specify the security method as a potential difference - it is beginning to look like no-one actually likes the UWSRegExt compromise as it does not add anything useful at the moment.

In general I think that it is better that an interface gives the same answer for the same input parameters - and whilst I can see that the service implementation might well want a different “outputLimit" for sync and async,  it is already possible to signal this difference in the response overflow, so in a sense that metadata is superfluous for TAP anyway - As a client if you do not know how many answers you are going to get for a particular query, then knowing the outputLimit beforehand does not really help. I do not see anything else in a quick scan of the TAPRegExt metadata that would be different for the sync and async endpoints.

I do agree that if you are going to register the sync/async endpoints separately then the concept in the registry model that the different UWS endpoints most closely correspond to is an interface, so UWSRegExt is needed rather than an attempt to do something with multiple Capabilities, as the Capability maps to the whole TAP service concept. I would have mapped the UWS interfaces differently however in UWSRegExt as the I do not think it is good modelling to have  two different interface sub-types for sync and async, but better to have a single UWS interface type with an attribute saying whether it is sync or async. There is a lot of commonality in the interface behaviour between sync and async that in OO design terms is hidden by having two different subtypes.


Paul.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20180913/c3274992/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1905 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20180913/c3274992/attachment-0001.p7s>