DAL/GWS/Registry - splinter session report

This splinter was initially decided to allow specific discussion on the TAP-1.1 authenticated endpoints issue arisen during the RFC period of the TAP-1.1 PR document.

The decision was taken quite quickly (thanks also the direct discussion among the interested parties). The solution is to ripristinate what the proposal number 2 from Pat Dowler's talk in the joint session. This means separate standardId(s) fro sync/async resurces in the capabilities document. A roadmap to implement this was decided and will start just after the interops ending.

Related to this decision were then discussed the impact on TAPRegExt specification, that will be asked to be updated accordingly as soon as the TAP-1.1 contiunes is path towards REC. The solution of merging TAP & TAPRegExt documents into a single specification is left as a subsequent revision not to add unpredictable items to the already critical schedule.

Also the issue with the, VOResource-1.1 introduced, mirrorURL element was taken into discussion. This mirrorURL element has unsufficient annotation to clearly allow for bundling mirrored resources based upon server location. Nonetheless the title attribute it allows for can be used to temporarily vercome the solution (and VOResource-1.1 text seems to allow this solution). The solution to have common values for the title attribute for resources originatig from the same location was then agreed upon and, together with a more general description on how to properly use VOSI endpoints for authenticated bundles in access protocols, will be described in an (Endorsed) Note to be prepared by the GWS-WG.

Another point discussed was about the difficulty in providing humans in front of browsers with an entry point to TAP services, whose API is meant mainly for machine actionability. This touched mainly 3 points. First, the baseURL response (its usage will be clarified in the TAP-1.1 text) to become browsable and contain information for users, thus allowing for quick opy/paste sharing on the net. Second, the capabilities endpoint to have, in the future, some basic rendering style to be human-readable. Third, the examples endpoint to be used as an entry point to researchers who want to understand how to use the service. Apart from the first point, the other two will probably see a light in the specification only in future revisions.

Finally, given some time was still available, authentication using OAuth2+tokens, also usable for non-browser-based appications, was shown from LSST experience and discussed upon.

-- MarcoMolinaro - 2018-11-11