<br><div class="gmail_quote">On Tue, Nov 18, 2008 at 12:00 PM, Breno de Medeiros <span dir="ltr">&lt;<a href="mailto:breno@google.com">breno@google.com</a>&gt;</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;">
You have some references like &quot;in Section 5.&quot; Please change them to<br>
&quot;in Section 5 of the OAuth Spec&quot;.<br>
<div><div></div><div class="Wj3C7c"></div></div></blockquote><div><br>But then it would be pointing to the wrong thing :-)<br><br>&quot;in Section 5&quot; means Section 5 of the document the reader is currently reading. <br>
<br>Dirk.<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><div class="Wj3C7c"><br>
On Tue, Nov 18, 2008 at 11:56 AM, Dirk Balfanz &lt;<a href="mailto:balfanz@google.com">balfanz@google.com</a>&gt; wrote:<br>
&gt; Ok, new spec is up:<br>
&gt; <a href="http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html" target="_blank">http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html</a><br>

&gt;<br>
&gt; Dirk.<br>
&gt;<br>
&gt; On Mon, Nov 17, 2008 at 5:40 PM, Dirk Balfanz &lt;<a href="mailto:balfanz@google.com">balfanz@google.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; [+Brian Eaton]<br>
&gt;&gt;<br>
&gt;&gt; On Mon, Nov 17, 2008 at 4:31 PM, Allen Tom &lt;<a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Sadly, because the OpenID authentication request is not signed, the CK<br>
&gt;&gt;&gt; can&#39;t be authenticated, but as you pointed out, although the user may<br>
&gt;&gt;&gt; authorize the application, the CK secret is still required to fetch the<br>
&gt;&gt;&gt; credentials. The worst that could happen is that a user will authorize an<br>
&gt;&gt;&gt; impostor, but the impostor will not be able to retrieve the token.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; That being said, in our case, the CK contains additional information<br>
&gt;&gt;&gt; besides the scope. Yahoo&#39;s OAuth Permissions screen contains a lot of rich<br>
&gt;&gt;&gt; information including the application&#39;s name, description, developer(s),<br>
&gt;&gt;&gt; images, authorization lifetimes, etc. Over time, new fields may be added to<br>
&gt;&gt;&gt; the approval page.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; While it might make sense for the application&#39;s scope to be passed in at<br>
&gt;&gt;&gt; authorization time, does it also make sense to define new parameters for all<br>
&gt;&gt;&gt; the other application specific metadata? The actual data that needs to be<br>
&gt;&gt;&gt; displayed on an approval page is very SP specific, and some SPs may have<br>
&gt;&gt;&gt; security/legal policies requiring that all metadata is manually reviewed,<br>
&gt;&gt;&gt; which makes it impossible for metadata to be passed in at runtime.<br>
&gt;&gt;<br>
&gt;&gt; Oh I see. Ok. I&#39;l make a new revision of the spec where I add a required<br>
&gt;&gt; parameter (the consumer key) to the auth request.<br>
&gt;&gt;<br>
&gt;&gt; What should the spec recommend the OP should do if the consumer key and<br>
&gt;&gt; realm don&#39;t match? Return a cancel? Return something else?<br>
&gt;&gt;<br>
&gt;&gt; Another change I&#39;ll be making is to take out references to unregistered<br>
&gt;&gt; consumers. Brian found a weakness in our approach (the one where we make the<br>
&gt;&gt; association secret the consumer secret) that makes me think we need to think<br>
&gt;&gt; about unregistered consumers a bit more[1].<br>
&gt;&gt;<br>
&gt;&gt; Dirk.<br>
&gt;&gt;<br>
&gt;&gt; [1] Basically, the problem is that we have oracles around the web that add<br>
&gt;&gt; OAuth signatures to arbitrary requests. They&#39;re called OpenSocial gadget<br>
&gt;&gt; containers. If and when OpenID signatures and OAuth signatures converge,<br>
&gt;&gt; with the current propocal we might end up in a situation where my gadget<br>
&gt;&gt; container will create OAuth signatures using the same key needed to assert<br>
&gt;&gt; auth responses.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; So that&#39;s why SPs may need the CK in order to display the Approval page.<br>
&gt;&gt;&gt; Make sense?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Allen<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Dirk Balfanz wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Need to know the CK for what? What purpose would hinting at the CK serve<br>
&gt;&gt;&gt;&gt; (since it wouldn&#39;t prove ownership)? And don&#39;t say &quot;scope&quot; :-)<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
<br>
<br>
<br>
</div></div>--<br>
<div><div></div><div class="Wj3C7c">--Breno<br>
<br>
+1 (650) 214-1007 desk<br>
+1 (408) 212-0135 (Grand Central)<br>
MTV-41-3 : 383-A<br>
PST (GMT-8) / PDT(GMT-7)<br>
</div></div></blockquote></div><br>