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
