-
Notifications
You must be signed in to change notification settings - Fork 7
Principles and Architecture
In order to achieve its objectives, the digital skill & education credentials would need to enable:
- Verifiability: Authenticity of the credential should be digitally verifiable by any application to which it is presented in a paperless and presence-less manner. This verification should not require the physical presence of the credential holder, or be contingent on any human action of the issuer.
- Portability: To ensure empowerment and choice for the credential holder, the credentials should be digitally portable across systems participating in the ecosystem. As in the case of physical certificates, unrestricted usage by the holder should be enabled. This includes easy digital storage of choice of the holder and easy consented sharing for various purposes that holder deem fit.
- Permanence: The credentials should continue to exist and be valid beyond the lifetime of the institution where it was awarded. That is, if a training agency which has awarded a credential subsequently ceases to exist, the credentials still remain verifiable and portable across the ecosystem.
- Self-Describing: The credential model should be self-describing in a manner that the verifier of the credential does not require private sources of information to validate or understand it. In practice, this means that all metadata, common identifiers, taxonomies, etc should be publicly accessible in various registries.
- Consent-based: In view of the Supreme Court Judgement on privacy, as well as the upcoming Data Protection Bill, design must ensure privacy preservation across the system including taking holder’s consent for collection and use.
- Inclusion: Design of credentials must ensure inclusion in terms of digital and physical usage (through printed modes with signed QR codes etc.), multi-lingual support, online and offline usage, and work seamlessly with inclusive and accessible technologies.
FIGURE: Credential Issuance & Verification - High Level Architecture
The following section is directly adapted with minimal changes from W3C VC specifications
In the physical world, a credential might consist of:
- Information related to identifying the subject of the credential (for example, a photo, name, identification number, etc.)
- Information related to the issuing authority (for example, a government agency, training agency, certification body, employer, etc.)
- Information related to the type of credential this is (for example, training certificate, proof of work, skill assessment certificate, licences, etc.)
- Information related to specific attributes or properties being asserted (for example, type of training, work details, etc.) along with any evidence/proof
- Additional metadata (for example, expiration date, terms of use, etc).
A Verifiable Credential (VC) 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.
Holders of verifiable credentials can then share these with verifiers to prove they possess verifiable credentials with certain characteristics.
While this specification attempts to improve the ease of expressing digital credentials, it also attempts to balance this goal with a number of privacy-preserving goals. The persistence of digital information, and the ease with which disparate sources of digital data can be collected and correlated, comprise a privacy concern that the use of verifiable and easily machine-readable credentials threatens to make it worse.
The following ecosystem roles are introduced in this specification:
holder A role an entity/person might perform by possessing one or more verifiable credentials. Example holders include students, employees, and customers.
issuer A role an entity performs by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder. Example issuers include corporations, non-profit organizations, trade associations, governments, and individuals.
subject An entity about which claims are made. Example subjects include human beings, animals, and things. In many cases the holder of a verifiable credential is the subject, but in certain cases it is not.
verifier A role an entity performs by receiving one or more verifiable credentials for processing. Example verifiers include employers, security personnel, and so on.
verifiable data registry (registries) A role a system might perform by mediating the creation and verification of identifiers, keys, VC schemas, revocation list, and other relevant data. These registries may be implemented via open APIs on top of trusted databases, decentralised databases, government ID databases, and distributed ledgers.
The following terms are used to describe concepts in this specification.
claim An assertion made about a subject.
credential A set of one or more claims made by an issuer. A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. The claims in a credential can be about different subjects.
data minimization The act of limiting the amount of shared data strictly to the minimum necessary to successfully accomplish a task or goal.
decentralized identifier
A portable URL-based identifier, also known as a DID, associated with an entity. These identifiers are most often used in a verifiable credential and are associated with subjects such that a verifiable credential itself can be easily ported from one repository to another without the need to reissue the credential. Some DID examples in Indian context are did:aadhaar:123456789012
or did:mobile:91123456790
.
decentralized identifier document Also referred to as a DID document, this is a document that is accessible using a verifiable data registry and contains information related to a specific decentralized identifier, such as the associated repository and public key information.
derived predicate A verifiable, boolean assertion about the value of another attribute in a verifiable credential. These are useful in zero-knowledge-proof-style verifiable presentations because they can limit information disclosure. For example, if a verifiable credential contains an attribute for expressing a specific date of birth, a derived predicate might reference the age attribute demonstrating that the issuer attests to age being higher than 21, without actually disclosing the date of birth.
entity A thing with distinct and independent existence, such as a person, organization, or device that performs one or more roles in the ecosystem.
graph A network of information composed of subjects and their relationship to other subjects or data.
holder A role an entity might perform by possessing one or more verifiable credentials and generating presentations from them. A holder is usually, but not always, a subject of the verifiable credentials they are holding. Holders store their credentials in credential repositories.
identity provider An identity provider, is a system for creating, maintaining, and managing identity information for holders, while providing authentication services to relying party applications within a federation or distributed network. This specification does not use this term unless comparing or mapping the concepts in this document to other specifications. This specification decouples the identity provider concept into two distinct concepts: the issuer and the holder.
issuer A role an entity can perform by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder.
presentation Data derived from one or more verifiable credentials, issued by one or more issuers, that is shared with a specific verifier. A verifiable presentation is a tamper-evident presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesized from, but do not contain, the original verifiable credentials (for example, zero-knowledge proofs).
repository A program, such as a storage vault or personal verifiable credential wallet, that stores and protects access to holders' verifiable credentials.
subject A thing about which claims are made.
validation The assurance that a verifiable credential or a verifiable presentation meets the needs of a verifier and other dependent stakeholders. This specification is constrained to verifying verifiable credentials and verifiable presentations regardless of their usage. Validating verifiable credentials or verifiable presentations is outside the scope of this specification.
verifiable data registry A role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as verifiable credential schemas, revocation registries, issuer public keys, and so on, which might be required to use verifiable credentials.
verification The evaluation of whether a verifiable credential or verifiable presentation is an authentic and timely statement of the issuer or presenter, respectively. This includes checking that: the credential (or presentation) conforms to the specification; the proof method is satisfied; and, if present, the status check succeeds.
verifier A role an entity performs by receiving one or more verifiable credentials, optionally inside a verifiable presentation for processing. Other specifications might refer to this concept as a relying party.
URI A Uniform Resource Identifier, as defined by RFC3986
The following sections outline core data model concepts, such as claims and credentials which form the foundation of this specification.
Claims A claim is a statement about a subject. A subject is a thing about which claims can be made. Claims are expressed using subject-property-value relationships.
SUBJECT ---(property)---> VALUE
The data model for claims, illustrated above, is powerful and can be used to express a large variety of statements. For example, whether someone graduated from a particular university can be expressed through this.
Individual claims can be merged together to express a graph of information about a subject. For example, a student is an alumni of a specific college and has 5 years of work experience.
A credential is a set of one or more claims made by the same entity. Credentials might also include an identifier and metadata to describe properties of the credential, such as the issuer, the expiry date and time, a representative image, a public key to use for verification purposes, the revocation mechanism, and so on.
A verifiable credential is a set of tamper-evident (digitally signed and valid under IT Act) claims and metadata that cryptographically prove who issued it.