On Tue, Nov 18, 2008 at 12:44 PM, Dirk Balfanz <[EMAIL PROTECTED]> wrote: > > 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.
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 <[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) > > -- --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 [email protected] http://openid.net/mailman/listinfo/specs
