Crates.io | caelum-vcdm |
lib.rs | caelum-vcdm |
version | 0.2.0 |
source | src |
created_at | 2019-11-06 14:33:04.512047 |
updated_at | 2019-11-27 16:11:47.254937 |
description | This crates implements w3's Verifiable Credential Data Model |
homepage | |
repository | https://gitlab.com/caelum-tech/caelum-vcdm/ |
max_upload_size | |
id | 178652 |
size | 182,460 |
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:
We want to help developers create these scenarios and making it easy to interact with other following the same specifications.
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.
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.
Verifiable Data Registry
.Issuer
, Holder
, Verifier
).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.
This library is created to satisfy w3's specifications.
This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at http://contributor-covenant.org/version/1/4
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.