Non-directed identity UX question

[Breno de Medeiros]

On Thu, Jan 14, 2010 at 15:47, Allen Tom <atom at yahoo-inc.com> wrote:
> Hi George -
>
> We've seen evidence that users mistype their OpenID urls on RPs, which is
> not surprising since users probably aren't sure what their OpenID urls are
> anyway...
>
> My hunch is that most of the time, the user mistyped the string, rather than
> is logged with the wrong account. If the user mistyped the string, then it
> would seem best for the OP to just ignore what the user entered, or
> alternatively tell the user to switch accounts.

You mean that the RP didn't perform discovery? Or that the user
mistyped a URL and it happened to be a valid OpenID URL for someone
else?

>
> If the user initiated the login process by entering their email address,
> then I think it would more likely that the string is correct, since the user
> probably knows their email address and is able to type it correctly.

I actually have doubts about that, because the email address space is
so densely used.

>
> I agree that delegation does seem kind of broken and needs to be fixed. I
> would like the OP to know the URL that was delegated to it.
>
> Allen
>
>
>
> On 1/14/10 11:49 AM, "George Fletcher" <gffletch at aol.com> wrote:
>
>> Hi,
>>
>> Just wondering what others have done regarding the following use case.
>> This is a non-directed identity flow. (Note: this is not an issue for
>> directed identity because in that flow there is no user entered claimed_id).
>>
>>
>> Alice is currently logged in to her OP (example.com) as aliceisno1
>> (OpenID: http://aliceisno1.example.com). She then goes to a relying
>> party (pictures.example.net) and starts a non-directed identity flow
>> using the OpenID http://alice.example.com.
>>
>> Question:
>>
>> What should the OP show Alice when she arrives at the OP to
>> authenticate? It seems to me there are a couple of options.
>>
>> 1. Tell Alice that she's currently logged in as
>> http://aliceisno1.example.com and then offer Alice an option of logging
>> out of http://aliceisno1.example.com and logging in as
>> http://alice.example.com. This would require the OP to ensure that only
>> http://alice.example.com is authenticated after the logout event (or
>> not... see option 2).
>>
>> 2. Tell Alice that she's currently logged in as
>> http://aliceisno1.example.com and ask if she wants to use that OpenID
>> instead. (See note below about possible impacts on RP implementations).
>>
>> 3. Ignore any SSO related cookies and just require Alice to authenticate
>> http://alice.example.com and return the appropriate data without setting
>> any session cookies. This could have some implications on global logout
>> (but of course that's not supported right now).
>>
>> [I've seen all three in the wild]
>>
>> Of course Alice should be able to cancel any option and get back to the RP.
>>
>> Option 2 impacts on RPs:
>>
>> It turns out that for delegation reasons, the RP really should key their
>> identity of the user on the claimed_id entered by the user. If the best
>> practice (from a usability perspective) is to go with option 2, then RPs
>> could connect http://aliceisno1.example.com to http://alice.example.com.
>> What this means is that RPs need to do "late binding" and only key data
>> by the user's claimed_id if the returned claimed_id matches what was
>> entered.
>>
>> Any idea of how many RPs do "early binding" vs "late binding"?
>>
>> Other thoughts or suggestions?
>>
>> Thanks,
>> George
>> _______________________________________________
>> user-experience mailing list
>> user-experience at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-user-experience
>
> _______________________________________________
> user-experience mailing list
> user-experience at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-user-experience
>



-- 
--Breno

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