Resolving old errata: security methods in interfaces

[Brian Major]

Hi Theresa,

Thanks for sending this out and thanks Markus for writing it up.  The
erratum looks good to me and is in line with the 'single URL' for a service
approach.  There's one point in there that I'd like to highlight for the
GWS members concerning the advertisement of an interface that allows
anonymous access.  The updated version of the comment for the
securityMethod element reads:

    "A missing securityMethod child indicates an interface usable without
authentication. In the presence of at least one securityMethod element,
services indicate the possibility of unauthenticated access using an empty
securityMethod element (i.e., one without standardID)".

So, interfaces with both anonymous and authenticated access will have a set
of securityMethod elements with one empty one.  For example:

<securityMethod />
<securityMethod standardID="ivo://ivoa.net/sso#cookie" />
<securityMethod standardID="ivo://ivoa.net/sso#tls-with-certificate" />

Regards,
Brian

On Fri, Mar 29, 2019 at 9:58 AM Theresa Dower <dower at stsci.edu> wrote:

> Registry et al,
>
>
> There are several proposed Registry-related errata that I would like to be
> finalized soon if possible. One relates to capabilities and interfaces and
> therefore VOSI (and therefore DAL and GWS).
>
>
> This change is to VOResource 1.1, which re-enables multiple security
> methods per interface. This is merely a return to  VOResource 1.0
> expectations and thus potentially small enough to do in the errata process
> and is needed for  RegTAP 1.1 and potentially other existing client issues.
>
>
> https://wiki.ivoa.net/twiki/bin/view/IVOA/VOResource-1_1-Erratum-1
>
>
> If anyone sees any egregious problems with this, please respond on list so
> we can resolve things before the interop?
>
>
> Thanks so much,
>
> --Theresa
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20190329/bd1c1ee3/attachment.html>