RegTAP 1.1, updated PR

[Mark Taylor]

On Tue, 7 May 2019, Markus Demleitner wrote:

> 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).

Direct communication yes if you already know who has authenticated
services.  In principle, RegTAP query caters for the case when you
know/suspect there are authenticated services out there, but not
who owns them.  In practice of course, just emailing CADC solves
the problem for ... now?  ... the forseeable future?

> 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.

That's what I thought, but the note in Appendix D.1

   "We're still not re-requiring the corresponding res_detail key;
    there are simply no clear use cases on all of this yet, and there's
    been enough back and forth (not to mention that res_details doesn't
    really work for information in interface anyway)."

suggested you'd considered and rejected the idea.  Anyway:

> I've hence re-added it to appendix A (volute rev. 5432), but it's no

thanks.

> 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.

Noted; I'm not planning on writing automated queries based on
that part of the schema, just occasionally making such queries
by hand.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/