RE: One subject, 2 VCs, 2 duplicate properties

There clearly is a relation, between what is described in the credential manifest’s Abstract (I don’t have the time to read it all) and the Credential Catalogue: I can see that the conditions that allow parties to obtain a credential be documented in the catalogue (in catalogues for real-world stuff, that would e.g. constitute of the price, or if it were booze, an age limit).

I hadn’t seen the manifest, but it occurs to me that a manifest specifies the ‘variables’ that the issuer uses in an (implied) criterion for deciding whther or not to issue a credential of a specific type. If that understanding is not way off, then I would suggest that its contributers generalize this idea into a specification that allows/enables:

  *   any party to define a generic argument (i.e. a predicate+(typed) variables) for making any specific decision;
  *   annotate this argument with criteria for determining whether or not data, when obtained from a given credential, would be considered valid (this is NOT verification) to be used in the argument for the particular decision;
  *   technical components to request presentations from which data can be extracted that satisfy these criteria;
  *   fill in the argument’s variables as presentations are received, and evaluate the argument as soon as possible.
You can use this for issuing credentials. You can use this also for providing every product/service. And other things.

Rieks
From: Oliver Terbu <oliver.terbu@mesh.xyz>
Sent: vrijdag 21 mei 2021 11:03
To: steve.e.magennis@gmail.com; Wayne Chang <wyc@fastmail.fm>; Daniel Buchner <Daniel.Buchner@microsoft.com>
Cc: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl>; Luca Boldrin <luca.boldrin@infocert.it>; Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>; public-credentials <public-credentials@w3.org>; Kruijssen, A. (Age) <age.kruijssen@tno.nl>; Stornebrink, M.H.M. (Michiel) <michiel.stornebrink@tno.nl>
Subject: Re: One subject, 2 VCs, 2 duplicate properties

@Rieks: It sounds like it might relate a little bit to https://identity.foundation/credential-manifest/ ? I'm looping in @Wayne Chang<mailto:wyc@fastmail.fm> and @Daniel Buchner<mailto:Daniel.Buchner@microsoft.com> since they were involved in the DIF CM work (in DIF Claims & Credentials WG).

On Thu, May 20, 2021 at 4:19 PM <steve.e.magennis@gmail.com<mailto:steve.e.magennis@gmail.com>> wrote:
… forking the conversation r.e. Cryptographically Enforceable Issuer Policies
@Joosten, H.J.M. (Rieks)<mailto:rieks.joosten@tno.nl>, how would it be determined if a Verifier satisfies policy conditions? Really interesting idea.

From: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>>
Sent: Thursday, May 20, 2021 2:48 AM
To: Luca Boldrin <luca.boldrin@infocert.it<mailto:luca.boldrin@infocert.it>>; Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Cc: public-credentials (public-credentials@w3.org<mailto:public-credentials@w3.org>) <public-credentials@w3.org<mailto:public-credentials@w3.org>>; Kruijssen, A. (Age) <age.kruijssen@tno.nl<mailto:age.kruijssen@tno.nl>>; Stornebrink, M.H.M. (Michiel) <michiel.stornebrink@tno.nl<mailto:michiel.stornebrink@tno.nl>>
Subject: RE: One subject, 2 VCs, 2 duplicate properties

Hi Luca,

I do not know about the latest developments/details of ESSIF, so what I say may not be quite correct. It is my understanding that ESSIF (not to be confused with eSSIF-Lab!) focusing on the use of the EBSI and EBSI DIDs. It is also my understanding that EBSI/ESSIF and other EBSI usecases hold the (in my percepion centralistic) view that you can use a registry for issuers, schemes and other stuff, all of which are to be considered ‘trusted’ because they are on this EU blockchain. While I do not object to the existence of such registries (whether or not on BCs), I do object against (centralistic) views as that whatever is registered thereon must or should be trusted: to me, that constitutes a violation of principle that I hold, which is that every party (person, organization) is autonomous in whatever decision it choses to make, which obviously holds for every trust decision.

The Credential Catalogue and Yellow Pages services are just some technological components like there are many around. While designed with a decentralized ideas in mind, I can see how they could serve within ESSIF (as tools are oblivious regarding their being used in a (de)centralized fashion).

In order for you to better determine if/how this might fit, let me summarize the main purposes for which we are designing the Credential Catalogue and Yellow Pages services (as technological components), which are:

  *   Support parties that want to perform the role of verifier, by enabling every such party

     *   to find out which kinds of credentials are issued by which parties and which parts thereof it would consider requesting for one or more specific purposes that it pursues (lots more to say about that);
     *   to find out which [credential-type, issuer] pairs come with sufficient (technical as well as non-technical) assurances so as to be valid (qualified) to be used for such specific purposes – obviously, the decision whether or not a set of assurances suffice for a specific purpose is up to this (autonomous) party. Lots more to be said about this as well.

  *   Support parties that want to perform the role of issuer, by enabling every such party

     *   to ‘advertise’ the credential-types that they are willing and capable of issuing, e.g. by providing ways/means to not only specify syntax/semantics (schema’s) of the credential(payload)s themselves, but also by providing ways/means by which to specify the (technical and non-technical) assurances that come with the credentials it issues.
     *   to obtain information (yet to be decided which/how) that allows it to learn what potential users of their credentials want these credentials to be (in terms of schema as well as in terms of assurances).

Later, we want to further develop these tools so that they (also) become more generic support tools for SSI-Assurance Communities (ACs), as introduced in the paper “Decentralized SSI Governance, the missing link in automating business decisions<https://docs.google.com/document/d/1FQTxzQ9z9Tv-WA_UYyfF8AgvEfBYBWRgGvSdjsQof4s/edit#heading=h.cj0pu3kcmf2q>”. We haven’t thoroughly thought about functionalities, but I am contemplating stuff such as:

  *   adding support for governance of credential types by ACs, including mechanisms for discussing and deciding on changes;
  *   adding support for accreditation mechanisms and schemes that AC’s could support;
  *   adding support for the advertising of object-types other than credentials. I think decision trees (i.e. specific ways of reasoning, linking them to credential types and leaving assurance requirements up to the ‘consuming parties’) could be beneficial.

A feature I would like to add that is not already introduced in the paper, but for which I hope to get some text down soon, is support for KeySmith advertisements. We have this idea of introducing a new role, which we provisionally call the KeySmith, that can provide a key-smithing service to both issuing parties and verifying parties, which enables issuers to specify a policy, encrypt (policy+credential) with a key it got from the KeySmith, such that a verifier can only decrypt the encrypted stuff if she has obtained a key from the key smith that was derived from the encryption key AND the verifier actually satisfies the policy. This service would enable ‘Cryptographically Enforceable Issuer Policies’, which have a variety of cool use-cases.

Does this help you?
Rieks
From: Luca Boldrin <luca.boldrin@infocert.it<mailto:luca.boldrin@infocert.it>>
Sent: donderdag 20 mei 2021 10:52
To: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>>; Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Cc: public-credentials (public-credentials@w3.org<mailto:public-credentials@w3.org>) <public-credentials@w3.org<mailto:public-credentials@w3.org>>; Luca Boldrin <luca.boldrin@infocert.it<mailto:luca.boldrin@infocert.it>>
Subject: 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<mailto:rieks.joosten@tno.nl>>
Inviato: martedì 18 maggio 2021 07:44
A: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Cc: public-credentials (public-credentials@w3.org<mailto:public-credentials@w3.org>) <public-credentials@w3.org<mailto: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@01D74E34.9B1BB830]


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.