Use Case: should RPs remember identifiers?

Tue Nov 28 21:11:39 UTC 2006

Ah. So basically, in your scenario "D", upon the first visit of the  
day (with expired session) of URL
     wiki.example.com/wiki/Special:Recentchanges
what is shown to Alice is a page that essentially only consists of a  
text field "enter your identifier here", with Alice's previously-used  
identifier filled in.

Upon submit, a suitable session cookie is set, so that upon the  
second visit of the same URL with a valid session,
     wiki.example.com/wiki/Special:Recentchanges
it actually shows the set of recent changes.

I assume for anonymous access of the same URL, it still would show  
the set of recent changes even the first time around, right?

I think this naturally leads to a scenario "E" (which we could call  
the "Amazon scenario" because Amazon works that way, I think): in  
this scenario, the wiki assumes that the person who last visited is  
also the person who is visiting now, even if no recent credentials  
have been provided (yet). So upon the first visit of the day (with  
expired session), the page would show the set of recent changes AND  
assume that it is Alice. (And offered a link titled something like  
"You are not Alice? Click here to be somebody else.") Only when Alice  
wanted to perform an operation that required her to be authenticated  
and authorized for a certain operation, such as rolling back spam,  
would she be redirected to her OpenID host.

On Nov 28, 2006, at 11:33, Dick Hardt wrote:

> Just like most applications that require authorization to access
> certain pages, the app would remember the URL Alice wanted to goto,
> and redirect her to the login page. In this case, the login page
> would prompt Alice for her OpenID, but would remember which one she
> had used before, so it would fill it in for her so that she only
> needs to click on the login button.
>
> On 28-Nov-06, at 9:15 AM, Johannes Ernst wrote:
>
>> 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
>>
>> _______________________________________________
>> 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