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. 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
