<div dir="ltr"><div class="gmail_default" style="font-size:small">Hmmm. It is always the case that changes in cardinality are the most disruptive in a database schema or API...</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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? <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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 :-)<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 12 Apr 2019 at 07:44, Theresa Dower <<a href="mailto:dower@stsci.edu">dower@stsci.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr">
<div id="gmail-m_1623695440676944808x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);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 style="display:inline-block;width:98%">
<div id="gmail-m_1623695440676944808x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> <a href="mailto:registry-bounces@ivoa.net" target="_blank">registry-bounces@ivoa.net</a> <<a href="mailto:registry-bounces@ivoa.net" target="_blank">registry-bounces@ivoa.net</a>> on behalf of Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>><br>
<b>Sent:</b> Friday, April 12, 2019 7:09:57 AM<br>
<b>To:</b> <a href="mailto:registry@ivoa.net" target="_blank">registry@ivoa.net</a><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="gmail-m_1623695440676944808PlainText">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://<a href="http://cadc.nrc.ca/sia" target="_blank">cadc.nrc.ca/sia</a> and ivo://<a href="http://cadc.nrc.ca/tap" target="_blank">cadc.nrc.ca/tap</a> 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 <a href="http://reg.g-vo.org" target="_blank">reg.g-vo.org</a> 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>
</div>
</blockquote></div>