Difference: SSO20RFC (7 vs. 8)

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:

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

Reply to Pierre Comments

Thans Pierre for your comments and suggestions

1. Question (1): According to my query to the Registry there are some services that are using the “security methods”, in fact this is an update of an existing recommendation and we are not modifying the resource schema. They are mainly VOSpace implementations (one of them is the Canadian one). However, I am not sure that this kind of document requires a “reference implementation”, in fact this document is a profile against existing security standards, we are proposing a way standards apply in the framework of the VO. This means that we want to identify a way services requiring authentication advertise that clients and we want identify and eventually rank a sub set of the authentication protocols available.
2. I used the format of the previous SSO document, however I agree with you so now I provide a list of Authors and one Editor
3. We try to keep the same format as the old version, and being a profile against existing security standards, we think it is important (especially for application developers) to have also non normative sections. To be consistent with the original document I would rather prefer to keep this format.
4. I modify the document according yo your suggestion
5. The appendix is just an extract of the VOResource description. As requested by the GWS, we include a copy of the XML schema for the SecurityMethod element. I change the Appendix name and I add also a short introduction, however I think that it could also be removed.
   

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.

1. Sec 1: "... to another service This ..." -> "... to another service. This ..."
2. Sec 2.1: "... this element distinguished ..." -> "... this element distinguishes ..."
3. 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.
4. Sec 2.2: "The order identify the priority ..." -> "The order identifies the priority ..."
5. Sec 2.2: "... SAML, than cookies ..." -> "... SAML, then cookies ..."
6. Sec 3.1: "... combination of the them" -> "... combination of them." ?
7. 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.
8. Table 1: The HTTP Basic Authentication securityMethod value in this table is missing a colon ( http//www..." ).
9. 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.
10. Sec 9.2: "IdP" and "IDP" are both used, are these the same thing?
11. Sec 9.2: "SAML2.0 allow also to service discovery mechanisms" - I don't understand what this means.
12. Appendix A: I can reply as I did above for Pierre question. The appendix is just an extract of the VOResource description. As requested by the GWS, we include a copy of the XML schema for the SecurityMethod element. I change the Appendix name and I add also a short introduction, however I think that it could also be removed.

Reply to Mark questions

Thanks for your comments and suggestions. I correct all the typos following your suggestions.

3. Thanks, that was a typo introduced converting from word to latex.

7. I modify the text to be consistent.

9. Sorry, the URL is actually dereferenceable but there was a typo. The correct url is https://www.w3.org/Protocols/HTTP/1.0/spec.html#BasicAA

12.

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?

As I explained to Pierre that was a request from GWS WG (see the above answer).

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

Reply to Marcus

Thanks Markus for your suggestions

The idea of this document is to provide a reference to existing standards for authentication that can be used when we require access to private “data”. Actually this SecutiryMethod is used by VOSpace services, but it is not limited to it (see. Eg. CADC services). So the VOSpace clients are using and implementing some of those protocols. As you said we can include in the Commentary if there is an implementation, I am not sure that this document is the right place to do that.

I do not think that the way the authentication policies are implemented by a project (even a VO project) should be discussed in this document, it is a decision to make at a project level, even if we want to operate a IdP or just a SP, depends on project (data center) decisions. Than, the policies in fact do not affect the protocol, the once a service tells a client that it requires tls-with-password, the client should be able to start a TLS communication and send a username/password. Both of these actions are fully documented in the rfc we cite in the document. The SecurityMethod is a way to advertise the client (or other services) and it is already in place in the Registry.

I agree that “ranking” the SecurityMethods could be useful for someone needs to implement a new service, so we add a final commentary with some suggestions.

Comments from TCG members during the TCG Review Period: 2015-12-01 - 2016-01-15

WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard.

IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.

TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )

Applications Working Group ( _Pierre Fernique, Tom Donaldson )

Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )

Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )

Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )

Registry Working Group ( _Markus Demleitner, Theresa Dower )

Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )

Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )

Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )

Data Curation & Preservation Interest Group ( Françoise Genova )

Operations Interest Group ( _Tom McGlynn, Mark Taylor )

Knowledge Discovery in Databases Interest Group ( George Djorgovski )

Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo )

Standards and Processes Committee ( Françoise Genova)

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->