This section is non-normative.

In the physical world, acredential might consist of:

• Information related to identifying thesubject of thecredential(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 ofcredential this is (for example, aDutch passport, an American driving license, or a health insurance card)
• Information related to specific attributes or properties being asserted bythe issuing authority about thesubject (for example, nationality,the classes of vehicle entitled to drive, or date of birth)
• Evidence related to how thecredential was derived
• Information related to constraints on the credential (for example, expirationdate, or terms of use).

Averifiable credential can represent all of the same information that aphysicalcredential represents. The addition of technologies, such asdigital signatures, makesverifiable credentials more tamper-evident andmore trustworthy than their physical counterparts.

Holders ofverifiable credentials can generateverifiable presentations and then share theseverifiable presentations withverifiers to prove they possessverifiable credentials with certain characteristics.

Bothverifiable credentials andverifiable presentations can betransmitted rapidly, making them more convenient than their physicalcounterparts when trying to establish trust at a distance.

While this specification attempts to improve the ease of expressing digitalcredentials, it also attempts to balance this goal with a number ofprivacy-preserving goals. The persistence of digital information, and the easewith which disparate sources of digital data can be collected and correlated,comprise a privacy concern that the use ofverifiable and easilymachine-readablecredentials threatens to make worse. This documentoutlines and attempts to address a number of these issues in Section7.Privacy Considerations. Examples of how to use this data modelusing privacy-enhancing technologies, such as zero-knowledge proofs, are alsoprovided throughout this document.

The word "verifiable" in the termsverifiable credential andverifiable presentationrefers to the characteristic of acredential orpresentationas being able to beverified by averifier,as defined in this document. Verifiability of a credential does not implythat the truth ofclaims encoded therein can be evaluated; however,the issuer can include values in theevidence property to help the verifierapply their business logic to determine whether the claims have sufficientveracity for their needs.

This section is non-normative.

This section describes the roles of the core actors and the relationshipsbetween them in an ecosystem whereverifiable credentials are expectedto be useful. A role is an abstraction that might be implemented in manydifferent ways. The separation of roles suggests likely interfaces andprotocols for standardization. The following roles are introduced in thisspecification:

holder

A role anentity might perform by possessing one or moreverifiable credentials and generatingverifiable presentationsfrom them. Example holders include students, employees, and customers.

issuer

A role anentity performs by assertingclaims about one ormoresubjects, creating averifiable credential from theseclaims, and transmitting theverifiable credential to aholder. Example issuers include corporations, non-profit organizations,trade associations, governments, and individuals.

subject

Anentity about whichclaims are made. Example subjects includehuman beings, animals, and things. In many cases theholder of averifiable credential is the subject, but in certain cases it is not. Forexample, a parent (theholder) might hold theverifiable credentials of a child (thesubject), or a pet owner(theholder) might hold theverifiable credentials of their pet(thesubject). For more information about these special cases, seeAppendixC.Subject-Holder Relationships.

verifier

A role anentity performs by receiving one or moreverifiable credentials, optionally inside averifiable presentation, for processing. Example verifiers includeemployers, security personnel, and websites.

verifiable data registry

A role a system might perform by mediating the creation andverificationof identifiers, keys, and other relevant data, such asverifiable credential schemas, revocation registries, issuer public keys,and so on, which might be required to useverifiable credentials. Someconfigurations might require correlatable identifiers forsubjects.Example verifiable data registries include trusted databases, decentralizeddatabases, government ID databases, and distributed ledgers. Oftenthere is more than one type of verifiable data registry utilized in anecosystem.

This section is non-normative.

The Verifiable Credentials Use Cases document [VC-USE-CASES] outlines a numberof key topics that readers might find useful, including:

• A more thorough explanation of therolesintroduced above
• Theneedsidentified in market verticals, such as education, finance, healthcare, retail,professional licensing, and government
• Commontasksperformed by the roles in the ecosystem, as well as their associatedrequirements
• Commonsequencesand flows identified by the Working Group.

As a result of documenting and analyzing the use cases document, the followingdesirable ecosystem characteristics were identified for this specification:

• Credentials represent statements made by anissuer.
• Verifiable credentials represent statements made by anissuer ina tamper-evident and privacy-respecting manner.
• Holders assemble collections ofcredentials and/orverifiable credentials from differentissuers into a singleartifact, apresentation.
• Holders transformpresentations intoverifiable presentationsto render them tamper-evident.
• Issuers can issueverifiable credentials about anysubject.
• Acting asissuer,holder, orverifier requires neitherregistration nor approval by any authority, as the trust involved is bilateralbetween parties.
• Verifiable presentations allow anyverifier toverify theauthenticity ofverifiable credentials from anyissuer.
• Holders can receiveverifiable credentials from anyone.
• Holders can interact with anyissuer and anyverifierthrough any user agent.
• Holders can shareverifiable presentations, which can then beverified without revealing the identity of theverifier to theissuer.
• Holders can storeverifiable credentials in any location, withoutaffecting theirverifiability and without theissuer knowinganything about where they are stored or when they are accessed.
• Holders can presentverifiable presentations to anyverifier without affecting authenticity of the claims and withoutrevealing that action to theissuer.
• Averifier canverifyverifiable presentations from anyholder, containing proofs ofclaims from anyissuer.
• Verification should not depend on direct interactions betweenissuers andverifiers.
• Verification should not reveal the identity of theverifier toanyissuer.
• The specification must provide a means forissuers to issueverifiable credentials that support selective disclosure, withoutrequiring all conformant software to support that feature.
• Issuers can issueverifiable credentials that supportselective disclosure.
• If a singleverifiable credential supports selective disclosure, thenholders can present proofs ofclaims without revealing the entireverifiable credential.
• Verifiable presentations can either disclose the attributes of averifiable credential, or satisfyderived predicates requested bytheverifier.Derived predicates are Boolean conditions, such asgreater than, less than, equal to, is in set, and so on.
• Issuers can issue revocableverifiable credentials.
• The processes of cryptographically protectingcredentials andpresentations, and verifyingverifiable credentials andverifiable presentations, have to be deterministic, bi-directional, andlossless. Any verification of averifiable credential orverifiable presentation has to be transformable to the generic data modeldefined in this document in a deterministic process, such that the resultingcredential orpresentation is semantically and syntacticallyequivalent to the original construct, so that it can be processed in aninteroperable fashion.
• Verifiable credentials andverifiable presentations have to beserializable in one or more machine-readable data formats. The process ofserialization and/or de-serialization has to be deterministic, bi-directional,and lossless. Any serialization of averifiable credential orverifiable presentation needs to be transformable to the generic datamodel defined in this document in a deterministic process such that theresultingverifiable credential can be processed in an interoperablefashion. The serialized form also needs to be able to be generated from the datamodel without loss of data or content.
• The data model and serialization must be extendable with minimal coordination.
• Revocation by theissuer should not reveal any identifying informationabout thesubject, theholder, the specificverifiable credential, or theverifier.
• Issuers can disclose the revocation reason.
• Issuers revokingverifiable credentials should distinguish betweenrevocation for cryptographic integrity (for example, the signing key iscompromised) versus revocation for a status change (for example, the driver’slicense is suspended).
• Issuers can provide a service for refreshing averifiable credential.

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key wordsMAY,MUST,MUST NOT,RECOMMENDED, andSHOULD in this document are to be interpreted as described inBCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Aconforming document is any concrete expression of the data modelthat complies with the normative statements in this specification.Specifically, all relevant normative statements in Sections4.Basic Concepts,5.Advanced Concepts, and6.Syntaxes of this documentMUST be enforced. A serializationformat for the conforming documentMUST be deterministic, bi-directional,and lossless as described in Section6.Syntaxes.Theconforming documentMAY be transmitted or stored in any suchserialization format.

Aconforming processor is any algorithm realizedas software and/or hardware that generates or consumes aconformingdocument. Conforming processorsMUST produce errors when non-conformingdocuments are consumed.

This specification makes no normative statements with regard to theconformance of roles in the ecosystem, such asissuers,holders,orverifiers, because the conformance of ecosystem roles are highlyapplication, use case, and market vertical specific.

Digital proof mechanisms, a subset of which are digital signatures, are requiredto ensure the protection of averifiable credential. Having andvalidating proofs, which may be dependent on the syntax of the proof(for example, using the JSON Web Signature of a JSON Web Token for proofing akey holder), are an essential part of processing averifiable credential.At the time of publication, Working Group members had implementedverifiable credentials using at least three proof mechanisms:

• JSON Web Tokens [RFC7519] secured using JSON Web Signatures [RFC7515]
• Data Integrity Proofs [DATA-INTEGRITY]
• Camenisch-Lysyanskaya Zero-Knowledge Proofs [CL-SIGNATURES].

Implementers are advised to note that not all proof mechanisms are standardizedas of the publication date of this specification. The group expects some ofthese mechanisms, as well as new ones, to mature independently and becomestandardized in time. Given there are multiple valid proof mechanisms, thisspecification does not standardize on any single digital signature mechanism.One of the goals of this specification is to provide a data model that can beprotected by a variety of current and future digital proof mechanisms.Conformance to this specification does not depend on the details of a particularproof mechanism; it requires clearly identifying the mechanism averifiable credential uses.

This document also contains examples that contain JSON and JSON-LD content.Some of these examples contain characters that are invalid JSON, such asinline comments (//) and the use of ellipsis (...)to denote information that adds little value to the example. Implementers arecautioned to remove this content if they desire to use the information asvalid JSON or JSON-LD.

This section is non-normative.

Aclaim is a statement about asubject. Asubject is athing about whichclaims can be made.Claims are expressed usingsubject-property-value relationships.

The data model forclaims, illustrated inFigure2above, is powerful and can be used to express a large variety of statements. Forexample, whether someone graduated from a particular university can be expressedas shown inFigure3 below.

Individualclaims can be merged together to express agraph ofinformation about asubject. The example shown inFigure4 below extends the previousclaim byadding theclaims that Pat knows Sam and that Sam is employed as aprofessor.

To this point, the concepts of aclaim and agraph of informationare introduced. To be able to trustclaims, more information isexpected to be added to the graph.

This section is non-normative.

Acredential is a set of one or moreclaims made by the sameentity.Credentials might also include an identifier andmetadata to describe properties of thecredential, such as theissuer, the expiry date and time, a representative image, a public keyto use forverification purposes, the revocation mechanism, and so on.The metadata might be signed by theissuer. Averifiable credential is a set of tamper-evidentclaims andmetadata that cryptographically prove who issued it.

Examples ofverifiable credentials include digital employeeidentification cards, digital birth certificates, and digital educationalcertificates.

Figure5 above shows the basic components of averifiable credential, but abstracts the details about howclaimsare organized into informationgraphs, which are then organized intoverifiable credentials.Figure6 below shows amore complete depiction of averifiable credential, which is normallycomposed of at least two informationgraphs. The firstgraphexpresses theverifiable credential itself, which contains credentialmetadata andclaims. The secondgraph expresses the digital proof,which is usually a digital signature.

This section is non-normative.

Enhancing privacy is a key design feature of this specification. Therefore, itis important forentities using this technology to be able to expressonly the portions of their persona that are appropriate for a given situation.The expression of a subset of one's persona is called averifiable presentation. Examples of different personas include aperson's professional persona, their online gaming persona, theirfamily persona, or an incognito persona.

Averifiable presentation expresses data from one or moreverifiable credentials, and is packaged in such a way that theauthorship of the data isverifiable. Ifverifiable credentialsare presented directly, they becomeverifiable presentations. Dataformats derived fromverifiable credentials that are cryptographicallyverifiable, but do not of themselves containverifiable credentials, might also beverifiable presentations.

The data in apresentation is often about the samesubject, butmight have been issued by multipleissuers. The aggregation of thisinformation typically expresses an aspect of a person, organization, orentity.

Figure7 above shows the components of averifiable presentation, but abstracts the details about howverifiable credentials are organized into informationgraphs,which are then organized intoverifiable presentations.

Figure8 below shows a more complete depiction of averifiable presentation, which is normally composed of at least fourinformationgraphs. The first of these informationgraphs, thePresentationGraph, expresses theverifiable presentationitself, which contains presentation metadata. TheverifiableCredential property in the PresentationGraphrefers to one or moreverifiable credentials, each being one of thesecond informationgraphs, i.e., a self-contained CredentialGraph, which in turn contains credential metadata and claims. Thethird informationgraph, the Credential ProofGraph, expressesthe credential graph proof, which is usually a digital signature. The fourthinformationgraph, the Presentation ProofGraph, expresses thepresentation graph proof, which is usually a digital signature.

This section is non-normative.

The previous sections introduced the concepts ofclaims,verifiable credentials, andverifiable presentations usinggraphical depictions. This section provides a concrete set of simple butcomplete lifecycle examples of the data model expressed in one of the concretesyntaxes supported by this specification. The lifecycle ofcredentialsandpresentations in theVerifiable Credentials Ecosystem oftentake a common path:

1. Issuance of one or moreverifiable credentials.
2. Storage ofverifiable credentials in acredential repository(such as a digital wallet).
3. Composition ofverifiable credentials into averifiable presentation forverifiers.
4. Verification of theverifiable presentation by theverifier.

To illustrate this lifecycle, we will use the example of redeeming an alumnidiscount from a university. In the example below, Pat receives an alumniverifiable credential from a university, and Pat stores theverifiable credential in a digital wallet.

{// set the context, which establishes the special terms we will be using  // such as 'issuer' and 'alumniOf'.  "@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1"  ],// specify the identifier for the credential  "id": "http://example.edu/credentials/1872",// the credential types, which declare what data to expect in the credential  "type": ["VerifiableCredential", "AlumniCredential"],// the entity that issued the credential  "issuer": "https://example.edu/issuers/565049",// when the credential was issued  "issuanceDate": "2010-01-01T19:23:24Z",// claims about the subjects of the credential  "credentialSubject": {// identifier for the only subject of the credential    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",// assertion about the only subject of the credential    "alumniOf": {      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",      "name": [{        "value": "Example University",        "lang": "en"      }, {        "value": "Exemple d'Université",        "lang": "fr"      }]    }  },// digital proof that makes the credential tamper-evident// see the NOTE at end of this section for more detail  "proof": {// the cryptographic signature suite that was used to generate the signature    "type": "RsaSignature2018",// the date the signature was created    "created": "2017-06-18T21:19:10Z",// purpose of this proof    "proofPurpose": "assertionMethod",// the identifier of the public key that can verify the signature    "verificationMethod": "https://example.edu/issuers/565049#key-1",// the digital signature value    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj      PAYuNzVBAh4vGHSrQyHUdBBPM"  }}

Pat then attempts to redeem the alumni discount. Theverifier, a ticketsales system, states that any alumni of "Example University" receives a discounton season tickets to sporting events. Using a mobile device, Pat starts theprocess of purchasing a season ticket. A step in this process requests an alumniverifiable credential, and this request is routed to Pat's digital wallet.The digital wallet asks Pat if they would like to provide a previously issuedverifiable credential. Pat selects the alumniverifiable credential, which is then composed into averifiable presentation. Theverifiable presentation is sent totheverifier andverified.

{  "@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1"  ],  "type": "VerifiablePresentation",// the verifiable credential issued in the previous example  "verifiableCredential": [{    "@context": [      "https://www.w3.org/2018/credentials/v1",      "https://www.w3.org/2018/credentials/examples/v1"    ],    "id": "http://example.edu/credentials/1872",    "type": ["VerifiableCredential", "AlumniCredential"],    "issuer": "https://example.edu/issuers/565049",    "issuanceDate": "2010-01-01T19:23:24Z",    "credentialSubject": {      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",      "alumniOf": {        "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",        "name": [{          "value": "Example University",          "lang": "en"        }, {          "value": "Exemple d'Université",          "lang": "fr"        }]      }    },    "proof": {      "type": "RsaSignature2018",      "created": "2017-06-18T21:19:10Z",      "proofPurpose": "assertionMethod",      "verificationMethod": "https://example.edu/issuers/565049#key-1",      "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X        sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc        X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj        PAYuNzVBAh4vGHSrQyHUdBBPM"    }  }],// digital signature by Pat on the presentation  // protects against replay attacks  "proof": {    "type": "RsaSignature2018",    "created": "2018-09-14T21:19:10Z",    "proofPurpose": "authentication",    "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1",// 'challenge' and 'domain' protect against replay attacks    "challenge": "1f44d55f-f161-4938-a659-f8026467f126",    "domain": "4jt78h47fh47",    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5      XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs      LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh      4vGHSrQyHUGlcTwLtjPAnKb78"  }}

When two software systems need to exchange data, they need to use terminologythat both systems understand. As an analogy, consider how two peoplecommunicate. Both people must use the same language and the words they use mustmean the same thing to each other. This might be referred to asthe context of a conversation.

Verifiable credentials andverifiable presentations have manyattributes and values that are identified byURIs [RFC3986]. However,thoseURIs can be long and not very human-friendly. In such cases,short-form human-friendly aliases can be more helpful. This specification usesthe@contextproperty to map such short-form aliases to theURIs required by specificverifiable credentials andverifiablepresentations.

Verifiable credentials andverifiable presentationsMUST include a@contextproperty.

@context

The value of the@contextpropertyMUST be an ordered setwhere the first item is aURI with the valuehttps://www.w3.org/2018/credentials/v1. For reference, a copy ofthe base context is provided in AppendixB.1Base Context.Subsequent items in the arrayMUST express context information and be composedof any combination ofURIs or objects. It isRECOMMENDED that eachURI in the@context be one which, if dereferenced, resultsin a document containing machine-readable information about the@context.

{"@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1"  ],  "id": "http://example.edu/credentials/58473",  "type": ["VerifiableCredential", "AlumniCredential"],  "issuer": "https://example.edu/issuers/565049",  "issuanceDate": "2010-01-01T00:00:00Z",  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "alumniOf": {      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",      "name": [{        "value": "Example University",        "lang": "en"      }, {        "value": "Exemple d'Université",        "lang": "fr"      }]    }  },  "proof": {... }}

The example above uses the base contextURI(https://www.w3.org/2018/credentials/v1) to establish that theconversation is about averifiable credential. The secondURI(https://www.w3.org/2018/credentials/examples/v1) establishes thatthe conversation is about examples.

The data available athttps://www.w3.org/2018/credentials/v1 is astatic document that is never updated andSHOULD be downloaded and cached. Theassociated human-readable vocabulary document for the Verifiable CredentialsData Model is available athttps://www.w3.org/2018/credentials/.This concept is further expanded on in Section5.3Extensibility.

When expressing statements about a specific thing, such as a person, product,or organization, it is often useful to use some kind of identifier so thatothers can express statements about the same thing. This specification definesthe optionalidproperty for such identifiers. Theidproperty is intended to unambiguously refer to an object,such as a person, product, or organization. Using theidproperty allows for the expression of statements about specific things intheverifiable credential.

If theidproperty is present:

• TheidpropertyMUST express an identifier that others areexpected to use when expressing statements about a specific thing identifiedby that identifier.
• TheidpropertyMUST NOT have more than one value.
• The value of theidpropertyMUST be aURI.

id

The value of theidpropertyMUST be a singleURI.It isRECOMMENDED that theURI in theid be one which, ifdereferenced, results in a document containing machine-readable informationabout theid.

{  "@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/565049",  "issuanceDate": "2010-01-01T00:00:00Z",  "credentialSubject": {"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "degree": {      "type": "BachelorDegree",      "name": "Bachelor of Science and Arts"    }  }}

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "UniversityDegreeCredential"
  ],
  "issuer": "https://example.edu/issuers/565049",
  "issuanceDate": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2022-02-25T14:58:42Z",
    "verificationMethod": "https://example.edu/issuers/565049#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3FXQjecWufY46yg5abdVZsXqLhxhueuSoZgNSARiKBk9czhSePTFehP
8c3PGfb6a22gkfUKods5D2UAUL5n2Brbx"
  }
}

---------------- JWT header ---------------
{
  "alg": "ES256",
  "typ": "JWT"
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "vc": {
    "@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/565049",
    "issuanceDate": "2010-01-01T00:00:00Z",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "degree": {
        "type": "BachelorDegree",
        "name": "Bachelor of Science and Arts"
      }
    }
  },
  "iss": "https://example.edu/issuers/565049",
  "nbf": 1262304000,
  "jti": "http://example.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
--------------- JWT ---------------
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3
d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L
2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sImlkIjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRl
bnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiVW5pdmVyc2l0eUR
lZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLz
U2NTA0OSIsImlzc3VhbmNlRGF0ZSI6IjIwMTAtMDEtMDFUMDA6MDA6MDBaIiwiY3JlZGVudGlhb
FN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEi
LCJkZWdyZWUiOnsidHlwZSI6IkJhY2hlbG9yRGVncmVlIiwibmFtZSI6IkJhY2hlbG9yIG9mIFN
jaWVuY2UgYW5kIEFydHMifX19LCJpc3MiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvNT
Y1MDQ5IiwibmJmIjoxMjYyMzA0MDAwLCJqdGkiOiJodHRwOi8vZXhhbXBsZS5lZHUvY3JlZGVud
GlhbHMvMzczMiIsInN1YiI6ImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMy
MSJ9.giMDNtWUgKbvWL4pteSpSkrh-lhgkhJUZ_gatHdRvEFs9_kB4G9neABvTuuQKfwERzi2KF
Qz3X0nzF-jrOO-5w

The example above uses two types of identifiers. The first identifier is fortheverifiable credential and uses an HTTP-based URL. The secondidentifier is for thesubject of theverifiable credential (thething theclaims are about) and uses adecentralized identifier,also known as aDID.

Software systems that process the kinds of objects specified in this documentuse type information to determine whether or not a providedverifiable credential orverifiable presentation is appropriate.This specification defines atypeproperty for theexpression of type information.

Verifiable credentials andverifiable presentationsMUST have atypeproperty. That is, anycredential orpresentation that does not havetypepropertyis notverifiable, so is neither averifiable credentialnor averifiable presentation.

type

The value of thetypepropertyMUST be, or map to (throughinterpretation of the@context property), one or moreURIs.If more than oneURI is provided, theURIsMUST be interpretedas an unordered set. Syntactic conveniencesSHOULD be used to ease developerusage. Such conveniences might include JSON-LD terms. It isRECOMMENDED thateachURI in thetype be one which, if dereferenced, resultsin a document containing machine-readable information about thetype.

{  "@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/565049",  "issuanceDate": "2010-01-01T00:00:00Z",  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "degree": {      "type": "BachelorDegree",      "name": "Bachelor of Science and Arts"    }  }}

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "UniversityDegreeCredential"
  ],
  "issuer": "https://example.edu/issuers/565049",
  "issuanceDate": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2022-02-25T14:58:43Z",
    "verificationMethod": "https://example.edu/issuers/565049#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "zeEdUoM7m9cY8ZyTpey83yBKeBcmcvbyrEQzJ19rD2UXArU2U1jPGoEt
rRvGYppdiK37GU4NBeoPakxpWhAvsVSt"
  }
}

---------------- JWT header ---------------
{
  "alg": "ES256",
  "typ": "JWT"
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "vc": {
    "@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/565049",
    "issuanceDate": "2010-01-01T00:00:00Z",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "degree": {
        "type": "BachelorDegree",
        "name": "Bachelor of Science and Arts"
      }
    }
  },
  "iss": "https://example.edu/issuers/565049",
  "nbf": 1262304000,
  "jti": "http://example.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
--------------- JWT ---------------
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3
d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L
2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sImlkIjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRl
bnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiVW5pdmVyc2l0eUR
lZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLz
U2NTA0OSIsImlzc3VhbmNlRGF0ZSI6IjIwMTAtMDEtMDFUMDA6MDA6MDBaIiwiY3JlZGVudGlhb
FN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEi
LCJkZWdyZWUiOnsidHlwZSI6IkJhY2hlbG9yRGVncmVlIiwibmFtZSI6IkJhY2hlbG9yIG9mIFN
jaWVuY2UgYW5kIEFydHMifX19LCJpc3MiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvNT
Y1MDQ5IiwibmJmIjoxMjYyMzA0MDAwLCJqdGkiOiJodHRwOi8vZXhhbXBsZS5lZHUvY3JlZGVud
GlhbHMvMzczMiIsInN1YiI6ImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMy
MSJ9.IOKrRQb0yrNxHivWbzfNRdKsSbP-mzc-eaQpdkHKkxTi46x8D0h3aLS9KXcAprcMPioEN6
NNSyqLj9ZTDYeoyg

With respect to this specification, the following table lists the objects thatMUST have atype specified.

Allcredentials,presentations, and encapsulated objectsMUSTspecify, or be associated with, additional more narrowtypes (likeUniversityDegreeCredential, for example) so software systems canprocess this additional information.

When processing encapsulated objects defined in this specification, (forexample, objects associated with thecredentialSubject object ordeeply nested therein), software systemsSHOULD use thetype informationspecified in encapsulating objects higher in the hierarchy. Specifically, anencapsulating object, such as acredential,SHOULD convey the associatedobjecttypes so thatverifiers can quickly determine the contentsof an associated object based on the encapsulating objecttype.

For example, acredential object with thetype ofUniversityDegreeCredential, signals to averifier that theobject associated with thecredentialSubject property contains theidentifier for the:

• Subject in theid property.
• Type of degree in thetype property.
• Title of the degree in thename property.

This enables implementers to rely on values associated with thetype property forverification purposes. The expectation oftypes and their associated properties should be documented in at least ahuman-readable specification, and preferably, in an additional machine-readablerepresentation.

Averifiable credential containsclaims about one or moresubjects. This specification defines acredentialSubjectproperty for the expression ofclaims about one or moresubjects.

Averifiable credentialMUST have acredentialSubjectproperty.

credentialSubject

The value of thecredentialSubjectproperty is defined asa set of objects that contain one or more properties that are each related to asubject of theverifiable credential. Each objectMAY contain anid, as described in Section4.2Identifiers.

{  "@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/565049",  "issuanceDate": "2010-01-01T00:00:00Z","credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "degree": {      "type": "BachelorDegree",      "name": "Bachelor of Science and Arts"    }  }}

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "UniversityDegreeCredential"
  ],
  "issuer": "https://example.edu/issuers/565049",
  "issuanceDate": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2022-02-25T14:58:43Z",
    "verificationMethod": "https://example.edu/issuers/565049#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "zeEdUoM7m9cY8ZyTpey83yBKeBcmcvbyrEQzJ19rD2UXArU2U1jPGoEt
rRvGYppdiK37GU4NBeoPakxpWhAvsVSt"
  }
}

---------------- JWT header ---------------
{
  "alg": "ES256",
  "typ": "JWT"
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "vc": {
    "@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/565049",
    "issuanceDate": "2010-01-01T00:00:00Z",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "degree": {
        "type": "BachelorDegree",
        "name": "Bachelor of Science and Arts"
      }
    }
  },
  "iss": "https://example.edu/issuers/565049",
  "nbf": 1262304000,
  "jti": "http://example.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
--------------- JWT ---------------
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3
d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L
2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sImlkIjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRl
bnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiVW5pdmVyc2l0eUR
lZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLz
U2NTA0OSIsImlzc3VhbmNlRGF0ZSI6IjIwMTAtMDEtMDFUMDA6MDA6MDBaIiwiY3JlZGVudGlhb
FN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEi
LCJkZWdyZWUiOnsidHlwZSI6IkJhY2hlbG9yRGVncmVlIiwibmFtZSI6IkJhY2hlbG9yIG9mIFN
jaWVuY2UgYW5kIEFydHMifX19LCJpc3MiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvNT
Y1MDQ5IiwibmJmIjoxMjYyMzA0MDAwLCJqdGkiOiJodHRwOi8vZXhhbXBsZS5lZHUvY3JlZGVud
GlhbHMvMzczMiIsInN1YiI6ImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMy
MSJ9.z5vgMTK1nfizNCg5N-niCOL3WUIAL7nXy-nGhDZYO_-PNGeE-0djCpWAMH8fD8eWSID5Pf
kPBYkx_dfLJnQ7NA

It is possible to express information related to multiplesubjects in averifiable credential. The example below specifies twosubjectswho are spouses. Note the use of array notation to associate multiplesubjects with thecredentialSubject property.

{  "@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1"  ],  "id": "http://example.edu/credentials/3732",  "type": ["VerifiableCredential", "RelationshipCredential"],  "issuer": "https://example.com/issuer/123",  "issuanceDate": "2010-01-01T00:00:00Z",  "credentialSubject":[{    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "name": "Jayden Doe",    "spouse": "did:example:c276e12ec21ebfeb1f712ebc6f1"  }, {    "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",    "name": "Morgan Doe",    "spouse": "did:example:ebfeb1f712ebc6f1c276e12ec21"  }]}

This specification defines a property for expressing theissuer ofaverifiable credential.

Averifiable credentialMUST have anissuerproperty.

issuer

The value of theissuerpropertyMUST be either aURI or an object containing anidproperty. It isRECOMMENDED that theURI in theissuer or itsid be one which, if dereferenced, results in a document containingmachine-readable information about theissuer that can be used toverify the information expressed in thecredential.

{  "@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",  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "degree": {      "type": "BachelorDegree",      "name": "Bachelor of Science and Arts"    }  }}

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "UniversityDegreeCredential"
  ],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2022-02-25T14:58:43Z",
    "verificationMethod": "https://example.edu/issuers/14#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z4kWncP1KLByEaSU3oaijUNk8GPGCCgntz8q4Gk55QuMwQe1dsWgSmf7
RsRNYgfJUChdSV22khsfpBsX7ub14aYbe"
  }
}

---------------- JWT header ---------------
{
  "alg": "ES256",
  "typ": "JWT"
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "vc": {
    "@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",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "degree": {
        "type": "BachelorDegree",
        "name": "Bachelor of Science and Arts"
      }
    }
  },
  "iss": "https://example.edu/issuers/14",
  "nbf": 1262373804,
  "jti": "http://example.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
--------------- JWT ---------------
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3
d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L
2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sImlkIjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRl
bnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiVW5pdmVyc2l0eUR
lZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLz
E0IiwiaXNzdWFuY2VEYXRlIjoiMjAxMC0wMS0wMVQxOToyMzoyNFoiLCJjcmVkZW50aWFsU3Via
mVjdCI6eyJpZCI6ImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSIsImRl
Z3JlZSI6eyJ0eXBlIjoiQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5
jZSBhbmQgQXJ0cyJ9fX0sImlzcyI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvaXNzdWVycy8xNCIsIm
5iZiI6MTI2MjM3MzgwNCwianRpIjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRlbnRpYWxzLzM3M
zIiLCJzdWIiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEifQ.oOoii
TBKC6zbJ8rx916SSHEKk4Fhc5-gFD8Qh64zRsf5ea7D-bu9zA1ii12hnXLloL7Cz0reXKA9P1nB
ZzQvTw

It is also possible to express additional information about the issuer byassociating an object with the issuer property:

{  "@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": {    "id": "did:example:76e12ec712ebc6f1c221ebfeb1f",    "name": "Example University"  },  "issuanceDate": "2010-01-01T19:23:24Z",  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "degree": {      "type": "BachelorDegree",      "name": "Bachelor of Science and Arts"    }  }}

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "UniversityDegreeCredential"
  ],
  "issuer": {
    "id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
    "name": "Example University"
  },
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2022-02-25T14:58:43Z",
    "verificationMethod": "did:example:76e12ec712ebc6f1c221ebfeb1f#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z2Xdmp6YDYz5RPKeRFDcPYorAmnERyr7aRNzv176oLMxwcW7GgKxAQT4
5jUKwsMA1XvrmFT5Y8WCx7ZnkNTTHJnu9"
  }
}

---------------- JWT header ---------------
{
  "alg": "ES256",
  "typ": "JWT"
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "vc": {
    "@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": {
      "id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
      "name": "Example University"
    },
    "issuanceDate": "2010-01-01T19:23:24Z",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "degree": {
        "type": "BachelorDegree",
        "name": "Bachelor of Science and Arts"
      }
    }
  },
  "iss": {
    "id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
    "name": "Example University"
  },
  "nbf": 1262373804,
  "jti": "http://example.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
--------------- JWT ---------------
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3
d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L
2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sImlkIjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRl
bnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiVW5pdmVyc2l0eUR
lZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjp7ImlkIjoiZGlkOmV4YW1wbGU6NzZlMTJlYzcxMm
ViYzZmMWMyMjFlYmZlYjFmIiwibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSJ9LCJpc3N1YW5jZ
URhdGUiOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoi
ZGlkOmV4YW1wbGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiZGVncmVlIjp7InR5cGU
iOiJCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn
19fSwiaXNzIjp7ImlkIjoiZGlkOmV4YW1wbGU6NzZlMTJlYzcxMmViYzZmMWMyMjFlYmZlYjFmI
iwibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSJ9LCJuYmYiOjEyNjIzNzM4MDQsImp0aSI6Imh0
dHA6Ly9leGFtcGxlLmVkdS9jcmVkZW50aWFscy8zNzMyIiwic3ViIjoiZGlkOmV4YW1wbGU6ZWJ
mZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIn0.ev4-5Dx9nRy_RUwWMLvnCJ1i-bizgom5VcyYE0
TpGsJ7-bPr6NFUh426Yzx5kc5cEh-a0JPPYBqM6jyrgmyvzA

This specification defines theissuanceDateproperty forexpressing the date and time when acredential becomes valid.

issuanceDate

AcredentialMUST have anissuanceDateproperty. Thevalue of theissuanceDatepropertyMUST be a string value ofan [XMLSCHEMA11-2] combineddate-time string representing the date and time thecredential becomes valid, which could be a date and time in the future.Note that this value represents the earliest point in timeat which the information associated with thecredentialSubjectproperty becomes valid.

{  "@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",  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "degree": {      "type": "BachelorDegree",      "name": "Bachelor of Science and Arts"    }  }}

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "UniversityDegreeCredential"
  ],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2022-02-25T14:58:43Z",
    "verificationMethod": "https://example.edu/issuers/14#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z4kWncP1KLByEaSU3oaijUNk8GPGCCgntz8q4Gk55QuMwQe1dsWgSmf7
RsRNYgfJUChdSV22khsfpBsX7ub14aYbe"
  }
}

---------------- JWT header ---------------
{
  "alg": "ES256",
  "typ": "JWT"
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "vc": {
    "@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",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "degree": {
        "type": "BachelorDegree",
        "name": "Bachelor of Science and Arts"
      }
    }
  },
  "iss": "https://example.edu/issuers/14",
  "nbf": 1262373804,
  "jti": "http://example.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
--------------- JWT ---------------
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3
d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L
2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sImlkIjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRl
bnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiVW5pdmVyc2l0eUR
lZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLz
E0IiwiaXNzdWFuY2VEYXRlIjoiMjAxMC0wMS0wMVQxOToyMzoyNFoiLCJjcmVkZW50aWFsU3Via
mVjdCI6eyJpZCI6ImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSIsImRl
Z3JlZSI6eyJ0eXBlIjoiQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5
jZSBhbmQgQXJ0cyJ9fX0sImlzcyI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvaXNzdWVycy8xNCIsIm
5iZiI6MTI2MjM3MzgwNCwianRpIjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRlbnRpYWxzLzM3M
zIiLCJzdWIiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEifQ.6MNXY
zdnWzepi1_-Ourj0yv0aokF1MgTUfpXZKNSUWqde3ZF6qRMQt_h0RbDC-qW-oXkjcPdEGidxrbK
chO2Ng

At least one proof mechanism, and the details necessary to evaluate that proof,MUST be expressed for acredential orpresentation to be averifiable credential orverifiable presentation; that is, to beverifiable.

This specification identifies two classes of proof mechanisms: external proofsand embedded proofs. Anexternal proof is onethat wraps an expression of this data model, such as a JSON Web Token, which iselaborated on in Section6.3.1JSON Web Token. Anembeddedproof is a mechanism where the proof is included in the data, such as aLinked Data Signature, which is elaborated upon in Section6.3.2Data Integrity Proofs.

When embedding a proof, theproofpropertyMUST be used.

proof

One or more cryptographic proofs that can be used to detect tampering andverify the authorship of acredential orpresentation. Thespecific method used for anembedded proofMUST be included using thetypeproperty.

Because the method used for a mathematical proof varies by representationlanguage and the technology used, the set of name-value pairs that is expectedas the value of theproofproperty will vary accordingly.For example, if digital signatures are used for the proof mechanism, theproofproperty is expected to have name-value pairs thatinclude a signature, a reference to the signing entity, and a representation ofthe signing date. The example below uses RSA digital signatures.

{  "@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1"  ],  "id": "http://example.gov/credentials/3732",  "type": ["VerifiableCredential", "UniversityDegreeCredential"],  "issuer": "https://example.edu",  "issuanceDate": "2010-01-01T19:23:24Z",  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "degree": {      "type": "BachelorDegree",      "name": "Bachelor of Science and Arts"    }  },"proof": {    "type": "Ed25519Signature2020",    "created": "2021-11-13T18:19:39Z",    "verificationMethod": "https://example.edu/issuers/14#key-1",    "proofPurpose": "assertionMethod",    "proofValue": "z58DAdFfa9SkqZMVPxAQpic7ndSayn1PzZs6ZjWp1CktyGesjuTSwRdo                   WhAfGFCF5bppETSTojQCrfFPP2oumHKtz"  }}

This specification defines theexpirationDateproperty forthe expression ofcredential expiration information.

expirationDate

If present, the value of theexpirationDatepropertyMUST bea string value of an [XMLSCHEMA11-2]date-time representing the date and time thecredentialceases to be valid.

{  "@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"    }  }}

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1",
    "https://w3id.org/security/suites/ed25519-2020/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": {
    "type": "Ed25519Signature2020",
    "created": "2022-02-25T14:58:43Z",
    "verificationMethod": "https://example.edu/issuers/14#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3zwi434j3HdZv3C3TJxBnwmmiBgrtzRjM2oeDtZyAEkDeNDBeB9Metc
vyB4ZZUvQswKqPdgk5cFSAnyJ3yjvButH"
  }
}

---------------- JWT header ---------------
{
  "alg": "ES256",
  "typ": "JWT"
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "vc": {
    "@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"
      }
    }
  },
  "exp": 1577906604,
  "iss": "https://example.edu/issuers/14",
  "nbf": 1262373804,
  "jti": "http://example.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
--------------- JWT ---------------
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3
d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L
2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sImlkIjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRl
bnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiVW5pdmVyc2l0eUR
lZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLz
E0IiwiaXNzdWFuY2VEYXRlIjoiMjAxMC0wMS0wMVQxOToyMzoyNFoiLCJleHBpcmF0aW9uRGF0Z
SI6IjIwMjAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6
ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJkZWdyZWUiOnsidHlwZSI6IkJ
hY2hlbG9yRGVncmVlIiwibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMifX19LC
JleHAiOjE1Nzc5MDY2MDQsImlzcyI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvaXNzdWVycy8xNCIsI
m5iZiI6MTI2MjM3MzgwNCwianRpIjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRlbnRpYWxzLzM3
MzIiLCJzdWIiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEifQ.M4eB
gls2xrn00dp5JX7UBzEPauEOTWhtMjR-omIIhVHBBI4-ksHH5F6nFHuKo6pDu7W8c-i_knDTlRr
1zRp3IA

This specification defines the followingcredentialStatusproperty for the discovery of information about the current status of averifiable credential, such as whether it is suspended or revoked.

credentialStatus

If present, the value of thecredentialStatuspropertyMUSTinclude the following:

• idproperty, whichMUST be aURI.
• typeproperty, which expresses thecredential statustype (also referred to as thecredential status method). It is expectedthat the value will provide enough information to determine the current statusof thecredential and that machine readable information needs to beretrievable from the URI. For example, the object could contain a link to anexternal document noting whether or not thecredential is suspended orrevoked.

The precise contents of thecredential status information is determinedby the specificcredentialStatustype definition, and variesdepending on factors such as whether it is simple to implement or if it isprivacy-enhancing.

{  "@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",  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "degree": {      "type": "BachelorDegree",      "name": "Bachelor of Science and Arts"    }  },"credentialStatus": {    "id": "https://example.edu/status/24",    "type": "CredentialStatusList2017"  }}

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "UniversityDegreeCredential"
  ],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "credentialStatus": {
    "id": "https://example.edu/status/24",
    "type": "CredentialStatusList2017"
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2022-02-25T14:58:43Z",
    "verificationMethod": "https://example.edu/issuers/14#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3BXsFfx1qJ5NsTkKqREjQ3AGh6RAmCwvgu1HcDSzK3P5QEg2TAw8ufk
tJBw8QkAQRciMGyBf5T2AHyRg2w13Uvhp"
  }
}

---------------- JWT header ---------------
{
  "alg": "ES256",
  "typ": "JWT"
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "vc": {
    "@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",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "degree": {
        "type": "BachelorDegree",
        "name": "Bachelor of Science and Arts"
      }
    },
    "credentialStatus": {
      "id": "https://example.edu/status/24",
      "type": "CredentialStatusList2017"
    }
  },
  "iss": "https://example.edu/issuers/14",
  "nbf": 1262373804,
  "jti": "http://example.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
--------------- JWT ---------------
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3
d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L
2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sImlkIjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRl
bnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiVW5pdmVyc2l0eUR
lZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLz
E0IiwiaXNzdWFuY2VEYXRlIjoiMjAxMC0wMS0wMVQxOToyMzoyNFoiLCJjcmVkZW50aWFsU3Via
mVjdCI6eyJpZCI6ImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSIsImRl
Z3JlZSI6eyJ0eXBlIjoiQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5
jZSBhbmQgQXJ0cyJ9fSwiY3JlZGVudGlhbFN0YXR1cyI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS
5lZHUvc3RhdHVzLzI0IiwidHlwZSI6IkNyZWRlbnRpYWxTdGF0dXNMaXN0MjAxNyJ9fSwiaXNzI
joiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLzE0IiwibmJmIjoxMjYyMzczODA0LCJqdGki
OiJodHRwOi8vZXhhbXBsZS5lZHUvY3JlZGVudGlhbHMvMzczMiIsInN1YiI6ImRpZDpleGFtcGx
lOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJ9.YQKQUu_zreDs69AZ8YqpMGHLl9V_tWH4N
S9P9l67J1wWHf0QCyt5hyuA8ckM4seV-1TRbeiHwdJ3VRkDMcwFcg

Defining the data model, formats, and protocols for status schemes are out ofscope for this specification. A Verifiable Credential Extension Registry[VC-EXTENSION-REGISTRY] exists that contains available status schemesfor implementers who want to implementverifiable credentialstatus checking.

PresentationsMAY be used to combine and presentcredentials.They can be packaged in such a way that the authorship of the data isverifiable. The data in apresentation is often all about the samesubject, but there is no limit to the number ofsubjects orissuers in the data. The aggregation of information from multipleverifiable credentials is a typical use ofverifiable presentations.

Averifiable presentation is typically composed of the followingproperties:

id

Theidproperty is optional andMAY be used to provide aunique identifier for thepresentation. For details related to the use ofthis property, see Section4.2Identifiers.

type

Thetypeproperty is required and expresses thetype ofpresentation, such asVerifiablePresentation. Fordetails related to the use of this property, see Section4.3Types.

verifiableCredential

If present, the value of theverifiableCredentialpropertyMUST be constructed from one or moreverifiable credentials, or of dataderived fromverifiable credentials in a cryptographicallyverifiable format.

holder

If present, the value of theholderpropertyis expected to be aURI for the entity that is generating thepresentation.

proof

If present, the value of theproofproperty ensures thatthepresentation isverifiable. For details related to the use ofthis property, see Section4.7Proofs (Signatures).

The example below shows averifiable presentation that embedsverifiable credentials.

{  "@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1"  ],  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",  "type": ["VerifiablePresentation", "CredentialManagerPresentation"],"verifiableCredential": [{... }],  "proof": [{... }]}

The contents of theverifiableCredentialproperty shownabove areverifiable credentials, as described by this specification. Thecontents of theproofproperty are proofs, as described bythe Data Integrity [DATA-INTEGRITY] specification. An example of averifiable presentation using the JWT proof mechanism is given in section6.3.1JSON Web Token.

4.10.1Presentations Using Derived Credentials

Some zero-knowledge cryptography schemes might enableholders toindirectly prove they holdclaims from averifiable credentialwithout revealing theverifiable credential itself. In these schemes, aclaim from averifiable credential might be used to derive apresented value, which is cryptographically asserted such that averifiercan trust the value if they trust theissuer.

For example, averifiable credential containing theclaimdate of birth might be used to derive the presented valueover the age of 15 in a manner that is cryptographicallyverifiable. That is, averifier can still trust the derived valueif they trust theissuer.

Note

For an example of a ZKP-styleverifiable presentation containingderived data instead of directly embeddedverifiable credentials, seeSection5.8Zero-Knowledge Proofs.

Selective disclosure schemes using zero-knowledge proofs can useclaimsexpressed in this model to prove additional statements about thoseclaims.For example, aclaim specifying asubject's date of birth can beused as a predicate to prove thesubject's age is within a given range,and therefore prove thesubject qualifies for age-related discounts,without actually revealing thesubject's birthdate. Theholderhas the flexibility to use theclaim in any way that is applicable tothe desiredverifiable presentation.

This section is non-normative.

Section1.2Ecosystem Overview provided an overview of theverifiable credential ecosystem. This section provides more detail abouthow the ecosystem is envisaged to operate.

The roles and information flows in theverifiable credential ecosystemare as follows:

• Anissuerissues averifiable credential to aholder. Issuance always occurs beforeany other actions involving acredential.
• Aholder mighttransfer one or more of itsverifiablecredentials to anotherholder.
• Aholderpresents one ormore of itsverifiable credentials to averifier, optionallyinside averifiable presentation.
• Averifierverifies the authenticity of the presentedverifiable presentation andverifiable credentials. This shouldinclude checking thecredential status for revocationof theverifiable credentials.
• Anissuer mightrevoke averifiable credential.
• Aholder mightdelete averifiable credential.

The most common sequence of actions is envisioned to be:

1. Anissuerissues to aholder.
2. Theholderpresents to averifier.
3. Theverifierverifies.

This specification does not define any protocol for transferringverifiable credentials orverifiable presentations, but assumingother specifications do specify how they are transferred between entities, thenthis Verifiable Credential Data Model is directly applicable.

This specification also does not define an authorization framework nor thedecisions that averifier might make afterverifying averifiable credential orverifiable presentation,taking into account theholder, theissuers of theverifiable credentials, the contents of theverifiable credentials, and its own policies.

In particular, Sections5.6Terms of Use andC.Subject-Holder Relationships specify how averifier candetermine:

• Whether theholder is asubject of averifiable credential.
• The relationship between thesubject and theholder.
• Whether the originalholder passed averifiable credential to asubsequentholder.
• Any restrictions using theverifiable credentials by theholderorverifier.

This section is non-normative.

Theverifiable credentials trust model is as follows:

• Theverifier trusts theissuer to issue thecredential thatit received. To establish this trust, acredential is expected to either:
  • Include aproof establishing that theissuer generated thecredential (that is, it is averifiable credential), or
  • Have been transmitted in a way clearly establishing that theissuergenerated theverifiable credential and that theverifiable credential was not tampered with in transit or storage. Thistrust could be weakened depending on the risk assessment of theverifier.
• Allentities trust theverifiable data registry to betamper-evident and to be a correct record of which data is controlled by whichentities.
• Theholder andverifier trust theissuer to issuetrue (that is, not false)credentials about thesubject, and torevoke them quickly when appropriate.
• Theholder trusts therepository to storecredentialssecurely, to not release them to anyone other than theholder, and to notcorrupt or lose them while they are in its care.

This trust model differentiates itself from other trust models by ensuringthe:

• Issuer and theverifier do not need to trust therepository
• Issuer does not need to know or trust theverifier.

By decoupling the trust between theidentity provider and therelying party a more flexible and dynamic trust model is created suchthat market competition and customer choice is increased.

For more information about how this trust model interacts with various threatmodels studied by the Working Group, see the Verifiable Credentials Use Casesdocument [VC-USE-CASES].

One of the goals of the Verifiable Credentials Data Model is to enablepermissionless innovation. To achieve this, the data model needs to beextensible in a number of different ways. The data model is required to:

• Model complex multi-entity relationships through the use of agraph-baseddata model.
• Extend the machine-readable vocabularies used to describe information in thedata model, without the use of a centralized system for doing so, through theuse of [LINKED-DATA].
• Support multiple types of cryptographic proof formats through the use ofData Integrity Proofs [DATA-INTEGRITY] and a variety of signature suiteslisted in the Linked Data Cryptographic Suites Registry [LDP-REGISTRY]
• Provide all of the extensibility mechanisms outlined above in a data format thatis popular with software developers and web page authors, and is enabled throughthe use of [JSON-LD].

This approach to data modeling is often called anopen world assumption, meaning that any entity can say anything aboutany other entity. While this approach seems to conflict with building simple andpredictable software systems, balancing extensibility with program correctnessis always more challenging with an open world assumption than with closedsoftware systems.

The rest of this section describes, through a series of examples, how bothextensibility and program correctness are achieved.

Let us assume we start with theverifiable credential shown below.

{  "@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1"  ],  "id": "http://example.com/credentials/4643",  "type": ["VerifiableCredential"],  "issuer": "https://example.com/issuers/14",  "issuanceDate": "2018-02-24T05:28:04Z",  "credentialSubject": {    "id": "did:example:abcdef1234567",    "name": "Jane Doe"  }}

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "http://example.com/credentials/4643",
  "type": [
    "VerifiableCredential"
  ],
  "issuer": "https://example.com/issuers/14",
  "issuanceDate": "2018-02-24T05:28:04Z",
  "credentialSubject": {
    "id": "did:example:abcdef1234567",
    "name": "Jane Doe"
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2022-02-25T14:58:43Z",
    "verificationMethod": "https://example.edu/issuers/14#keys-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "zyrpmzxPy2fDzqv9Pgr4XBzX2rys1FDuLNkYRVmhXuyype8fB44qNX8m
NnXf99i7x1eSpLdYKNhEKknEJmdGfQ4w"
  }
}

---------------- JWT header ---------------
{
  "alg": "ES256",
  "typ": "JWT"
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "http://example.com/credentials/4643",
    "type": [
      "VerifiableCredential"
    ],
    "issuer": "https://example.com/issuers/14",
    "issuanceDate": "2018-02-24T05:28:04Z",
    "credentialSubject": {
      "id": "did:example:abcdef1234567",
      "name": "Jane Doe"
    }
  },
  "iss": "https://example.com/issuers/14",
  "nbf": 1519450084,
  "jti": "http://example.com/credentials/4643",
  "sub": "did:example:abcdef1234567"
}
--------------- JWT ---------------
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3
d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L
2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sImlkIjoiaHR0cDovL2V4YW1wbGUuY29tL2NyZWRl
bnRpYWxzLzQ2NDMiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIl0sImlzc3VlciI6Imh
0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVycy8xNCIsImlzc3VhbmNlRGF0ZSI6IjIwMTgtMDItMj
RUMDU6Mjg6MDRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTphYmNkZ
WYxMjM0NTY3IiwibmFtZSI6IkphbmUgRG9lIn19LCJpc3MiOiJodHRwczovL2V4YW1wbGUuY29t
L2lzc3VlcnMvMTQiLCJuYmYiOjE1MTk0NTAwODQsImp0aSI6Imh0dHA6Ly9leGFtcGxlLmNvbS9
jcmVkZW50aWFscy80NjQzIiwic3ViIjoiZGlkOmV4YW1wbGU6YWJjZGVmMTIzNDU2NyJ9.oIDq_
JtiKwm1AVikEjMuurZcfZdTtNAvus63k2kbD1HF2l_5V36ekulxPPY7rKYEeiH3e6bTq1urNoML
K3UipA

Thisverifiable credential states that theentity associated withdid:example:abcdef1234567 has aname with a value ofJane Doe.

Now let us assume a developer wants to extend theverifiable credentialto store two additional pieces of information: an internal corporate referencenumber, and Jane's favorite food.

The first thing to do is to create a JSON-LD context containing two new terms,as shown below.

{  "@context": {    "referenceNumber": "https://example.com/vocab#referenceNumber",    "favoriteFood": "https://example.com/vocab#favoriteFood"  }}

After this JSON-LD context is created, the developer publishes it somewhere soit is accessible toverifiers who will be processing theverifiable credential. Assuming the above JSON-LD context is published athttps://example.com/contexts/mycontext.jsonld, we can extend thisexample by including the context and adding the newproperties andcredentialtype to theverifiable credential.

{  "@context": [    "https://www.w3.org/2018/credentials/v1","https://example.com/contexts/mycontext.jsonld"  ],  "id": "http://example.com/credentials/4643",  "type": ["VerifiableCredential", "CustomExt12"],  "issuer": "https://example.com/issuers/14",  "issuanceDate": "2018-02-24T05:28:04Z","referenceNumber": 83294847,  "credentialSubject": {    "id": "did:example:abcdef1234567",    "name": "Jane Doe","favoriteFood": "Papaya"  }}

This example demonstrates extending the Verifiable Credentials Data Model in apermissionless and decentralized way. The mechanism shown also ensures thatverifiable credentials created in this way provide a mechanism to preventnamespace conflicts and semantic ambiguity.

A dynamic extensibility model such as this does increase the implementationburden. Software written for such a system has to determine whetherverifiable credentials with extensions are acceptable based on the riskprofile of the application. Some applications might accept only certainextensions while highly secure environments might not accept any extensions.These decisions are up to the developers of these applications and arespecifically not the domain of this specification.

Developers are urged to ensure that extension JSON-LD contexts are highlyavailable. Implementations that cannot fetch a context will produce an error.Strategies for ensuring that extension JSON-LD contexts are always availableinclude using content-addressed URLs for contexts, bundling context documentswith implementations, or enabling aggressive caching of contexts.

Implementers are advised to pay close attention to the extension points in thisspecification, such as in Sections4.7Proofs (Signatures),4.9Status,5.4Data Schemas,5.5Refreshing,5.6Terms of Use, and5.7Evidence. While thisspecification does not define concrete implementations for those extensionpoints, the Verifiable Credentials Extension Registry [VC-EXTENSION-REGISTRY]provides an unofficial, curated list of extensions that developers can use fromthese extension points.

Data schemas are useful when enforcing a specific structure on a givencollection of data. There are at least two types of data schemas that thisspecification considers:

• Data verification schemas, which are used toverify that the structureand contents of acredential orverifiable credential conform to apublished schema.
• Data encoding schemas, which are used to map the contents of averifiable credential to an alternative representation format, such as abinary format used in a zero-knowledge proof.

It is important to understand that data schemas serve a different purpose fromthe@context property, which neither enforces data structure ordata syntax, nor enables the definition of arbitrary encodings to alternaterepresentation formats.

This specification defines the followingproperty for the expression of adata schema, which can be included by anissuer intheverifiable credentials that it issues:

credentialSchema

The value of thecredentialSchemapropertyMUST be one ormore data schemas that provideverifiers with enough information todetermine if the provided data conforms to the provided schema. EachcredentialSchemaMUST specify itstype (for example,JsonSchemaValidator2018), and anidpropertythatMUST be aURI identifying the schema file. The precise contents ofeach data schema is determined by the specific type definition.

{  "@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",  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "degree": {      "type": "BachelorDegree",      "name": "Bachelor of Science and Arts"    }  },"credentialSchema": {    "id": "https://example.org/examples/degree.json",    "type": "JsonSchemaValidator2018"  }}

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "UniversityDegreeCredential"
  ],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "credentialSchema": {
    "id": "https://example.org/examples/degree.json",
    "type": "JsonSchemaValidator2018"
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2022-02-25T14:58:43Z",
    "verificationMethod": "https://example.edu/issuers/14#keys-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5JKxik9jw25W2s9Q3N3RMovCVLSt1h6bBTZrKsy3JWP48KokH4spdBU
xTykSb11FCtn8q5HWybySAGCFaWwN2aiT"
  }
}

---------------- JWT header ---------------
{
  "alg": "ES256",
  "typ": "JWT"
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "vc": {
    "@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",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "degree": {
        "type": "BachelorDegree",
        "name": "Bachelor of Science and Arts"
      }
    },
    "credentialSchema": {
      "id": "https://example.org/examples/degree.json",
      "type": "JsonSchemaValidator2018"
    }
  },
  "iss": "https://example.edu/issuers/14",
  "nbf": 1262373804,
  "jti": "http://example.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
--------------- JWT ---------------
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3
d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L
2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sImlkIjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRl
bnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiVW5pdmVyc2l0eUR
lZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLz
E0IiwiaXNzdWFuY2VEYXRlIjoiMjAxMC0wMS0wMVQxOToyMzoyNFoiLCJjcmVkZW50aWFsU3Via
mVjdCI6eyJpZCI6ImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSIsImRl
Z3JlZSI6eyJ0eXBlIjoiQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5
jZSBhbmQgQXJ0cyJ9fSwiY3JlZGVudGlhbFNjaGVtYSI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS
5vcmcvZXhhbXBsZXMvZGVncmVlLmpzb24iLCJ0eXBlIjoiSnNvblNjaGVtYVZhbGlkYXRvcjIwM
TgifX0sImlzcyI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvaXNzdWVycy8xNCIsIm5iZiI6MTI2MjM3
MzgwNCwianRpIjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRlbnRpYWxzLzM3MzIiLCJzdWIiOiJ
kaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEifQ.GRJHwxvQfgEOP8TaaBn
p2ZCPjFlA_KodpdBupHsRroql10gaE--8oAXR1e-wOuxjFoK-T814h9LKnv71IMI38Q

In the example above, theissuer is specifying acredentialSchema, which points to a [JSON-SCHEMA-2018] file thatcan be used by averifier to determine if theverifiable credential is well formed.

Data schemas can also be used to specify mappings to other binary formats, suchas those used to perform zero-knowledge proofs. For more information on usingthecredentialSchemaproperty with zero-knowledge proofs,see Section5.8Zero-Knowledge Proofs.

{  "@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",  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "degree": {      "type": "BachelorDegree",      "name": "Bachelor of Science and Arts"    }  },"credentialSchema": {    "id": "https://example.org/examples/degree.zkp",    "type": "ZkpExampleSchema2018"  },  "proof": {... }}

In the example above, theissuer is specifying acredentialSchema pointing to a zero-knowledge packed binary dataformat that is capable of transforming the input data into a format, which canthen be used by averifier to determine if the proof provided with theverifiable credential is valid.

It is useful for systems to enable the manual or automatic refresh of anexpiredverifiable credential. For more information about expiredverifiable credentials, see Section4.8Expiration. Thisspecification defines arefreshServiceproperty, whichenables anissuer to include a link to a refresh service.

Theissuer can include the refresh service as an element inside theverifiable credential if it is intended for either theverifier ortheholder (or both), or inside theverifiable presentation if itis intended for theholder only. In the latter case, this enables theholder to refresh theverifiable credential before creating averifiable presentation to share with averifier. In the formercase, including the refresh service inside theverifiable credentialenables either theholder or theverifier to perform futureupdates of thecredential.

The refresh service is only expected to be used when either thecredential has expired or theissuer does not publishcredential status information.Issuers are advised not to put therefreshServiceproperty in averifiable credentialthat does not contain public information or whose refresh service is notprotected in some way.

refreshService

The value of therefreshServicepropertyMUST be one or morerefresh services that provides enough information to the recipient's softwaresuch that the recipient can refresh theverifiable credential. EachrefreshService valueMUST specify itstype (forexample,ManualRefreshService2018) and itsid, whichis theURI of the service. There is an expectation that machine readableinformation needs to be retrievable from the URI. The precise content ofeach refresh service is determined by the specificrefreshServicetype definition.

{  "@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",  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "degree": {      "type": "BachelorDegree",      "name": "Bachelor of Science and Arts"    }  },"refreshService": {    "id": "https://example.edu/refresh/3732",    "type": "ManualRefreshService2018"  }}

In the example above, theissuer specifies a manualrefreshService that can be used by directing theholder ortheverifier tohttps://example.edu/refresh/3732.

Terms of use can be utilized by anissuer or aholder tocommunicate the terms under which averifiable credential orverifiable presentation was issued. Theissuer places their termsof use inside theverifiable credential. Theholder places theirterms of use inside averifiable presentation. This specification definesatermsOfUseproperty for expressing terms of useinformation.

The value of thetermsOfUseproperty tells theverifier what actions it is required to perform (anobligation),not allowed to perform (aprohibition), or allowed to perform (apermission) if it is to accept theverifiable credential orverifiable presentation.

termsOfUse

The value of thetermsOfUsepropertyMUST specify one ormore terms of use policies under which the creator issued thecredentialorpresentation. If the recipient (aholder orverifier) is not willing to adhere to the specified terms of use, thenthey do so on their own responsibility and might incur legal liability if theyviolate the stated terms of use. EachtermsOfUse valueMUST specifyitstype, for example,IssuerPolicy, andMAY specify itsinstanceid. The precise contents of each term of use is determinedby the specifictermsOfUsetype definition.

{  "@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",  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "degree": {      "type": "BachelorDegree",      "name": "Bachelor of Science and Arts"    }  },"termsOfUse": [{    "type": "IssuerPolicy",    "id": "http://example.com/policies/credential/4",    "profile": "http://example.com/profiles/credential",    "prohibition": [{      "assigner": "https://example.edu/issuers/14",      "assignee": "AllVerifiers",      "target": "http://example.edu/credentials/3732",      "action": ["Archival"]    }]  }]}

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "UniversityDegreeCredential"
  ],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "termsOfUse": [
    {
      "type": "IssuerPolicy",
      "id": "http://example.com/policies/credential/4",
      "profile": "http://example.com/profiles/credential",
      "prohibition": [
        {
          "assigner": "https://example.edu/issuers/14",
          "assignee": "AllVerifiers",
          "target": "http://example.edu/credentials/3732",
          "action": [
            "Archival"
          ]
        }
      ]
    }
  ],
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2022-02-25T14:58:43Z",
    "verificationMethod": "https://example.edu/issuers/14#keys-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z2ty8BNvrKCvAXGqJVXF8aZ1jK5o5uXFvhXJksUXhn61uSwJJmWdcntf
qvZTLbWmQHpieyhdcrG43em37Jo8bswvR"
  }
}

---------------- JWT header ---------------
{
  "alg": "ES256",
  "typ": "JWT"
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "vc": {
    "@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",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "degree": {
        "type": "BachelorDegree",
        "name": "Bachelor of Science and Arts"
      }
    },
    "termsOfUse": [
      {
        "type": "IssuerPolicy",
        "id": "http://example.com/policies/credential/4",
        "profile": "http://example.com/profiles/credential",
        "prohibition": [
          {
            "assigner": "https://example.edu/issuers/14",
            "assignee": "AllVerifiers",
            "target": "http://example.edu/credentials/3732",
            "action": [
              "Archival"
            ]
          }
        ]
      }
    ]
  },
  "iss": "https://example.edu/issuers/14",
  "nbf": 1262373804,
  "jti": "http://example.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
--------------- JWT ---------------
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3
d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L
2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sImlkIjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRl
bnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiVW5pdmVyc2l0eUR
lZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLz
E0IiwiaXNzdWFuY2VEYXRlIjoiMjAxMC0wMS0wMVQxOToyMzoyNFoiLCJjcmVkZW50aWFsU3Via
mVjdCI6eyJpZCI6ImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSIsImRl
Z3JlZSI6eyJ0eXBlIjoiQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5
jZSBhbmQgQXJ0cyJ9fSwidGVybXNPZlVzZSI6W3sidHlwZSI6Iklzc3VlclBvbGljeSIsImlkIj
oiaHR0cDovL2V4YW1wbGUuY29tL3BvbGljaWVzL2NyZWRlbnRpYWwvNCIsInByb2ZpbGUiOiJod
HRwOi8vZXhhbXBsZS5jb20vcHJvZmlsZXMvY3JlZGVudGlhbCIsInByb2hpYml0aW9uIjpbeyJh
c3NpZ25lciI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvaXNzdWVycy8xNCIsImFzc2lnbmVlIjoiQWx
sVmVyaWZpZXJzIiwidGFyZ2V0IjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRlbnRpYWxzLzM3Mz
IiLCJhY3Rpb24iOlsiQXJjaGl2YWwiXX1dfV19LCJpc3MiOiJodHRwczovL2V4YW1wbGUuZWR1L
2lzc3VlcnMvMTQiLCJuYmYiOjEyNjIzNzM4MDQsImp0aSI6Imh0dHA6Ly9leGFtcGxlLmVkdS9j
cmVkZW50aWFscy8zNzMyIiwic3ViIjoiZGlkOmV4YW1wbGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZ
lMTJlYzIxIn0.YMeGs_5KDNzta-h_ehAY9RS6jyyJ8kB36QOXQL6GR1WCkWUz7S2ZUUsBblvipk
cgnA4fCfdjI5c_aZI3Ce8byw

In the example above, theissuer (theassigner) isprohibitingverifiers (theassignee) from storing the datain an archive.

{  "@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1",    {        "@protected": true,        "VerifiablePresentationTermsOfUseExtension": {          "@id": "https://www.w3.org/2018/credentials/examples#VerifiablePresentationExtension",          "@context": {            "@protected": true,            "termsOfUse": {              "@id": "https://www.w3.org/2018/credentials#termsOfUse",              "@type": "@id"            }          }        }    }  ],  "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",  "type": ["VerifiablePresentation", "VerifiablePresentationTermsOfUseExtension"],  "verifiableCredential": [{    "@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",    "credentialSubject": {      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",      "degree": {      "type": "BachelorDegree",      "name": "Bachelor of Science and Arts"    }    },    "proof": {... }  }],"termsOfUse": [{    "type": "HolderPolicy",    "id": "http://example.com/policies/credential/6",    "profile": "http://example.com/profiles/credential",    "prohibition": [{      "assigner": "did:example:ebfeb1f712ebc6f1c276e12ec21",      "assignee": "https://wineonline.example.org/",      "target": "http://example.edu/credentials/3732",      "action": ["3rdPartyCorrelation"]    }]  }],  "proof": [ ... ]}

In the example above, theholder (theassigner), who isalso thesubject, expressed a term of use prohibiting theverifier(theassignee,https://wineonline.example.org) fromusing the information provided to correlate theholder orsubjectusing a third-party service. If theverifier were to use a third-partyservice for correlation, they would violate the terms under which theholder created thepresentation.

This feature is also expected to be used by government-issuedverifiable credentials to instruct digital wallets to limit their use tosimilar government organizations in an attempt to protect citizens fromunexpected usage of sensitive data. Similarly, someverifiable credentials issued by private industry are expected to limitusage to within departments inside the organization, or during business hours.Implementers are urged to read more about this rapidly evolving feature in theappropriate section of the Verifiable Credentials Implementation Guidelines[VC-IMP-GUIDE] document.

Evidence can be included by anissuer to provide theverifier withadditional supporting information in averifiable credential. This couldbe used by theverifier to establish the confidence with which it relieson the claims in theverifiable credential.

For example, anissuer could check physical documentation provided by thesubject or perform a set of background checks before issuing thecredential. In certain scenarios, this information is useful to theverifier when determining the risk associated with relying on a givencredential.

This specification defines theevidenceproperty forexpressing evidence information.

evidence

The value of theevidencepropertyMUST be one or moreevidence schemes providing enough information for averifier to determinewhether the evidence gathered by theissuer meets its confidencerequirements for relying on thecredential. Each evidence scheme isidentified by itstype. Theidproperty is optional,but if present,SHOULD contain a URL that points to where more information aboutthis instance of evidence can be found. The precise content of each evidencescheme is determined by the specificevidencetypedefinition.

{  "@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",  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "degree": {      "type": "BachelorDegree",      "name": "Bachelor of Science and Arts"    }  },"evidence": [{    "id": "https://example.edu/evidence/f2aeec97-fc0d-42bf-8ca7-0548192d4231",    "type": ["DocumentVerification"],    "verifier": "https://example.edu/issuers/14",    "evidenceDocument": "DriversLicense",    "subjectPresence": "Physical",    "documentPresence": "Physical",    "licenseNumber": "123AB4567"  }],  "proof": {... }}

A zero-knowledge proof is a cryptographic method where an entity can prove toanother entity that they know a certain value without disclosing the actualvalue. A real-world example is proving that an accredited university hasgranted a degree to you without revealing your identity or any other personallyidentifiable information contained on the degree.

The key capabilities introduced by zero-knowledge proof mechanisms are theability of aholder to:

• Combine multipleverifiable credentials from multipleissuers intoa singleverifiable presentation without revealingverifiable credential orsubject identifiers to theverifier. This makes it more difficult for theverifier to colludewith any of the issuers regarding the issuedverifiable credentials.
• Selectively disclose theclaims in averifiable credential to averifier without requiring the issuance of multiple atomicverifiable credentials. This allows aholder to provide averifier with precisely the information they need and nothing more.
• Produce a derivedverifiable credential that is formatted according totheverifier's data schema instead of theissuer's, withoutneeding to involve theissuer afterverifiable credentialissuance. This provides a great deal of flexibility forholders to usetheir issuedverifiable credentials.

This specification describes a data model that supports selective disclosurewith the use of zero-knowledge proof mechanisms. The examples below highlighthow the data model can be used to issue, present, and verify zero-knowledgeverifiable credentials.

For aholder to use a zero-knowledgeverifiable presentation,they need anissuer to have issued averifiable credential in a mannerthat enables theholder to derive a proof from the originally issuedverifiable credential, so that theholder can present theinformation to averifier in a privacy-enhancing manner.This implies that theholder can prove the validity of theissuer's signature without revealing the values that were signed, or whenonly revealing certain selected values. The standard practice is to do so byproving knowledge of the signature, without revealing the signature itself.There are two requirements forverifiable credentials when they are to beused in zero-knowledge proof systems.

• Theverifiable credentialMUST contain a Proof, using theproofproperty, so that theholder can derive averifiable presentation that reveals only the information than theholder intends to reveal.
• If acredential definition is being used, thecredentialdefinitionMUST be defined in thecredentialSchemaproperty,so that it can be used by all parties to perform various cryptographicoperations in zero-knowledge.

The following example shows one method of usingverifiable credentials inzero-knowledge. It makes use of a Camenisch-Lysyanskaya Signature[CL-SIGNATURES], which allows the presentation of theverifiablecredential in a way that supports the privacy of theholder andsubject through the use of selective disclosure of theverifiable credential values. Some other cryptographic systems which relyupon zero-knowledge proofs to selectively disclose attributes can be found in the[LDP-REGISTRY] as well.

{  "@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1"  ],  "type": ["VerifiableCredential", "UniversityDegreeCredential"],"credentialSchema": {    "id": "did:example:cdf:35LB7w9ueWbagPL94T9bMLtyXDj9pX5o",    "type": "did:example:schema:22KpkXgecryx9k7N6XN1QoN3gXwBkSU8SfyyYQG"  },  "issuer": "did:example:Wz4eUg7SetGfaUVCn8U9d62oDYrUJLuUtcy619",  "credentialSubject": {    "givenName": "Jane",    "familyName": "Doe",    "degree": {      "type": "BachelorDegree",      "name": "Bachelor of Science and Arts",      "college": "College of Engineering"    }  },"proof": {    "type": "CLSignature2019",    "issuerData": "5NQ4TgzNfSQxoLzf2d5AV3JNiCdMaTgm...BXiX5UggB381QU7ZCgqWivUmy4D",    "attributes": "pPYmqDvwwWBDPNykXVrBtKdsJDeZUGFA...tTERiLqsZ5oxCoCSodPQaggkDJy",    "signature": "8eGWSiTiWtEA8WnBwX4T259STpxpRKuk...kpFnikqqSP3GMW7mVxC4chxFhVs",    "signatureCorrectnessProof": "SNQbW3u1QV5q89qhxA1xyVqFa6jCrKwv...dsRypyuGGK3RhhBUvH1tPEL8orH"  }}

The example above provides theverifiable credential definition by usingthecredentialSchemaproperty and a specific proof that isusable in the Camenisch-Lysyanskaya Zero-Knowledge Proof system.

The next example utilizes theverifiable credential above to generate anew derivedverifiable credential with a privacy-preserving proof. Thederivedverifiable credential is then placed in averifiable presentation, so that theverifiable credentialdiscloses only theclaims and additional credential metadata that theholder intended. To do this, all of the following requirements areexpected to be met:

• Each derivedverifiable credential within averifiablepresentationMUST contain all information necessary to verify theverifiable credential, either by including it directly within thecredential, or by referencing the necessary information.
• Averifiable presentationMUST NOT leak information that would enabletheverifier to correlate theholder across multipleverifiable presentations.
• Theverifiable presentationSHOULD contain aproofproperty to enable theverifier to check that all derivedverifiable credentials in theverifiable presentation were issuedto the sameholder without leaking personally identifiable informationthat theholder did not intend to share.

{  "@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1"  ],  "type": "VerifiablePresentation",  "verifiableCredential": [    {      "@context": [        "https://www.w3.org/2018/credentials/v1",        "https://www.w3.org/2018/credentials/examples/v1"      ],      "type": ["VerifiableCredential", "UniversityDegreeCredential"],"credentialSchema": {        "id": "did:example:cdf:35LB7w9ueWbagPL94T9bMLtyXDj9pX5o",        "type": "did:example:schema:22KpkXgecryx9k7N6XN1QoN3gXwBkSU8SfyyYQG"      },      "issuer": "did:example:Wz4eUg7SetGfaUVCn8U9d62oDYrUJLuUtcy619",      "credentialSubject": {        "degreeType": "BachelorDegree",        "degreeSchool": "College of Engineering"      },"proof": {        "type": "AnonCredDerivedCredentialv1",        "primaryProof": "cg7wLNSi48K5qNyAVMwdYqVHSMv1Ur8i...Fg2ZvWF6zGvcSAsym2sgSk737",        "nonRevocationProof": "mu6fg24MfJPU1HvSXsf3ybzKARib4WxG...RSce53M6UwQCxYshCuS3d2h"      }  }],"proof": {    "type": "AnonCredPresentationProofv1",    "proofValue": "DgYdYMUYHURJLD7xdnWRinqWCEY5u5fK...j915Lt3hMzLHoPiPQ9sSVfRrs1D"  }}

There are at least two different cases to consider for anentitywanting to dispute acredential issued by anissuer:

• Asubject disputes a claim made by theissuer. For example, theaddressproperty is incorrect or out of date.
• Anentity disputes a potentially false claim made by theissuerabout a differentsubject. For example, an imposter claims the socialsecurity number for anentity.

The mechanism for issuing aDisputeCredential is the same asfor a regularcredential except that thecredentialSubjectidentifier in theDisputeCredentialproperty is theidentifier of the disputedcredential.

For example, if acredential with an identifier ofhttps://example.org/credentials/245 is disputed, thesubjectcan issue thecredential shown below and present it to theverifier along with the disputedcredential.

{  "@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1"  ],  "id": "http://example.com/credentials/123",  "type": ["VerifiableCredential", "DisputeCredential"],"credentialSubject": {    "id": "http://example.com/credentials/245",    "currentStatus": "Disputed",    "statusReason": {      "value": "Address is out of date.",      "lang": "en"    },  },  "issuer": "https://example.com/people#me",  "issuanceDate": "2017-12-05T14:27:42Z",  "proof": {... }}

In the aboveverifiable credential theissuer is claiming thatthe address in the disputedverifiable credential is wrong.

This section is non-normative.

Verifiable credentials are intended as a means of reliably identifyingsubjects. While it is recognized that Role Based Access Controls (RBACs)and Attribute Based Access Controls (ABACs) rely on this identification as ameans of authorizingsubjects to access resources, this specificationdoes not provide a complete solution for RBAC or ABAC. Authorization is not anappropriate use for this specification without an accompanying authorizationframework.

The Working Group did consider authorization use cases during the creation ofthis specification and is pursuing that work as an architectural layer builton top of this specification.

The data model, as described in Section3.Core Data Model, can beencoded in JavaScript Object Notation (JSON) [RFC8259] by mapping propertyvalues to JSON types as follows:

• Numeric values representable as IEEE754SHOULD be represented as a Number type.
• Boolean valuesSHOULD be represented as a Boolean type.
• Sequence valueSHOULD be represented as an Array type.
• Unordered sets of valuesSHOULD be represented as an Array type.
• Sets ofpropertiesSHOULD be represented as an Object type.
• Empty valuesSHOULD be represented as a null value.
• Other valuesMUST be represented as a String type.

[JSON-LD] is a JSON-based format used to serializeLinked Data. Thesyntax is designed to easily integrate into deployed systems already using JSON,and provides a smooth upgrade path from JSON to [JSON-LD]. It is primarilyintended to be a way to use Linked Data in Web-based programming environments,to build interoperable Web services, and to store Linked Data in JSON-basedstorage engines.

[JSON-LD] is useful when extending the data model described in thisspecification. Instances of the data model are encoded in [JSON-LD] in thesame way they are encoded in JSON (Section6.1JSON), with theaddition of the@contextproperty. TheJSON-LD contextis described in detail in the [JSON-LD] specification and its use iselaborated on in Section5.3Extensibility.

Multiple contextsMAY be used or combined to express any arbitrary informationaboutverifiable credentials in idiomatic JSON. TheJSON-LD context,available athttps://www.w3.org/2018/credentials/v1, is a staticdocument that is never updated and can therefore be downloaded and cached clientside. The associated vocabulary document for the Verifiable Credentials DataModel is available athttps://www.w3.org/2018/credentials.

The data model described in this specification is designed to be proof formatagnostic. This specification does not normatively require any particular digitalproof or signature format. While the data model is the canonical representationof acredential orpresentation, theproofing mechanisms for these are often tied to the syntax used in thetransmission of the document between parties. As such, each proofing mechanismhas to specify whether the verification of the proof is calculated against thestate of the document as transmitted, against the possibly transformed data model, oragainst another form. At the time of publication, at least two proof formatsare being actively utilized by implementers and the Working Group feltthat documenting what these proof formats are and how they are being used wouldbe beneficial to implementers. The sections detailing the current proof formatsbeing actively utilized to issueverifiable credentials are:

• Section6.3.1JSON Web Token, and
• Section6.3.2Data Integrity Proofs.

{    "alg": "RS256",    "typ": "JWT",    "kid": "did:example:abfe13f712120431c276e12ecab#keys-1"}

{  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",  "jti": "http://example.edu/credentials/3732",  "iss": "https://example.com/keys/foo.jwk",  "nbf": 1541493724,  "iat": 1541493724,  "exp": 1573029723,  "nonce": "660!6345FSer",  "vc": {    "@context": [      "https://www.w3.org/2018/credentials/v1",      "https://www.w3.org/2018/credentials/examples/v1"    ],    "type": ["VerifiableCredential", "UniversityDegreeCredential"],    "credentialSubject": {      "degree": {        "type": "BachelorDegree",        "name": "Bachelor of Science and Arts"      }    }  }}

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRpZDpleGFtcGxlOmFiZmUxM2Y3MTIxMjA0MzFjMjc2ZTEyZWNhYiNrZXlzLTEifQ.eyJzdWIiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJqdGkiOiJodHRwOi8vZXhhbXBsZS5lZHUvY3JlZGVudGlhbHMvMzczMiIsImlzcyI6Imh0dHBzOi8vZXhhbXBsZS5jb20va2V5cy9mb28uandrIiwibmJmIjoxNTQxNDkzNzI0LCJpYXQiOjE1NDE0OTM3MjQsImV4cCI6MTU3MzAyOTcyMywibm9uY2UiOiI2NjAhNjM0NUZTZXIiLCJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJVbml2ZXJzaXR5RGVncmVlQ3JlZGVudGlhbCJdLCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsidHlwZSI6IkJhY2hlbG9yRGVncmVlIiwibmFtZSI6IjxzcGFuIGxhbmc9J2ZyLUNBJz5CYWNjYWxhdXLDqWF0IGVuIG11c2lxdWVzIG51bcOpcmlxdWVzPC9zcGFuPiJ9fX19.KLJo5GAyBND3LDTn9H7FQokEsUEi8jKwXhGvoN3JtRa51xrNDgXDb0cq1UTYB-rK4Ft9YVmR1NI_ZOF8oGc_7wAp8PHbF2HaWodQIoOBxxT-4WNqAxft7ET6lkH-4S6Ux3rSGAmczMohEEf8eCeN-jC8WekdPl6zKZQj0YPB1rx6X0-xlFBs7cl6Wt8rfBP_tZ9YgVWrQmUWypSioc0MUyiphmyEbLZagTyPlUyflGlEdqrZAv6eSe6RtxJy6M1-lD7a5HTzanYTWBPAUHDZGyGKXdJw-W_x0IWChBzI8t3kpG253fg6V3tPgHeKXE94fz_QpYfg--7kLsyBAfQGbg

{  "alg": "RS256",  "typ": "JWT",  "kid": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1"}

{  "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21",  "jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",  "aud": "did:example:4a57546973436f6f6c4a4a57573",  "nbf": 1541493724,  "iat": 1541493724,  "exp": 1573029723,  "nonce": "343s$FSFDa-",  "vp": {    "@context": [      "https://www.w3.org/2018/credentials/v1",      "https://www.w3.org/2018/credentials/examples/v1"    ],    "type": ["VerifiablePresentation"],// base64url-encoded JWT as string    "verifiableCredential": ["..."]  }}

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRpZDpleGFtcGxlOjB4YWJjI2tleTEifQ.eyJpc3MiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJqdGkiOiJ1cm46dXVpZDozOTc4MzQ0Zi04NTk2LTRjM2EtYTk3OC04ZmNhYmEzOTAzYzUiLCJhdWQiOiJkaWQ6ZXhhbXBsZTo0YTU3NTQ2OTczNDM2ZjZmNmM0YTRhNTc1NzMiLCJuYmYiOjE1NDE0OTM3MjQsImlhdCI6MTU0MTQ5MzcyNCwiZXhwIjoxNTczMDI5NzIzLCJub25jZSI6IjM0M3MkRlNGRGEtIiwidnAiOnsiQGNvbnRleHQiOlsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy9leGFtcGxlcy92MSJdLCJ0eXBlIjpbIlZlcmlmaWFibGVQcmVzZW50YXRpb24iLCJDcmVkZW50aWFsTWFuYWdlclByZXNlbnRhdGlvbiJdLCJ2ZXJpZmlhYmxlQ3JlZGVudGlhbCI6WyJleUpoYkdjaU9pSlNVekkxTmlJc0luUjVjQ0k2SWtwWFZDSXNJbXRwWkNJNkltUnBaRHBsZUdGdGNHeGxPbUZpWm1VeE0yWTNNVEl4TWpBME16RmpNamMyWlRFeVpXTmhZaU5yWlhsekxURWlmUS5leUp6ZFdJaU9pSmthV1E2WlhoaGJYQnNaVHBsWW1abFlqRm1OekV5WldKak5tWXhZekkzTm1VeE1tVmpNakVpTENKcWRHa2lPaUpvZEhSd09pOHZaWGhoYlhCc1pTNWxaSFV2WTNKbFpHVnVkR2xoYkhNdk16Y3pNaUlzSW1semN5STZJbWgwZEhCek9pOHZaWGhoYlhCc1pTNWpiMjB2YTJWNWN5OW1iMjh1YW5kcklpd2libUptSWpveE5UUXhORGt6TnpJMExDSnBZWFFpT2pFMU5ERTBPVE0zTWpRc0ltVjRjQ0k2TVRVM016QXlPVGN5TXl3aWJtOXVZMlVpT2lJMk5qQWhOak0wTlVaVFpYSWlMQ0oyWXlJNmV5SkFZMjl1ZEdWNGRDSTZXeUpvZEhSd2N6b3ZMM2QzZHk1M015NXZjbWN2TWpBeE9DOWpjbVZrWlc1MGFXRnNjeTkyTVNJc0ltaDBkSEJ6T2k4dmQzZDNMbmN6TG05eVp5OHlNREU0TDJOeVpXUmxiblJwWVd4ekwyVjRZVzF3YkdWekwzWXhJbDBzSW5SNWNHVWlPbHNpVm1WeWFXWnBZV0pzWlVOeVpXUmxiblJwWVd3aUxDSlZibWwyWlhKemFYUjVSR1ZuY21WbFEzSmxaR1Z1ZEdsaGJDSmRMQ0pqY21Wa1pXNTBhV0ZzVTNWaWFtVmpkQ0k2ZXlKa1pXZHlaV1VpT25zaWRIbHdaU0k2SWtKaFkyaGxiRzl5UkdWbmNtVmxJaXdpYm1GdFpTSTZJanh6Y0dGdUlHeGhibWM5SjJaeUxVTkJKejVDWVdOallXeGhkWExEcVdGMElHVnVJRzExYzJseGRXVnpJRzUxYmNPcGNtbHhkV1Z6UEM5emNHRnVQaUo5ZlgxOS5LTEpvNUdBeUJORDNMRFRuOUg3RlFva0VzVUVpOGpLd1hoR3ZvTjNKdFJhNTF4ck5EZ1hEYjBjcTFVVFlCLXJLNEZ0OVlWbVIxTklfWk9GOG9HY183d0FwOFBIYkYySGFXb2RRSW9PQnh4VC00V05xQXhmdDdFVDZsa0gtNFM2VXgzclNHQW1jek1vaEVFZjhlQ2VOLWpDOFdla2RQbDZ6S1pRajBZUEIxcng2WDAteGxGQnM3Y2w2V3Q4cmZCUF90WjlZZ1ZXclFtVVd5cFNpb2MwTVV5aXBobXlFYkxaYWdUeVBsVXlmbEdsRWRxclpBdjZlU2U2UnR4Snk2TTEtbEQ3YTVIVHphbllUV0JQQVVIRFpHeUdLWGRKdy1XX3gwSVdDaEJ6STh0M2twRzI1M2ZnNlYzdFBnSGVLWEU5NGZ6X1FwWWZnLS03a0xzeUJBZlFHYmciXX19.ft_Eq4IniBrr7gtzRfrYj8Vy1aPXuFZU-6_ai0wvaKcsrzI4JkQEKTvbJwdvIeuGuTqy7ipO-EYi7V4TvonPuTRdpB7ZHOlYlbZ4wA9WJ6mSVSqDACvYRiFvrOFmie8rgm6GacWatgO4m4NqiFKFko3r58LueFfGw47NK9RcfOkVQeHCq4btaDqksDKeoTrNysF4YS89INa-prWomrLRAhnwLOo1Etp3E4ESAxg73CR2kA5AoMbf5KtFueWnMcSbQkMRdWcGC1VssC0tB0JffVjq7ZV6OTyV4kl1-UVgiPLXUTpupFfLRhf9QpqMBjYgP62KvhIvW8BbkGUelYMetA

This section is non-normative.

It is important to recognize there is a spectrum of privacy ranging frompseudonymous to strongly identified. Depending on the use case, people havedifferent comfort levels about what information they are willing to provideand what information can be derived from what is provided.

For example, most people probably want to remain anonymous when purchasingalcohol because the regulatory check required is solely based on whether aperson is above a specific age. Alternatively, for medical prescriptionswritten by a doctor for a patient, the pharmacy fulfilling the prescription isrequired to more strongly identify the medical professional and the patient.Therefore there is not one approach to privacy that works for all use cases.Privacy solutions are use case specific.

The Verifiable Credentials Data Model strives to support the full privacyspectrum and does not take philosophical positions on the correct level ofanonymity for any specific transaction. The following sections provide guidancefor implementers who want to avoid specific scenarios that are hostile toprivacy.

This section is non-normative.

Data associated withverifiable credentials stored in thecredential.credentialSubject field is susceptible to privacyviolations when shared withverifiers. Personally identifying data, suchas a government-issued identifier, shipping address, and full name, can beeasily used to determine, track, and correlate anentity. Eveninformation that does not seem personally identifiable, such as thecombination of a birthdate and a postal code, has very powerful correlationand de-anonymizing capabilities.

Implementers are strongly advised to warnholders when they share datawith these kinds of characteristics.Issuers are strongly advised toprovide privacy-protectingverifiable credentials when possible. Forexample, issuingageOververifiable credentials instead ofdate of birthverifiable credentials when averifier wants todetermine if anentity is over the age of 18.

Because averifiable credential often contains personally identifiableinformation (PII), implementers are strongly advised to use mechanisms whilestoring and transportingverifiable credentials that protect the datafrom those who should not access it. Mechanisms that could be considered includeTransport Layer Security (TLS) or other means of encrypting the data while intransit, as well as encryption or data access control mechanisms to protectthe data in averifiable credential while at rest.

This section is non-normative.

Subjects ofverifiable credentials are identified using thecredential.credentialSubject.id field. The identifiers used toidentify asubject create a greater risk of correlation when theidentifiers are long-lived or used across more than one web domain.

Similarly, disclosing thecredential identifier(credential.id) leads to situations where multipleverifiers, or anissuer and averifier, can collude tocorrelate theholder. Ifholders want to reduce correlation, theyshould useverifiable credential schemes that allow hiding theidentifier duringverifiable presentation. Such schemes expect theholder to generate the identifier and might even allow hiding theidentifier from theissuer, while still keeping the identifier embeddedand signed in theverifiable credential.

If strong anti-correlation properties are a requirement in averifiable credentials system, it is strongly advised that identifiersare either:

• Bound to a single origin
• Single-use
• Not used at all, but instead replaced by short-lived, single-use bearer tokens.

This section is non-normative.

The contents ofverifiable credentials are secured using thecredential.proof field. Theproperties in this fieldcreate a greater risk of correlation when the same values are used across morethan one session or domain and the value does not change. Examples include theverificationMethod,created,proofPurpose, andjws fields.

If strong anti-correlation properties are required, it is advised thatsignature values and metadata are regenerated each time using technologies likethird-party pairwise signatures, zero-knowledge proofs, or group signatures.

This section is non-normative.

Verifiable credentials might contain long-lived identifiers that couldbe used to correlate individuals. These types of identifiers includesubject identifiers, email addresses, government-issued identifiers,organization-issued identifiers, addresses, healthcare vitals,verifiable credential-specific JSON-LD contexts, and many other sorts oflong-lived identifiers.

Organizations providing software toholders should strive to identifyfields inverifiable credentials containing information that could beused to correlate individuals and warnholders when this information isshared.

This section is non-normative.

There are mechanisms external toverifiable credentials that are used totrack and correlate individuals on the Internet and the Web. Some of thesemechanisms include Internet protocol (IP) address tracking, web browserfingerprinting, evercookies, advertising network trackers, mobile networkposition information, and in-application Global Positioning System (GPS) APIs.Usingverifiable credentials cannot prevent the use of these othertracking technologies. Also, when these technologies are used in conjunctionwithverifiable credentials, new correlatable information could bediscovered. For example, a birthday coupled with a GPS position can be used tostrongly correlate an individual across multiple websites.

It is recommended that privacy-respecting systems prevent the use of theseother tracking technologies whenverifiable credentials are being used.In some cases, tracking technologies might need to be disabled on devices thattransmitverifiable credentials on behalf of aholder.

This section is non-normative.

To enable recipients ofverifiable credentials to use them in a varietyof circumstances without revealing more PII than necessary for transactions,issuers should consider limiting the information published in acredential to a minimal set needed for the expected purposes. One way toavoid placing PII in acredential is to use an abstractpropertythat meets the needs ofverifiers without providing specific informationabout asubject.

For example, this document uses theageOverpropertyinstead of a specific birthdate, which constitutes much stronger PII. Ifretailers in a specific market commonly require purchasers to be older than acertain age, anissuer trusted in that market might choose to offer averifiable credential claiming thatsubjects have met thatrequirement instead of offeringverifiable credentials containingclaims about specific birthdates. This enables individual customers tomake purchases without revealing specific PII.

This section is non-normative.

Privacy violations occur when information divulged in one context leaks intoanother. Accepted best practice for preventing such violations is to limit theinformation requested, and received, to the absolute minimum necessary. Thisdata minimization approach is required by regulation in multiple jurisdictions,including the Health Insurance Portability and Accountability Act (HIPAA) in theUnited States and the General Data Protection Regulation (GDPR) in the EuropeanUnion.

Withverifiable credentials, data minimization forissuers meanslimiting the content of averifiable credential to the minimum requiredby potentialverifiers for expected use. Forverifiers, dataminimization means limiting the scope of the information requested orrequired for accessing services.

For example, a driver's license containing a driver's ID number, height, weight,birthday, and home address is acredential containing more informationthan is necessary to establish that the person is above a certain age.

It is considered best practice forissuers to atomize information or usea signature scheme that allows forselective disclosure. For example, anissuer of driver's licenses could issue averifiable credentialcontaining every attribute that appears on a driver's license, as well as a setofverifiable credentials where everyverifiable credentialcontains only a single attribute, such as a person's birthday. It could alsoissue more abstractverifiable credentials (for example, averifiable credential containing only anageOver attribute).One possible adaptation would be forissuers to provide secure HTTPendpoints for retrieving single-usebearer credentials that promote thepseudonymous usage ofverifiable credentials. Implementers that find thisimpractical or unsafe, should consider usingselective disclosure schemesthat eliminate dependence onissuers at proving time and reduce temporalcorrelation risk fromissuers.

Verifiers are urged to only request information that is absolutelynecessary for a specific transaction to occur. This is important for at leasttwo reasons. It:

• Reduces the liability on theverifier for handling highly sensitiveinformation that it does not need to.
• Enhances the privacy of the individual by only asking for information requiredfor a specific transaction.

This section is non-normative.

Abearer credential is aprivacy-enhancing piece of information, such as a concert ticket, which entitlestheholder of the bearer credential to a specific resource withoutdivulging sensitive information about theholder. Bearer credentials areoften used in low-risk use cases where the sharing of the bearer credential isnot a concern or would not result in large economic or reputational losses.

Verifiable credentials that arebearer credentials are madepossible by not specifying thesubject identifier, expressed using theidproperty, which is nested in thecredentialSubjectproperty. For example, the followingverifiable credential is abearer credential:

{  "@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1"  ],  "id": "http://example.edu/credentials/temporary/28934792387492384",  "type": ["VerifiableCredential", "UniversityDegreeCredential"],  "issuer": "https://example.edu/issuers/14",  "issuanceDate": "2017-10-22T12:23:48Z",  "credentialSubject": {// note that the 'id' property is not specified for bearer credentials    "degree": {      "type": "BachelorDegree",      "name": "Bachelor of Science and Arts"    }  }}

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "http://example.edu/credentials/temporary/28934792387492384",
  "type": [
    "VerifiableCredential",
    "UniversityDegreeCredential"
  ],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2017-10-22T12:23:48Z",
  "credentialSubject": {
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2022-02-25T14:58:43Z",
    "verificationMethod": "https://example.edu/issuers/14#keys-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z49oZrBSGbo4ASwCLCms2YGkGbgHtFyAv8J5849XF4qwhNqRvs92FZtH
ZdHFMcA1uwDWNKhxvikAvRfmUjKFJUUWT"
  }
}

---------------- JWT header ---------------
{
  "alg": "ES256",
  "typ": "JWT"
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "http://example.edu/credentials/temporary/28934792387492384",
    "type": [
      "VerifiableCredential",
      "UniversityDegreeCredential"
    ],
    "issuer": "https://example.edu/issuers/14",
    "issuanceDate": "2017-10-22T12:23:48Z",
    "credentialSubject": {
      "degree": {
        "type": "BachelorDegree",
        "name": "Bachelor of Science and Arts"
      }
    }
  },
  "iss": "https://example.edu/issuers/14",
  "nbf": 1508675028,
  "jti": "http://example.edu/credentials/temporary/28934792387492384"
}
--------------- JWT ---------------
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3
d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L
2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sImlkIjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRl
bnRpYWxzL3RlbXBvcmFyeS8yODkzNDc5MjM4NzQ5MjM4NCIsInR5cGUiOlsiVmVyaWZpYWJsZUN
yZWRlbnRpYWwiLCJVbml2ZXJzaXR5RGVncmVlQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJodHRwcz
ovL2V4YW1wbGUuZWR1L2lzc3VlcnMvMTQiLCJpc3N1YW5jZURhdGUiOiIyMDE3LTEwLTIyVDEyO
jIzOjQ4WiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImRlZ3JlZSI6eyJ0eXBlIjoiQmFjaGVsb3JE
ZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyJ9fX0sImlzcyI6Imh
0dHBzOi8vZXhhbXBsZS5lZHUvaXNzdWVycy8xNCIsIm5iZiI6MTUwODY3NTAyOCwianRpIjoiaH
R0cDovL2V4YW1wbGUuZWR1L2NyZWRlbnRpYWxzL3RlbXBvcmFyeS8yODkzNDc5MjM4NzQ5MjM4N
CJ9.g_t3HGoAWKXUXFaVemchk4HckdNfxizpLfMQxR7S_sMLsjCsxP1LniBVY0mORMrp_6W0u3_
IiqT1X1dGa4eqPg

Whilebearer credentials can be privacy-enhancing, they must be carefullycrafted so as not accidentally divulge more information than theholderof thebearer credential expects. For example, repeated use of the samebearer credential across multiple sites enables these sites topotentially collude to unduly track or correlate theholder. Likewise,information that might seem non-identifying, such as a birthdate and postalcode, can be used to statistically identify an individual when used together inthe samebearer credential or session.

Issuers ofbearer credentials should ensure that thebearer credentials provide privacy-enhancing benefits that:

• Are single-use, where possible.
• Do not contain personally identifying information.
• Are not unduly correlatable.

Holders should be warned by their software ifbearer credentialscontaining sensitive information are issued or requested, or if there is acorrelation risk when combining two or morebearer credentials across oneor more sessions. While it might be impossible to detect all correlation risks,some might certainly be detectable.

Verifiers should not requestbearer credentials that can be usedto unduly correlate theholder.

This section is non-normative.

When processingverifiable credentials,verifiers are expected toperform many of the checks listed in AppendixA.Validation aswell as a variety of specific business process checks. Validity checks mightinclude checking:

• The professional licensure status of theholder.
• A date of license renewal or revocation.
• The sub-qualifications of an individual.
• If a relationship exists between theholder and theentitywith whom theholder is attempting to interact.
• The geolocation information associated with theholder.

The process of performing these checks might result in information leakage thatleads to a privacy violation of theholder. For example, a simpleoperation such as checking a revocation list can notify theissuer that aspecific business is likely interacting with theholder. This couldenableissuers to collude and correlate individuals without theirknowledge.

Issuers are urged to not use mechanisms, such ascredentialrevocation lists that are unique percredential, during theverification process that could lead to privacy violations. Organizationsproviding software toholders should warn whencredentials includeinformation that could lead to privacy violations during the verificationprocess.Verifiers should consider rejectingcredentials thatproduce privacy violations or that enable bad privacy practices.

This section is non-normative.

When aholder receives averifiable credential from anissuer, theverifiable credential needs to be stored somewhere(for example, in acredential repository).Holders are warned thatthe information in averifiable credential is sensitive in nature andhighly individualized, making it a high value target for data mining. Servicesthat advertise free storage ofverifiable credentials might in fact bemining personal data and selling it to organizations wanting to buildindividualized profiles on people and organizations.

Holders need to be aware of the terms of service for theircredential repository, specifically the correlation and data miningprotections in place for those who store theirverifiable credentialswith the service provider.

Some effective mitigations for data mining and profiling include using:

• Service providers that do not sell your information to third parties.
• Software that encryptsverifiable credentials such that a serviceprovider cannot view the contents of thecredential.
• Software that storesverifiable credentials locally on a device that youcontrol and that does not upload or analyze your information beyond yourexpectations.

This section is non-normative.

Holding two pieces of information about the samesubject almost alwaysreveals more about thesubject than just the sum of the two pieces, evenwhen the information is delivered through different channels. The aggregation ofverifiable credentials is a privacy risk and all participants inthe ecosystem need to be aware of the risks of data aggregation.

For example, if twobearer credentials, one for an email address and thenone stating theholder is over the age of 21, are provided acrossmultiple sessions, theverifier of the information now has a uniqueidentifier as well as age-related information for that individual. It is noweasy to create and build a profile for theholder such that more and moreinformation is leaked over time. Aggregation ofcredentials can also beperformed across multiple sites in collusion with each other, leading to privacyviolations.

From a technological perspective, preventing aggregation of information is avery difficult privacy problem to address. While new cryptographic techniques,such as zero-knowledge proofs, are being proposed as solutions to the problemof aggregation and correlation, the existence of long-lived identifiers andbrowser tracking techniques defeats even the most modern cryptographictechniques.

The solution to the privacy implications of correlation or aggregation tends notto be technological in nature, but policy driven instead. Therefore, if aholder does not want information about them to be aggregated, they mustexpress this in theverifiable presentations they transmit.

This section is non-normative.

Despite the best efforts to assure privacy, actually usingverifiable credentials can potentially lead to de-anonymization and aloss of privacy. This correlation can occur when:

• The sameverifiable credential is presented to the sameverifiermore than once. Theverifier could infer that theholder is thesame individual.
• The sameverifiable credential is presented to differentverifiers, and either thoseverifiers collude or a third partyhas access to transaction records from bothverifiers. An observantparty could infer that the individual presenting theverifiable credential is the same person at both services. That is, theaccounts are controlled by the same person.
• Asubject identifier of acredential refers to the samesubject across multiplepresentations orverifiers. Evenwhen differentcredentials are presented, if thesubjectidentifier is the same,verifiers (and those with access toverifier logs) could infer that theholder of thecredential is the same person.
• The underlying information in acredential can be used to identify anindividual across services. In this case, using information from other sources(including information provided directly by theholder),verifierscan use information inside thecredential to correlate the individualwith an existing profile. For example, if aholder presentscredentials that include postal code, age, and gender, averifiercan potentially correlate thesubject of thatcredential with anestablished profile. For more information, see [DEMOGRAPHICS].
• Passing the identifier of acredential to a centralized revocationserver. The centralized server can correlate thecredential usage acrossinteractions. For example, if acredential is used for proof of age inthis manner, the centralized service could know everywhere thatcredential was presented (all liquor stores, bars, adult stores, lotterypurchases, and so on).

In part, it is possible to mitigate this de-anonymization and loss of privacyby:

• Using a globally-unique identifier as thesubject for any givencredential and never re-use thatcredential.
• If thecredential supports revocation, using a globally-distributedservice for revocation.
• Designing revocation APIs that do not depend on submitting the ID of thecredential. For example, use a revocation list instead of a query.
• Avoiding the association of personally identifiable information with anyspecific long-livedsubject identifier.

It is understood that these mitigation techniques are not always practicalor even compatible with necessary usage. Sometimes correlation is arequirement.

For example, in some prescription drug monitoring programs, usage monitoring isa requirement. Enforcement entities need to be able to confirm that individualsare not cheating the system to get multiple prescriptions for controlledsubstances. This statutory or regulatory need to correlate usage overridesindividual privacy concerns.

Verifiable credentials will also be used to intentionally correlateindividuals across services, for example, when using a common persona to log into multiple services, so all activity on each of those services isintentionally linked to the same individual. This is not a privacy issue aslong as each of those services uses the correlation in the expected manner.

Privacy risks ofcredential usage occur when unintended or unexpectedcorrelation arises from the presentation ofcredentials.

This section is non-normative.

When aholder chooses to share information with averifier, itmight be the case that theverifier is acting in bad faith and requestsinformation that could be used to harm theholder. For example, averifier might ask for a bank account number, which could then be usedwith other information to defraud theholder or the bank.

Issuers should strive to tokenize as much information as possible suchthat if aholder accidentally transmitscredentials to the wrongverifier, the situation is not catastrophic.

For example, instead of including a bank account number for the purpose ofchecking an individual's bank balance, provide a token that enables theverifier to check if the balance is above a certain amount. In thiscase, the bank could issue averifiable credential containing a balancechecking token to aholder. Theholder would then include theverifiable credential in averifiable presentation and bind thetoken to a credit checking agency using a digital signature. Theverifier could then wrap theverifiable presentation in theirdigital signature, and hand it back to the issuer to dynamically check theaccount balance.

Using this approach, even if aholder shares the account balance tokenwith the wrong party, an attacker cannot discover the bank account number, northe exact value in the account. And given the validity period for thecounter-signature, does not gain access to the token for more than a fewminutes.

This section is non-normative.

As detailed in Section7.13Usage Patterns, usage patterns can becorrelated into certain types of behavior. Part of this correlation ismitigated when aholder uses averifiable credential without theknowledge of theissuer.Issuers can defeat this protectionhowever, by making theirverifiable credentials short lived and renewalautomatic.

For example, anageOververifiable credential is useful forgaining access to a bar. If anissuer issues such averifiable credential with a very short expiration date and an automaticrenewal mechanism, then theissuer could possibly correlate the behaviorof theholder in a way that negatively impacts theholder.

Organizations providing software toholders should warn them if theyrepeatedly usecredentials with short lifespans, which could result inbehavior correlation.Issuers should avoid issuingcredentials ina way that enables them to correlate usage patterns.

This section is non-normative.

An ideal privacy-respecting system would require only the information necessaryfor interaction with theverifier to be disclosed by theholder.Theverifier would then record that the disclosure requirement was metand forget any sensitive information that was disclosed. In many cases,competing priorities, such as regulatory burden, prevent this ideal system frombeing employed. In other cases, long-lived identifiers prevent single use. Thedesign of anyverifiable credentials ecosystem, however, should striveto be as privacy-respecting as possible by preferring single-useverifiable credentials whenever possible.

Using single-useverifiable credentials provides several benefits. Thefirst benefit is toverifiers who can be sure that the data in averifiable credential is fresh. The second benefit is toholders,who know that if there are no long-lived identifiers in theverifiable credential, theverifiable credential itself cannot beused to track or correlate them online. Finally, there is nothing for attackersto steal, making the entire ecosystem safer to operate within.

This section is non-normative.

In an ideal private browsing scenario, no PII will be revealed. Because manycredentials include PII, organizations providing software toholders should warn them about the possibility of revealing thisinformation if they wish to usecredentials andpresentationswhile in private browsing mode. As each browser vendor handles private browsingdifferently, and some browsers might not have this feature at all, it isimportant for implementers to be aware of these differences and implementsolutions accordingly.

This section is non-normative.

It cannot be overstated thatverifiable credentials rely on a highdegree of trust inissuers. The degree to which aholder might takeadvantage of possible privacy protections often depends strongly on the supportanissuer provides for such features. In many cases, privacy protectionswhich make use of zero-knowledge proofs, data minimization techniques, bearercredentials, abstract claims, and protections against signature-basedcorrelation, require theissuer to actively support such capabilities andincorporate them into theverifiable credentials they issue.

It should also be noted that, in addition to a reliance onissuerparticipation to provideverifiable credential capabilities that helppreserveholder andsubject privacy,holders rely onissuers to not deliberately subvert privacy protections. For example, anissuer might signverifiable credentials using a signature schemethat protects against signature-based correlation. This would protect theholder from being correlated by the signature value as it is shared amongverifiers. However, if theissuer creates a unique key for eachissuedcredential, it might be possible for theissuer to trackpresentations of thecredential, regardless of averifier'sinability to do so.

This section is non-normative.

Some aspects of the data model described in this specification can beprotected through the use of cryptography. It is important for implementers tounderstand the cryptography suites and libraries used to create and processcredentials andpresentations. Implementing and auditingcryptography systems generally requires substantial experience. Effectivered teaming can alsohelp remove bias from security reviews.

Cryptography suites and libraries have a shelf life and eventually fall tonew attacks and technology advances. Production quality systems need to takethis into account and ensure mechanisms exist to easily and proactively upgradeexpired or broken cryptography suites and libraries, and to invalidateand replace existingcredentials. Regular monitoring is important toensure the long term viability of systems processingcredentials.

This section is non-normative.

Verifiable credentials often contain URLs to data that resides outside oftheverifiable credential itself. Linked content that exists outside averifiable credential, such as images, JSON-LD Contexts, and othermachine-readable data, are often not protected against tampering because thedata resides outside of the protection of theproof on theverifiable credential. Forexample, the following highlighted links are not content-integrity protected butprobably should be:

{  "@context": ["https://www.w3.org/2018/credentials/v1","https://www.w3.org/2018/credentials/examples/v1"  ],  "id": "http://example.edu/credentials/58473",  "type": ["VerifiableCredential", "AlumniCredential"],  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "image":"https://example.edu/images/58473",    "alumniOf": {      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",      "name": [{        "value": "Example University",        "lang": "en"      }, {        "value": "Exemple d'Université",        "lang": "fr"      }]    }  },  "proof": {... }}

While this specification does not recommend any specific content integrityprotection, document authors who want to ensure links to content are integrityprotected are advised to use URL schemes that enforce content integrity. Twosuch schemes are the [HASHLINK] specification and the [IPFS]. The examplebelow transforms the previous example and adds content integrity protection tothe JSON-LD Contexts using the [HASHLINK] specification, and content integrityprotection to the image by using an [IPFS] link.

{  "@context": [    "https://www.w3.org/2018/credentials/v1?hl=z3aq31uzgnZBuWNzUB",    "https://www.w3.org/2018/credentials/examples/v1?hl=z8guWNzUBnZBu3aq31"  ],  "id": "http://example.edu/credentials/58473",  "type": ["VerifiableCredential", "AlumniCredential"],  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "image":"ipfs:/ipfs/QmXfrS3pHerg44zzK6QKQj6JDk8H6cMtQS7pdXbohwNQfK/image",    "alumniOf": {      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",      "name": [{        "value": "Example University",        "lang": "en"      }, {        "value": "Exemple d'Université",        "lang": "fr"      }]    }  },  "proof": {... }}

While the example above is one way to achieve content integrity protection,there are other solutions that might be better suited for certain applications.Implementers are urged to understand how links to external machine-readablecontent that are not content-integrity protected could result in successfulattacks against their applications.

This section is non-normative.

This specification allowscredentials to be produced that do not containsignatures or proofs of any kind. These types ofcredentials are oftenuseful for intermediate storage, or self-asserted information, which isanalogous to filling out a form on a web page. Implementers should be aware thatthese types ofcredentials are notverifiable because theauthorship either is not known or cannot be trusted.

This section is non-normative.

Averifier might need to ensure it is the intended recipient of averifiable presentation and not the target of aman-in-the-middle attack.Approaches such as token binding [RFC8471], which ties the request for averifiable presentation to the response, can secure the protocol.Any unsecured protocol is susceptible to man-in-the-middle attacks.

This section is non-normative.

It is considered best practice forissuers to atomize information in acredential, or use a signature scheme that allows for selectivedisclosure. In the case of atomization, if it is not done securely by theissuer, theholder might bundle together differentcredentials in a way that was not intended by theissuer.

For example, a university might issue twoverifiable credentials to aperson, each containing twoproperties, which must be taken together toto designate the "role" of that person in a given "department", such as "StaffMember" in the "Department of Computing", or "Post Graduate Student" in the"Department of Economics". If theseverifiable credentials are atomizedto put only one of theseproperties into eachcredential , thenthe university would issue fourcredentials to the person, eachcontaining one of the following designations: "Staff Member", "Post GraduateStudent", "Department of Computing", and "Department of Economics". Theholder might then transfer the "Staff Member" and "Department ofEconomics"verifiable credentials to averifier, which togetherwould comprise a falseclaim.

This section is non-normative.

Whenverifiable credentials are issued for highly dynamic information,implementers should ensure the expiration times are set appropriately.Expiration periods longer than the timeframe where theverifiable credential is valid might create exploitable securityvulnerabilities. Expiration periods shorter than the timeframe where theinformation expressed by theverifiable credential is valid creates aburden onholders andverifiers. It is therefore important to setvalidity periods forverifiable credentials that are appropriate to theuse case and the expected lifetime for the information contained in theverifiable credential.

This section is non-normative.

Whenverifiable credentials are stored on a device and thatdevice is lost or stolen, it might be possible for an attacker to gain accessto systems using the victim'sverifiable credentials. Ways to mitigatethis type of attack include:

• Enabling password, pin, pattern, or biometric screen unlock protection on thedevice.
• Enabling password, biometric, or multi-factor authentication for thecredentialrepository.
• Enabling password, biometric, or multi-factor authentication when accessingcryptographic keys.
• Using a separate hardware-based signature device.
• All or any combination of the above.

This section is non-normative.

Many physicalcredentials in use today, such as government identificationcards, have poor accessibility characteristics, including, but not limited to,small print, reliance on small and high-resolution images, and no affordancesfor people with vision impairments.

When utilizing this data model to createverifiable credentials, it issuggested that data model designers use adata first approach. Forexample, given the choice of using data or a graphical image to depict acredential, designers should express every element of the image, such asthe name of an institution or the professionalcredential, in amachine-readable way instead of relying on a viewer's interpretation of theimage to convey this information. Using a data first approach is preferredbecause it provides the foundational elements of building different interfacesfor people with varying abilities.

This section is non-normative.

Data publishers are strongly encouraged to read the section onCross-Syntax Expression in theStrings on the Web: Language and DirectionMetadata document [STRING-META] to ensure that the expression oflanguage and base direction information is possible across multiple expressionsyntaxes, such as [JSON-LD], [JSON], and CBOR [RFC7049].

The general design pattern is to use the following markup template whenexpressing a text string that is tagged with a language and, optionally, aspecific base direction.

"property": {  "value": "The string value",  "lang": "LANGUAGE"  "dir": "DIRECTION"}

Using the design pattern above, the following example expresses the title of abook in the English language without specifying a text direction.

"title": {  "value": "HTML and CSS: Designing and Creating Websites",  "lang": "en"}

The next example uses a similar title expressed in the Arabic language with abase direction of right-to-left.

"title": {  "value": "HTML و CSS: تصميم و إنشاء مواقع الويب",  "lang": "ar"  "dir": "rtl"}

Implementers utilizing JSON-LD are strongly urged toextend the JSON-LD Context defining theinternationalizedproperty and use the Scoped Context feature of JSON-LDto alias the@value,@language, and@direction keywords tovalue,lang,anddir, respectively. An example of a JSON-LD Context snippetdoing this is shown below.

"title": {"@context": {"value": "@value", "lang": "@language", "dir": "@direction"},  "@id": "https://www.w3.org/2018/credentials/examples#title"}

This section is non-normative.

When multiple languages, base directions, and annotations are used in a singlenatural language string, more complex mechanisms are typically required. It ispossible to use markup languages, such as HTML, to encode text with multiplelanguages and base directions. It is also possible to use therdf:HTML datatype to encode such values accurately in JSON-LD.

Despite the ability to encode information as HTML, implementers are stronglydiscouraged from doing this because it:

• Requires some version of an HTML processor, which increases the burden ofprocessing language and base direction information.
• Increases the security attack surface when utilizing this data model becauseblindly processing HTML could result in executing ascript tag thatan attacker injected at some point during the data production process.

If implementers feel they must use HTML, or other markup languages capable ofcontaining executable scripts, to address a specific use case, they are advisedto analyze how an attacker would use the markup to mount injection attacksagainst a consumer of the markup and then deploy mitigations against theidentified attacks.

This section is non-normative.

In theverifiable credentials presented by aholder, the valueassociated with theidproperty for eachcredentialSubject is expected to identify asubject to theverifier. If theholder is also thesubject, thentheverifier could authenticate theholder if they havepublic key metadata related to theholder. Theverifier could thenauthenticate theholder using a signature generated by theholdercontained in theverifiable presentation. Theidproperty is optional.Verifiers could use otherpropertiesin averifiable credential to uniquely identify asubject.

This section is non-normative.

The value associated with theissuerproperty is expectedto identify anissuer that is known to and trusted by theverifier.

Relevant metadata about theissuerproperty is expectedto be available to theverifier. For example, anissuer canpublish information containing the public keys it uses to digitally signverifiable credentials that it issued. This metadata is relevant whenchecking the proofs on theverifiable credentials.

This section is non-normative.

TheissuanceDate is expected to be within an expected range for theverifier. For example, averifier can check that the issuance dateof averifiable credential is not in the future.

This section is non-normative.

The cryptographic mechanism used to prove that the information in averifiable credential orverifiable presentation was nottampered with is called aproof. There are many types of cryptographicproofs including, but not limited to, digital signatures, zero-knowledge proofs,Proofs of Work, and Proofs of Stake. In general, when verifying proofs,implementations are expected to ensure:

• The proof is available in the form of a known proof suite.
• All required proof suiteproperties are present.
• The proof suiteverification algorithm, when applied to the data, resultsin an acceptable proof.

Some proofs are digital signatures. In general, when verifying digitalsignatures, implementations are expected to ensure:

• Acceptably recent metadata regarding the public key associated with thesignature is available. For example, the metadata might includeproperties related to expiration, key owner, or key purpose.
• The key is not suspended, revoked, or expired.
• The cryptographic signature is expected to verify.
• If the cryptographic suite expects aproofPurposeproperty,it is expected to exist and be a valid value, such asassertionMethod.

This section is non-normative.

TheexpirationDate is expected to be within an expected rangefor theverifier. For example, averifier can check that theexpiration date of averifiable credential is not in the past.

This section is non-normative.

If thecredentialStatus property is available, the status of averifiable credential is expected to be evaluated by theverifieraccording to thecredentialStatustype definition for theverifiable credential and theverifier's own status evaluationcriteria. For example, averifier can ensure the status of theverifiable credential is not "withdrawn for cause by theissuer".

This section is non-normative.

Fitness for purpose is about whether the customproperties in theverifiable credential are appropriate for theverifier's purpose.For example, if averifier needs to determine whether asubject isolder than 21 years of age, they might rely on a specificbirthdateproperty, or on more abstractproperties, such asageOver.

Theissuer is trusted by theverifier to make theclaims athand. For example, a franchised fast food restaurant location trusts thediscount couponclaims made by the corporate headquarters of thefranchise. Policy information expressed by theissuer in theverifiable credential should be respected byholders andverifiers unless they accept the liability of ignoring the policy.

This section is non-normative.

The base context, located athttps://www.w3.org/2018/credentials/v1 with a SHA-256 digest ofab4ddd9a531758807a79a5b450510d61ae8d147eab966cc9a200c07095b0cdcc,can be used to implement a local cached copy. For convenience, the base contextis also provided in this section.

{  "@context": {    "@version": 1.1,    "@protected": true,    "id": "@id",    "type": "@type",    "VerifiableCredential": {      "@id": "https://www.w3.org/2018/credentials#VerifiableCredential",      "@context": {        "@version": 1.1,        "@protected": true,        "id": "@id",        "type": "@type",        "cred": "https://www.w3.org/2018/credentials#",        "sec": "https://w3id.org/security#",        "xsd": "http://www.w3.org/2001/XMLSchema#",        "credentialSchema": {          "@id": "cred:credentialSchema",          "@type": "@id",          "@context": {            "@version": 1.1,            "@protected": true,            "id": "@id",            "type": "@type",            "cred": "https://www.w3.org/2018/credentials#",            "JsonSchemaValidator2018": "cred:JsonSchemaValidator2018"          }        },        "credentialStatus": {"@id": "cred:credentialStatus", "@type": "@id"},        "credentialSubject": {"@id": "cred:credentialSubject", "@type": "@id"},        "evidence": {"@id": "cred:evidence", "@type": "@id"},        "expirationDate": {"@id": "cred:expirationDate", "@type": "xsd:dateTime"},        "holder": {"@id": "cred:holder", "@type": "@id"},        "issued": {"@id": "cred:issued", "@type": "xsd:dateTime"},        "issuer": {"@id": "cred:issuer", "@type": "@id"},        "issuanceDate": {"@id": "cred:issuanceDate", "@type": "xsd:dateTime"},        "proof": {"@id": "sec:proof", "@type": "@id", "@container": "@graph"},        "refreshService": {          "@id": "cred:refreshService",          "@type": "@id",          "@context": {            "@version": 1.1,            "@protected": true,            "id": "@id",            "type": "@type",            "cred": "https://www.w3.org/2018/credentials#",            "ManualRefreshService2018": "cred:ManualRefreshService2018"          }        },        "termsOfUse": {"@id": "cred:termsOfUse", "@type": "@id"},        "validFrom": {"@id": "cred:validFrom", "@type": "xsd:dateTime"},        "validUntil": {"@id": "cred:validUntil", "@type": "xsd:dateTime"}      }    },    "VerifiablePresentation": {      "@id": "https://www.w3.org/2018/credentials#VerifiablePresentation",      "@context": {        "@version": 1.1,        "@protected": true,        "id": "@id",        "type": "@type",        "cred": "https://www.w3.org/2018/credentials#",        "sec": "https://w3id.org/security#",        "holder": {"@id": "cred:holder", "@type": "@id"},        "proof": {"@id": "sec:proof", "@type": "@id", "@container": "@graph"},        "verifiableCredential": {"@id": "cred:verifiableCredential", "@type": "@id", "@container": "@graph"}      }    },    "EcdsaSecp256k1Signature2019": {      "@id": "https://w3id.org/security#EcdsaSecp256k1Signature2019",      "@context": {        "@version": 1.1,        "@protected": true,        "id": "@id",        "type": "@type",        "sec": "https://w3id.org/security#",        "xsd": "http://www.w3.org/2001/XMLSchema#",        "challenge": "sec:challenge",        "created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"},        "domain": "sec:domain",        "expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"},        "jws": "sec:jws",        "nonce": "sec:nonce",        "proofPurpose": {          "@id": "sec:proofPurpose",          "@type": "@vocab",          "@context": {            "@version": 1.1,            "@protected": true,            "id": "@id",            "type": "@type",            "sec": "https://w3id.org/security#",            "assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"},            "authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"}          }        },        "proofValue": "sec:proofValue",        "verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"}      }    },    "EcdsaSecp256r1Signature2019": {      "@id": "https://w3id.org/security#EcdsaSecp256r1Signature2019",      "@context": {        "@version": 1.1,        "@protected": true,        "id": "@id",        "type": "@type",        "sec": "https://w3id.org/security#",        "xsd": "http://www.w3.org/2001/XMLSchema#",        "challenge": "sec:challenge",        "created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"},        "domain": "sec:domain",        "expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"},        "jws": "sec:jws",        "nonce": "sec:nonce",        "proofPurpose": {          "@id": "sec:proofPurpose",          "@type": "@vocab",          "@context": {            "@version": 1.1,            "@protected": true,            "id": "@id",            "type": "@type",            "sec": "https://w3id.org/security#",            "assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"},            "authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"}          }        },        "proofValue": "sec:proofValue",        "verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"}      }    },    "Ed25519Signature2018": {      "@id": "https://w3id.org/security#Ed25519Signature2018",      "@context": {        "@version": 1.1,        "@protected": true,        "id": "@id",        "type": "@type",        "sec": "https://w3id.org/security#",        "xsd": "http://www.w3.org/2001/XMLSchema#",        "challenge": "sec:challenge",        "created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"},        "domain": "sec:domain",        "expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"},        "jws": "sec:jws",        "nonce": "sec:nonce",        "proofPurpose": {          "@id": "sec:proofPurpose",          "@type": "@vocab",          "@context": {            "@version": 1.1,            "@protected": true,            "id": "@id",            "type": "@type",            "sec": "https://w3id.org/security#",            "assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"},            "authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"}          }        },        "proofValue": "sec:proofValue",        "verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"}      }    },    "RsaSignature2018": {      "@id": "https://w3id.org/security#RsaSignature2018",      "@context": {        "@version": 1.1,        "@protected": true,        "challenge": "sec:challenge",        "created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"},        "domain": "sec:domain",        "expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"},        "jws": "sec:jws",        "nonce": "sec:nonce",        "proofPurpose": {          "@id": "sec:proofPurpose",          "@type": "@vocab",          "@context": {            "@version": 1.1,            "@protected": true,            "id": "@id",            "type": "@type",            "sec": "https://w3id.org/security#",            "assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"},            "authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"}          }        },        "proofValue": "sec:proofValue",        "verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"}      }    },    "proof": {"@id": "https://w3id.org/security#proof", "@type": "@id", "@container": "@graph"}  }}

This section is non-normative.

Theverifiable credential andverifiable presentation data modelsleverage a variety of underlying technologies including [JSON-LD] and[JSON-SCHEMA-2018]. This section will provide a comparison of the@context,type, andcredentialSchemaproperties, and cover some of the more specific use cases where it is possibleto use these features of the data model.

Thetype property is used to uniquely identifythe type of theverifiable credential in which it appears, i.e., toindicate which set of claims theverifiable credential contains.This property, and the valueVerifiableCredential within the set ofits values, are mandatory. Whilst it is good practice to include one additionalvalue depicting the unique subtype of thisverifiable credential, it is permittedto either omit or include additional type values in the array. Manyverifiers will request averifiable credential of a specific subtype, thenomitting the subtype value could make it more difficult for verifiers to informthe holder whichverifiable credential they require. When averifiablecredential has multiple subtypes, listing all of them in thetypeproperty is sensible. While the semantics are the same in both a [JSON] and[JSON-LD] representation, the usage of thetype property in a[JSON-LD] representation of averifiable credential is able to enforce the semantics of theverifiable credential better than a [JSON] representation of the samecredential because the machine is able to check the semantics. With [JSON-LD],the technology is not only describing the categorization of the set of claims,the technology is also conveying the structure and semantics of the sub-graph ofthe properties in the graph. In [JSON-LD], this represents the type of the nodein the graph which is why some [JSON-LD] representations of averifiablecredential will use thetype property on many objects in theverifiable credential.

The primary purpose of the@context property, from a [JSON-LD]perspective, is to convey the meaning of the data and term definitions of thedata in averifiable credential, in a machine readable way. When encoding a pure[JSON] representation, the@context property remains mandatory andprovides some basic support for global semantics. The@contextproperty is used to map the globally unique URIs for properties inverifiablecredentials andverifiable presentations into short-form alias names,making both the [JSON] and [JSON-LD] representations more human-friendlyto read. From a [JSON-LD] perspective, this mapping also allows the data inacredential to be modeled in a network of machine-readable data, byenhancing how the data in theverifiable credential orverifiablepresentation relates to a larger machine-readable data graph. This isuseful for telling machines how to relate the meaning of data toother data in an ecosystem where parties are unable to coordinate. Thisproperty, with the first value in the set beinghttps://www.w3.org/2018/credentials/v1, is mandatory.

Since the@context property is used to map data to a graphdata model, and thetype property in [JSON-LD] is used todescribe nodes within the graph, thetype property becomeseven more important when using the two properties in combination. For example,if thetype property is not included within the resolved@context resource using [JSON-LD], it could lead to claims beingdropped and/or their integrity no longer being protected during production andconsumption of theverifiable credential. Alternatively, it could lead toerrors being raised during production or consumption of averifiablecredential. This will depend on the design choices of the implementation andboth paths are used in implementations today, so it's important to pay attentionto these properties when using a [JSON-LD] representation of averifiablecredential orverifiable presentation.

The primary purpose of thecredentialSchema property is todefine the structure of theverifiable credential, and the datatypes forthe values of each property that appears. AcredentialSchema is usefulfor defining the contents and structure of a set of claims in averifiablecredential, whereas [JSON-LD] and a@context in averifiablecredential are best used only for conveying the semantics and termdefinitions of the data, and can be used to define the structure of theverifiable credential as well.

While it is possible to use some [JSON-LD] features to allude to thecontents of theverifiable credential, it's not generallysuggested to use@context to constrain the data types of thedata model. For example,"@type": "@json" is useful for leaving thesemantics open-ended and not strictly defined. This can be dangerous ifthe implementer is looking to constrain the data type of the claims in thecredential, and is expected not to be used.

When thecredentialSchema and@context propertiesare used in combination, both producers and consumers can be more confidentabout the expected contents and data types of theverifiable credentialandverifiable presentation.

This section is non-normative.

The most common relationship is when asubject is theholder. Inthis case, averifier can easily deduce that asubject is theholder if theverifiable presentation is digitally signed by theholder and all containedverifiable credentials are about asubject that can be identified to be the same as theholder.

If only thecredentialSubject is allowed to insert averifiable credential into averifiable presentation, theissuer can insert thenonTransferableproperty intotheverifiable credential, as described 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", "ProofOfAgeCredential"],  "issuer": "https://example.edu/issuers/14",  "issuanceDate": "2010-01-01T19:23:24Z",  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "ageOver": 21    },  "nonTransferable": true,  "proof": { ..  "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21",  ... }}

This section is non-normative.

In this case, thecredentialSubjectproperty might containmultipleproperties, each providing an aspect of a description of thesubject, which combine together to unambiguously identify thesubject. Some use cases might not require theholder to beidentified at all, such as checking to see if a doctor (thesubject) isboard-certified. Other use cases might require theverifier to useout-of-band knowledge to determine the relationship between thesubjectand theholder.

{  "@context": ["https://www.w3.org/2018/credentials/v1", "https://schema.org/"]  "id": "http://example.edu/credentials/332",  "type": ["VerifiableCredential", "IdentityCredential"],  "issuer": "https://example.edu/issuers/4",  "issuanceDate": "2017-02-24T19:73:24Z",  "credentialSubject": {    "name": "J. Doe",    "address": {      "streetAddress": "10 Rue de Chose",      "postalCode": "98052",      "addressLocality": "Paris",      "addressCountry": "FR"    },    "birthDate": "1989-03-15"    ...  },  "proof": {... }}

The example above uniquely identifies thesubject using the name,address, and birthdate of the individual.

This section is non-normative.

Usuallyverifiable credentials are presented toverifiers by thesubject. However, in some cases, thesubject might need to pass thewhole or part of averifiable credential to anotherholder. Forexample, if a patient (thesubject) is too ill to take a prescription(theverifiable credential) to the pharmacist (theverifier), afriend might take the prescription in to pick up the medication.

The data model allows for this by letting thesubject issue a newverifiable credential and give it to the newholder, who canthen present bothverifiable credentials to theverifier.However, the content of this secondverifiable credential is likely tobe application-specific, so this specification cannot standardize the contentsof this secondverifiable credential. Nevertheless, a non-normativeexample is provided in AppendixC.5Subject Passes a Verifiable Credential to Someone Else.

This section is non-normative.

The Verifiable Credentials Data Model supports theholder acting onbehalf of thesubject in at least the following ways. The:

• Issuer can include the relationship between theholder andthesubject in thecredentialSubjectproperty.
• Issuer can express the relationship between theholder andthesubject by issuing a newverifiable credential, which theholder utilizes.
• Subject can express their relationship with theholder byissuing a newverifiable credential, which theholder utilizes.

The mechanisms listed above describe the relationship between theholder and thesubject and helps theverifier decidewhether the relationship is sufficiently expressed for a given use case.

{  "@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1"  ],  "id": "http://example.edu/credentials/3732",  "type": ["VerifiableCredential", "AgeCredential", "RelationshipCredential"],  "issuer": "https://example.edu/issuers/14",  "issuanceDate": "2010-01-01T19:23:24Z",  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "ageUnder": 16,    "parent": {      "id": "did:example:ebfeb1c276e12ec211f712ebc6f",      "type": "Mother"    }  },  "proof": {... }// the proof is generated by the DMV}

In the example above, theissuer expresses the relationship between thechild and the parent such that averifier would most likely accept thecredential if it is provided by the child or the parent.

{  "@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1"  ],  "id": "http://example.edu/credentials/3732",  "type": ["VerifiableCredential", "RelationshipCredential"],  "issuer": "https://example.edu/issuers/14",  "issuanceDate": "2010-01-01T19:23:24Z",  "credentialSubject": {    "id": "did:example:ebfeb1c276e12ec211f712ebc6f",    "child": {      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",      "type": "Child"    }  },  "proof": {... }// the proof is generated by the DMV}

In the example above, theissuer expresses the relationship between thechild and the parent in a separatecredential such that averifier would most likely accept any of the child'scredentialsif they are provided by the child or if thecredential above isprovided with any of the child'scredentials.

{  "@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1"  ],  "id": "http://example.org/credentials/23894",  "type": ["VerifiableCredential", "RelationshipCredential"],  "issuer": "http://example.org/credentials/23894",  "issuanceDate": "2010-01-01T19:23:24Z",  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "parent": {      "id": "did:example:ebfeb1c276e12ec211f712ebc6f",      "type": "Mother"    }  },  "proof": {... }// the proof is generated by the child}

In the example above, the child expresses the relationship between the child andthe parent in a separatecredential such that averifier wouldmost likely accept any of the child'scredentials if thecredential above is provided.

Similarly, the strategies described in the examples above can be used for manyother types of use cases, including power of attorney, pet ownership, andpatient prescription pickup.

This section is non-normative.

When asubject passes averifiable credential to anotherholder, thesubject might issue a newverifiable credentialto theholder in which the:

• Issuer is thesubject.
• Subject is theholder to whom theverifiable credential isbeing passed.
• Claim contains theproperties being passed on.

Theholder can now create averifiable presentation containingthese twoverifiable credentials so that theverifier canverify that thesubject gave the originalverifiable credential to theholder.

{  "@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1"  ],  "id": "https://example.com/VP/0987654321",  "type": ["VerifiablePresentation"],  "verifiableCredential": [    {     "@context": [       "https://www.w3.org/2018/credentials/v1",       "https://www.w3.org/2018/credentials/examples/v1"      ],      "id": "http://pharma.example.com/credentials/3732",      "type": ["VerifiableCredential", "PrescriptionCredential"],      "issuer": "https://pharma.example.com/issuer/4",      "issuanceDate": "2010-01-01T19:23:24Z",      "credentialSubject": {        "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",        "prescription": {....}      },      "credentialStatus": {        "id": "https://pharma.example.com/credentials/status/3#94567",        "type": "RevocationList2020Status",        "revocationListIndex": "94567",        "revocationListCredential": "https://pharma.example.com/credentials/status/3"      },      "proof": {....}    },    {      "@context": [        "https://www.w3.org/2018/credentials/v1",        "https://www.w3.org/2018/credentials/examples/v1"      ],      "id": "https://example.com/VC/123456789",      "type": ["VerifiableCredential", "PrescriptionCredential"],      "issuer": "did:example:ebfeb1f712ebc6f1c276e12ec21",      "issuanceDate": "2010-01-03T19:53:24Z",      "credentialSubject": {        "id": "did:example:76e12ec21ebhyu1f712ebc6f1z2",        "prescription": {....}      },      "proof": {        "type": "RsaSignature2018",        "created": "2018-06-17T10:03:48Z",        "proofPurpose": "assertionMethod",        "jws": "pYw8XNi1..Cky6Ed=",        "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21/keys/234"      }    }  ],  "proof": [{    "type": "RsaSignature2018",    "created": "2018-06-18T21:19:10Z",    "proofPurpose": "authentication",    "verificationMethod": "did:example:76e12ec21ebhyu1f712ebc6f1z2/keys/2",    "challenge": "c0ae1c8e-c7e7-469f-b252-86e6a0e7387e",    "jws": "BavEll0/I1..W3JT24="  }]}

In the above example, a patient (the originalsubject) passed aprescription (the originalverifiable credential) to a friend, andissued a newverifiable credential to the friend, in which the friend isthesubject, thesubject of the originalverifiable credential is theissuer, and thecredential isa copy of the original prescription.

This section is non-normative.

When anissuer wants to authorize aholder to possess acredential that describes asubject who is not theholder,and theholder has no known relationship with thesubject, thentheissuer might insert the relationship of theholder to itselfinto thesubject'scredential.

{  "@context": [    "https://www.w3.org/2018/credentials/v1",    "https://www.w3.org/2018/credentials/examples/v1"  ],  "id": "http://example.edu/credentials/3732",  "type": ["VerifiableCredential", "NameAndAddress"],  "issuer": "https://example.edu/issuers/14",  "holder": {    "type": "LawEnforcement",    "id": "did:example:ebfeb1276e12ec21f712ebc6f1c"  },  "issuanceDate": "2010-01-01T19:23:24Z",  "credentialSubject": {    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",    "name": "Mr John Doe",    "address": "10 Some Street, Anytown, ThisLocal, Country X"  },  "proof": {    "type": "RsaSignature2018",    "created": "2018-06-17T10:03:48Z",    "proofPurpose": "assertionMethod",    "verificationMethod": "https://example.edu/issuers/14/keys/234",    "jws": "pY9...Cky6Ed = "  }}

This section is non-normative.

The Verifiable Credentials Data Model currently does not support either ofthese scenarios. It is for further study how they might be supported.

[JSON-LD]

JSON-LD 1.1: A JSON-based Serialization for Linked Data. Gregg Kellogg; Manu Sporny; Dave Longley; Markus Lanthaler; Pierre-Antoine Champin; Niklas Lindström. W3C JSON-LD 1.1 Working Group. W3C Working Draft. URL:https://www.w3.org/TR/json-ld11/

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL:https://www.rfc-editor.org/rfc/rfc2119

[RFC3986]

Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL:https://www.rfc-editor.org/rfc/rfc3986

[RFC7515]

JSON Web Signature (JWS). M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL:https://www.rfc-editor.org/rfc/rfc7515

[RFC7519]

JSON Web Token (JWT). M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL:https://www.rfc-editor.org/rfc/rfc7519

[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL:https://www.rfc-editor.org/rfc/rfc8174

[RFC8259]

The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. December 2017. Internet Standard. URL:https://www.rfc-editor.org/rfc/rfc8259

[XMLSCHEMA11-2]

W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL:https://www.w3.org/TR/xmlschema11-2/

[CL-SIGNATURES]

A Signature Scheme with Efficient Protocols. Jan Camenisch; Anna Lysyanskaya. IBM Research. Peer Reviewed Paper. URL:https://www.researchgate.net/publication/220922101_A_Signature_Scheme_with_Efficient_Protocols

[DATA-INTEGRITY]

Data Integrity. Manu Sporny; Dave Longley. Credentials Community Group. CG-DRAFT. URL:https://w3c-ccg.github.io/data-integrity-spec/

[DEMOGRAPHICS]

Simple Demographics Often Identify People Uniquely. Latanya Sweeney. Data Privacy Lab. URL:https://dataprivacylab.org/projects/identifiability/paper1.pdf

[HASHLINK]

Cryptographic Hyperlinks. Manu Sporny. Internet Engineering Task Force (IETF). Internet-Draft. URL:https://datatracker.ietf.org/doc/draft-sporny-hashlink/

[IPFS]

InterPlanetary File System (IPFS). Wikipedia. URL:https://en.wikipedia.org/wiki/InterPlanetary_File_System

[JSON]

The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. December 2017. Internet Standard. URL:https://www.rfc-editor.org/rfc/rfc8259

[JSON-SCHEMA-2018]

JSON Schema: A Media Type for Describing JSON Documents. Austin Wright; Henry Andrews. Internet Engineering Task Force (IETF). Internet-Draft. URL:https://datatracker.ietf.org/doc/draft-handrews-json-schema/

[LDP-REGISTRY]

Linked Data Cryptographic Suite Registry. Manu Sporny; Drummond Reed; Orie Steele. Credentials Community Group. CG-DRAFT. URL:https://w3c-ccg.github.io/ld-cryptosuite-registry/

[LINKED-DATA]

Linked Data Design Issues. Tim Berners-Lee. W3C. 27 July 2006. W3C-Internal Document. URL:https://www.w3.org/DesignIssues/LinkedData.html

[RFC7049]

Concise Binary Object Representation (CBOR). C. Bormann; P. Hoffman. IETF. October 2013. Proposed Standard. URL:https://www.rfc-editor.org/rfc/rfc7049

[RFC7516]

JSON Web Encryption (JWE). M. Jones; J. Hildebrand. IETF. May 2015. Proposed Standard. URL:https://www.rfc-editor.org/rfc/rfc7516

[RFC7797]

JSON Web Signature (JWS) Unencoded Payload Option. M. Jones. IETF. February 2016. Proposed Standard. URL:https://www.rfc-editor.org/rfc/rfc7797

[RFC8471]

The Token Binding Protocol Version 1.0. A. Popov, Ed.; M. Nystroem; D. Balfanz; J. Hodges. IETF. October 2018. Proposed Standard. URL:https://www.rfc-editor.org/rfc/rfc8471

[STRING-META]

Strings on the Web: Language and Direction Metadata. Addison Phillips; Richard Ishida. Internationalization Working Group. W3C Working Draft. URL:https://www.w3.org/TR/string-meta/

[VC-EXTENSION-REGISTRY]

Verifiable Credentials Extension Registry. Manu Sporny. Credentials Community Group. CG-DRAFT. URL:https://w3c-ccg.github.io/vc-extension-registry/

[VC-IMP-GUIDE]

Verifiable Credentials Implementation Guidelines 1.0. Andrei Sambra; Manu Sporny. Credentials Community Group. W3C Editor's Draft. URL:https://w3c.github.io/vc-imp-guide/

[VC-USE-CASES]

Verifiable Credentials Use Cases. Shane McCarron; Joe Andrieu; Matt Stone; Tzviya Siegman; Gregg Kellogg; Ted Thibodeau. W3C. 24 September 2019. W3C Working Group Note. URL:https://www.w3.org/TR/vc-use-cases/

[WCAG21]

Web Content Accessibility Guidelines (WCAG) 2.1. Andrew Kirkpatrick; Joshue O'Connor; Alastair Campbell; Michael Cooper. W3C. 5 June 2018. W3C Recommendation. URL:https://www.w3.org/TR/WCAG21/