On Tue, Nov 18, 2008 at 12:00 PM, Breno de Medeiros <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > wrote: > >> > >> [+Brian Eaton] > >> > >> On Mon, Nov 17, 2008 at 4:31 PM, Allen Tom <[EMAIL PROTECTED]> 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) >
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
