Use Case: should RPs remember identifiers?

Dick Hardt dick at sxip.com
Mon Nov 27 17:35:22 UTC 2006


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




More information about the user-experience mailing list