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" :-) >>> >>> >> >
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
