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).
_______________________________________________
specs mailing list
[email protected]
http://openid.net/mailman/listinfo/specs
