https://www.youtube.com/watch?v=GIgTk2ryk8I
This project is a building block for the interoperable usage of W3C verifiable credentials to prove the immunization status of an user. It makes use of W3C compliant DIDs and VCs to verify any kind of immunization health pass that's presented to a verifier. Its operational goals are to provide a high level, extendable SDK/API and sample implementations to:
- allow any verifier app to reliably resolve DIDs, check credential signatures, schema, semantics and the claim's medical content itself
- interoperate with as many user wallets / communication scenarios and credential strategies used by EHRs or health applications on planet earth
- utilize (draft) standards for inter-agent operations, e.g by using Aries/DIDComm, DIFs Universal Resolver, Verifiable Presentations or Credential Presentation Requests as specified by
- demonstrate how to look up / query for and validate a chain of arbitrary credentials to ensure the credential issuer can actually be trusted.
- support an extensible range of immunization credential schemas since health credentials aren't internationally standardized (yet, but approaches using FHIR or JSON-LD data are the most promising ones).
Linux Foundation / Covid Credentials Initiative (CCI), the Vaccination Credential Initiative (VCI), Good Health Pass are the most well known working groups that strive to specify a worldwide standard for vaccination crdentials, including their creation, derivation and attestation.
If all that "identity" / DID stuff is totally new to you and you need a soft introduction, we've got you covered: checkout our docs about Verifiable Credentials for health applications. It should explain most concepts rather well and contains even more pointers to basic concepts.
This is a monorepo built on pnpm workspaces. Get a global pnpm if you haven't got one already by:
npm install -g pnpm
At the moment we support two DID methods: ethr and key. The ethr method relies on blockchain lookups. We prepared a local ganache chain in the docker-compose file. Run docker-compose up -d to bring it up.
Since during development we're relying on a local ethr did registry we must deploy a registry on our local ganache blockchain. Cd into univax-core and pnpm run contracts should to that. Take down the deployed contrat's address and put it in your .env.local files.
We're using Typescript. Most tsconfigs extend the root tsconfig.json. We rely on eslint and use dotenv-flow for env configurations. .env are sample files and go into VCS, you override them by .env.local files.
These are the main packages relevant at the moment:
comes with foundational classes and no interactivity or environmental assumptions. For signing and credential creation is relies on the @transmute crypto libraries and makes use of did-jwt and did-jwt-vc which are primarily supposed to interact with EcDsa256 keypairs. The library also supports EdDSA25519 signatures and contains code to add and verify ed25519 public keys to a did:ethr identity. The resolver is configured to resolve did:ethr (on any network, when providing an Infura API key) and did:key.
is a mostly isolated cli demonstrating the use of univax-core. Contains interactive tools to interact with the code found in univax-core. Most noteably, we're not really building a cli wallet but for convenience we're relying on the aliases.json file that keeps track of public and private keys (based on ganache's public seed myth like bonus scare over problem client lizard pioneer submit female collect). Make triple sure to never put any real secret into the aliases.json file! It's going to be removed from VCS when someone adds a little agent / wallet functionality that makes it obsolete. The CLI foundation is Oclif which is somewhat proposed by the official Typescript website.
is a preliminary, very light weight backend server that offers two APIs:
-
commis a non-standard, Server Sent Events based backbone for asynchronous client communication. Roughly related to DidComm (but not compatible!) and highly inspired by Jolocom's interaction tokens flow. -
vcis a proprietary verifiable credential registry that we use to request credentials that are not presented by the prover herself, e.g. to lookup credentials that someone has claimed about the issuer (doctor).
provides shared components for frontends, particularly an identity context that yields resolver, issuer and verifier services. Also adds hooks that create a randomized local did:ethr and offers local credential storage (for provider and patient).
a provider demo that lets an user provide generic immunization related values. Issues credential offers and reacts to their responses by issuing and transferring credentials to patients.
a patient wallet that allows accepting and presenting credentials.
a verifier that displays presentiation requests for validateable credential types and validates presented credentials according to all known verification strategies.
https://docs.google.com/drawings/d/13b9sgbuBdMUyieHmv9rLTJEK8jzxQr-jtFhBX3_Ox9E/edit https://docs.google.com/drawings/d/1WAYKZuJconP5IY7ZivE2VdVv0udourOjaEUOW1Kjs88/edit https://docs.google.com/drawings/d/1tlYGOYkzx7LOUWkncpYN8j2ZdULznufuDyzinlpTq24/edit
An umbrella initiative for VCI / CCI and others is the Good Health Collaborative: https://www.goodhealthpass.org/ , comes with a whitepaper and a Blueprint Draft
Linux Foundation Public Health Covid Credential Initiative (LFPH CCI)
- https://www.covidcreds.org/
- https://www.lfph.io/2020/12/16/press-release/
- https://www.youtube.com/watch?v=ionT4gvM4Os
Vaccination Credential Initiative
(Microsoft, Oracle, Salesforce etc)
European Health Network (EHN) Specs and Reference implementations
https://github.com/ehn-digital-green-development
https://github.com/ehn-dcc-development
https://github.com/ehn-dcc-development/ehn-dcc-schema
Spherity / SAP Reopen
IATA Travel Pass Initiative
Digital Immunization Passport
Meta.me Hlth.id https://metame.com/ https://hlthid.com/
Hlth.id also supported in https://www.healthcerts.gov.sg/
DIVOC is an open standard for vaccination proofs and used all over India https://divoc.egov.org.in/ and here's their verifier: https://verify.cowin.gov.in/
NY Excelsior Pass (based on IBM's Digital Health Pass) https://www.business-standard.com/article/current-affairs/with-ibm-help-new-york-first-state-in-us-to-launch-vaccine-passport-121032800535_1.html
David Janes / CCCC4 / Consensas opinion: https://www.yogitatrainingcenter.com/w3c-verifiable-credentials-the-fairly-odd-blueprints-by-david-janes-consensas-feb-2021/
https://techcrunch.com/2021/01/19/europe-is-working-on-a-common-framework-for-vaccine-passports/
curated list of all vaccination passport providers in the world (David Janes) https://docs.google.com/document/d/1MQfZzlkYkXCXvnUXd7Cd6Y5g0RRXrKxGGqVcbBnSk1k/edit
a really valuable recording of ID4Africa's April'21 session https://www.youtube.com/watch?v=2Ud4SWCShDA
a talk by truu / evernym on that matter https://www.youtube.com/watch?v=iCL5bddCTtI
FHIR4 immunization general https://www.hl7.org/fhir/immunization.schema.json.html
Paul Knowles' / John Walker's (CCI) effort to bring together jurisdicational dependent and global credential specs: https://drive.google.com/drive/u/1/folders/1h4vF79KzUY6KipBt3A6kMEboiqcSYtv7
Immunization Schema Survey https://docs.google.com/document/d/1a4j0-6kJonEfSlX50ZEfAEbx2ab2IW8UuBK8vigsoLU/edit#heading=h.y43f7b8rk9yr
List of paper based vaccine credentials https://www.lfph.io/wp-content/uploads/2021/03/CCI-Paper-Based-VC-Summit-Summary-Report.pdf
A paper based, compressed credential by PathCheck https://vaccine-docs.pathcheck.org/ https://github.com/Path-Check/paper-cred/ https://github.pathcheck.org/vial.html
IBM's Digital Health Pass https://www.ibm.com/products/digital-health-pass
https://w3id.org/vaccination/ -> https://w3c-ccg.github.io/vaccination-vocab/ https://w3c-ccg.github.io/vaccination-vocab/context/v1/index.json https://w3c-ccg.github.io/vaccination-vocab/context/v1/EU/unstable.json
(John Walker & Mukund Parthasarathy) https://github.com/SemanticClarity/labtest-results-vocab/
The preliminary FHIR4 spec, driven by M$ Smart Health Cards project & DVCI: http://build.fhir.org/ig/dvci/vaccine-credential-ig/branches/main/ -> https://github.com/dvci/vaccine-credential-ig
M$ Smart Health Cards initiative bundles FHIR/HL7 information into health credentials https://github.com/microsoft-healthcare-madison/health-wallet-demo/blob/master/src/fixtures/vc.json Covid 19 sample: https://github.com/microsoft-healthcare-madison/health-wallet-demo/blob/master/src/fixtures/vc.pcr.json (in action: https://smarthealth.cards/credential-modeling/)
http://build.fhir.org/ig/dvci/vaccine-credential-ig/branches/main/
Helpers for FHIR / JSON-LD schematics https://github.com/fhircat
unofficial draft of a W3C vaccination model
https://github.com/Spherity/Pathogen-Vocab
CCCC4 initiative's schema, based on a Canadian effort, driven by Consensas e.a. https://docs.google.com/document/d/1pCyS_lhbMGhOkq1jFEkI_od-9QunURKzGWA7ty5DCII/edit
Schema.org can be utilized for that: https://schema.org/docs/meddocs.html https://schema.org/docs/health-lifesci.home.html https://schema.org/MedicalTherapy
it's impl and extended by Consensas: https://github.com/Consensas/information-passport/blob/main/docs/Vaccination.md and a sample: https://consensas.world/did/did:cns:ABMY2TCODB.json
yet another weird medical coding standard https://loinc.org/downloads/loinc-table/ Loinc Covid19 specs: https://loinc.org/sars-cov-2-and-covid-19/
https://repository.immregistries.org/resource/hl7-version-2-5-1-implementation-guide-for-immunization-messaging-release-1-5-1/ (slighty unrelated, mainly deals with communication aspects)
https://cvc.canimmunize.ca/docs/#/
https://www.cdc.gov/vaccines/programs/iis/downloads/business-rules.pdf
pointing to detailed vaccination code sources (CVX / MVX):
CVX (Vacc codes): https://www2a.cdc.gov/vaccines/IIS/IISStandards/vaccines.asp?rpt=cvx MVX (Vacc manufacturer codes): https://www2a.cdc.gov/vaccines/IIS/IISStandards/vaccines.asp?rpt=mvx CPT (Snomed?) -> CVXmappings: https://www2a.cdc.gov/vaccines/IIS/IISStandards/vaccines.asp?rpt=cpt
specs on how CDC is storing and representing immunization data in various use cases: https://www.cdc.gov/vaccines/programs/iis/about.html https://www.cdc.gov/vaccines/programs/iis/functional-standards/func-stds-v4-1.html https://www.cdc.gov/vaccines/programs/iis/technical-guidance/downloads/hl7guide-1-5-2014-11.pdf
Vaccination proof interop guidelines by the European Union: https://ec.europa.eu/health/sites/health/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf
Trust framework / interop requirements https://ec.europa.eu/health/sites/health/files/ehealth/docs/trust-framework_interoperability_certificates_en.pdf
EU Standardised Data set: https://ec.europa.eu/health/sites/health/files/preparedness_response/docs/covid-19_rat_common-list_en.pdf
Press Release on EU gateway: https://ec.europa.eu/commission/presscorner/detail/en/IP_21_2721
Customer facing info site: https://ec.europa.eu/info/live-work-travel-eu/coronavirus-response/safe-covid-19-vaccines-europeans/eu-digital-covid-certificate_en
Digital Green Certificate overview https://ec.europa.eu/health/ehealth/covid-19_en
European legislation: https://ec.europa.eu/commission/presscorner/detail/en/ip_21_1181 -> law: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52021PC0130
as discussed by Evernym: https://www.evernym.com/blog/eu-digital-green-certificate-program/
and debated on TC: https://techcrunch.com/2021/03/17/europes-rush-for-a-covid-19-digital-pass-stirs-concerns/
(WHO) A call for participation https://www.who.int/news-room/articles-detail/call-for-public-comments-interim-guidance-for-developing-a-smart-vaccination-certificate-release-candidate-1
Qatar open data: https://www.data.gov.qa/explore/dataset/h4-vaccination/information/
Lumedic https://www.lumedic.io/
Singapore wallet with Open Attestations support https://github.com/Open-Attestation/identity-wallet
Healthcerts usage at Singapore
- Further information on HealthCerts: https://go.gov.sg/hc
- Notαrise: Platform for digital documents to be officiated by the Singapore Government: www.notarise.gov.sg
- Open-sourced information on Verify (Platform for authorities to confirm authenticity and legitimacy of digital certificates): https://go.gov.sg/oaverify
- For more information on Singapore’s open-sourced e-wallet reference implementation: https://go.gov.sg/oawallet
- For more information on Open Attestation: https://go.gov.sg/oa
- HealthCerts accredited partners: https://go.gov.sg/hcproviders
- To collaborate on HealthCerts: https://go.gov.sg/healthcertscollab
- Medium blog articles on HealthCerts (2 part article) https://go.gov.sg/hcblog1 https://go.gov.sg/hcblog2
- To view video on HealthCerts: https://go.gov.sg/hcvid https://go.gov.sg/hc
A ruby impl of health cards (DVCI) https://github.com/dvci/health_cards
https://w3c-ccg.github.io/did-primer/ https://www.w3.org/TR/did-core/#a-simple-example https://www.w3.org/TR/vc-data-model/#proofs-signatures https://www.w3.org/TR/vc-data-model/#linked-data-proofs
The official, generic universal DIF DID resolver: https://github.com/decentralized-identity/universal-resolver
Specs & links to lots of Method implementations https://w3c.github.io/did-spec-registries/#did-methods
Did resolution process definition https://w3c-ccg.github.io/did-resolution/
A lot of use case samples (maily non tech) https://www.w3.org/TR/did-use-cases/
Mattr is a cli tool for all kinds of DID / VC ops https://mattr.global/ APIs: https://learn.mattr.global/
https://verifier.interop.transmute.world/
https://www.w3.org/TR/vc-data-model/ https://www.w3.org/TR/vc-imp-guide/
A nonfinal vc http api interface spec https://github.com/w3c-ccg/vc-http-api
https://w3c-ccg.github.io/vc-extension-registry/#proof-methods
DIF specs https://github.com/decentralized-identity/claims-credentials
Credential Status Registry https://w3c-ccg.github.io/vc-csl2017/#introduction
Open Attestation is a chain based credential storage https://www.openattestation.com https://www.openattestation.com/docs/getting-started/
Related to attestations: Open Certs https://www.opencerts.io/
https://w3c-ccg.github.io/vp-request-spec/ needed to request a credential from a holder
https://identity.foundation/presentation-exchange/ https://github.com/decentralized-identity/presentation-exchange https://w3c-ccg.github.io/vp-request-spec/ needed to request a credential from a holder
https://www.evernym.com/blog/getting-to-practical-interop-with-verifiable-credentials/
Defines a transport agnostic, encrypted, eventually signed, routable, fully async protocol to transfer messages between DIDs.
General Specification for connection interactions: https://didcomm.org/, https://github.com/decentralized-identity/didcomm-messaging
Specs: https://identity.foundation/didcomm-messaging/spec/
Jolocom's /(DIF) Rust impl https://github.com/jolocom/didcomm-rs/blob/main/README.md https://github.com/decentralized-identity/didcomm-rs (and an earlier js implementation: https://github.com/decentralized-identity/DIDComm-js)
A good overview of supported DID-Auth schemas
https://nbviewer.jupyter.org/github/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/final-documents/did-auth.pdf
or:
(https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/final-documents/did-auth.md)
is a reference impl for DIDComm + information exchange on top of Hyperledger Indy. Most RFCs can be considered de facto standards:
lots of specs that are relevant for interoperable credential exchange protocols. Supposed to be the DIDComm foundation: https://github.com/hyperledger/aries-rfcs/blob/master/index.md
an early JS implementation: https://github.com/hyperledger/aries-framework-javascript
https://github.com/hyperledger/aries-rfcs/blob/master/features/0160-connection-protocol/README.md#0-invitation-to-connect (superseded by: https://github.com/hyperledger/aries-rfcs/blob/master/features/0023-did-exchange/README.md)
ideas of communication, multi clients / keys, encapsulated in a DID doc conventions: https://github.com/hyperledger/aries-rfcs/blob/master/features/0067-didcomm-diddoc-conventions/README.md
credentials (1 -> 2):
old: https://github.com/hyperledger/aries-rfcs/blob/master/features/0036-issue-credential/README.md
https://github.com/hyperledger/aries-rfcs/blob/master/features/0453-issue-credential-v2/README.md
present proof protocol (1 -> 2): old: https://github.com/hyperledger/aries-rfcs/blob/master/features/0037-present-proof/README.md https://github.com/hyperledger/aries-rfcs/blob/master/features/0454-present-proof-v2/README.md
message spec: https://github.com/hyperledger/aries-rfcs/blob/master/features/0510-dif-pres-exch-attach/README.md (also see DIF presentation-exchange, above)
out of band protocols (QR Codes): https://github.com/hyperledger/aries-rfcs/blob/master/features/0434-outofband/README.md
is a public dlt to store DIDs and decentralize vc issuer credentials. https://sovrin.org/test-sovrin-tokens/ based on hyperledger indy. test directly on indy: https://sovrin.org/wp-content/uploads/Token-Test-Instructions.pdf
At the moment (Feb 2021) we're using ethr-did for demonstration reasons. Even though it's not a really recommended way to build self sovereign identities, it allows blockchain anchored DID documents very efficiently and is quite simple to setup, understand, extend and utilize. Real world use cases will likely rely on more advanced did methods (see below for a list of highly promising "in the wild" DID methods)
https://github.com/uport-project/ethr-did-registry https://github.com/decentralized-identity/ethr-did-resolver https://github.com/decentralized-identity/did-jwt https://github.com/decentralized-identity/did-jwt-vc
based on Joels work: https://medium.com/uport/erc1056-erc780-an-open-identity-and-claims-protocol-for-ethereum-aef7207bc744
Lightweight Identity: https://eips.ethereum.org/EIPS/eip-1056
On Chain Credentials Registry: ethereum/EIPs#780 (not really recommended)
followed by:
Verifiable Claims on Ethereum: https://eips.ethereum.org/EIPS/eip-1812
Uport's local ethr did https://github.com/uport-project/ethr-did
https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md https://github.com/gatacaid/gataca-did-method https://github.com/cryptonicsconsulting/signor-did-contracts/blob/master/did-method-spec.md https://lianxi-tech.github.io/monid/ (neu) https://github.com/SelfKeyFoundation/selfkey-did-ledger/blob/develop/DIDMethodSpecs.md
decentralized-identity/ethr-did-resolver#106 : the resolver would be able to resolve key material in base58 encoding (instead of base64url) as required by most crypto did libraries at the moment.
-
Jolocom. Highly involved in the SSI/DID space, drives the INATBA international SSI consortium. Concentrates on DIDComm v2 (open sourced a Rust implementation / JWK, JWM recently). Identities are anchored on Rinkeby (did:jolo) but they're migrating KERI based microledger DIDs (did:jun)
-
Ceramic / IDX is by far the most decentralized and far-though solution for a truly distributed and user controlled identity management. Based on IPFS. In Beta.
-
Sovrin / Evernym. By far the most advanced and used solution. Runs on a commercial permissioned blockchain. Root anchoring would cost "real" (€) money. Supports sub identities and drives DidComm development. Evernym Connectme is a general DID / VC wallet, based on sovrin + mobile wallet sdk
-
lissi.id. A government driven (and financed) wallet based on Hyperledger (?) with a focus on eIDAS compliance (later). Supported by Main.Incubator, TU Berlin, Bundesdruckerei, Deutsche Bahn e.a. Default wallet implementation for the administratively supported IDUnion initiative.
-
trinsic.id implements standards, APIs and tools for Verifiable Credentials. Also based on Hyperledger standards (Aries/DIDComm). Offers Credential services like issuance, revocation and a studio application to design credential schemas. They're making use of sovrin networks and are interoperable with LiSSI.
-
Apple Wallet (sic) also fundamentally builds upon VC schematics.
driven by Transmute, lots of React (Material) foundational code and password based locking of content that's wrapped in credentials:
https://w3c-ccg.github.io/universal-wallet-interop-spec/
anchors CRDT records of DID changes on arbitrary ledgers (or even inline of the did fragment part, see "long form" sidetree DIDs)
https://identity.foundation/sidetree/spec/ https://github.com/decentralized-identity/sidetree
most popular implementation: ION (anchors on Bitcoin, driven by Micro$oft) https://github.com/decentralized-identity/ion
Transmute has built a more generic (and simpler) implementation that supports :ion (bitcoin), :elem (ethereum), :photon (QLDB) and :trustbloc (fabric) methods: https://github.com/transmute-industries/sidetree.js
Microsofts approach looks very promising: https://github.com/microsoft/VerifiableCredentials-Crypto-SDK-Typescript
https://github.com/w3c-ccg/lds-jws2020
NaCL DIDs: https://github.com/uport-project/nacl-did (sig suites: https://github.com/digitalbazaar/vc-js/blob/master/BACKGROUND.md#generating-keys-and-suites)
generic did:key methods Transmute https://w3c-ccg.github.io/did-method-key/ https://github.com/transmute-industries/did-key.js https://did.key.transmute.industries/
Since there is no support for update and deactivate for the did:key method, it is not possible to recover from a security compromise. For this reason, using a did:key for interactions that last weeks to months is strongly discouraged.
browser based ed25519: noble https://github.com/paulmillr/noble-ed25519
How JWS signatures are built: http://www.davedoesdev.com/json-web-signatures-on-node-js/
Suite Middleware https://github.com/digitalbazaar/crypto-ld
Ed25519 Suite https://github.com/digitalbazaar/ed25519-verification-key-2018
More on ED25519: https://w3c-ccg.github.io/lds-ed25519-2018/
signing VCs (vs-js) lib: https://github.com/digitalbazaar/vc-js/ https://www.npmjs.com/package/vc-js/v/0.6.4?activeTab=readme
based on W3C draft on Crypto LD signatures: https://w3c-ccg.github.io/ld-cryptosuite-registry/#ed25519 https://github.com/w3c-ccg
https://www.ionos.com/digitalguide/websites/website-creation/tutorial-json-ld-with-schemaorg/
Jolocom's lib doku for custom credentials: https://jolocom-lib.readthedocs.io/en/latest/signedCredentials.html#working-with-custom-credentials
https://khalilstemmler.com/blogs/tooling/prettier/ https://khalilstemmler.com/blogs/typescript/eslint-for-typescript/
- are ethr-did-registry key definitions compat to json-ld-signatures?
- do we need the "assumption" types?
- shall we spike IDX / Keri to setup a chain independent controller resolver?
- when do we need universal resolution?
-
let univax-core only operate on signer
({data}) => Uint8Arrayinterfaces and add private key converters for the different key types accordingly (get rid of Signer) -
test against generic did/vc wallets
-
add a verifier for Consensas JSON-LD schemes for an immunization proof
-
what's that Segment 4 spec of the CCI working group?
-
use a VC revocation registry like ERC780
-
revoke Credentials using their hash (see: are ld proofs part of that hash?? )
-
store a remote picture on ipfs that's resolveable by the verifier / part of the credential (or another credential?)
-
add BBS+ signature support https://www.npmjs.com/package/@mattrglobal/bbs-signatures