Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-kitten-sasl-openid-06.txt

From: Eliot Lear <[email-masked]>
Date: Fri, 04 Nov 2011 11:28:06 +0100

Hi Brian,

Apologies for the belated review.  Please see comments below.

On 7/22/64 8:33 PM, Brian E Carpenter wrote:
> Please see attached review.

>
> "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?

The issue is that OpenID was designed where you could serialize with
cookies.  You can't do that with a non-browser app in the middle. 
Still, the matter is internal to the RP.  There is no need for the
information to be interpreted by other parties, and as such we ought not
specify its form.  If you would like I can add some text around this
since it seems to be a point of confusion.

> > 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.

The whole point of this mechanism is for non-browser apps to leverage
browsers for their authentication.  Note that you are quoting
"discussion", and that any implementer would understand the context of
what that means (especially given the previous sentence).

> 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?

We fixed the nit.  However, your profound comment is directed at
"Discussion".  A precise normative specification  as well as an example
follows below the above text.

> 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?

No attempt is made here to "back door" standardize OpenID, but rather to
simply make it available to SASL applications.

Eliot

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 04 Nov 2011 11:16:43 +0000

>>Please see attached review.
 [...]

>since it seems to be a point of confusion.
IMHO, I think some text in this area would be helpful.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Nov 2011 17:38:26 +1300

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Nov 2011 05:28:02 +0000

> came up in today's RFC Editor Advisory Group meeting).

Thanks Brian,

Sandy mailed and said that Olaf/Nevil had some ideas about
how to handle this and would get in touch, so I guess we'll
see what they think and go from there,

Cheers,
S