Chris, I remember that well, and I agree that it makes a lot of sense. I think when this is combined with George's concept of the other ways in which a local identity agent can assist the use, then IDMML really starts to gain some legs.
See also my reply to George. =Drummond > -----Original Message----- > From: Chris Drake [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 02, 2008 1:30 PM > To: Drummond Reed > Cc: 'George Fletcher'; 'Dick Hardt'; [email protected] > Subject: Re: IDMML (was RE: Using email address as OpenID identifier) > > 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>> [EMAIL PROTECTED] > 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> [email protected] > DR> http://openid.net/mailman/listinfo/specs > > _______________________________________________ specs mailing list [email protected] http://openid.net/mailman/listinfo/specs
