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)