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

[Eliot Lear <[e-mail]>]

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