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
