Re: Consistency of negative responses to checkid_immediate requests
On 27-Dec-06, at 11:11 AM, Recordon, David wrote: I think using cancel would add consistency between the modes, any reason I'm not seeing why it is a bad choice? Because then, only from the message contents, the RP wouldn't be able to distinguish between responses to immediate and non-immediate requests. Josh argued that in most cases the RPs would use different return_to URLs for immediate / non-immediate requests. My preference would be for option 2, i.e. a new mode. There's a different path the RPs have to take in this case, so I think openid.mode is the best qualified to express it. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consistency of negative responses to checkid_immediate requests
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
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
Re: Consistency of negative responses to checkid_immediate requests
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. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consistency of negative responses to checkid_immediate requests
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. That's a good point. I guess it comes down to how long OpenID 1.1 support will be necessary. If it's a long time (effectively forever) then it's definitely not worth it. If it's a relatively short period of time, then I think it is worth it for the cleaner spec. Unless someone agrees that it'd be worth it, I'll leave it alone. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consistency of negative responses to checkid_immediate requests
The internet has only standards worth the name that were only supposed to last for a short time. I think past experience shows that our assumption needs to be everything stays around forever. We haven't even solved the \n\a problem yet. On Dec 14, 2006, at 16:14, Josh Hoyt wrote: 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. That's a good point. I guess it comes down to how long OpenID 1.1 support will be necessary. If it's a long time (effectively forever) then it's definitely not worth it. If it's a relatively short period of time, then I think it is worth it for the cleaner spec. Unless someone agrees that it'd be worth it, I'll leave it alone. 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
Re: Consistency of negative responses to checkid_immediate requests
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. In the cancel case (which indicates that the user cancelled the request in some way) the RP will probably return to the login form to invite the user to try again. In the checkid_immediate case, what needs to happen is that the RP must start a checkid_setup request instead, since a negative response in the checkid_immediate case generally means I can't answer this until I've presented some UI to the user. I suppose it could be argued that the RP should know what it's doing and be able to distinguish between these cases using its own state, but given that the meaning of these responses is different I don't think it's a problem that the messages are different. It'd might be nice if the checkid_setup error response were called something other than id_res, though. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
