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" <[email protected]> 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 <[email protected]> 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" <[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
