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

Wed Apr 2 22:40:37 UTC 2008

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:christopher at pobox.com]
> Sent: Wednesday, April 02, 2008 1:30 PM
> To: Drummond Reed
> Cc: 'George Fletcher'; 'Dick Hardt'; specs at openid.net
> 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>> 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
> 
> 