Re: Subject vs. claims

The point, as I read it, is that it’s not a slam-dunk for someone
unfamiliar with DID and VC to explain the difference between physical and
digital. Saying it’s privacy too tersely, actually may add to the confusion
because in the examples of a driver or doctor license, when used as
intended, privacy is not an issue. @Chadwick’s point seems to be addressing
a side-effect of physical credentials rather than @Ammouial’s point.

I agree, the difference IS privacy, but in order for me to expliain that, I
would have to introduce the concept of self-sovereignty on the part of the
subject. I would then have to relate how self-sovereignty impacts the
primary use of the credential where privacy is not really an issue for any
of the three parties.

When I present a VC to establish a new relationship, for example, KYC with
a bank, I would hope and expect that they use the DID as the persistent key
for the new row they create in their subjects table. This does not
represent any privacy issues. The credentials linked to that DID are public
by design.

Isn’t this the answer to the original question?

Can this be explained other than by reference to self-sovereignty?

Adrian



On Fri, Jan 11, 2019 at 5:15 AM David Chadwick <D.W.Chadwick@kent.ac.uk>
wrote:

> Hi David
>
> the difference between today's physical credentials and our future
> standard electronic VCs is privacy protection. Physical credentials do
> not provide privacy protection as your examples show. On the other hand
> VCs do. Consequently the VC format is different and essentially says:
>
> the subject, who is identified by this random URI, has this attested
> attribute.
>
> The random URI might be a DID, or anything else.
>
> I hope this answers you question
>
> David
>
> On 10/01/2019 20:46, David Elie Raymond Christophe Ammouial wrote:
> > Hello WG,
> >
> >
> >
> > There’s a concept I’ve been wanting to propose to the group, in the hope
> > to challenge it, refine it, possibly include it, or maybe dismiss it
> > altogether.
> >
> >
> >
> > I’ve been looking at typical credentials around me and at what
> > information they carry:
> >
> >   * Company photo check (badge): Name, picture, government ID number,
> >     employee number, and implicitly being an employee
> >   * Taxi driver credential: Name, picture, government ID number,
> >     geographical area of authorised driving, car plates, credential
> >     number, and implicitly being authorised to operate as a taxi driver
> >   * Diploma: Name, title obtained (maybe with a specialty, honours, etc.)
> >   * Peruvian government ID: Name, government ID number, marital status,
> >     birth date, gender/sex, postal address, organ donor bool
> >   * Etc.
> >
> >
> >
> > It looks to me like most credentials are in fact split into two
> > semantic/conceptual parts, even though it’s not always evident visually:
> >
> >   * *Who*is the credential about? (“Who” in the broad sense of identity,
> >     it could be an organization or even an object.)
> >       o You can also think of this as “if”, or precondition.
> >   * *What*does the credential say about that entity?
> >       o You can also think of this as “then”, or conclusion.
> >
> >
> >
> > I think that difference is crucial, in the sense that a taxi driver
> > badge is not saying “that person’s name is XXXX and their government ID
> > is YYYY”. At the contrary, it’s saying that IF someone has this face,
> > name and government ID, THEN they’re authorised to operate as a taxi
> > driver. On the other hand, a government ID says “IF someone has this
> > face, THEN they have this name and this ID number”. In other terms, some
> > of the claims are about identifying the subject, while the others are
> > the actual attested information, and which claims belong to which group
> > vary from credential to credential. One common aspect seems to be that
> > the picture is always an identification claim, and never one of the
> > attested claims. Except for government-issued credentials, name seems to
> > always be an identification claim as well.
> >
> >
> >
> > I can’t really unsee it now that I’m starting to see it in actual
> > credentials, and I think it’s very important to mark that difference
> > formally, because the whole purpose of a credential is about what it
> > attests to (and what it doesn’t). Such semantic ambiguity could be a
> > problem in some situations. Reversely, separating the two roles could
> > help creating more relevant digital tools.
> >
> >
> >
> > I didn’t find any discussion about this topic, and the specification
> > doesn’t seem to mention it either, so I’m curious about what others
> > think. I realise we’re in a stage of spec freezing, so I hope it’s not
> > too late to bring this kind of stuff up.
> >
> >
> >
> > Best regards.
> >
> > David
> >
> >
> > ------------------------------------------------------------------------
> >
> > AVISO DE CONFIDENCIALIDAD.
> > Este correo y la información contenida o adjunta al mismo es privada y
> > confidencial y va dirigida exclusivamente a su destinatario. everis
> > informa a quien pueda haber recibido este correo por error que contiene
> > información confidencial cuyo uso, copia, reproducción o distribución
> > está expresamente prohibida. Si no es Vd. el destinatario del mismo y
> > recibe este correo por error, le rogamos lo ponga en conocimiento del
> > emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo
> > de ningún modo.
> >
> > CONFIDENTIALITY WARNING.
> > This message and the information contained in or attached to it are
> > private and confidential and intended exclusively for the addressee.
> > everis informs to whom it may receive it in error that it contains
> > privileged information and its use, copy, reproduction or distribution
> > is prohibited. If you are not an intended recipient of this E-mail,
> > please notify the sender, delete it and do not read, act upon, print,
> > disclose, copy, retain or redistribute any portion of this E-mail.
>
> --

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: https://patientprivacyrights.org/donate-3/