RegTAP 1.1, updated PR

[Markus Demleitner]

Hi Mark,

On Mon, May 06, 2019 at 09:40:07AM +0000, Mark Taylor wrote:
> I can think of one discovery use case for securityMethod that
> is not satisfied by authenticated_only: client developers looking
> for services with diverse security methods against which they can
> test their software.  This is not a very important use case,

Conceivably.  Of course, *I*'d expect this kind of discovery to be
effected through direct interaction between the service operator and
the client developer (or perhaps the DAL list).

But ok, even if it's not a huge use case, if it's cheap to satisfy,
I'm in.

> In absence of the security_method_id in rr.interface, I'd expect to see
> a rr.res_details key /capability/interface/securityMethod/@standardID
> listed in Appendix A, but the note in the change log Appendix D.1
> says you've decided not to do that.  Does the existence of this use
> case make a difference?

Partly.  But of course I should have re-added this key anyway, as
when the security_method_id column is gone again, it's now an
unmapped VOResource feature that marginally fits what res_detail can
do.

I've hence re-added it to appendix A (volute rev. 5432), but it's no
longer mandatory as in TAP 1.0; I'm still sure that once we figure
out what we need for interoperable federated authentication, we'll
probably have to touch RegTAP's mapping of securityMethod anyway, so
I'd like to discourage clients from trying to hack on using
res_detail in that department.

It's been in reg.g-vo.org all along if you want to play:

  select count(*) 
  from rr.res_detail 
  where detail_xpath='/capability/interface/securityMethod/@standardID';

currently gives 33 there.  Admittedly, it's essentially CADC only
that these come from.  So, if you know someone with registerable
authenticated services: Ask them to put in securityMethod!

      -- Markus