Use Case: should RPs remember identifiers?

[Johannes Ernst]

Could you expand on this? I'm unclear about the exact screens you are  
envisioning.

For example, if Alice bookmarks
     wiki.example.com/wiki/Special:Recentchanges
and visits that URL (with an expired session, with respect to the  
wiki), what does she see? Where does the "prompt" go?


On Nov 27, 2006, at 9:35, Dick Hardt wrote:

> 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