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

[Patrick Dowler]

Hmmm. It is always the case that changes in cardinality are the most
disruptive in a database schema or API...

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?

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.

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


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


On Fri, 12 Apr 2019 at 07:44, Theresa Dower <dower at stsci.edu> wrote:

>
> OK, I'm working on re-implementing what we decide here for the ST RegTAP
> service. The current proposal looks fairly straightforward for our ingest
> implementation.
>
>
> I think Markus is right that the RegTAP 1.2 solution is adding another
> table once we understand what further information is really helpful for our
> use cases.
>
>
> I don't like that in *removing* security_method_id we're losing
> information about which security methods each endpoint supports (yes, it's
> just an identifier, not much loss, but still potentially actionable
> information), and expecting client changes at this stage, but given the
> alternatives are changing keys or creating a table that isn't fully defined
> by use cases yet, I don't see a better idea either.
>
>
> --Theresa
>
>
>
> ------------------------------
> *From:* registry-bounces at ivoa.net <registry-bounces at ivoa.net> on behalf
> of Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
> *Sent:* Friday, April 12, 2019 7:09:57 AM
> *To:* registry at ivoa.net
> *Subject:* Late RegTAP rr.interface update [was: rr.interface+auth=ouch]
>
> Dear Registry,
>
> In the issue of how to sensibly represent securityMethod in RegTAP:
>
> On Mon, Apr 08, 2019 at 12:59:20PM +0200, Markus Demleitner wrote:
> > On Fri, Apr 05, 2019 at 02:28:53PM -0700, Patrick Dowler wrote:
> > > ** and the interesting change:
> > >
> > > - updated ivo://cadc.nrc.ca/sia and ivo://cadc.nrc.ca/tap records to
> > > include multiple securityMethod(s) in the accessURL (for sia I only did
> > > this in the SIA-2.0 capability); this seems to be schema-valid given
> that
> > > the records refer to VOResource-1.0 but I don't know if/how this kight
> > > effect recipients of such records
> > >
> > > Let me  know if this works OK or if I need to make any further tweaks,
> >
> > As far as I can see, this is fine as such, but it has uncovered an
> > issue this poses with RegTAP (and it shows once again we shouldn't
> > make anything a REC without implementation. Good thing we caught it
> > now).
> >
> > In RegTAP 1.0, rr.interface is supposed to have a primary key (ivoid,
> > intf_index), where intf_index is something like the sibling index of
> > or anything else uniquely identifying the index element.
> [...]
> > Solution (b)
> > ------------
> >
> > We could also forget about the de-normalisation and drop the
> > security_method_id column in rr.interface; in the proposed sample
> > queries, it was only used to filter for "unauth access possible"
> > anyway.  For that, we could add a column "open_access" (or a bit more
> > provicative, fair_interface:-) to rr.interface, which is true if
> > there's an empty securityMethod or none at all, false otherwise.
> >
> > And then we wait what kind of discovery problems actually arise in
> > the context of authentication and will probably add
> > rr.security_method table in RegTAP 1.2.
>
> ...I've now put this solution (b) into RegTAP (volute rev. 5385).
> The passage central to this issue now reads:
>
>   In VOResource, interfaces can have zero or more \vorent{securityMethod}
>   children to convey support for authentication and authorization methods.
>   Apart from an identifier for an authentication method, no actual content
>   has been specified so far for these elements.  Also, there are as of now
>   no actual discovery cases employing this information except ``filter out
>   services requiring authentication''.  Hence, RegTAP 1.1 does not attempt
>   to map \vorent{securityMethod} except through the
>   \rtent{authenticated\_only} column which is required to be 0 when there
>   is no \vorent{securityMethod} or at least one \vorent{securityMethod}
>   without a \vorent{standardId} on an
>   interface, 1 otherwise.
>
>   Clients not prepared to authenticate to services should always include a
>   \verb|authenticated_only=0| condition when retrieving access URLs
>   from RegTAP 1.1 services, as it is conceivable that a future VO will
>   contain many services requiring authentication and users should not have
>   to try out which of them they can actually use.
>
> I'm going to roll this out to the reg.g-vo.org services pretty soon
> (because they keep shouting at me they don't like CADC's last
> update).  I will keep the rr.interface.security_method_id column (at
> constant NULL until ~the end of the year, though, in order not to
> break clients that may already have adopted the recommendation to
> constrain it to NULL from previous versions).
>
> That doesn't mean this is cast in stone.  If you feel this
> should be done differently, it would still be great if you could
> protest soon, since I'd like RegTAP to go into RFC before Paris.
>
>             -- Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20190412/a8892076/attachment-0001.html>