W3C home > Mailing lists > Public > public-credentials@w3.org > September 2022

RE: Funded Deployments of Verifiable Credentials - framework for meta-credentials

From: Deventer, M.O. (Oskar) van <oskar.vandeventer@tno.nl>
Date: Mon, 5 Sep 2022 10:02:29 +0000
To: W3C Credentials CG <public-credentials@w3.org>, "Sporny, Manu" <msporny@digitalbazaar.com>
Message-ID: <990f8aa859974d6bb93279038fccd732@tno.nl>
Hi Manu, all,

Is there already ongoing work on “meta-credentials”, or should there be in W3C-CCG?

Verifiable credentials are always associated with some assurances.

  1.  The issuer is trusted to issue this type of credential (https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0289-toip-stack#discovery-and-verification-of-authoritative-issuers)
  2.  The verifier is authorized to verify this type of credential (https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0289-toip-stack#discovery-and-verification-of-authoritative-verifiers)

The former is the regular decision of a verifier to trust an issuer. The latter relates e.g. to the European eIDAS requirement that a verifier needs to be authorized to verify certain sensitive government-issued credentials.

Internet-reachable trust lists are the default solution to check whether an issuer or verifier is accredited to issue/verifier a certain type of credential, for example the EBSI Trusted Issuers Registry<https://ec.europa.eu/digital-building-blocks/wikis/display/EBSIDOC/Trusted+Issuers+Registry+API> or other (Fraunhofer-TRAIN<https://essif-lab.eu/essif-train-by-fraunhofer-gesellschaft/>). However, internet-reachable trust lists have some major disadvantages.

  1.  They don’t work in offline scenarios
  2.  The “phone-home” interaction leaks information (=privacy)

An obvious alternative is meta-credentials, i.e. credentials about being authorized to issue/verify a certain type of credential. This alternative had already been highlighted in the aforementioned TOIP RFC 0289<https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0289-toip-stack#defining-a-governance-framework>. There are many credential types, and potentially equally many of these meta-credentials. Nevertheless, it may be useful to develop a framework that enables automated verification of meta-credentials. At least it should be automatically verifiable whether a presented meta-credential is applicable to the type of credential that is requested or presented. Perhaps W3C could develop a generic solution for this?

Any thoughts?

Best regards,


-----Original Message-----
From: Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>
Sent: zaterdag 27 augustus 2022 20:48
To: W3C Credentials CG <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Funded Deployments of Verifiable Credentials

Hi everyone (VCWG BCC'd),

I've been asked to do a presentation around funded deployments of Verifiable Credentials at multiple upcoming conferences (W3C TPAC, RWoT, etc.) and don't feel like I have a firm grasp of every publicly funded Verifiable Credential deployment happening around the world.

If you are funded to pilot or productionize a system that uses DIDs or Verifiable Credentials, and you are comfortable with talking about the program publicly, please add details to this slide deck:


I know I'm missing publicly announced projects from MATTR, Mesur.io, Mavennet, Transmute, and possibly Avast, ESSIF, the German government, and others. If you know of someone that's not on these lists, but is deploying VCs and DIDs, please send this request to them.

The first presentation is in two weeks, so please add your projects into the deck before then.

-- manu


Manu Sporny - https://www.linkedin.com/in/manusporny/

Founder/CEO - Digital Bazaar, Inc.

News: Digital Bazaar Announces New Case Studies (2021) https://www.digitalbazaar.com/

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.
Received on Monday, 5 September 2022 10:02:47 UTC

This archive was generated by hypermail 2.4.0 : Monday, 5 September 2022 10:02:48 UTC