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