On Tue, Nov 18, 2008 at 10:04 PM, Breno de Medeiros <[EMAIL PROTECTED]>wrote:
> On Tue, Nov 18, 2008 at 10:00 PM, Dirk Balfanz <[EMAIL PROTECTED]> wrote: > > > > > > On Tue, Nov 18, 2008 at 6:19 PM, Allen Tom <[EMAIL PROTECTED]> 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? 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) >
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
