[OpenID] OpenID SREG best practice question

[Breno de Medeiros]

On Fri, Nov 14, 2008 at 7:21 AM, George Fletcher <gffletch at aol.com> wrote:
> Comments inline...
>
> Breno de Medeiros wrote:
>>
>> On Thu, Nov 13, 2008 at 5:17 PM, SitG Admin
>> <sysadmin at shadowsinthegarden.com> wrote:
>>
>>>>
>>>> I like the idea of tracking when the data changes and doing something
>>>> special then. I'd love to see RPs only ask for SREG data when they need
>>>> it. However, this is increasingly difficult with directed identity as
>>>> the RP doesn't know who the user is until after authentication.
>>>>
>>>
>>> The problem, then, is that RP's can only ask for the user's SREG data
>>> *during* authentication? And by the time it knows to ask for this
>>> data, the user has *already* authenticated, so it's too late?
>>>
>>> Ideally, there would be something like checkid_immediate for SREG;
>>> practically, the UX is still broken because it "logs in" the user and
>>> then says "Hold on one second, we need to send you back to your OP
>>> again." - effectively forcing the user to go through a login screen
>>> (assuming they have one with their OP) twice.
>>>
>>> On the other hand, if they wouldn't have had a combined login screen
>>> (and this is up to individual OP's, but if we assume that most OP's
>>> will follow the "show user what information they're about to submit"
>>> guidelines previously mentioned on this list, the OP will have the
>>> same problem - it can't show this information to users until *it*
>>> (the OP!) knows who that user is, so it will have a separate login
>>> screen for SREG data anyway), and the RP just bounces the user right
>>> back at their OP, the UX is a littler slower and the underlying
>>> process is about twice as much, but the user thinks they never left
>>> their OP.
>>>
>>
>> The Google OP will fail with setup_needed on checkid_immediate if it
>> needs to prompt the user (which includes the case when the attributes
>> have changed). So in principle, you could send checkid_immediate with
>> identity_select and no AX component, and if that does not work,
>> sending checkid_setup always with the AX component.
>>
>>
>
> Just to make sure I understand. In this scenario, the RP is sending the
> checkid_immediate along with the AX query. Then at the Google OP, it first
> checks to see if the user is logged in. If the user is logged into the
> Google OP, then...
>  1. If they've interacted with the RP before and set the auto-approve flag,
> then checkid_immediate will succeed but will not send the email address.
>  2. If the user has not interacted with the RP before, then
> checkid_immediate will fail so that the user will be forced through the UI
> to give consent to return the email address.
>  3. If the user has interacted with the RP in the past, but has not given
> auto-approval, then again checkid_immediate will fail because the user needs
> to consent to release of their email address.
>
> Obviously, if the user is not logged in, checkid_immediate will fail :)
>
> So if I've got the logic right, then checkid_immediate will only succeed
> with the Google OP if the user is logged in and has set the auto-approval
> flag.

Yes. That is the intended behavior. Indeed, the use of AX has no
impact on whether the user is prompted or not, _unless_ (a) the user
has pre-approved sending the attribute and (b) the attribute value has
changed since the last login.

>
> Thanks,
> George
>>>
>>> -Shade
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net
>>> http://openid.net/mailman/listinfo/general
>>>
>>>
>>
>>
>>
>>
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)