OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

Breno de Medeiros breno at google.com
Wed Nov 19 18:14:37 UTC 2008


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

Sounds good, because such requests may either be accidental or
malicious, and the OP might have to deal with them accordingly.

> Dirk.
>
>
>>
>> >
>> > Dirk.
>> >>
>> >> Allen
>> >>
>> >
>> >
>>
>>
>>
>> --
>> --Breno
>>
>> +1 (650) 214-1007 desk
>> +1 (408) 212-0135 (Grand Central)
>> MTV-41-3 : 383-A
>> PST (GMT-8) / PDT(GMT-7)
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)



More information about the specs mailing list