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