Re: Subject vs. claims

The reason the issuer laminates a drivers license photo and date of birth
is to prevent self-sovereign dissociation of the ID (DID), identity
(photo), and an attribute (DOB), bound by the signature of the issuer as
laminator. In some cases, the subject wants to present only a binding of
the identity (photo) and the attribute or ZKP to prevent privacy leaks. In
other cases, presenting the ID and photo are sufficient and the attribute
(DOB) is irrelevant. In both cases, the issuer’s signature as laminator is
essential.

Can someone point me to our explanation of digital credentials in this
simplest of cases?

Adrian

On Fri, Jan 11, 2019 at 12:00 PM David Chadwick <D.W.Chadwick@kent.ac.uk>
wrote:

> Hi David
>
> you are correct in observing that the photo is there for identification
> and authentication of the subject. This is what humans are good at
> doing: seeing a face (identification) and matching it to a picture (authn).
>
> So it should also be obvious that for digital VCs, processed by
> computers, the above method is not optimum for identification and
> authentication. So we dont need to add photos to VCs. We need something
> that computers are good at processing. We have chosen to use
> cryptography, in the shape of either public key cryptography or ZKPs.
> The crypto key is tightly bound to the subject's ID (URI) so that the
> subject can be authenticated, but NOT identified.
>
> This is because it has everything to do with privacy. If it did not, we
> could identify the VC subject with personally identifying information.
> But we dont. We use an anonymous URI instead, in order to protect the
> subject's privacy.
>
> Now if the subject wants his/her photo to be an asserted attribute (and
> to lose his/her anonymity) then the answer is to bind the photo to the
> ID. By proving you own the ID, you prove to the verifier that this is
> your photo
>
> I hope this helps
>
> David
>
>
>
>
> On 11/01/2019 16:26, David Elie Raymond Christophe Ammouial wrote:
> > Hi David, Adrian, thanks for your answers.
> >
> >
> >
> > I understand David’s point in that the identification part of the
> > credential, as its name says, is the “id” (or “@id”, still confused
> > about the difference or lack thereof) attribute. So any way to refer to
> > the subject of a credential is to go there, while the rest of the claims
> > carry the actual attested information. That’s fair enough, and that does
> > answer my question, so thank you.
> >
> >
> >
> > (FWIW, I don’t think it has to do with privacy or self-sovereignty
> > though, but rather with formalising semantics clearly. Physical
> > credentials mix identification and claims, while digital credentials
> don’t.)
> >
> >
> >
> > I’d like to go back to name-and-picture identification. Most real-world
> > credentials identify their subject through their name and a picture of
> > their face, because that’s how we as relying parties authenticate people
> > in real life. If I take a cab and I want to know if the driver is the
> > authorised one, I will look at their face and compare it with the
> > picture on the credential. I’ll probably want to do that even if I got
> > the credential in a digital and verifiable format (e.g. through a mobile
> > app).
> >
> >
> >
> > If I could rewrite all the world’s tools and procedures, I would
> > probably switch all authentication to DID Auth. Fortunately, we don’t
> > have to wait until then for VCs to be useful, because you can still
> > verify a VC’s proof whatever the identification and authentication
> > mechanism is (i.e. whatever the semantics of the “id” attribute and the
> > way to check it). I guess that’s why VC and DID are separate specs in
> > the first place.
> >
> >
> >
> > So my follow-up question is: how would you use the “id” attribute to
> > describe a physical subject meant to be authenticated visually? Would it
> > make sense to accept as value a “Person” object containing identifying
> > properties? Or maybe use the “sameAs” attribute for that kind of content?
> >
> >
> >
> > Thanks.
> >
> > David
> >
> >
> >
> >
> >
> > *From: *Adrian Gropper <agropper@healthurl.com>
> > *Date: *Friday, January 11, 2019 at 07:58
> > *To: *David Chadwick <D.W.Chadwick@kent.ac.uk>
> > *Cc: *"public-vc-wg@w3.org" <public-vc-wg@w3.org>
> > *Subject: *Re: Subject vs. claims
> > *Resent-From: *<public-vc-wg@w3.org>
> > *Resent-Date: *Friday, January 11, 2019 at 07:57
> >
> >
> >
> > 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
> > <mailto: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/
> >
> >
> > ------------------------------------------------------------------------
> >
> > 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/