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

[Theresa Dower]

Following up on this after having a chance to play with some code and speak with Pat:


So long as we keep the ability to share the security_method information in the detail table, an existing operational discovery case is met. NAVO's validation/uptime monitor is already using information in the detail table for test queries where available; a similar search seems possible. (Though it does raise a question of whether we can, even in some convoluted way, query through the various cap and intf indices in res_detail for test queries associated with particular security methods, and I haven't yet tried.)


The current proposal to add a bit flag (effectively) column per interface for having unauthenticated access or not gives today's clients the info we need today for discovering unsecured/public-access endpoints. We won't be able to remove it without a major version change. That change could be paired with creating a full table for security method information if it turns out we need it (or technically we could add the table in a minor rev and leave the redundant data, which smells). Are we OK with this? I think the most involved parties are, if anyone else wants to speak up, please do. We are still hoping to call this done in Paris.


Cheers,

--Theresa

________________________________
From: registry-bounces at ivoa.net <registry-bounces at ivoa.net> on behalf of Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
Sent: Tuesday, April 16, 2019 3:31:57 AM
To: registry at ivoa.net
Subject: Re: Late RegTAP rr.interface update [was: rr.interface+auth=ouch]

Hi Pat,

On Mon, Apr 15, 2019 at 08:31:47AM -0700, Patrick Dowler wrote:
> A side issue: we have had what I think are under-informed discussions about
> what services actually implement and which securityMethod(s) are actually
> in use in the past. That started from "don't need to register all the

I'm pretty sure there simply haven't been any securityMethods defined
for many years (except for, IIRC, some astrogrid VOSpace that's now
disappeared) in records that made it to the VO Registry.

I know that because RegTAP 1.0 (optionally) mapped securityMethod to
the

/capability/interface/securityMethod/@standardID

rr.res_details key.  RegTAP 1.1 still lets you do that, and
http://dc.g-vo.org/tap (for instance) does.  So, you can run

  select *
  from rr.res_detail
  where detail_xpath like '%securityMethod%'

and see what's there.

> interface/securityMethod combinations" and would continue if we didn't
> capture the set of securityMethod(s) that services used in RegTAP. Then
> later on we either can or cannot use RegTAP to see what's actually in use,
> depending on what gets captured in the relational mapping. I think we will
> want that information in the future.

So do I; but for this kind of research, we can always just locate the
records that have nonempty securityMethods and pull their full
records from an OAI-PMH endpoint.  At least until we've figured out
what to do with this information on the client side (and, more
critically, what information that is), I don't expect there's going
to be prohibitively many such records.

I guess my point is that I feel "research-level statistics" isn't
quite a sufficient use case for mapping something into RegTAP
("operational statistics" might be a different matter, though).

         -- Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20190424/8f0b86b8/attachment.html>