OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
balfanz at google.com
Wed Nov 19 06:32:05 UTC 2008
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
> >>> 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
> >> realm was invalid. There may actually need to be 2 errors, one to
> >> that the CK is invalid, and another to indicate that the CK is not valid
> >> 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,
> > 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
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?
> > Dirk.
> >> Allen
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the specs