Thanks! Fixed. Dirk.
On Thu, Nov 20, 2008 at 6:37 AM, Paul Madsen <[EMAIL PROTECTED]> wrote: > Dirk, typo in Sec 6 > > The Combined Provider SHOULD in addition obtain, from the Combined > Provider, a list ..... > > paul > > Dirk Balfanz 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" :-) >>>> >>>> >>> >> > ------------------------------ > > _______________________________________________ > specs mailing [EMAIL PROTECTED]://openid.net/mailman/listinfo/specs > > ------------------------------ > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.549 / Virus Database: 270.9.6/1797 - Release Date: 18/11/2008 > 11:23 AM > > > > -- > [image: ConnectID] <http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1> >
<<gMwy.1.gif>>
_______________________________________________ specs mailing list [email protected] http://openid.net/mailman/listinfo/specs
