4 releases
0.2.0 | Nov 27, 2019 |
---|---|
0.1.3 | Nov 14, 2019 |
0.1.2 | Nov 8, 2019 |
0.1.0 | Nov 6, 2019 |
#436 in Authentication
87KB
1K
SLoC
Verifiable Credential Data Model [WIP]
This crates implements w3's Verifiable Credential Data Model
specifications.
This means it will create, read, update and delete (a.k.a. CRUD) all properties of a
Verifiable Credential
and a Verifiable Presentation
. As well as interacting with other
Verifiable Credential
and Verifiable Presentation
.
A
Verifiable Credential
or aVerifiable Presentation
can represent all of the same information that a physical credential represents. The addition of technologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts. In the physical world, a credential might consist of:
- Information related to identifying the subject of the credential (for example, a photo, name, or identification number)
- Information related to the issuing authority (for example, a city government, national agency, or certification body)
- Information related to the type of credential this is (for example, a Dutch passport, an American driving license, or a health insurance card)
- Information related to specific attributes or properties being asserted by the issuing authority about the subject (for example, nationality, the classes of vehicle entitled to drive, or date of birth)
- Evidence related to how the credential was derived
- Information related to constraints on the credential (for example, expiration date, or terms of use).
We want to help developers create these scenarios and making it easy to interact with other following the same specifications.
Roles
Each of the following roles denotes an entity (person or organization) which holds a unique Decentralized Identifier (DID) stored in a blockchain along with a public key, which together can be used to secure communication and verify continuity of identity between all parties.
-
The Subject is the entity to which the information pertains. The Holder is the entity which is holding that information. For the purposes of Lorena, Subject and Holder are treated as the same.
-
The Issuer is the entity which validates (either manually or automatically) a piece of information about the Subject, and provides a digital signature (signed with the public key associated with the Issuer's DID) that attests to this validation.
-
The Verifier is the entity which wants to know something about the Subject. The Verifier needs to authenticate information about the Subject, and it trusts the Issuer's judgement on that information.
The entities playing these roles all have equal standing: each one has a DID, a (secret) private key and its associated public key which is published with the DID on the blockchain, and each can hold Verifiable Credentials (VCs). The roles can shift, and can be a peer-to-peer relationship or hierarchical as appropriate to needs.
Components
Services
The Lorena Identity Playground is a React single-page application which implements a prototype identity container which allows a Subject (Holder) to create a DID, create credentials and ask an Issuer to issue a VC, and send a VC to a Verifier.
Hoverfloat is a demonstration website for a fictional transportation service. It is written in React as a single-page application with no server back-end. It acts as a Verifier which takes VCs sent by a Subject and makes sure they were issued by a trusted Issuer.
Lorena Matrix Daemon is a Node JS back-end service which acts as an Issuer of VCs upon request by Subjects. It implements an email verification service and coordinates communication between anonymous guest accounts through Matrix.
Lorena Substrate is a Substrate-based blockchain for publishing DIDs and their associated public keys.
Matrix is decentralized communication service used for secure communicate between the different entities and services.
Implementations
How to use
Roadmap
- [ X ] Basic CRUD implementation on properties.
- [ X ] Basic CRUD implementation on Optional properties.
- [ X ] Verifying basic cryptographic proofs.
- Implementation of Zero-Knowledge proof using Zenroom.
- Connecting to
Verifiable Data Registry
. - Validation for necessary properties.
- Implementation of Roles (
Issuer
,Holder
,Verifier
).
Contributing
Please, contribute to vcdm
! The more the better! Feel free to to open an issue and/or contacting directly with the owner for any request or suggestion.
Acknowledgment
This library is created to satisfy w3's specifications.
Code of conduct
This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at http://contributor-covenant.org/version/1/4
License
This project is distributed under the terms of both the Apache License (Version 2.0) and the MIT license, specified in LICENSE-APACHE and LICENSE-MIT respectively.
Related repositories
Dependencies
~8.5MB
~159K SLoC