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

Breno de Medeiros breno at google.com
Tue Nov 18 20:50:25 UTC 2008


On Tue, Nov 18, 2008 at 12:44 PM, Dirk Balfanz <balfanz at google.com> wrote:
>
> On Tue, Nov 18, 2008 at 12:00 PM, Breno de Medeiros <breno at google.com>
> wrote:
>>
>> You have some references like "in Section 5." Please change them to
>> "in Section 5 of the OAuth Spec".
>
> But then it would be pointing to the wrong thing :-)
>
> "in Section 5" means Section 5 of the document the reader is currently
> reading.

Well, the current wording is confusing: "consumer key agreed upon in
Section 5 (Before Requesting Authentication - Registration). ". We did
not do anything in Section 5, except vaguely defer to the OAuth spec.
Something like "consumer key, described in Section 5 (...)."

>
> Dirk.
>
>>
>> On Tue, Nov 18, 2008 at 11:56 AM, Dirk Balfanz <balfanz at google.com> wrote:
>> > Ok, new spec is up:
>> >
>> > http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html
>> >
>> > Dirk.
>> >
>> > 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[1].
>> >>
>> >> Dirk.
>> >>
>> >> [1] 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?
>> >>>
>> >>> Allen
>> >>>
>> >>>
>> >>>
>> >>> 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" :-)
>> >>>>
>> >>>
>> >>
>> >
>> >
>>
>>
>>
>> --
>> --Breno
>>
>> +1 (650) 214-1007 desk
>> +1 (408) 212-0135 (Grand Central)
>> MTV-41-3 : 383-A
>> PST (GMT-8) / PDT(GMT-7)
>
>



-- 
--Breno

+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 mailing list