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. >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
