Late RegTAP rr.interface update [was: rr.interface+auth=ouch]

[Markus Demleitner]

Dear Registry,

In the issue of how to sensibly represent securityMethod in RegTAP:

On Mon, Apr 08, 2019 at 12:59:20PM +0200, Markus Demleitner wrote:
> On Fri, Apr 05, 2019 at 02:28:53PM -0700, Patrick Dowler wrote:
> > ** and the interesting change:
> > 
> > - updated ivo://cadc.nrc.ca/sia and ivo://cadc.nrc.ca/tap records to
> > include multiple securityMethod(s) in the accessURL (for sia I only did
> > this in the SIA-2.0 capability); this seems to be schema-valid given that
> > the records refer to VOResource-1.0 but I don't know if/how this kight
> > effect recipients of such records
> > 
> > Let me  know if this works OK or if I need to make any further tweaks,
> 
> As far as I can see, this is fine as such, but it has uncovered an
> issue this poses with RegTAP (and it shows once again we shouldn't
> make anything a REC without implementation. Good thing we caught it
> now).
> 
> In RegTAP 1.0, rr.interface is supposed to have a primary key (ivoid,
> intf_index), where intf_index is something like the sibling index of
> or anything else uniquely identifying the index element.
[...]
> Solution (b)
> ------------
> 
> We could also forget about the de-normalisation and drop the
> security_method_id column in rr.interface; in the proposed sample
> queries, it was only used to filter for "unauth access possible"
> anyway.  For that, we could add a column "open_access" (or a bit more
> provicative, fair_interface:-) to rr.interface, which is true if
> there's an empty securityMethod or none at all, false otherwise.
> 
> And then we wait what kind of discovery problems actually arise in
> the context of authentication and will probably add
> rr.security_method table in RegTAP 1.2.

...I've now put this solution (b) into RegTAP (volute rev. 5385).
The passage central to this issue now reads:

  In VOResource, interfaces can have zero or more \vorent{securityMethod}
  children to convey support for authentication and authorization methods.
  Apart from an identifier for an authentication method, no actual content
  has been specified so far for these elements.  Also, there are as of now
  no actual discovery cases employing this information except ``filter out
  services requiring authentication''.  Hence, RegTAP 1.1 does not attempt
  to map \vorent{securityMethod} except through the
  \rtent{authenticated\_only} column which is required to be 0 when there
  is no \vorent{securityMethod} or at least one \vorent{securityMethod}
  without a \vorent{standardId} on an
  interface, 1 otherwise.

  Clients not prepared to authenticate to services should always include a
  \verb|authenticated_only=0| condition when retrieving access URLs
  from RegTAP 1.1 services, as it is conceivable that a future VO will
  contain many services requiring authentication and users should not have
  to try out which of them they can actually use.

I'm going to roll this out to the reg.g-vo.org services pretty soon
(because they keep shouting at me they don't like CADC's last
update).  I will keep the rr.interface.security_method_id column (at
constant NULL until ~the end of the year, though, in order not to
break clients that may already have adopted the recommendation to
constrain it to NULL from previous versions).

That doesn't mean this is cast in stone.  If you feel this
should be done differently, it would still be great if you could
protest soon, since I'd like RegTAP to go into RFC before Paris.

            -- Markus