Verifiable credentials

Verifiable credentials (VCs) are the electronic equivalent of the physical credentials that we all possess today, such as: plastic cards, passports, driving licences, qualifications and awards, etc. The data model for verifiable credentials is a World Wide Web Consortium Recommendation, "Verifiable Credentials Data Model 1.0 - Expressing verifiable information on the Web" published 19 November 2019.[1]

The VC model places the holder of a credential at the center of the identity ecosystem, giving individuals control of their identity attributes. This contrasts with the federated identity management (FIM) model, as adopted by SAML and OpenID Connect, which places the identity provider (IdP) in the central role as the dispenser of identity attributes and the determiner of which Service Providers (SPs) it will give them to. In the federated model a user's privacy is violated, since the IdP knows every SP that the user visits. The W3C VC model, on the other hand, parallels the way we use identification cards today: the user holds plastic cards in their wallet, and can present them to anyone at anytime without requiring the permission of the card issuer. Such a model is decentralized and gives much more autonomy and flexibility to the participants.

The holder of a verifiable credential sits at the center of a triangle of trust, mediating between issuer and verifier. The issuer and holder trust each other, the holder trusts the verifier, and the verifier trusts the issuer. Any role in the triangle can be played by a person, an institution, or an IoT device.

The W3C VC standard defines the syntax and semantics of Verifiable Credentials. Many different protocols are being specified for carrying VCs from the issuer/IdP to the holder, and the holder to the verifier. Examples include:

• Aries RFC 0036: Issue Credential Protocol 1.0.,[2] and Aries RFC 0037: Present Proof Protocol 1.0[3]
• David W Chadwick, Romain Laborde, Arnaud Oglaza, Remi Venant, Samer Wazan, Manreet Nijjar “Improved Identity Management with Verifiable Credentials and FIDO”, IEEE Communications Standards Magazine Vol 3, Issue 4, Dec 2019, Pages 14–20

However, none of these protocols are standardized yet, and other competing protocols may still emerge. Many people who are experimenting with VCs today are using some flavor of HTTPS to carry VCs between the various parties. It is anticipated that in due course the most popular or de-facto protocol(s) will be standardized by the W3C or another standards body once more experience is gained.

One interesting feature of VCs, is that the holder of a VC does not always have to be the subject of the credential. In most cases users will hold their own VCs, just as we carry physical credentials around with us today i.e., the holder and the subject will be the same entity. But this will not always be the case. For example, when the VC subject is a pet, and the VC is a vaccination certificate, the holder may be the pet's owner; when the VC subject is an infant, and the VC is a birth certificate, the holder may be one or both parents.

Verifiable Credentials may be expressed using JSON. A VC is typically composed of: the context of the VC, the identity of the issuer, the date and time of issuing, the expiry date and time, the type of VC, the subject of the VC, one or more identity attributes of the VC subject, and finally the cryptographic proof created by the issuer to ensure the integrity and authenticity of the VC. No single proof mechanism is standardized. On the contrary, the data model is flexible enough to support multiple existing cryptographic mechanisms, such as digital signatures. Proof mechanisms that are currently being used by implementors include: JSON Web Tokens with JSON Web Signatures, JSON-LD proofs, and zero-knowledge proofs using schemes such as IBM's anonymous credentials.

The context of the VC, defined using the @context JSON property, is a JSON-LD construct that allows user friendly terms to be used for JSON properties. According to the VC data model, the value of many properties must be a URI. Whilst these are globally unambiguous, which is an important feature for an internationally standardized data model, they are not user friendly. Consequently the @context property allows short-form, user-friendly aliases to be defined for each URI. This makes it much easier, and more user friendly, to specify VCs. An example is given below.

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "expirationDate": "2020-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": { 
  }
}

W3C VC's are extensible. Not only can any new property be added to VCs, as determined by the issuer, but there are also some standard properties that have been defined specifically as extension points. These include the following:

terms of use

these are restrictions placed on the use of the VC by the issuer

schema

this defines the schema for the content of the VC

evidence

this allows the issuer to say what evidence it collected about the subject and/or attributes before issuing the VC

status

pointers to where a verifier can discover the current status of a VC (e.g., whether it has been revoked).