RE: One subject, 2 VCs, 2 duplicate properties

… forking the conversation r.e. Cryptographically Enforceable Issuer
Policies

 <mailto:rieks.joosten@tno.nl> @Joosten, H.J.M. (Rieks), how would it be
determined if a Verifier satisfies policy conditions? Really interesting
idea.

 

From: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl> 
Sent: Thursday, May 20, 2021 2:48 AM
To: Luca Boldrin <luca.boldrin@infocert.it>; Michael Herman (Trusted Digital
Web) <mwherman@parallelspace.net>
Cc: public-credentials (public-credentials@w3.org)
<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

 

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_UYyfF8AgvEfBYBWRgGvSdjsQ
of4s/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

 



 

 

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.