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

[Dirk Balfanz]

On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom <atom at yahoo-inc.com> wrote:

>  Some more feedback:
>
> The first sentence in the Abstract should say "describes" instead of
> "describe."
>

Done.


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

Done.


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

Done.


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

Done. This assumes that "authorizing an access token" is the same as
"approving a request token that can be exchanged for an access token".


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

Done.


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

Done.


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

Yes it should be discoverable, but we don't know yet how that will work.
According to Eran, The Right Way to do this is provide meta-data for the
OpenID endpoint, and have that point to the access token endpoint. So you
would serve something like this as the meta-data for your actual OpenID
endpoint:

<XRD>
  <Type>http://specs.openid.net/auth/2.0/server</Type>
  <Type>http://specs.openid.net/extensions/oauth/1.0</Type>

  <Service>
    <Type>http://oauth.net/core/1.0/endpoint/access</Type>
    <URI>http://url-of-the-access-token-endpoint/</URI>
  </Service>
<XRD>

But this kind of stuff has yet to gel in the various committees looking at
discovery. As far as I know, in current versions of XRD(S), you can't have
<Type> elements underneath <XRD> elements. Once that's all sorted out, we
should probably include it in the spec. Although it might be that it falls
out automatically out of XRD in general and OAuth discovery in particular,
i.e. we would basically just have to remind the reader of how to put those
other pieces together to make the access token endpoint discoverable.



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

But you need to have the consumer secret to exchange it, no? What if it were
just a incrementing integer? What would the attack be?


>
>
> I think the spec is getting pretty close.
>

Thanks again, Allen - this is really helpful!

Dirk.


>
> 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/20081126/412269fa/attachment-0001.htm>