Use Case: should RPs remember identifiers?

Tue Nov 28 22:35:34 UTC 2006

Yes, you have accurately described scenario "D".

Scenario "E" is a different use case where there is "soft auth" until  
a critical function is needed. LinkedIn does the same thing as Amazon  
here. Let's all this a different use case since it is not a different  
scenario for solving your original use case.

-- Dick

On 28-Nov-06, at 1:11 PM, Johannes Ernst wrote:

> 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
>
> _______________________________________________
> user-experience mailing list
> user-experience at openid.net
> http://openid.net/mailman/listinfo/user-experience
>
>