<div dir="ltr"><div class="gmail_default" style="font-size:small">Incomplete answer:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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 &quot;what else can I use?&quot; now that they have these VO tools in hand... (more to say on this later)<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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 &quot;don&#39;t need to register all the interface/securityMethod combinations&quot; and would continue if we didn&#39;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&#39;s actually in use, depending on what gets captured in the relational mapping. I think we will want that information in the future.</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 Mon, 15 Apr 2019 at 04:52, Markus Demleitner &lt;<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>&gt; 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">Hi Pat,<br>
<br>
On Fri, Apr 12, 2019 at 12:09:22PM -0700, Patrick Dowler wrote:<br>
&gt; Having said that, I agree with Theresa that losing information that people<br>
&gt; put into registry records seems wrong. Are there other cases where<br>
&gt; information in someone&#39;s publishing registry does not make it into RegTAP?<br>
<br>
Quite a few.  Most notably of course most of the complex content in<br>
TAPRegExt (e.g., user defined functions).  Also, some not-so-complex<br>
content from *RegExts (like testQuery) are optional (and even where<br>
not, they&#39;re just mapped into res_detail), because nobody<br>
has found a discovery case for them.  Analogously, the<br>
testQueryString from VOResource 1.1 interface isn&#39;t mapped since it<br>
seems unlikely people will ever want to do discovery on them.<br>
<br>
The case for securityMethod is a bit different, however: I&#39;m sure<br>
there are discovery cases for it, in particular &quot;Give me all services<br>
I have credentials for&quot; (supposing there is some sort of federated<br>
authentication in the VO eventually).  The problem is that with<br>
current securityMethod modelling, there&#39;s no way to answer such a<br>
query; it simply needs more metadata (essentially something like<br>
&quot;authentication authority supported&quot; or perhaps even &quot;group<br>
required&quot;, I guess).<br>
<br>
Is there a discovery case involving the security method ids (which is<br>
all we have now)?  I don&#39;t really see any.  Will clients want to know<br>
&quot;all services that use authentication schemes I have code for&quot;?<br>
Frankly, I&#39;d hope that will never be needed and VO service providers<br>
will agree on two or three auth schemes so common that all<br>
self-respecting clients will support all of them.  Any other<br>
situation will make our users seriously unhappy.<br>
<br>
&gt; How bad is it to add the security_method table with just the identifiers<br>
&gt; now (to preserve that content)?  Then we can use that as a base to<br>
&gt; prototype what if anything else might go inside a securityMethod element<br>
&gt; and hence that table... that would probably rule out PR before Paris.<br>
<br>
If I believed there&#39;s a useful discovery case for that, I&#39;d have<br>
added it.  But since I don&#39;t: It&#39;s always so much easier to add<br>
something than to take something (that&#39;s part of a standard) away.<br>
<br>
So, if you have something to prototype, just let me know and I&#39;ll do<br>
a table in <a href="http://reg.g-vo.org" rel="noreferrer" target="_blank">reg.g-vo.org</a>.  That&#39;s quite independent of anything we<br>
might specify in RegTAP 1.1.<br>
<br>
&gt; My personal bet: I don&#39; think anything will go in there and I&#39;d store an<br>
&gt; array of URI in the interface table but that&#39;s opening up a whole different<br>
&gt; can of worms so *waves hands* let&#39;s discuss how that sort of thing could<br>
&gt; work over drinks in Paris :-)<br>
<br>
Yeah -- the fattest worm of all being the lack of a non-painful, if<br>
possible even streamable, way to store arrays of variable-length<br>
strings in VOTable cells.  If anyone wants to put that on their<br>
plate, they&#39;d have my heartfelt support.  But meanwhile: Assume you<br>
have that array: What would you do with it?<br>
<br>
          -- Markus<br>
</blockquote></div>