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)_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
