SSO v2.0 Proposed Recommendation: Request for Comments

Public discussion page for the IVOA SSO 2.0 Proposed Recommendation.

The latest version of the SSO Specification can be found at:

• http://www.ivoa.net/documents/SSO/20151029/index.html

Comments from the IVOA Community and TCG members during RFC period: 2015-11-01 - 2015-12-13

Comment by Pierre Fernique

1. Are there authenticated services already described in the VO registry ? and if yes, is it already in use ? Can we considered it as a reference implementation ? And in fact, do we have reference implementations ?
2. Author list and editor lists seems to not follow the current usage of IVOA. It is a little bit strange to have all the Grid and Web service group as authors, and 3 editors. Maybe it opens the question concerning the method to keep knowledge of successive editors.
3. I wonder if all complementary sections (short introduction to each authentication method) are really relevant in an IVOA standard. I would suggest to put all normative points in a dedicated section and move all explanation of existing authoritative methods in an general non normative section, or as an appendix.
4. The structuration of section 3 could be modified for avoiding the section 3.1 alone item.
5. Appendix A must have a short introduction to explain what is this long XML schema. The title "VOResource SecurityMethod extract" is definitively not clear.
6. must, may, shall... should be in uppercase in normative sections.

• p1: Andreé => André
• p4: user?s => users
• p4: service?s => service
• p4: Is => If a service
• p6: as having a em Web => ?
• p7: table 1 label strangely folded

Comments from MarkTaylor

I don't have a good enough understanding of security to assess the substance of this document, but I have some editorial comments.

• Sec 1: "... to another service This ..." -> "... to another service. This ..."
• Sec 2.1: "... this element distinguished ..." -> "... this element distinguishes ..."
• Sec 2.2: There are problems with the XML snippets included here. The <interface> start tag in both cases assigns an attribute with the name xmlns:vs: - I'm pretty sure the trailing colon there should be removed. Also, the attribute assignments are quoted with repeated single quotes e.g. xsi:type=''vs:ParamHTTP'' - that looks a bit wrong in the PDF but is definitely wrong in the HTML. Quote using single quotes (or single-character double quotes) instead.
• Sec 2.2: "The order identify the priority ..." -> "The order identifies the priority ..."
• Sec 2.2: "... SAML, than cookies ..." -> "... SAML, then cookies ..."
• Sec 3.1: "... combination of the them" -> "... combination of them." ?
• Table 1: This table lists IVOA Identifiers defined as securityMethod values. These identifiers are in some cases referenced in the mechanism-specific subsections later in the text, but not others, e.g. sec 7.1 says: "Interfaces using this mechanism shall be be registered with the security method ivo://ivoa.net/sso#tls-with-password ." , but there is no corresponding note in the subsections describing cookies, OAuth, SAML or OpenID. Similar notes should be added to the relevant subsections for consistency and clarity.
• Table 1: The HTTP Basic Authentication securityMethod value in this table is missing a colon ( http//www..." ).
• Table 1: Where does the HTTP Basic Auth URI come from? There's no requirement that these URIs are dereferenceable, but using the form http://www.w3.org/Protocols/HTTP/1.0/spec/html#BasicAA which has a different form from the others, looks like it would make sense if that URL was dereferenceable, but it's not. There might be a good answer to this, but I'm interested to know what it is.
• Sec 9.2: "IdP" and "IDP" are both used, are these the same thing?
• Sec 9.2: "SAML2.0 allow also to service discovery mechanisms" - I don't understand what this means.
• Appendix A: Like Pierre, I don't understand what this XML is doing here. Also, the top-level xs:schema element contains the attribute version="1.02" - what's that the version of?

Comments from MarkusDemleitner

In general, I have to admit I am not altogether sure what the function of this standard is -- is it intended to just list authentication methods that people should use in the VO and give them names? If so, I guess much of the prose doesn't serve much purpose, and perhaps the standard would benefit from removing them as the reader wouldn't be led to expect more than such references.

If, on the other hand, the objective is to provide guidance on how to implement services requiring authentication in a VO context, I believe much more practical advice was in order. That, in particular, concerns the mechanisms involving third parties, i.e., SAML and OAuth, and to some degree TLS (insofar as certificates really only make sense with some PKI). Natural questions one might have for those are: Are there IdPs or ASes in use by VO projects? Perhaps even operated by them? What policies do those have? Are ways for discovering them being planned? Can I, as an implementor, freeride on existing authentication infrastructures, and if so, which? Such information could be given in non-normative sections, such that it wouldn't hurt if the infrastructures were taken down.

Another natural question people might expect to see answered if there's "Commentary" in the first place is if, at the time of writing, there was already client support for a given protocol in some VO clients.

Conversely, client authors are probably overwhelmed by the sheer number of protocols "approved" here -- are they expected to implement all of them? If not (and I sure hope there is no such expectation), is there any rational way to decide? Perhaps the document could say something like "if in doubt, implement this and this, and if you're still not satisified, our next choice would be this". This would also give some indication to service implementors which mechanism to choose if they're free to choose.

More concrete issues:

For reasons of nicely formatted references, I'd really prefer if there were actual author names given in the metadata.

p. 6 "Services that are registered with a IVOA registry as having a em WebService type interface..." Apart from the spurious em, I believe this sentence should go in accordance with the change log ("...remove all references to SOAP..."). The WebService interface type in VOResource is annotated with "A Web Service that is describable by a WSDL document", which I take to mean "A SOAP interface" (I am fairly sure that was the intention, anyway).

p. 8 "particular attention" -> ? (particular care? but care for what?)

p. 11 "OAuth is related" -> ?

Does Appendix A actually help? My feeling is that a chapter-exact reference into VOResource would do at least as well. Or perhaps just include generated documentation using the new ivoatex/schemadoc.xslt mechanism (cf. ivoatexDoc in volute trunk).

p. 13 "...methods ad relative..." -> ?

-- MarkusDemleitner - 2015-12-10