OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Some more feedback:

The first sentence in the Abstract should say "describes" instead of 
"describe."

The phrase "OpenID OAuth Extension" is not consistently capitalized in 
the spec. For instance, it's capitalized in the first sentence in 
section 3, but "extension" is lowercase in section 4.  Sections 5 and 8 
call it the OAuth extension, rather than the OpenID OAuth Extension.

The second word in Section 7, "Requesting" should be all lowercase.

In Section 7, the phrase "this extension can be used to request that the 
end user authorize an OAuth token" should probably be clarified to say 
that the user is authorizing an OAuth Access token.

In the last sentence of Section 8, the phrase "SHOULD not" should be in 
all caps, "SHOULD NOT."

I recommend that the phrase "Combined Consumer" be used instead of 
simply "Consumer" everywhere in the spec. The third paragraph in section 
9, and the description for OAuth token secret in Section 10 still say 
Consumer.

In Section 10, is the Access Token endpoint discoverable? I guess that's 
out of scope for this spec.

In Section 10, and perhaps also in Section 12, the spec should mention 
that because the hybrid protocol does not have a request token secret, 
and because the user is never required to manually type in the request 
token (unlike in OAuth), the hybrid Request Token probably should be 
longer and harder to guess than the standard OAuth Request Token. At 
least for our implementation, I'm thinking that the hybrid RT == OAuth's 
RT+RTSecret.

I think the spec is getting pretty close.

thanks
Allen




Dirk Balfanz wrote:
>
>
>     Otherwise, the spec is looking pretty good!
>
>
> Great! We're officially calling it Draft 1 now :-) (the previous 
> version was Draft 0).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081125/0c597239/attachment-0002.htm>