I think using "cancel" would add consistency between the modes, any reason I'm not seeing why it is a bad choice?
--David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Tuesday, December 26, 2006 4:17 PM To: Johnny Bufu Cc: Martin Atkins; specs@openid.net Subject: Re: Consistency of negative responses to checkid_immediate requests Reviving an old thread... On 12/14/06, Johnny Bufu <[EMAIL PROTECTED]> wrote: > On 14-Dec-06, at 12:13 AM, Josh Hoyt wrote: > > On 12/13/06, Martin Atkins <[EMAIL PROTECTED]> wrote: > >> Josh Hoyt wrote: > >>> It's confusing to me make the failure response to an immediate > >>> mode request be "id_res", especially if that is not the failure > >>> response for setup mode. I can't see a reason that they can't both > >>> use the "cancel" response to indicate that the OP or end user do > >>> not wish to complete the transaction. > >>> > >>> This is a very minor change, but it will make the spec simpler. > >> > >> I think the RP will want to do something different in these two > >> cases. > > > > That's true, but the RP will probably need to handle the success > > case differently for immediate mode anyway (e.g. it will have to do > > AJAX to update the page) so I expect it to have a specific return_to > > URL for immediate requests. Since using a different return_to is > > trivial, I prefer the consistency of negative responses. > > The current / v1 modes will need to be mentioned in the compatibility > section, and also implemented. Not sure if this simplification will > then still be worth. Since the user_setup_url parameter is now gone, there is no way to differentiate between a broken/truncated response and a cancel response to an immediate mode request. I think that there needs to be *some* positive way to identify cancellation of immediate mode requests, rather than depending on lack of other parameters. I'd be happy with any of these ways to positively identify a cancel response to checkid_immediate: 1. re-using "cancel" as I suggested above 2. introducing a new mode (e.g. "setup_needed" ) 3. adding a parameter that the id_res response is an immediate cancellation (e.g. openid.setup_needed=true) I no longer buy the argument about having to support the OpenID 1 mechanism in the library, since cancellation of an immediate mode response is already indicated differently between OpenID 1 and 2, so it's really just a matter of what goes into the OpenID 2 code path rather than whether the two code paths exist. Pseudo-code for the current approach: def isSetupNeeded(): if this is OpenID 1: return whether there is a user_setup_url parameter if this is OpenID 2: # This is the branch that I want to change return whether there are any other OpenID parameters passed at all Thoughts? Josh _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
