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 <[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
