Users on Public Computers

Tue Nov 7 02:51:15 UTC 2006

Hi Johannes,

I proposed a solution to the "single sign out" problem a month or two
ago.

In fact - a whole range of solutions have been proposed, and relative
merits of all discussed already - does anyone have the free time to go
back over the postings, extract all the knowledge & contributions, and
document them all?

To summarize my proposal - I was seeking a standardized OpenID RP
endpoint interface into which I (as an IdP) or a software agent (eg: a
browser plugin) could "post" user information - be this a login
request, email change request, log-out request, account signup,
account cancelation, or whatever.  My preferred implementation was a
<LINK> tag placed on (and thus identifying) a login page, and within
the link tag, the endpoint of the RP for accepting IdP(OP/agent)
input.

Kind Regards,
Chris Drake

Tuesday, November 7, 2006, 1:04:44 PM, you wrote:

JE> I continue to believe that we need single-sign-out
JE> functionality, in particular once OpenID moves up the stack for
JE> higher-value transactions.

JE> Some people have made the case that that is undesirable
JE> and/or impossible; I beg to differ.

JE> Having automatic authentication against the IdP is quite
JE> similar to not having a password on the identity at all, in that
JE> it reduces the confidence that we know the real-world identity of
JE> the entity/user at the other end. In my view, there's nothing
JE> wrong with that, but we do need to be able to convey that to
JE> relying parties in a way that cannot be easily attacked.

JE> On Nov 6, 2006, at 16:41, Joshua Viney wrote:

JE> One question re: User Experience and single-sign-on comes to mind:

JE> How do we treat users who are accessing their IdP and Relying Parties via public computers?

JE> Use Case:
JE> Good User at public library wants to leave a comment on Blog X
JE> Blog X requires the person to authenticate via OpenID
JE> Good User enters their OpenID and successfully authenticates
JE> via email and password (or whatever) (and authorizes the RP
JE> ('realm' in 2.0) if necessary) at their IdP
JE> Good User is redirected to Blog X signed in
JE> Good User leaves comment
JE> Good User signs out of Blog X (if sign out is even an option)
JE> Good User then leaves the public library and goes shopping
JE> Evil User jumps on computer and proceeds to leave comments at
JE> any number of OpenID enabled blogs using Good User's OpenID (he
JE> saw it while looking over Good User's shoulder, or he checks any
JE> sites that Good User did NOT sign out of that might display his
JE> OpenID)
JE> Evil User, uses Good User's signed in IdP session to sign into any number of sites, etc

JE> Outcome: Good User's reputation is ruined and his/her OpenID
JE> is banned from a whole list of Relying Parties. Good User then
JE> blames their IdP, the Relying Parties and OpenID as a technology
JE> and tells everyone he/she knows not to use it blogs about it and
JE> initiates a press release.

JE> It may be easy to pass this off as an implementation specific
JE> issue or as "user error", but this use case is somewhat likely for
JE> 2 reasons:

JE> 1. A user's OpenID URI is not necessarily a private thing
JE> (obscurity is not security anyway)
JE> 2. Users will be at least 1 site removed from their IdP while
JE> accessing a Relying Party, and no one is use to signing out twice
JE> 3. It is very very likely that IdP's will use some type of "remember me" functionality

JE> One solution to consider would be a global sign-out feature
JE> on relying party sites that signs users out of their IdP as well.
JE> Another solution would be to make very specific recommendations
JE> about messaging users who may be using public computers.

JE> Josh Viney
JE> http://www.eastmedia.com -- EastMedia
JE> http://identity.eastmedia.com -- OpenID, Identity 2.0

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