RegTAP 1.1 implementation - was late rr.interface update

[Theresa Dower]

Just a note that the STScI fully searchable registry is now running RegTAP 1.1 operationally, using this latest version of the spec. This makes for two reference implementations and a general consensus, so we're set for RFC in Paris. (and I hope to see many of you there.)


--Theresa

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

Hi Theresa,

On Wed, Apr 24, 2019 at 04:41:52PM +0000, Theresa Dower wrote:
> 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.)

With the traditional model of test queries attached to capabilities
that's implied -- the same test query is expected to run on each
interface (which becomes somewhat questionable with SSA's
queryDataCmd, but then I don't see we'll ever have something other
than vs:ParamHTTP for SSA).

With VOResource 1.1, people can attach testQueryStrings to interfaces
(where they, really, belong).  RegTAP 1.1 doesn't (properly) map
these, the logic being that they aren't really user interface (we
could still change this, claiming validators are users, too).  If I
ran a validator with the current draft, I'd add a local
test_query_string column to my rr.interface table.

> 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

I don't think we should remove it later, as I suspect the use case we
have for it now will stay dominant.  If and when we will have
finer-grained auth info later, I expect replicating with it what we'd
do with authenticated_only now will be more fuss for clients than
keeping the column will be for RegTAP services.  So: I'd argue it
should be there for... well, what part of eternity we can reasonably
predict.

> 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

I give you there is a slight odour in the air above
authenticated_only and a future rr.security_method table.  But I'd
say it's still safely on the good side of the fragnance-stink
line.

       -- Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20190503/542ba338/attachment.html>