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

[Patrick Dowler]

Incomplete answer:

Our infrastructure where we make use of securityMethod heavily relies on
(i) users already picked which service instance they are interacting with
and (ii) use capabilities to figure out the accessURL to use. So we only
use what could be called a registry discovery query to find the accessURL
of the VOSI-capabiltiies after already knowing the resourceID. We are using
a registry lookup so that users and  system services know about logical
identifiers instead of URLs and we can thus change how we deploy things
with minimal fuss. I would need to think about how it would look to users
when they broaden their usage to "what else can I use?" now that they have
these VO tools in hand... (more to say on this later)

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


--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Mon, 15 Apr 2019 at 04:52, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Hi Pat,
>
> On Fri, Apr 12, 2019 at 12:09:22PM -0700, Patrick Dowler wrote:
> > Having said that, I agree with Theresa that losing information that
> people
> > put into registry records seems wrong. Are there other cases where
> > information in someone's publishing registry does not make it into
> RegTAP?
>
> Quite a few.  Most notably of course most of the complex content in
> TAPRegExt (e.g., user defined functions).  Also, some not-so-complex
> content from *RegExts (like testQuery) are optional (and even where
> not, they're just mapped into res_detail), because nobody
> has found a discovery case for them.  Analogously, the
> testQueryString from VOResource 1.1 interface isn't mapped since it
> seems unlikely people will ever want to do discovery on them.
>
> The case for securityMethod is a bit different, however: I'm sure
> there are discovery cases for it, in particular "Give me all services
> I have credentials for" (supposing there is some sort of federated
> authentication in the VO eventually).  The problem is that with
> current securityMethod modelling, there's no way to answer such a
> query; it simply needs more metadata (essentially something like
> "authentication authority supported" or perhaps even "group
> required", I guess).
>
> Is there a discovery case involving the security method ids (which is
> all we have now)?  I don't really see any.  Will clients want to know
> "all services that use authentication schemes I have code for"?
> Frankly, I'd hope that will never be needed and VO service providers
> will agree on two or three auth schemes so common that all
> self-respecting clients will support all of them.  Any other
> situation will make our users seriously unhappy.
>
> > How bad is it to add the security_method table with just the identifiers
> > now (to preserve that content)?  Then we can use that as a base to
> > prototype what if anything else might go inside a securityMethod element
> > and hence that table... that would probably rule out PR before Paris.
>
> If I believed there's a useful discovery case for that, I'd have
> added it.  But since I don't: It's always so much easier to add
> something than to take something (that's part of a standard) away.
>
> So, if you have something to prototype, just let me know and I'll do
> a table in reg.g-vo.org.  That's quite independent of anything we
> might specify in RegTAP 1.1.
>
> > My personal bet: I don' think anything will go in there and I'd store an
> > array of URI in the interface table but that's opening up a whole
> different
> > can of worms so *waves hands* let's discuss how that sort of thing could
> > work over drinks in Paris :-)
>
> Yeah -- the fattest worm of all being the lack of a non-painful, if
> possible even streamable, way to store arrays of variable-length
> strings in VOTable cells.  If anyone wants to put that on their
> plate, they'd have my heartfelt support.  But meanwhile: Assume you
> have that array: What would you do with it?
>
>           -- Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20190415/18e58b9b/attachment.html>