Regarding case B...
At AOL if the user is already authenticated but has not given consent to
be "identified" to the RP we show a consent screen and allow the user to
logout and login as a different user (a.k.a. "switch users"). Also on
this consent screen we allow the user to permanently remember their
consent decision. This effectively give the user seamless SSO the next
time they log into that RP. Of course these consents can be revoked by
the user.
One of the issues of "switch user" is that it terminates the previous
web session. So if the user was reading mail for the first user, their
mail session is logged out. It's possible to keep these authentications
separate but in the end that seems more confusing for the user than helpful.
I'm curious as to others experience.
Thanks,
George
On 1/11/10 7:54 PM, Allen Tom wrote:
Hi Alex -
I agree with Breno that cases A and C require the user to restart the
process from the beginning. Given that the user indicated that they wanted
to authenticate using an account at the OP, presumably the user chose an OP
for which they already have an account and remember the password, so
hopefully A and C are edge cases.
Our statistics indicate that the overwhelming majority of the time, the user
is already signed into Yahoo when the Yahoo OP receives an authentication
request. I believe that other OPs have also observed similar behavior.
B is definitely an interesting case, as people often have several accounts
and may want to "switch users" before signing into the RP. I think the best
UX would be for the OP's approval screen to indicate which account the user
is currently signed in with, and an option to sign in as a different user.
Allen
On 1/11/10 3:01 PM, "Breno de Medeiros"<[email protected]> wrote:
For many RPs, if user starts processes A or C (with regards to their
in-house login system), I assume it'd still be often the case where
the user will have to re-start the process from the original context.
Case B is more interesting as it raises issues exclusive to use of a
(open) federated login system.
On Mon, Jan 11, 2010 at 14:44, Alex Barth<[email protected]> wrote:
In the course of ironing out workflows between OpenID provder and OpenID
relying parties it I am facing usability problems that I'd like to submit
here to the attention of some more experienced OpenID developers than I am.
I am interested in any feedback, pointers to existing conversations,
sections in current and future specs that I may have overlooked etc.
Here is the problem: There are some actions that can occur during
authentication where a user can fall through the cracks:
A User is redirected with an authentication request from RP to OP, requests
a new password on OP, email client opens different browser for a one time
password reset link embedded in the email.
B User is redirected with authentication request from RP to OP, but would
like to log in with different user than the one currently authenticated on
OP, user is logged out and session is deleted.
C RP offers OP as identity provider, user selects OP, is redirected with
authentication request to OP. User does not have an account yet, creates
one, confirms email address, but again, email client opens different browser
(similar to A).
In all of these scenarios the user's session and with it her authentication
request is lost - the authentication process is stuck in its tracks.
Is the assessment of the problem flawed? Is there a solution in the specs
that I am overlooking?
Thank you for your input.
Alex Barth
http://www.developmentseed.org/blog
tel (202) 250-3633
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
