Re: Subject vs. claims

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.