<div dir="ltr">Hi Pat and all,<div><br></div><div>As there haven't been any objections to this idea, I have added a bit of</div><div>text to the VOSI 1.1 document stating that anonymous access to the</div><div>capabilities and availability must be provided.</div><div><br></div><div>At the end of section 4:<br><br>"The capabilities and availability endpoints must not require any credentials<br>to view. Thus, the interface registry entries for capabilities and availability</div><div>must not contain a securityMethod element."</div><div><br></div><div>I think this is a harmless addition but if you have any comments please</div><div>reply soon--VOSI 1.1 RFC period end is overdue.</div><div><br></div><div>Cheers,</div><div>Brian</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 3, 2016 at 2:08 PM, Patrick Dowler <span dir="ltr"><<a href="mailto:pdowler.cadc@gmail.com" target="_blank">pdowler.cadc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I'm in the process of clarifying some text in WD-TAP-1.1 about the use<br>
of fixed names resources and various authentication mechanisms and it<br>
became clear that the VOSI-availability and VOSI-capabilities<br>
resources must be provided with anonymous access or they are almost<br>
useless.<br>
<br>
For capabilities, the client makes an anonymous call to find out which<br>
resources require authentication and which securityMethod to use, so<br>
this is clearly a bootstrap problem.<br>
<br>
For availablity, I envision a client trying to call a service and<br>
failing and the calling the availability resource to see if the<br>
service is functioning correctly. This helps to disambiguate<br>
authentication failures (beyond simply grok'ing the response codes)<br>
from service failure modes (that are all too real :-). It looks to me<br>
that to be useful anonymous availability has to be available.<br>
<br>
Technically, services could also provide authenticated availability<br>
and capabilities but cannot see any concrete use cases... maybe<br>
performing more extensive availablity checks for certain users or<br>
describing additional capabilities to certain users -- so I would not<br>
disallow this on custom resources.<br>
<br>
So, I would like to maybe simplify TAP to say that anonymous<br>
availability and capabilities must be provided (and on /capabilities<br>
for the latter) and I think this could be added to VOSI-1.1 and only<br>
referenced from TAP.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
--<br>
Patrick Dowler<br>
Canadian Astronomy Data Centre<br>
Victoria, BC, Canada<br>
</font></span></blockquote></div><br></div></div></div>