R: One subject, 2 VCs, 2 duplicate properties

Hi Rieks,
are "Credential Catalogue" and "SSI Yellow Pages service" connected in any way with
ESSIV_v2 "trusted schema registry" and "trusted issuer registry"?
My feeling is that ESSIF aims has  institutional view, so registries are authoritative: an issuer listed in the registries should therefore in principle be trusted.
This is possibly applicable to some public services, but hardly scales to most business scenarios. Your approach seems more realistic and in line with certificate policies published by CAs.
Best,
--luca



Da: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl>
Inviato: martedì 18 maggio 2021 07:44
A: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Cc: public-credentials (public-credentials@w3.org) <public-credentials@w3.org>
Oggetto: RE: One subject, 2 VCs, 2 duplicate properties

Q1: Yes, they can, and this is quite fundamental. The issuer of VC1 will create VC1 it using its (subjective) knowledge it has about Erin, and similarly, the issuer of VC2 will use its (subjective) knowledge about Erin. Even if we assume that both issuers are truthful, trustworthy etc., there is always a possibility that they have a different perception of Erins characteristics. While the likelikhood for such differences might be smaller for 'age' than for 'haircolor',  but it is not going to be zero.

Q2: What makes sense to me is that this should not be seen as a problem to solve, but as the reality that we have to deal with. It happens in real life all the time, and we have all sorts of mechanisms to deal with that in real life. What we might do, is provide guidance to parties that want to use VCs so as to make them aware of this reality, and that if they want to request for credentials, it pays (for parties that seek to play the verifier role) to think up front about which VC-types to request, which issuers to request from, and  the assurances that must be in place to use the various claims in received presentations (=validation). This is a design-time activity, and to me it makes sense that issuers advertise the credential-types they are prepared to issue, and not only say what syntax and semantics the VC (payload) will have (which might be standardized for some credential-types), but also the procedures it has followed to determine the veracity of the claims it will be issuing, any assurances to that veracity and anything else that will enable parties that seek to play the verifier role to make the aforementioned determinations. I see all this as the first step to support SSI Assurance Communities.

Rieks

P.S.: TNO has started with a (small) project where we look into how to support issuers in making such advertisements, by designing a tool called "Credential Catalogue" and an associated "SSI Yellow Pages service".

From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Sent: dinsdag 18 mei 2021 07:02
To: public-credentials (public-credentials@w3.org<mailto:public-credentials@w3.org>) <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: One subject, 2 VCs, 2 duplicate properties

Context

  *   Erin is the Subject of 2 Verifiable Credentials: VC1 and VC2
  *   VC1 has 2 properties: "age" and "hairColor"
  *   VC2 has the same 2 properties (by name): "age" and "hairColor"

Questions

  1.  Assuming VC1 and VC2 apply/are valid at the same instant in time, can the value of the "age" property (or the "hairColor" property) be different in V1 compared to V2?
  2.  What makes sense? ...what is realistic? ...how should VCs behave in this regard?

I would prefer/like to have each of VC1 and VC2 share the same underlying values for each of these properties.

Best regards,
Michael Herman
Far Left Self-Sovereignist

Self-Sovereign Blockchain Architect
Trusted Digital Web
Hyperonomy Digital Identity Lab
Parallelspace Corporation

[cid:image001.jpg@01D74D66.31409D00]


This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.