John: IMHO: The only significant feature that OpenID 2.0 and OpenID Connect have in common is the word "OpenID"
For me, user-centric is less about empowering the user, and much more about how we can scale past one IdP. -- Dick On 2011-07-20, at 4:22 PM, John Kemp wrote: > On Jul 20, 2011, at 2:50 PM, Phillip Hallam-Baker wrote: > >> One of the bad habits of that period was the excessive generation of jargon. >> By the end I think that everyone was thoroughly confused. I would ditch the >> term entirely and instead use "user centric communication pattern", it takes >> more characters but it is apparent to everyone that we are talking about the >> same thing. >> >> >> The term User Focused is not taken as far as I know. That is what I am >> arguing for. A User Focused approach is highly likely to have a user centric >> communication pattern. > > With all due respect, I would personally not wish to restart the jargon wars, > and I think we're moving far away from the original point of this thread by > discussing the meaning of "user-centric". > > Personally I was just trying to discover what is different about BrowserID > when compared to OpenID (Connect *or* 2.0). I can't see very much different > really in how we expect users to play a role in the protocol. I do think its > good that the verification of a user's email address actually being used by > the user is made possible by the properties of the identifier, but I can't > see much else that commends BrowserID over OpenID, and some people may even > think it a bad thing that the user identifier has properties other than that > of being an identifier (ie. it can be used to send email to the user) - and I > think that's a valid concern which may outweigh the convenience of easy > verification of the link from the identifier to the user. > > All these technologies *might* properly respect the wishes of the user if > implemented that way (and there may even be multiple ways to do that). Why > should they not be implemented that way? It's not a technical problem, as far > as I can tell. > > Regards, > > - John > >> >> >> >> >> On Wed, Jul 20, 2011 at 1:47 PM, Dick Hardt <[email protected]> wrote: >> Phillip >> >> The term was defined and used in literature and by analysts 6 or 7 years ago. >> >> Many assumed it meant the user was in control or the focus -- I find that >> definition misleading and hides the significant scale advantages of the >> architecture. I just realized that my old blog is offline, where I had >> defined the term in the past. Hmmm, perhaps time to pull that off the shelf >> and polish it up again. >> >> -- Dick >> >> On 2011-07-20, at 12:24 PM, Phillip Hallam-Baker wrote: >> >>> I think we should make the term user centric mean what it appears to mean - >>> make the user the focus of the design. >>> >>> One of the ways in which OpenID lost its way was the obsession with making >>> it easy for bloggers to deploy and even weirder for people to be able to >>> set up Idps. Both of these came across as much higher priorities in the >>> design than the user experience. >>> >>> It should not be unnecessarily hard for bloggers to add support for an >>> Identity protocol, but that should not be a higher goal than the user and >>> in particular support for legacy versions of platform infrastructure seems >>> like it should be a non-issue. >>> >>> >>> One consequence of this approach is that you want to make sure that the >>> user is able to control all the flows of information that affect them and >>> that when things break the user should know where and why. That in turn >>> tends towards a protocol architecture where the user is in the hub of all >>> the protocol message flows but I would see that as a (minor) technical >>> consequence of the deeper philosophical approach. >>> >>> >>> On the account identifier approach, I stand by the assertion that the user >>> should recognize their account by means of an identifier of the form >>> [email protected] where idp-service.com is the DNS name of the >>> service provider. >>> >>> Now it may be useful to bind claims referring to other accounts with that >>> form, but that is a separate matter. >>> >>> When the user types in something into a client to configure their service, >>> the string should be [email protected]. >>> >>> Then when they go to the idp-service.com site to configure their service >>> they might bind their gmail and yahoo accounts to it. >>> >>> >>> One other consequence of being user-centric is that it allows for a two >>> point deployment model. I am currently working on an account management >>> protocol that allows me to manage all my usernames and passwords for all of >>> my sites from any browser I have authorized to have access. >>> >>> In this scheme I don't care whether the Huffington Post supports my >>> protocol or not. They don't get a choice. I am storing my username and >>> password for the huffpost in my chosen cloud because that is a very low >>> value data resource to me and I could not give a flying monkey if it is >>> compromised. I just don't care. >>> >>> Now my Fidelity account is another matter. There I care quite a lot. I am >>> not going to put a raw password in there but I might allow it to be used as >>> an additional factor. >>> >>> >>> So in this scheme I will occasionally need to bind a client running on a >>> new machine to the service. And this is one of the few times that I need to >>> expose that account identifier. I give the identifier to the client, >>> authorize the binding using my second factor confirmation and the client is >>> then bound by a public keypair that is unique to that device and cannot be >>> exported. >>> >> >> >> >> >> -- >> Website: http://hallambaker.com/ >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs > _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
