<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<p><span>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.</span><br>
</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>--Theresa<br>
</p>
<p><br>
</p>
<p><br>
</p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> registry-bounces@ivoa.net <registry-bounces@ivoa.net> on behalf of Markus Demleitner <msdemlei@ari.uni-heidelberg.de><br>
<b>Sent:</b> Friday, April 12, 2019 7:09:57 AM<br>
<b>To:</b> registry@ivoa.net<br>
<b>Subject:</b> Late RegTAP rr.interface update [was: rr.interface+auth=ouch]</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Dear Registry,<br>
<br>
In the issue of how to sensibly represent securityMethod in RegTAP:<br>
<br>
On Mon, Apr 08, 2019 at 12:59:20PM +0200, Markus Demleitner wrote:<br>
> On Fri, Apr 05, 2019 at 02:28:53PM -0700, Patrick Dowler wrote:<br>
> > ** and the interesting change:<br>
> > <br>
> > - updated ivo://cadc.nrc.ca/sia and ivo://cadc.nrc.ca/tap records to<br>
> > include multiple securityMethod(s) in the accessURL (for sia I only did<br>
> > this in the SIA-2.0 capability); this seems to be schema-valid given that<br>
> > the records refer to VOResource-1.0 but I don't know if/how this kight<br>
> > effect recipients of such records<br>
> > <br>
> > Let me know if this works OK or if I need to make any further tweaks,<br>
> <br>
> As far as I can see, this is fine as such, but it has uncovered an<br>
> issue this poses with RegTAP (and it shows once again we shouldn't<br>
> make anything a REC without implementation. Good thing we caught it<br>
> now).<br>
> <br>
> In RegTAP 1.0, rr.interface is supposed to have a primary key (ivoid,<br>
> intf_index), where intf_index is something like the sibling index of<br>
> or anything else uniquely identifying the index element.<br>
[...]<br>
> Solution (b)<br>
> ------------<br>
> <br>
> We could also forget about the de-normalisation and drop the<br>
> security_method_id column in rr.interface; in the proposed sample<br>
> queries, it was only used to filter for "unauth access possible"<br>
> anyway. For that, we could add a column "open_access" (or a bit more<br>
> provicative, fair_interface:-) to rr.interface, which is true if<br>
> there's an empty securityMethod or none at all, false otherwise.<br>
> <br>
> And then we wait what kind of discovery problems actually arise in<br>
> the context of authentication and will probably add<br>
> rr.security_method table in RegTAP 1.2.<br>
<br>
...I've now put this solution (b) into RegTAP (volute rev. 5385).<br>
The passage central to this issue now reads:<br>
<br>
In VOResource, interfaces can have zero or more \vorent{securityMethod}<br>
children to convey support for authentication and authorization methods.<br>
Apart from an identifier for an authentication method, no actual content<br>
has been specified so far for these elements. Also, there are as of now<br>
no actual discovery cases employing this information except ``filter out<br>
services requiring authentication''. Hence, RegTAP 1.1 does not attempt<br>
to map \vorent{securityMethod} except through the<br>
\rtent{authenticated\_only} column which is required to be 0 when there<br>
is no \vorent{securityMethod} or at least one \vorent{securityMethod}<br>
without a \vorent{standardId} on an<br>
interface, 1 otherwise.<br>
<br>
Clients not prepared to authenticate to services should always include a<br>
\verb|authenticated_only=0| condition when retrieving access URLs<br>
from RegTAP 1.1 services, as it is conceivable that a future VO will<br>
contain many services requiring authentication and users should not have<br>
to try out which of them they can actually use.<br>
<br>
I'm going to roll this out to the reg.g-vo.org services pretty soon<br>
(because they keep shouting at me they don't like CADC's last<br>
update). I will keep the rr.interface.security_method_id column (at<br>
constant NULL until ~the end of the year, though, in order not to<br>
break clients that may already have adopted the recommendation to<br>
constrain it to NULL from previous versions).<br>
<br>
That doesn't mean this is cast in stone. If you feel this<br>
should be done differently, it would still be great if you could<br>
protest soon, since I'd like RegTAP to go into RFC before Paris.<br>
<br>
-- Markus<br>
</div>
</span></font>
</body>
</html>