OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Paul Madsen]

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 <balfanz at google.com 
> <mailto:balfanz at google.com>> wrote:
>
>     [+Brian Eaton]
>
>     On Mon, Nov 17, 2008 at 4:31 PM, Allen Tom <atom at yahoo-inc.com
>     <mailto:atom at yahoo-inc.com>> 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 at openid.net
> http://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
>   

-- 
ConnectID <http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081120/a26d214c/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gMwy.1.gif
Type: image/gif
Size: 9265 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081120/a26d214c/attachment-0002.gif>