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

Dirk Balfanz balfanz at google.com
Wed Nov 19 18:29:51 UTC 2008


On Wed, Nov 19, 2008 at 10:14 AM, Breno de Medeiros <breno at google.com>wrote:

> 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.
>

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).

Dirk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081119/9d71f736/attachment-0001.htm>


More information about the specs mailing list