- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Mon, 13 Jun 2016 14:34:15 -0400
- To: David Chadwick <d.w.chadwick@kent.ac.uk>, W3C Credentials Community Group <public-credentials@w3.org>
On 06/13/2016 11:26 AM, David Chadwick wrote: > > > On 13/06/2016 15:34, Dave Longley wrote: >> On 06/12/2016 03:52 PM, David Chadwick wrote: >>> I would like to suggest a change to the latest data model >>> document http://opencreds.org/specs/source/claims-data-model/ >>> >>> Specifically, the document abstract currently says >>> >>> A TBD credential is a set of claims made by an entity about an >>> identity. A TBD credential may refer to a qualification, >>> achievement, quality, or other information about an identity such >>> as a name, government ID, home address, or university degree that >>> typically indicates suitability. >>> >>> The problem I have with this, is that the set of claims are >>> being made about an identity, rather than the set of claims >>> actually being the identity. In my opinion the above is in direct >>> contradiction to the first sentence of the abstract which says >>> 'An identity is a collection of attributes about an entity'. >>> >>> I would therefore like to change the abstract to read >>> >>> A TBD credential is a set of claims made by one entity (the >>> issuer) about another entity (the holder). A TBD credential may >>> refer to a qualification, achievement, quality, or other >>> information about the entity. A set of credentials forms one of >>> possibly many identities of the entity. >>> >>> If this is agreed, then other similar changes will be needed >>> throughout the document such as: a collection of digital TBD >>> credentials that assert claims about that identity. TBD >>> Credentials are associated with identities etc. >> >> I don't see the same contradiction, so the language is failing in >> one way or another. I consider "an identity" to be the superset of >> all possible sets of credentials. A set of credentials is merely a >> profile of that identity. > > Can I ask you "how many identities can a subject have?". Your > sentence above implies the answer is one. If so, then we have a > fundamental disagreement I think if I try to answer that question tersely it may only introduce more misunderstanding. I think it's better to talk about identifiers than about "identities". When I have talked about "Identity" in the data model, I'm merely talking about marking a "thing" with a "type" so that a Verifiable Claims piece of software can easily distinguish it as a subject that claims have been made about vs. some other thing that the software is disinterested in. That's it; that's the scope of it. As a human being using this architecture, you are never a "subject". Some aspect of you or some way in which you present yourself can be a subject, but that is an abstraction of "who you are". In fact, "who you are" is different depending on the audience -- and over time. If we start getting into "what is identity?" questions, we start getting bogged down into complex ontological discussions. I prefer to avoid those in this particular forum. I've been too busy to respond in depth to the recent pseudonym discussion, but in short, the identifiers that anyone may register with an Identity Registry are just that -- pseudonyms. You can create as many of these as you like. It's up to you (and software) to manage these to help you do what you want to do. Every one of these identifiers simply provides a label to ensure we're talking about "the same thing". That's all that is meant by "identity". It refers to a subject we can make claims about in the Verifiable Claims ecosystem. Whether a subject is meant to refer to "the identity you use to present your public self to the world", or "the identity you use to present yourself to some particular community", or "the identity you use to open bank accounts", or "a cat" doesn't really matter. The number of these things is unbounded. To make this more practical... Here's how I view the architecture, from the perspective of a human being who wants to use the system. One use case is that I have some legal documents about me that I'd like to convert into digital credentials so I can present them to websites as needed. In order to do this, I first must go out and register an identifier on an Identifier Registry. After I do that, I need go to the appropriate issuers (via their websites on in person) and present evidence of who I am and the identifier I'd like them to associate my credentials with, along with proof of ownership over that identifier. I may decide that I want actually want more than one identifier -- in which case I'll register more and then decide which I want to give out to whom to have my credentials associated with. In the simplest case, I'm going to have my driver's license and my birth certificate credentials associated with the same identifier that I plan on using to register for things like bank accounts or a passport. I have no need for more than one identifier in this case -- and those credentials carry a lot of PII anyway, so they are inherently linkable. When I share these things, I'll agree to some legally binding privacy policy that the recipient must not breach. Now, I may also want to obtain a credential that just says I'm over 21, so I can buy adult beverages online. In order to obtain this, I will present my driver's license credential to an appropriate issuer. My "over 21" credential will be assigned to the same identifier as my driver's license, but when I use it, I don't want to share that identifier. Instead, when I visit a website to buy adult beverages, I will check the "share anonymously" box and some TBD technical details will cause my credential to be rewritten to include a new identifier that cannot be linked to the original one. There are a variety of ways to do this -- with various trade offs. The point is that this privacy-enhancing feature can be built on top as a layer. The above are some of the core features of the ecosystem related to "identity", but I think we can largely talk about them by just referring to "identifiers". We may avoid miscommunication and scope creep that way. -- Dave Longley CTO Digital Bazaar, Inc. http://digitalbazaar.com
Received on Monday, 13 June 2016 18:34:41 UTC