Use Case: should RPs remember identifiers?

David Fuelling sappenin at gmail.com
Thu Nov 30 20:59:08 UTC 2006


Two thoughts on this one...well, actually 1 thought & 1 question.  

First, it might be useful to recognize a scenario A++.  This is essentially
scenario A, except that when Alice is prompted to login each time,
Firefox/IE recognizes that it's a username/password form, and autofills the
username+password automatically (quite a bit more convenient than
re-entering username/pass each time, and on my machine at least, works with
most web-sites).  

That may be the existing experience/behavior you want to measure UX against
on the browser side (for most sites anyway).

Secondly, what happens if a user specifies a given OpenId Identifier at the
RP (say, http://bob.example.com), but then logs into the example.com IdP/OP
as beth (OpenId Identifier http://beth.example.com).  Where does the OpenId
process fail, or does it?  Since OpenId RP's can handle a specific Id, as
well as just an OP Url, should the OP simply assert on behalf of beth in
this case, even though bob's id was specified at the RP?  

I guess I'm a bit hazy on the spec here.  Does the spec mandate that a user
MUST login to the OP using the OpenId URL/user that was entered on the RP?
This has bearing on whether C or D (or E) is preferable in my mind.

david

> -----Original Message-----
> From: user-experience-bounces at openid.net [mailto:user-experience-
> bounces at openid.net] On Behalf Of Dick Hardt
> Sent: Monday, November 27, 2006 12:35 PM
> To: OpenID user experience
> Subject: Re: Use Case: should RPs remember identifiers?
> 
> I would pick option D.
> 
> Alice's OpenID identifier is filled in at the prompt, but she needs
> to click the button to login to the wiki. Otherwise it becomes
> disconcerting on how to login as a different user from the same
> machine. One more click then (C), but less confusing, and the user is
> still in control.
> 
> -- Dick
> 
> On 27-Nov-06, at 9:30 AM, Johannes Ernst wrote:
> 
> > Using the now several different MediaWiki OpenID extensions in
> > existence prompted me to write this use case. Anybody agree or
> > disagree on what they desired behavior is here?
> >
> > 1. Alice is an administrator of wiki wiki.example.com, which
> > supports OpenID. She is responsible for rolling back wiki spam. To
> > rollback wiki spam, she needs to be authenticated as an
> > administrator on this wiki.
> > 2. To make things easy on herself, she bookmarks wiki.example.com/
> > wiki/Special:Recentchanges, (the list of recent changes on the
> > wiki) for a quick and frequent check on potential spam. She
> > typically visits this page once a day.
> > 3. When Alice discovers a change that might be spam, she performs a
> > "diff" of the revisions in question and examines the change that
> > was made. If it was spam, she clicks on "rollback" -- the button
> > that is displayed on "diff pages" by MediaWiki, if the current user
> > is authenticated as an administrator
> >
> > Here are the different implementations that I have seen:
> >
> > A. WIthout OpenID, MediaWiki remembers Alice's session for some
> > time (<<1 day). Thus, in order to perform this use case once a day,
> > Alice must re-enter her MediaWiki user name and password every time
> > she wishes to remove spam.
> >
> > B. With the OpenID plugin on openid.net/wiki, or the OpenID plugin
> > at iiw.windley.org, Alice must re-enter her OpenID identifier every
> > time she checks on spam. (Session duration seems to be similar/the
> > same as in case of (A)). Assuming she has a valid session at her
> > OpenID identity provider, this is potentially more convenient than
> > (A), but not by much.
> >
> > C. In the NetMesh implementation (e.g. yadis.org), we store the
> > OpenID identifier in a long-term cookie. When Alice's session is
> > expired, the relying party (the wiki) automatically performs the
> > redirect dance with the identifier stored in the cookie. The
> > result: Alice does not need to re-enter anything, but -- assuming
> > she has a valid session at her OpenID identity provider -- she is
> > automatically authenticated.
> >
> > I would argue that (C) is better at meeting the needs of Alice than
> > (A) or (B). Certainly, for Alice == me, experience over recent
> > weeks has shown that to be true and that's why I am bringing this
> > up. (I have bookmarked the recent changes of openid.net/wiki,
> > yadis.org, lid.netmesh.org, and a few others, and openid.net/wiki
> > requires me to do a lot of repetitive stuff that I don't really
> > want to do).
> >
> >
> >
> >
> >
> > Johannes Ernst
> > NetMesh Inc.
> >
> >
> > <openid-relying-party-authenticated.gif>
> > <lid.gif>
> >  http://netmesh.info/jernst
> >
> > _______________________________________________
> > user-experience mailing list
> > user-experience at openid.net
> > http://openid.net/mailman/listinfo/user-experience
> 
> _______________________________________________
> user-experience mailing list
> user-experience at openid.net
> http://openid.net/mailman/listinfo/user-experience




More information about the user-experience mailing list