<br><br><div class="gmail_quote">On Wed, Nov 19, 2008 at 10:14 AM, 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;">
<div><div></div><div class="Wj3C7c">On Tue, Nov 18, 2008 at 10:32 PM, Dirk Balfanz <<a href="mailto:balfanz@google.com">balfanz@google.com</a>> wrote:<br>
><br>
><br>
> On Tue, Nov 18, 2008 at 10:04 PM, Breno de Medeiros <<a href="mailto:breno@google.com">breno@google.com</a>><br>
> wrote:<br>
>><br>
>> On Tue, Nov 18, 2008 at 10:00 PM, Dirk Balfanz <<a href="mailto:balfanz@google.com">balfanz@google.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On Tue, Nov 18, 2008 at 6:19 PM, Allen Tom <<a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>> wrote:<br>
>> >><br>
>> >> Dirk Balfanz wrote:<br>
>> >>><br>
>> >>> Oh I see. Ok. I'l make a new revision of the spec where I add a<br>
>> >>> required<br>
>> >>> parameter (the consumer key) to the auth request.<br>
>> >>><br>
>> >> Cool, thanks!<br>
>> >><br>
>> >><br>
>> >>> What should the spec recommend the OP should do if the consumer key<br>
>> >>> and<br>
>> >>> realm don't match? Return a cancel? Return something else?<br>
>> >>><br>
>> >> I'd recommend an error consistent with Section 8.2.4 in the OpenID 2.0<br>
>> >> spec, with a new error_code value indicating that the either the CK or<br>
>> >> the<br>
>> >> realm was invalid. There may actually need to be 2 errors, one to<br>
>> >> indicate<br>
>> >> that the CK is invalid, and another to indicate that the CK is not<br>
>> >> valid for<br>
>> >> the realm.<br>
>> >><br>
>> >> <a href="http://openid.net/specs/openid-authentication-2_0.html#anchor20" target="_blank">http://openid.net/specs/openid-authentication-2_0.html#anchor20</a><br>
>> ><br>
>> > But Section 8.2 is about the association response. In the auth response,<br>
>> > we<br>
>> > currently only have cancel or setup_needed. If we invent another error<br>
>> > condition there, we're no longer a pure "extension".<br>
>><br>
>> The solution is to add an optional term in the openid.oauth response<br>
>> and return the appropriate error code from the OAuth error handling<br>
>> spec.<br>
><br>
> Well, the oauth errors are about things like the nonce being reused, the<br>
> signature not verifying, or the request token being revoked. We don't have<br>
> any of that here.<br>
> It seems to me that in OpenID, you simply don't return a value if the<br>
> extension in question encountered some sort of problem. We follow that<br>
> spirit when the user declines the OAuth request (while, at the same time,<br>
> approving the authentication request). This error condition (realm not<br>
> matching the CK), however, feels different. This is more like if the RP<br>
> violates the "both present or both absent" rule and sends a claimed if but<br>
> no identity. As far as I can tell, the spec is silent on what the SP is<br>
> supposed to do when such inconsistent requests come in. Maybe that's what we<br>
> should do, too - just say that they have to match, and don't say what should<br>
> happen if they don't?<br>
<br>
</div></div>Sounds good, because such requests may either be accidental or<br>
malicious, and the OP might have to deal with them accordingly.<br>
<div class="Ih2E3d"></div></blockquote><div><br>Ok, new version is up. I took out the sentence that recommended to send a cancel. I also added a section on discovery (just copied whatever the AX extension says about that).<br>
<br>Dirk.<br><br> </div></div><br>