Re: Data model abstract

Thankyou, this clarifies things. I have in a separate thread raised the
issue about registering identifiers, and whether this is mandatory or
not, especially when the ID is a public key. I suggest we discuss this
issue there, rather than in this thread, which we can conclude here.

regards

David

On 13/06/2016 19:34, Dave Longley wrote:
> 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.
> 
>

Received on Tuesday, 14 June 2016 07:53:40 UTC