It's been pointed out that there are actually two normative references
to OpenID documents in this draft. The second one is
http://openid.net/specs/openid-simple-registration-extension-1_0.html
which is also an XML2RFC document.
There's also a reference to an OASIS standard, whose longevity might
also be considered an open issue.
The RFC Editor has definite concerns about such references (this
came up in today's RFC Editor Advisory Group meeting).
Regards
Brian Carpenter
On 2011-10-17 14:41, Brian E Carpenter wrote:
> 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
