Dick - it seems like you may be conflating authentication with identity. OpenID Connect provides a framework for multiple claims issuers. I believe the claims aggregation and distributed claims capabilities in Connect provide the potential to scale your interested in.
- cmort On Jul 20, 2011, at 5:16 PM, "Dick Hardt" <[email protected]> wrote: > 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 _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
