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 <wyc@fastmail.fm> and @Daniel Buchner
<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> wrote:

> … forking the conversation r.e. Cryptographically Enforceable Issuer
> Policies
>
> @Joosten, H.J.M. (Rieks) <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>
> *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_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>
> *Sent:* donderdag 20 mei 2021 10:52
> *To:* Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl>; Michael Herman
> (Trusted Digital Web) <mwherman@parallelspace.net>
> *Cc:* public-credentials (public-credentials@w3.org) <
> public-credentials@w3.org>; Luca Boldrin <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>
> *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>
> *Sent:* dinsdag 18 mei 2021 07:02
> *To:* public-credentials (public-credentials@w3.org) <
> 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.
>