OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Breno de Medeiros
breno at google.com
Tue Nov 18 20:00:37 UTC 2008
You have some references like "in Section 5." Please change them to
"in Section 5 of the OAuth Spec".
On Tue, Nov 18, 2008 at 11:56 AM, Dirk Balfanz <balfanz at google.com> wrote:
> Ok, new spec is up:
> On Mon, Nov 17, 2008 at 5:40 PM, Dirk Balfanz <balfanz at google.com> wrote:
>> [+Brian Eaton]
>> On Mon, Nov 17, 2008 at 4:31 PM, Allen Tom <atom at yahoo-inc.com> wrote:
>>> Sadly, because the OpenID authentication request is not signed, the CK
>>> can't be authenticated, but as you pointed out, although the user may
>>> authorize the application, the CK secret is still required to fetch the
>>> credentials. The worst that could happen is that a user will authorize an
>>> impostor, but the impostor will not be able to retrieve the token.
>>> That being said, in our case, the CK contains additional information
>>> besides the scope. Yahoo's OAuth Permissions screen contains a lot of rich
>>> information including the application's name, description, developer(s),
>>> images, authorization lifetimes, etc. Over time, new fields may be added to
>>> the approval page.
>>> While it might make sense for the application's scope to be passed in at
>>> authorization time, does it also make sense to define new parameters for all
>>> the other application specific metadata? The actual data that needs to be
>>> displayed on an approval page is very SP specific, and some SPs may have
>>> security/legal policies requiring that all metadata is manually reviewed,
>>> which makes it impossible for metadata to be passed in at runtime.
>> Oh I see. Ok. I'l make a new revision of the spec where I add a required
>> parameter (the consumer key) to the auth request.
>> What should the spec recommend the OP should do if the consumer key and
>> realm don't match? Return a cancel? Return something else?
>> Another change I'll be making is to take out references to unregistered
>> consumers. Brian found a weakness in our approach (the one where we make the
>> association secret the consumer secret) that makes me think we need to think
>> about unregistered consumers a bit more.
>>  Basically, the problem is that we have oracles around the web that add
>> OAuth signatures to arbitrary requests. They're called OpenSocial gadget
>> containers. If and when OpenID signatures and OAuth signatures converge,
>> with the current propocal we might end up in a situation where my gadget
>> container will create OAuth signatures using the same key needed to assert
>> auth responses.
>>> So that's why SPs may need the CK in order to display the Approval page.
>>> Make sense?
>>> Dirk Balfanz wrote:
>>>> Need to know the CK for what? What purpose would hinting at the CK serve
>>>> (since it wouldn't prove ownership)? And don't say "scope" :-)
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
More information about the specs