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

Darren Bounds dbounds at gmail.com
Thu Nov 13 21:58:03 UTC 2008


I think so. What about cases where two descrete applications/consumers  
share a realm?

Sent from a mobile device.

On Nov 13, 2008, at 3:58 PM, Dirk Balfanz <balfanz at google.com> wrote:

>
>
> On Thu, Nov 13, 2008 at 12:46 PM, Allen Tom <atom at yahoo-inc.com>  
> wrote:
> Hi Yariv,
>
> In the registered consumer case, the SP will need the Consumer Key  
> to show the Approval page. Previous versions of the spec had the  
> Request Token in the OpenID Authentication request, which allowed  
> the SP to derive the Consumer Key from the Request Token. At the  
> IIW, we had discussed somehow tying the Association Handle to the  
> Consumer Key.
>
> Regardless of the solution, the SP will need to be know the Consumer  
> Key in order to properly identify the OAuth Consumer when displaying  
> the Approval page. The OpenID Realm is not quite sufficient, at  
> least for SPs which require consumers to pre-register for a CK.
>
> I don't think this is true - I believe the realm is sufficient. Let  
> me try and explain. (We'll assume registered consumers.) On the  
> approval page, we need to identify the consumer. In its current  
> form, the spec basically assumes that you're gonna use the realm for  
> that.
>
> Let's assume that The Bad Guy somehow managed to sneak a misleading  
> realm into a request, i.e. the user sees the realm on the login page  
> and clicks "approve" when he wouldn't have approved had he known the  
> real identity of The Bad Guy.
>
> The OP embeds, in the request token, the realm to which the request  
> token was issued.
>
> Later, when The Bad Guy tries to exchange the request token for an  
> access token, it won't work, b/c The Bad Guy only has access to his  
> own consumer secret, which doesn't match the realm embedded in the  
> request token.
>
> So we _do_ have a binding from the request token to the consumer  
> key, it's just enforced later, not at approval time.
>
> Does this make sense, or am I missing something?
>
> Dirk.
>
>
>
> One possible optimization would be to just use the Consumer Key as  
> the OpenID Association Handle, and Consumer Secret as the OpenID  
> Association. The Consumer can just sign the OpenID Auth request  
> using its CK/CS and the OP can return a pre-approved response token  
> in the OpenID assertion. The Consumer can then exchange the response  
> token for the OAuth Access Token/ ATS.
>
> Thoughts?
> Allen
>
>
>
> Yariv Adan wrote:
>>
>> Following the IIW session on this topic, we updated the spec in http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html 
>>  to address the issues that were raised. Especially, optimizing on  
>> how OAuth request token is handled, allowed to remove one full  
>> roundtrip!
>> Would appreciate any feedback on the updated suggestion.
>>
>> Thanks
>>
>> On Mon, Nov 3, 2008 at 12:00 PM, <specs-request at openid.net> wrote:
>> Send specs mailing list submissions to
>>        specs at openid.net
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        http://openid.net/mailman/listinfo/specs
>> or, via email, send a message with subject or body 'help' to
>>        specs-request at openid.net
>>
>> You can reach the person managing the list at
>>        specs-owner at openid.net
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of specs digest..."
>>
>>
>> Today's Topics:
>>
>>   1. Proposal to create the OpenID OAuth Hybrid Working Group
>>      (Yariv Adan)
>>
>>
>> --- 
>> -------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 3 Nov 2008 15:30:57 +0100
>> From: Yariv Adan <yariv at google.com>
>> Subject: Proposal to create the OpenID OAuth Hybrid Working Group
>> To: specs at openid.net
>> Message-ID:
>>        <7c1383150811030630r2eaf4e5fxdad6dfbd00cf9010 at mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>>  In accordance with the OpenID Foundation IPR policies and  
>> procedures<
>> http://openid.net/foundation/intellectual-property/ > this note  
>> proposes the
>> formation of a new working group chartered to produce an OpenID
>> specification.
>> As per Section 4.1 of the Policies, the specifics of the proposed  
>> working
>> group are:
>>
>> Background Information:
>> OpenID has always been focused on how to enable user-authentication  
>> within
>> the browser.  Over the last year, OAuth has been developed to allow
>> authorization either from within a browser, desktop software, or  
>> mobile
>> devices.  Obviously there has been interest in using OpenID and OAuth
>> together allowing a user to share their identity as well as grant a  
>> Relying
>> Party access to an OAuth protected resource in a single step.  A  
>> small group
>> of people have been working on developing an extension to OpenID  
>> which makes
>> this possible in a collaborative fashion within
>> http://code.google.com/p/step2/.  This small project includes a  
>> draft spec
>> and Open Source implementations which the proposers would like to  
>> finalize
>> within the OpenID Foundation.
>>
>>
>> Working Group Name:
>> OpenID OAuth Hybrid Working Group
>>
>>
>> Purpose:
>> Produce a standard OpenID extension to the OpenID Authentication  
>> protocol
>> that provides a mechanism to embed an OAuth approval request into  
>> an OpenID
>> authentication request to permit combined user approval. The  
>> extension
>> addresses the use case where the OpenID Provider and OAuth Service  
>> Provider
>> are the same service. To provide good user experience, it is  
>> important to
>> present a combined authentication and authorization screen for the  
>> two
>> protocols.
>>
>>
>> Scope:
>> Standardize the draft Hybrid Protocol (
>> http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html 
>> )
>> as an official OpenID Extension describing how to combine an OpenID
>> authentication request with the approval of an OAuth request token.
>>
>>
>> Anticipated Contributions:
>> Draft specification referenced above and various text contributions  
>> as more
>> developers implement it.
>>
>>
>> Proposed List of Specifications:
>> OpenID OAuth Extension 1.0. Spec completion by Q4 2008.
>>
>>
>> Anticipated audience or users of the work:
>>  - OpenID Providers and Relying Parties
>>  - OAuth Consumers and Service Providers
>>  - Implementers of OpenID Providers and Relying Parties
>>
>>
>> Language in which the WG will conduct business:
>> English.
>>
>>
>> Method of work:
>> E-mail discussions on the working group mailing list and working  
>> group
>> conference calls.
>>
>>
>> Basis for determining when the work of the WG is completed:
>> The work will be completed once it is apparent that maximal  
>> consensus on the
>> protocol proposal has been achieved within the working group,  
>> consistent
>> with the purpose and scope.
>>
>>
>> Proposers:
>>  - Ben Laurie, benl at google.com, Google
>>  - Breno de Medeiros, breno at google.com, Google
>>  - David Recordon, drecordon at sixapart.com, Six Apart
>>  - Dirk Balfanz, balfanz at google.com, Google
>>  - Joseph Smarr, jsmarr at plaxo.com, Plaxo
>>  - Yariv Adan, yariv at google.com, Google  - Allen Tom, atom at yahoo-inc.com 
>>  ,
>> Yahoo
>>  - Josh Hoyt, josh at janrain.com , JanRain
>>
>>
>> Initial Editors:
>>  - Dirk Balfanz, balfanz at google.com, Google  - Breno de Medeiros,
>> breno at google.com, Google
>>
>>
>> --
>> Yariv Adan | Product Manager
>> Google Switzerland GmbH | Identifikationsnummer: CH-020.4.028.116-1
>> This e-mail is confidential. If you are not the right addressee  
>> please do
>> not forward it, please inform the sender, and please erase this e- 
>> mail
>> including any attachments. Thanks.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://openid.net/pipermail/specs/attachments/20081103/21c48c00/attachment.html
>>
>> ------------------------------
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>> End of specs Digest, Vol 27, Issue 3
>> ************************************
>>
>>
>>
>> -- 
>> Yariv Adan | Product Manager
>> Google Switzerland GmbH | Identifikationsnummer: CH-020.4.028.116-1
>> This e-mail is confidential. If you are not the right addressee  
>> please do not forward it, please inform the sender, and please  
>> erase this e-mail including any attachments. Thanks.
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081113/24c20a6a/attachment-0002.htm>


More information about the specs mailing list