Please see attached review. I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-kitten-sasl-openid-06.txt Reviewer: Brian Carpenter Review Date: 2011-10-17 IETF LC End Date: 2011-10-25 IESG Telechat date: Summary: On track but has open issues -------- I don't have any comment on the technical specification as such, but there are some points that need attention IMHO: Major issues: ------------- > 2.1. Binding SASL to OpenID in the Relying Party > > To ensure that a specific request is bound, and in particular to ease > interprocess communication, it may be necessary for the relying party > to encode some sort of nonce or transaction-id in the URIs it > transmits through the client for success or failure. This can be > done in any number of ways. Examples would include making changes to > the base URI or otherwise including an additional fragment. "some sort of..." "any number of ways" This is very loose language for a standards-track draft. I don't know what to suggest but it just seems too vague as it is. If all you can actually specify is a transport mechanism, then shouldn't the specification avoid hand-waving on other matters? > 2.2. Discussion > > As mentioned above OpenID is primarily designed to interact with web- > based applications. Portions of the authentication stream are only > defined in the crudest sense. That is, when one is prompted to > approve or disapprove an authentication, anything that one might find > on a browser is allowed, including JavaScript, fancy style-sheets, > etc. Because of this lack of structure, implementations will need to > invoke a fairly rich browser in order to ensure that the > authentication can be completed. Errm what? "Fairly rich" is a useless statement from a specification PoV. And in any case, Section 2 is "Applicability for non-HTTP Use Cases", so I don't understand what JS, style-sheets or browsers have to do with it. > Once there is an outcome, the SASL server needs to know about it. > The astute will hopefully by now have noticed an "=" client SASL > response. This is not to say that nothing is happening, but rather > that authentication flow has shifted from SASL to OpenID, and will > return when the server has an outcome to hand to the client. The > alternative to this flow is some signal from the HTML browser to the > SASL client of the results that is in turn passed to the SASL server. > The IPC issue this raises is substantial. Better, we conclude, to > externalize the authentication to the browser, and have an "=" client > response. The second sentence seems to be missing a noun after "astute". But more profoundly, this paragraph really isn't OK for a technical specification. It mixes up a vague explanation of server behaviour with an imprecise discussion of a solution not adopted. Could the paragraph be rewritten in a style that will help an implementor write code? Is it saying that on receipt of an "=" response the server should continue to wait? If it isn't conveying something like that, I suspect that this paragraph is white noise. > 10.1. Normative References > > [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", > December 2007. The IESG needs to decide whether reference [OpenID] meets the requirements of Section 7 of RFC 2026. This should be mentioned in the writeup, but the it isn't in the tracker yet. Assuming that http://openid.net/specs/openid-authentication-2_0.html is the intended document, this seems like a case where the URL should be included in the reference. However - since that document was manifestly generated by xml2rfc, including RFC 2119 language and Normative References, the question does arise whether this isn't a backdoor "standardification" of OpenID. Why is kitten-sasl-openid on the standards track when it depends on a document that clearly could have been proposed as standards track but wasn't? Minor issues ------------ > 2. Applicability for non-HTTP Use Cases > > OpenID was originally envisioned for HTTP [RFC2616] and HTML > [W3C.REC-html401-19991224] based communications, and with the > associated semantic, the idea being that the user would be redirected > by the Relying Party to an identity provider who authenticates the > user, and then sends identity information and other attributes > (either directly or indirectly) to the Relying Party. The identity > provider in the OpenID specifications is referred to as an OpenID > Provider (OP). The actual protocol flow, as copied from the OpenID > 2.0 specification, is as follows: Does the IETF have permission to use this copied material under RFC 5378 conditions? > 4. OpenID GSS-API Mechanism Specification ... > The GSS-API mechanism OID for OpenID is OID-TBD (IANA to assign: see > IANA considerations). I suggest inserting a literal instance of "OID-TBD" in the IANA Considerations text too. idnits says: -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120)