<html><body bgcolor="#FFFFFF"><div>I think so. What about cases where two descrete applications/consumers share a realm?<br><br>Sent from a mobile device.</div><div><br>On Nov 13, 2008, at 3:58 PM, Dirk Balfanz &lt;<a href="mailto:balfanz@google.com">balfanz@google.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><br><br><div class="gmail_quote">On Thu, Nov 13, 2008 at 12:46 PM, Allen Tom <span dir="ltr">&lt;<a href="mailto:atom@yahoo-inc.com"><a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a></a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



  

<div bgcolor="#ffffff" text="#000000">
Hi Yariv,<br>
<br>
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.<br>
<br>
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.<br>
</div></blockquote><div><br>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. <br>
<br>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. <br>
<br>The OP embeds, in the request token, the realm to which the request token was issued.<br><br>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. <br>
<br>So we _do_ have a binding from the request token to the consumer key, it's just enforced later, not at approval time. <br><br>Does this make sense, or am I missing something?<br><br>Dirk.<br><br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><br>
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.<br>
<br>
Thoughts?<br>
Allen<br>
<br>
<br>
<br>
Yariv Adan wrote:
<blockquote type="cite">
  <div dir="ltr">Following the IIW session on this topic, we updated
the spec in <a href="http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html" target="_blank"><a href="http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html">http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html</a></a>
to address the issues that were raised. Especially, optimizing on how
OAuth request token is handled, allowed to remove one full roundtrip!<br>
Would appreciate any feedback on the updated suggestion.<br>
  <br>
Thanks<br>
  <br>
  <div class="gmail_quote">On Mon, Nov 3, 2008 at 12:00 PM, <span dir="ltr">&lt;<a href="mailto:specs-request@openid.net" target="_blank"><a href="mailto:specs-request@openid.net">specs-request@openid.net</a></a>></span>
wrote:<br>
  <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Send
specs mailing list submissions to<br>
&nbsp; &nbsp; &nbsp; &nbsp;<a href="mailto:specs@openid.net" target="_blank"><a href="mailto:specs@openid.net">specs@openid.net</a></a><br>
    <br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
&nbsp; &nbsp; &nbsp; &nbsp;<a href="http://openid.net/mailman/listinfo/specs" target="_blank"><a href="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</a></a><br>
or, via email, send a message with subject or body 'help' to<br>
&nbsp; &nbsp; &nbsp; &nbsp;<a href="mailto:specs-request@openid.net" target="_blank"><a href="mailto:specs-request@openid.net">specs-request@openid.net</a></a><br>
    <br>
You can reach the person managing the list at<br>
&nbsp; &nbsp; &nbsp; &nbsp;<a href="mailto:specs-owner@openid.net" target="_blank"><a href="mailto:specs-owner@openid.net">specs-owner@openid.net</a></a><br>
    <br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of specs digest..."<br>
    <br>
    <br>
Today's Topics:<br>
    <br>
&nbsp; 1. Proposal to create the OpenID OAuth Hybrid Working Group<br>
&nbsp; &nbsp; &nbsp;(Yariv Adan)<br>
    <br>
    <br>
----------------------------------------------------------------------<br>
    <br>
Message: 1<br>
Date: Mon, 3 Nov 2008 15:30:57 +0100<br>
From: Yariv Adan &lt;<a href="mailto:yariv@google.com" target="_blank"><a href="mailto:yariv@google.com">yariv@google.com</a></a>><br>
Subject: Proposal to create the OpenID OAuth Hybrid Working Group<br>
To: <a href="mailto:specs@openid.net" target="_blank"><a href="mailto:specs@openid.net">specs@openid.net</a></a><br>
Message-ID:<br>
&nbsp; &nbsp; &nbsp; &nbsp;&lt;<a href="mailto:7c1383150811030630r2eaf4e5fxdad6dfbd00cf9010@mail.gmail.com" target="_blank"><a href="mailto:7c1383150811030630r2eaf4e5fxdad6dfbd00cf9010@mail.gmail.com">7c1383150811030630r2eaf4e5fxdad6dfbd00cf9010@mail.gmail.com</a></a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
    <br>
&nbsp;In accordance with the OpenID Foundation IPR policies and
procedures&lt;<br>
    <a href="http://openid.net/foundation/intellectual-property/" target="_blank"><a href="http://openid.net/foundation/intellectual-property/">http://openid.net/foundation/intellectual-property/</a></a>
> this note proposes the<br>
formation of a new working group chartered to produce an OpenID<br>
specification.<br>
As per Section 4.1 of the Policies, the specifics of the proposed
working<br>
group are:<br>
    <br>
Background Information:<br>
OpenID has always been focused on how to enable user-authentication
within<br>
the browser. &nbsp;Over the last year, OAuth has been developed to allow<br>
authorization either from within a browser, desktop software, or mobile<br>
devices. &nbsp;Obviously there has been interest in using OpenID and OAuth<br>
together allowing a user to share their identity as well as grant a
Relying<br>
Party access to an OAuth protected resource in a single step. &nbsp;A small
group<br>
of people have been working on developing an extension to OpenID which
makes<br>
this possible in a collaborative fashion within<br>
    <a href="http://code.google.com/p/step2/" target="_blank"><a href="http://code.google.com/p/step2/">http://code.google.com/p/step2/</a></a>. &nbsp;This small
project includes a draft spec<br>
and Open Source implementations which the proposers would like to
finalize<br>
within the OpenID Foundation.<br>
    <br>
    <br>
Working Group Name:<br>
OpenID OAuth Hybrid Working Group<br>
    <br>
    <br>
Purpose:<br>
Produce a standard OpenID extension to the OpenID Authentication
protocol<br>
that provides a mechanism to embed an OAuth approval request into an
OpenID<br>
authentication request to permit combined user approval. The extension<br>
addresses the use case where the OpenID Provider and OAuth Service
Provider<br>
are the same service. To provide good user experience, it is important
to<br>
present a combined authentication and authorization screen for the two<br>
protocols.<br>
    <br>
    <br>
Scope:<br>
Standardize the draft Hybrid Protocol (<br>
    <a href="http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html" target="_blank"><a href="http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html">http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html</a></a>)<br>

as an official OpenID Extension describing how to combine an OpenID<br>
authentication request with the approval of an OAuth request token.<br>
    <br>
    <br>
Anticipated Contributions:<br>
Draft specification referenced above and various text contributions as
more<br>
developers implement it.<br>
    <br>
    <br>
Proposed List of Specifications:<br>
OpenID OAuth Extension 1.0. Spec completion by Q4 2008.<br>
    <br>
    <br>
Anticipated audience or users of the work:<br>
&nbsp;- OpenID Providers and Relying Parties<br>
&nbsp;- OAuth Consumers and Service Providers<br>
&nbsp;- Implementers of OpenID Providers and Relying Parties<br>
    <br>
    <br>
Language in which the WG will conduct business:<br>
English.<br>
    <br>
    <br>
Method of work:<br>
E-mail discussions on the working group mailing list and working group<br>
conference calls.<br>
    <br>
    <br>
Basis for determining when the work of the WG is completed:<br>
The work will be completed once it is apparent that maximal consensus
on the<br>
protocol proposal has been achieved within the working group, consistent<br>
with the purpose and scope.<br>
    <br>
    <br>
Proposers:<br>
&nbsp;- Ben Laurie, <a href="mailto:benl@google.com" target="_blank"><a href="mailto:benl@google.com">benl@google.com</a></a>,
Google<br>
&nbsp;- Breno de Medeiros, <a href="mailto:breno@google.com" target="_blank"><a href="mailto:breno@google.com">breno@google.com</a></a>, Google<br>
&nbsp;- David Recordon, <a href="mailto:drecordon@sixapart.com" target="_blank"><a href="mailto:drecordon@sixapart.com">drecordon@sixapart.com</a></a>, Six
Apart<br>
&nbsp;- Dirk Balfanz, <a href="mailto:balfanz@google.com" target="_blank"><a href="mailto:balfanz@google.com">balfanz@google.com</a></a>, Google<br>
&nbsp;- Joseph Smarr, <a href="mailto:jsmarr@plaxo.com" target="_blank"><a href="mailto:jsmarr@plaxo.com">jsmarr@plaxo.com</a></a>, Plaxo<br>
&nbsp;- Yariv Adan, <a href="mailto:yariv@google.com" target="_blank"><a href="mailto:yariv@google.com">yariv@google.com</a></a>,
Google &nbsp;- Allen Tom, <a href="mailto:atom@yahoo-inc.com" target="_blank"><a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a></a> ,<br>
Yahoo<br>
&nbsp;- Josh Hoyt, <a href="mailto:josh@janrain.com" target="_blank"><a href="mailto:josh@janrain.com">josh@janrain.com</a></a>
, JanRain<br>
    <br>
    <br>
Initial Editors:<br>
&nbsp;- Dirk Balfanz, <a href="mailto:balfanz@google.com" target="_blank"><a href="mailto:balfanz@google.com">balfanz@google.com</a></a>, Google &nbsp;-
Breno de Medeiros,<br>
    <a href="mailto:breno@google.com" target="_blank"><a href="mailto:breno@google.com">breno@google.com</a></a>,
Google<br>
    <br>
    <br>
--<br>
Yariv Adan | Product Manager<br>
Google Switzerland GmbH | Identifikationsnummer: CH-020.4.028.116-1<br>
This e-mail is confidential. If you are not the right addressee please
do<br>
not forward it, please inform the sender, and please erase this e-mail<br>
including any attachments. Thanks.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://openid.net/pipermail/specs/attachments/20081103/21c48c00/attachment.html" target="_blank"><a href="http://openid.net/pipermail/specs/attachments/20081103/21c48c00/attachment.html">http://openid.net/pipermail/specs/attachments/20081103/21c48c00/attachment.html</a></a><br>
    <br>
------------------------------<br>
    <br>
_______________________________________________<br>
specs mailing list<br>
    <a href="mailto:specs@openid.net" target="_blank"><a href="mailto:specs@openid.net">specs@openid.net</a></a><br>
    <a href="http://openid.net/mailman/listinfo/specs" target="_blank"><a href="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</a></a><br>
    <br>
End of specs Digest, Vol 27, Issue 3<br>
************************************<br>
  </blockquote>
  </div>
  <br>
  <br clear="all">
  <br>
-- <br>
Yariv Adan | Product Manager<br>
Google Switzerland GmbH | Identifikationsnummer: CH-020.4.028.116-1<br>
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. &nbsp; <br>
  </div>
  <pre><hr size="4" width="90%">_______________________________________________
specs mailing list
<a href="mailto:specs@openid.net" target="_blank"><a href="mailto:specs@openid.net">specs@openid.net</a></a>
<a href="http://openid.net/mailman/listinfo/specs" target="_blank"><a href="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</a></a>
  </pre>
</blockquote>
<br>
</div>

</blockquote></div><br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>specs mailing list</span><br><span><a href="mailto:specs@openid.net">specs@openid.net</a></span><br><span><a href="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</a></span><br></div></blockquote></body></html>