On Tue, Nov 18, 2008 at 10:32 PM, Dirk Balfanz <[EMAIL PROTECTED]> wrote: > > > 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?
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) _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs