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> firstname.lastname@example.org DR> http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list email@example.com http://openid.net/mailman/listinfo/specs