IDMML (was RE: Using email address as OpenID identifier)

Wed Apr 2 20:29:48 UTC 2008

Hi Drummond,

I pushed hard for RP identification for 2 or 3 months back around
October 2006.  If anyone wants to go back through the archives,
there's a pile of other important reasons to have some way that an IdP
and/or browser agent can identify an OpenID-enabled site.  The antique
thread below lists a few.  My proposal too was a <link> tag.

Kind Regards,
Chris Drake

Tuesday, November 7, 2006, 12:51:15 I, you wrote:

CD> Hi Johannes,

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

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

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

CD> Kind Regards,
CD> Chris Drake

CD> 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
JE>> 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

Kind Regards,
Chris Drake,
=1id.com

Thursday, April 3, 2008, 4:38:13 AM, you wrote:

>> > Dick Hardt wrote:
>> >
>> > :-) ... that label would be more accurate. There is lots of work to be
>> > done to make OpenID simpler for users. I think that what will be easy
>> > for users is something provided by the browser that lets the user
>> > click to initiate a login or registration. No typing is better then
>> > any typing! Back when we started working on the protocols we could not
>> > expect this kind of functionality to be in the browsers. Now that
>> > awareness is higher, having it built into the browser is feasible. I
>> > of course am biased given the work we have done with Sxipper
>> > http://sxipper.com :)
>> For the majority of users, this is probably the most likely path of
>> introduction to OpenID. Note that it's not just about allowing the user
>> to do something with one click, but also about being proactive and
>> informing the user that they can login to a site with an identity they
>> already have. This can be as simple as telling the browser "identity
>> agent" (e.g. sxipper) which email addresses the user has and letting the
>> identity agent figure out which OpenID's the user has that they don't
>> even know about.
>> 
>> George Fletcher wrote:
>>
>> I think relying party sites that support OpenID could do more to make it
>> clear on their home pages that they support OpenID (as often it's hidden
>> behind another click). This could be as simple as some <link> tags that
>> advertise support for OpenID. Maybe a <link> to the XRDS doc describing
>> the services of the site. Then the identity agent can discover the
>> relying party OpenID return_to endpoint and log the user in directly.
>> Can be used to solve a phishing problem and makes the experience easy
>> for the user.
>> 
>> Some related thoughts ....
>>    http://practicalid.blogspot.com/2007/06/clients-to-rescue.html
>> 
>> http://practicalid.blogspot.com/2007/06/passive-identity-meta-system-
>> markup.html

DR> George, I read your two posts with great interest...and then noticed that
DR> they were last summer!

DR> You are a man ahead of your time.

DR> Where has discussion of your "IDMML" gone since your posts?

DR> =Drummond 

DR> _______________________________________________
DR> specs mailing list
DR> specs at openid.net
DR> http://openid.net/mailman/listinfo/specs