Use Case: should RPs remember identifiers?

Fri Dec 1 02:06:11 UTC 2006

David,

The OpenID Authentication 2.0 spec, getting close to final, definitely does
not require that the user login to the OP using the same identifier given to
the RP. Just the opposite -- it gives the user the option to give the RP one
identifier and the OP another. The OP is ultimately responsible for
returning an assertion to the RP with the identifier the OP is verifying.

=Drummond  

-----Original Message-----
From: user-experience-bounces at openid.net
[mailto:user-experience-bounces at openid.net] On Behalf Of David Fuelling
Sent: Thursday, November 30, 2006 12:59 PM
To: 'OpenID user experience'
Subject: RE: Use Case: should RPs remember identifiers?

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

_______________________________________________
user-experience mailing list
user-experience at openid.net
http://openid.net/mailman/listinfo/user-experience