Re: SREG 1.1 Request parameters
Enis Soztutar wrote: As far as I understand, the distinction between sreg.required and sreg.optional is entirely in the responsibility of the consumer and there is not reason for the protocol to include this arbitrary division. An OP implementation will just merge the two fields and try to fill them as much as it can. This distinction is made to avoid the following flow, which isn't very user-friendly: 1. RP sends user to OP with a request for email address. 2. OP asks user whether or not to send email address. 3. User elects not to send email address. 4. RP then says We can't let you register without an email address. Type one in here. 5. User elects to supply an email address after all, but now has no assistance from the OP to complete this field. By having the optional/required distinction, in step two the OP can say something like The RP may not allow you to log in without this information. This means that the user can make the decision in step 3 with the knowledge that it probably won't succeed, or he can make the decision in step 5 a few steps earlier and get assistance from the OP to enter the email address. It's only a very subtle distinction, but it is important so that the OP can explain the situation to the user at the right point in the transaction. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: SREG 1.1 Request parameters
Well, I have not thought about the OP to ask the user to pass the data to the RP leveraging required/optional fields information. Thanks for the clarification. Martin Atkins wrote: Enis Soztutar wrote: As far as I understand, the distinction between sreg.required and sreg.optional is entirely in the responsibility of the consumer and there is not reason for the protocol to include this arbitrary division. An OP implementation will just merge the two fields and try to fill them as much as it can. This distinction is made to avoid the following flow, which isn't very user-friendly: 1. RP sends user to OP with a request for email address. 2. OP asks user whether or not to send email address. 3. User elects not to send email address. 4. RP then says We can't let you register without an email address. Type one in here. 5. User elects to supply an email address after all, but now has no assistance from the OP to complete this field. By having the optional/required distinction, in step two the OP can say something like The RP may not allow you to log in without this information. This means that the user can make the decision in step 3 with the knowledge that it probably won't succeed, or he can make the decision in step 5 a few steps earlier and get assistance from the OP to enter the email address. It's only a very subtle distinction, but it is important so that the OP can explain the situation to the user at the right point in the transaction. ___ 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: SREG 1.1 Request parameters
On 21/02/2008, Enis Soztutar [EMAIL PROTECTED] wrote: Hi, As far as I understand, the distinction between sreg.required and sreg.optional is entirely in the responsibility of the consumer and there is not reason for the protocol to include this arbitrary division. An OP implementation will just merge the two fields and try to fill them as much as it can. It is a hint from the RP about which pieces of user information it requires. The OP may choose to use that info when asking the user for authorisation to send the data. Of course, the RP needs to handle the case where it doesn't receive some user details it asked for, possibly by getting the user to fill them in when they return from their OP. I propose we merge this two fields for version 1.1. This will introduce another backwards compatibility rule, but I think this design will be better. Introducing new features to the SREG extension seems a bit questionable. If you want to do things that SREG doesn't handle, you'd be better off looking at the attribute exchange extension. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
