Fair point; we're still working on protocol substrates, but believe this UX will be able to be built. There is an added advantage of having a formal model for the authentication provider to provide claims aggregation or introduction in a way that a pure user-centric model cannot easily do without an active client

- cmort
On Jul 20, 2011, at 9:34 PM, "Dick Hardt" wrote:

Per Mike's comments, I don't see where the UX for multiple claims
happens - or is there a spec I'm missing?

-- Dick
On 2011-07-20, at 8:28 PM, Chuck Mortimore wrote:

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


- John

On Wed, Jul 20, 2011 at 1:47 PM, Dick Hardt wrote:

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 username at idp-service.com 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 username at idp-service.com.

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
specs at lists.openid.net
specs mailing list
specs at lists.openid.net

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2021 Grokbase