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

Dirk Balfanz balfanz at google.com
Tue Nov 18 20:44:33 UTC 2008


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.

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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081118/fb8f1ee1/attachment-0002.htm>


More information about the specs mailing list