diff --git a/transitions/2024/CR2/diagrams/claim-example-2.svg b/transitions/2024/CR2/diagrams/claim-example-2.svg new file mode 100644 index 000000000..25103c129 --- /dev/null +++ b/transitions/2024/CR2/diagrams/claim-example-2.svg @@ -0,0 +1,52 @@ + + + + +
+
+
+ + + Pat + + +
+
+
+ + Pat + + + + +
+
+
+ + + 21 + + +
+
+
+ + 21 + + + + + + + +
+
+
+ overAge +
+
+
+ +  overAge  + + diff --git a/transitions/2024/CR2/diagrams/claim-example.svg b/transitions/2024/CR2/diagrams/claim-example.svg new file mode 100644 index 000000000..afd277d83 --- /dev/null +++ b/transitions/2024/CR2/diagrams/claim-example.svg @@ -0,0 +1,52 @@ + + + + +
+
+
+ + + Pat + + +
+
+
+ + Pat + + + + +
+
+
+ + + Example University + + +
+
+
+ + Example University + + + + + + + +
+
+
+ alumniOf +
+
+
+ +  alumniOf  + + diff --git a/transitions/2024/CR2/diagrams/claim-extended.svg b/transitions/2024/CR2/diagrams/claim-extended.svg new file mode 100644 index 000000000..2a7dfafe6 --- /dev/null +++ b/transitions/2024/CR2/diagrams/claim-extended.svg @@ -0,0 +1,118 @@ + + + + +
+
+
+ + + Pat + + +
+
+
+ + Pat + + + + +
+
+
+ + + Example University + + +
+
+
+ + Example University + + + + + + + +
+
+
+ alumniOf +
+
+
+ +   alumniOf   + + + + +
+
+
+ + + Sam + + +
+
+
+ + Sam + + + + +
+
+
+ + + Professor + + +
+
+
+ + Professor + + + + + + + +
+
+
+ jobTitle +
+
+
+ +   jobTitle   + + + + + + + +
+
+
+ knows +
+
+
+ +  knows  + + diff --git a/transitions/2024/CR2/diagrams/claim.svg b/transitions/2024/CR2/diagrams/claim.svg new file mode 100644 index 000000000..cb22862d5 --- /dev/null +++ b/transitions/2024/CR2/diagrams/claim.svg @@ -0,0 +1,52 @@ + + + + +
+
+
+ + + Subject + + +
+
+
+ + Subject + + + + +
+
+
+ + + Value + + +
+
+
+ + Value + + + + + + + +
+
+
+ Property +
+
+
+ +  Property  + + diff --git a/transitions/2024/CR2/diagrams/ecosystem.svg b/transitions/2024/CR2/diagrams/ecosystem.svg new file mode 100644 index 000000000..da2c04c53 --- /dev/null +++ b/transitions/2024/CR2/diagrams/ecosystem.svg @@ -0,0 +1,211 @@ + + + + + + + +
+
+
+ + Register Identifiers + +
+ + and use Schemas + +
+
+
+
+ + Register Identifiers... + + + + +
+
+
+ + + + Verifiable Data Registry + + + +
+ + + Maintains identifiers and schemas + + +
+
+
+
+ + Verifiable Data Registry... + + + + +
+
+
+
+ + + + Holder + + + +
+
+ + + Acquires, stores, presents VCs + + +
+
+
+
+ + Holder... + + + + +
+
+
+
+ + + + Verifier + + + +
+
+ + + Verifies VCs + + +
+
+
+
+ + Verifier... + + + + +
+
+
+
+ + + + Issuer + + + +
+
+ + + Issues VCs + + +
+
+
+
+ + Issuer... + + + + + + + +
+
+
+ + Verify Identifiers + +
+ + and use Schemas + +
+
+
+
+ + Verify Identifiers... + + + + + + + +
+
+
+ + Verify Identifiers + +
+ + and Schemas + +
+
+
+
+ + Verify Identifiers... + + + + +
+
+
+ + Issue Credentials + +
+
+
+ + Issue Credentials + + + + +
+
+
+ + Send Presentation + +
+
+
+ + Send Presentation + + diff --git a/transitions/2024/CR2/diagrams/presentation.svg b/transitions/2024/CR2/diagrams/presentation.svg new file mode 100644 index 000000000..4d09aedd7 --- /dev/null +++ b/transitions/2024/CR2/diagrams/presentation.svg @@ -0,0 +1,79 @@ + + + + + +
+
+
+ + + + Verifiable Presentation + + + +
+
+
+ + Verifiable Presentation + + + + +
+
+
+
+ + + Presentation Metadata + + +
+
+
+
+ + Presentation Metadata + + + + +
+
+
+
+ + + Verifiable Credential(s) + + +
+
+
+
+ + Verifiable Credential(s) + + + + +
+
+
+
+ + + Proof(s) + + +
+
+
+
+ + Proof(s) + + diff --git a/transitions/2024/CR2/diagrams/privacy-spectrum.svg b/transitions/2024/CR2/diagrams/privacy-spectrum.svg new file mode 100644 index 000000000..14743e178 --- /dev/null +++ b/transitions/2024/CR2/diagrams/privacy-spectrum.svg @@ -0,0 +1,51 @@ + + + + + + + + + + + + + + + + + + + +...less privacy... +...more privacy... + +No protection for privacy +highly correlatable +(global IDs) + +e.g., government ID, +shipping address, +credit card info + + +Moderate privacy protection +correlatable via collusion +(Personally Identifiable Info) + +e.g., name, birthday, zipcode + + +Good privacy protection +non-correlatable +(pseudonyms) + +e.g., "is over 21" + + + diff --git a/transitions/2024/CR2/diagrams/vc-graph.svg b/transitions/2024/CR2/diagrams/vc-graph.svg new file mode 100644 index 000000000..bc4e31250 --- /dev/null +++ b/transitions/2024/CR2/diagrams/vc-graph.svg @@ -0,0 +1,409 @@ + + + + +
+
+
+ + + verifiable credential graph +
+ (the default graph) +
+ + +
+
+
+ + verifiable credential... + + + + + + +
+
+
+ + + Signature 456 + + +
+
+
+ + Signature 456 + + + + +
+
+
+ + + Example University Public Key 7 + + +
+
+
+ + Example University P... + + + + +
+
+
+ + + 2022-06-18T21:19.10Z + + +
+
+
+ + 2022-06-18T21:19.10Z + + + + +
+
+
+ + + Data Integrity Proof + + +
+
+
+ + Data Integrity Proof + + + + +
+
+
+ + + 34dj239dsj328 + + +
+
+
+ + 34dj239dsj328 + + + + +
+
+
+ + + zBavE110…3JT2pq + + +
+
+
+ + zBavE110…3JT2pq + + + + + +
+
+
+ type +
+
+
+ +  type  + + + + + +
+
+
+ created +
+
+
+ +  created + + + + + +
+
+
+ nonce +
+
+
+ + nonce  + + + + + +
+
+
+ proofValue +
+
+
+ + proofValue + + + + + +
+
+
+ type +
+
+
+ +  type  + + + +
+
+
+ verificationMethod +
+
+
+ + verificationMethod + + + + +
+
+
+ + + verifiable credential proof graph +
+ (a named graph) +
+ + +
+
+
+ + verifiable credential pro... + + + + + +
+
+
+ proof +
+
+
+ + proof + + + + +
+
+
+ + + Example University + + +
+
+
+ + Example University + + + + +
+
+
+ + + 2010-01-01T10:37.24Z + + +
+
+
+ + 2010-01-01T10:37.24Z + + + + +
+
+
+ + + Example Alumni Credential + + +
+
+
+ + Example Alumni Credent... + + + + +
+
+
+ + + Credential123 + + +
+
+
+ + Credential123 + + + + +
+
+
+ + + Pat + + +
+
+
+ + Pat + + + + + +
+
+
+ type +
+
+
+ + type + + + + + +
+
+
+ type +
+
+
+ + type + + + +
+
+
+ validFrom +
+
+
+ + validFrom  + + + + + +
+
+
+ issuer +
+
+
+ + issuer + + + + + +
+
+
+ credentialSubject +
+
+
+ +  credentialSubject  + + + + + +
+
+
+ alumniOf +
+
+
+ + alumniOf + + diff --git a/transitions/2024/CR2/diagrams/vc-jwt.svg b/transitions/2024/CR2/diagrams/vc-jwt.svg new file mode 100644 index 000000000..768c64267 --- /dev/null +++ b/transitions/2024/CR2/diagrams/vc-jwt.svg @@ -0,0 +1,361 @@ + + + + + +
+
+
+ + + SD-JWT (Decoded) + + +
+
+
+ + SD-JWT (Decoded) + + + + + + +
+
+
+ Header +
+
+
+ + Header + + + + +
+
+
+ Payload +
+
+
+ + Payload   + + + + +
+
+
+ Signature +
+
+
+ + Signature + + + + + + + + + +
+
+
+ + + verifiable credential graph +
+ (serialized in JSON) +
+ + +
+
+
+ + verifiable credential... + + + + +
+
+
+ + + Example University + + +
+
+
+ + Example University + + + + +
+
+
+ + + 2010-01-01T10:37.24Z + + +
+
+
+ + 2010-01-01T10:37.24Z + + + + +
+
+
+ + + Example Alumni Credential + + +
+
+
+ + Example Alumni Credent... + + + + +
+
+
+ + + Credential123 + + +
+
+
+ + Credential123 + + + + +
+
+
+ + + Pat + + +
+
+
+ + Pat + + + + + +
+
+
+ type +
+
+
+ + type + + + + + +
+
+
+ type +
+
+
+ + type + + + +
+
+
+ validFrom +
+
+
+ + validFrom  + + + + + +
+
+
+ issuer +
+
+
+ + issuer + + + + + +
+
+
+ credentialSubject +
+
+
+ +  credentialSubject  + + + + + +
+
+
+ alumniOf +
+
+
+ + alumniOf + + + + + +
+
+
+ DtEhU3ljbEg8L38VWAfUA... +
+
+
+ + DtEhU3ljbEg8L38VWAfUA... + + + + + +
+
+
+ + kid: aB8J-_Z + +
+
+
+ + kid: aB8J-_Z + + + + +
+
+
+ + iss: https://example.com + +
+
+
+ + iss: https://example.com + + + + +
+
+
+ + alg: ES384 + +
+
+
+ + alg: ES384 + + + + +
+
+
+ + iat: + + + 1704690029 + +
+
+
+ + iat: 1704690029 + + + + +
+
+
+ + cty: vc + +
+
+
+ + cty: vc + + + + +
+
+
+ + typ: vc+sd-jwt + +
+
+
+ + typ: vc+sd-jwt + + diff --git a/transitions/2024/CR2/diagrams/vc.svg b/transitions/2024/CR2/diagrams/vc.svg new file mode 100644 index 000000000..dd2c718ac --- /dev/null +++ b/transitions/2024/CR2/diagrams/vc.svg @@ -0,0 +1,79 @@ + + + + + +
+
+
+ + + + Verifiable Credential + + + +
+
+
+ + Verifiable Credential + + + + +
+
+
+
+ + + Credential Metadata + + +
+
+
+
+ + Credential Metadata + + + + +
+
+
+
+ + + Claim(s) + + +
+
+
+
+ + Claim(s) + + + + +
+
+
+
+ + + Proof(s) + + +
+
+
+
+ + Proof(s) + + diff --git a/transitions/2024/CR2/diagrams/vp-graph-mult-creds.svg b/transitions/2024/CR2/diagrams/vp-graph-mult-creds.svg new file mode 100644 index 000000000..8bde40160 --- /dev/null +++ b/transitions/2024/CR2/diagrams/vp-graph-mult-creds.svg @@ -0,0 +1,1197 @@ + + + + + +
+
+
+ + + Presentation ABC + + +
+
+
+ + Presentation ABC + + + + +
+
+
+ + + VerifiablePresentation + + +
+
+
+ + VerifiablePresentation + + + + +
+
+
+ + + DoNotArchive + + +
+
+
+ + DoNotArchive + + + + + +
+
+
+ termsOfUse +
+
+
+ +  termsOfUse  + + + + + +
+
+
+ type +
+
+
+ +  type  + + + + + +
+
+
+ verifiableCredential +
+
+
+ + verifiableCredential + + + + + +
+
+
+ proof +
+
+
+ + proof + + + + +
+
+
+ + + verifiable presentation graph +
+ (the default graph) +
+ + +
+
+
+ + verifiable presentation gra... + + + + + +
+
+
+ + + Signature 8920 + + +
+
+
+ + Signature 8920 + + + + + +
+
+
+ type +
+
+
+ +  type  + + + +
+
+
+ verificationMethod +
+
+
+ + verificationMethod + + + + + +
+
+
+ created +
+
+
+ +  created + + + + + +
+
+
+ type +
+
+
+ +  type  + + + + + +
+
+
+ nonce +
+
+
+ + nonce  + + + + + +
+
+
+ proofValue +
+
+
+ + proofValue + + + + +
+
+
+ + + Example University Public Key 11 + + +
+
+
+ + Example University P... + + + + +
+
+
+ + + 2024-01-02T12:43.56Z + + +
+
+
+ + 2024-01-02T12:43.56Z + + + + +
+
+
+ + + Data Integrity Proof + + +
+
+
+ + Data Integrity Proof + + + + +
+
+
+ + + hasdkyruod87j + + +
+
+
+ + hasdkyruod87j + + + + +
+
+
+ + + zpweJHoan87 + + +
+
+
+ + zpweJHoan87 + + + + +
+
+
+ + + verifiable presentation proof graph +
+ (a named graph) +
+ + +
+
+
+ + verifiable presentation proof graph... + + + + + +
+
+
+ verifiableCredential +
+
+
+ + verifiableCredential + + + + + + +
+
+
+ + + Signature 456 + + +
+
+
+ + Signature 456 + + + + +
+
+
+

+ + + Example University Public Key 7 + + +

+
+
+
+ + Example Unive... + + + + +
+
+
+ + + 2022-06-18T21:19.10Z + + +
+
+
+ + 2022-06-18T21:19... + + + + +
+
+
+ + + Data Integrity Proof + + +
+
+
+ + Data Integrity... + + + + +
+
+
+ + + 34dj239dsj328 + + +
+
+
+ + 34dj239dsj328 + + + + +
+
+
+ + + zBavE110…3JT2pq + + +
+
+
+ + zBavE110…3JT2pq + + + + + +
+
+
+ + verificationMethod + +
+
+
+ + verificationMethod + + + + + +
+
+
+ + created + +
+
+
+ +  created + + + + + +
+
+
+ + type + +
+
+
+ +   type   + + + + + +
+
+
+ + nonce + +
+
+
+ + nonce  + + + + + +
+
+
+ + proofValue + +
+
+
+ + proofValue  + + + + +
+
+
+

+ + + + verifiable credential proof graph + +
+ + (a named graph) + +
+ + +

+
+
+
+ + verifiable credential proo... + + + + +
+
+
+

+ + + verifiable credential graph +
+ (a named graph) +
+ + +

+
+
+
+ + verifiable cred... + + + + +
+
+
+ + + Example University + + +
+
+
+ + Example Unive... + + + + +
+
+
+ + + 2010-01-01T10:37.24Z + + +
+
+
+ + 2010-01-01T10:37... + + + + +
+
+
+

+ + + Example Alumni Credential + + +

+
+
+
+ + Example Alumni... + + + + +
+
+
+ + + Credential123 + + +
+
+
+ + Credential123 + + + + +
+
+
+ + + Pat + + +
+
+
+ + Pat + + + + + +
+
+
+ + type + +
+
+
+ + type + + + + + +
+
+
+ + validFrom + +
+
+
+ +  validFrom  + + + + + +
+
+
+ + issuer + +
+
+
+ + issuer + + + + + +
+
+
+ + credentialSubject + +
+
+
+ +   credentialSubject   + + + + + +
+
+
+ + alumniOf + +
+
+
+ + alumniOf + + + + + +
+
+
+ + proof + +
+
+
+ + proof + + + + + + +
+
+
+ + + Signature 789 + + +
+
+
+ + Signature 789 + + + + +
+
+
+

+ + + Example University Public Key 7 + + +

+
+
+
+ + Example Unive... + + + + +
+
+
+ + + 2024-01-01T10:50.10Z + + +
+
+
+ + 2024-01-01T10:50... + + + + +
+
+
+ + + Data Integrity Proof + + +
+
+
+ + Data Integrity... + + + + +
+
+
+ + + 45jhei78j0ei + + +
+
+
+ + 45jhei78j0ei + + + + +
+
+
+ + + zHbNml98dnao + + +
+
+
+ + zHbNml98dnao + + + + + +
+
+
+ + verificationMethod + +
+
+
+ + verificationMethod + + + + + +
+
+
+ + created + +
+
+
+ +  created + + + + + +
+
+
+ + type + +
+
+
+ +   type   + + + + + +
+
+
+ + nonce + +
+
+
+ + nonce  + + + + + +
+
+
+ + proofValue + +
+
+
+ + proofValue  + + + + +
+
+
+

+ + + + verifiable credential proof graph + +
+ + (a named graph) + +
+ + +

+
+
+
+ + verifiable credential proo... + + + + +
+
+
+

+ + + verifiable credential graph +
+ (a named graph) +
+ + +

+
+
+
+ + verifiable cred... + + + + +
+
+
+ + + Example University + + +
+
+
+ + Example Unive... + + + + +
+
+
+ + + 2024-01-01T10:37.24Z + + +
+
+
+ + 2024-01-01T10:37... + + + + +
+
+
+

+ + + Example Alumni Credent + + + ial + + +

+
+
+
+ + Example Alumni... + + + + +
+
+
+ + + Credential456 + + +
+
+
+ + Credential456 + + + + +
+
+
+ + + Ted + + +
+
+
+ + Ted + + + + + +
+
+
+ + type + +
+
+
+ + type + + + + + +
+
+
+
+
+
+
+ + + + +
+
+
+ + validFrom + +
+
+
+ +  validFrom   + + + + + +
+
+
+ + issuer + +
+
+
+ + issuer + + + + + +
+
+
+ + credentialSubject + +
+
+
+ +   credentialSubject   + + + + + +
+
+
+ + alumniOf + +
+
+
+ + alumniOf + + + + + +
+
+
+ + proof + +
+
+
+ + proof + + diff --git a/transitions/2024/CR2/diagrams/vp-graph.svg b/transitions/2024/CR2/diagrams/vp-graph.svg new file mode 100644 index 000000000..beb0ece3a --- /dev/null +++ b/transitions/2024/CR2/diagrams/vp-graph.svg @@ -0,0 +1,742 @@ + + + + + + + +
+
+
+ + + Signature 456 + + +
+
+
+ + Signature 456 + + + + +
+
+
+ + + Example University Public Key 7 + + +
+
+
+ + Example University P... + + + + +
+
+
+ + + 2022-06-18T21:19.10Z + + +
+
+
+ + 2022-06-18T21:19.10Z + + + + +
+
+
+ + + Data Integrity Proof + + +
+
+
+ + Data Integrity Proof + + + + +
+
+
+ + + 34dj239dsj328 + + +
+
+
+ + 34dj239dsj328 + + + + +
+
+
+ + + zBavE110…3JT2pq + + +
+
+
+ + zBavE110…3JT2pq + + + + + +
+
+
+ type +
+
+
+ +  type  + + + +
+
+
+ verificationMethod +
+
+
+ + verificationMethod + + + + + +
+
+
+ created +
+
+
+ +  created + + + + + +
+
+
+ type +
+
+
+ +  type  + + + + + +
+
+
+ nonce +
+
+
+ + nonce  + + + + + +
+
+
+ proofValue +
+
+
+ + proofValue + + + + +
+
+
+ + + verifiable credential proof graph +
+ (a named graph) +
+ + +
+
+
+ + verifiable credential proof graph... + + + + + +
+
+
+ proof +
+
+
+ + proof + + + + +
+
+
+ + + verifiable credential graph +
+ (a named graph) +
+ + +
+
+
+ + verifiable credential... + + + + +
+
+
+ + + Presentation ABC + + +
+
+
+ + Presentation ABC + + + + +
+
+
+ + + VerifiablePresentation + + +
+
+
+ + VerifiablePresentation + + + + +
+
+
+ + + DoNotArchive + + +
+
+
+ + DoNotArchive + + + + + +
+
+
+ termsOfUse +
+
+
+ +  termsOfUse  + + + + + +
+
+
+ type +
+
+
+ +  type  + + + + + +
+
+
+ verifiableCredential +
+
+
+ + verifiableCredential + + + + + +
+
+
+ proof +
+
+
+ + proof + + + + +
+
+
+ + + Signature 8910 + + +
+
+
+ + Signature 8910 + + + + + +
+
+
+ type +
+
+
+ +  type  + + + +
+
+
+ verificationMethod +
+
+
+ + verificationMethod + + + + + +
+
+
+ created +
+
+
+ +  created + + + + + +
+
+
+ type +
+
+
+ +  type  + + + + + +
+
+
+ nonce +
+
+
+ + nonce  + + + + + +
+
+
+ proofValue +
+
+
+ + proofValue + + + + + +
+
+
+ + + Example University Public Key 11 + + +
+
+
+ + Example University P... + + + + +
+
+
+ + + 2023-01-15T12:43.56Z + + +
+
+
+ + 2023-01-15T12:43.56Z + + + + +
+
+
+ + + Data Integrity Proof + + +
+
+
+ + Data Integrity Proof + + + + +
+
+
+ + + d23848djsj3239 + + +
+
+
+ + d23848djsj3239 + + + + +
+
+
+ + + zp2KaZ…8Fj3eK + + +
+
+
+ + zp2KaZ…8Fj3eK + + + + +
+
+
+ + + verifiable presentation proof graph +
+ (a named graph) +
+ + +
+
+
+ + verifiable presentation proof graph... + + + + +
+
+
+ + + Example University + + +
+
+
+ + Example University + + + + +
+
+
+ + + 2010-01-01T10:37.24Z + + +
+
+
+ + 2010-01-01T10:37.24Z + + + + +
+
+
+ + + Example Alumni Credential + + +
+
+
+ + Example Alumni Credent... + + + + +
+
+
+ + + Credential123 + + +
+
+
+ + Credential123 + + + + +
+
+
+ + + Pat + + +
+
+
+ + Pat + + + + + +
+
+
+ type +
+
+
+ + type + + + + + +
+
+
+ type +
+
+
+ + type + + + +
+
+
+ validFrom +
+
+
+ + validFrom  + + + + + +
+
+
+ issuer +
+
+
+ + issuer + + + + + +
+
+
+ credentialSubject +
+
+
+ +  credentialSubject  + + + + + +
+
+
+ alumniOf +
+
+
+ + alumniOf + + + + +
+
+
+ + + verifiable presentation graph +
+ (the default graph) +
+ + +
+
+
+ + verifiable presentation gra... + + diff --git a/transitions/2024/CR2/diagrams/vp-jwt-mult-creds.svg b/transitions/2024/CR2/diagrams/vp-jwt-mult-creds.svg new file mode 100644 index 000000000..469bbab36 --- /dev/null +++ b/transitions/2024/CR2/diagrams/vp-jwt-mult-creds.svg @@ -0,0 +1,442 @@ + + + + + +
+
+
+ + + SD-JWT (Decoded) + + +
+
+
+ + SD-JWT (Decoded) + + + + + + +
+
+
+ Header +
+
+
+ + Header + + + + +
+
+
+ Payload +
+
+
+ + Payload   + + + + +
+
+
+ Signature +
+
+
+ + Signature + + + + + + + + + +
+
+
+ cYjaSdfIoJH45NIqw3MYnasGIba... +
+
+
+ + cYjaSdfIoJH45NIqw3MYnasGIba... + + + + + +
+
+
+ + kid: aB8J-_Z + +
+
+
+ + kid: aB8J-_Z + + + + +
+
+
+ + iss: https://example.com + +
+
+
+ + iss: https://example.c... + + + + +
+
+
+ + alg: ES384 + +
+
+
+ + alg: ES384 + + + + +
+
+
+ + iat: + + 1704690029 +
+
+
+ + iat: 1704690029 + + + + +
+
+
+ + cty: vp + +
+
+
+ + cty: vp + + + + +
+
+
+ + typ: vp+sd-jwt + +
+
+
+ + typ: vp+sd-jwt + + + + + + +
+
+
+ + + verifiable presentation graph +
+ (serialized in JSON) +
+ + +
+
+
+ + verifiable presentation gr... + + + + +
+
+
+ + + Presentation ABC + + +
+
+
+ + Presentation ABC + + + + +
+
+
+ + + VerifiablePresentation + + +
+
+
+ + VerifiablePresentation + + + + +
+
+
+ + + DoNotArchive + + +
+
+
+ + DoNotArchive + + + + + +
+
+
+ termsOfUse +
+
+
+ +  termsOfUse  + + + + + +
+
+
+ type +
+
+
+ +  type  + + + + + +
+
+
+ verifiableCredential +
+
+
+ + verifiableCredential + + + + + +
+
+
+ + + EnvelopedVerifiableCredential + + +
+
+
+ + EnvelopedVerifiable... + + + + +
+
+
+ + + data:application/vc+sd-jwt,QzVjV...RMjU + + +
+
+
+ + data:application/vc+sd-jw... + + + + + +
+
+
+ + type + +
+
+
+ + type + + + + +
+
+
+ + + enveloped verifiable credential graph +
+ (serialized in JSON) +
+ + +
+
+
+ + enveloped verifia... + + + + + +
+
+
+ + + EnvelopedVerifiableCredential + + +
+
+
+ + EnvelopedVerifiable... + + + + +
+
+
+ + + data:application/vc+sd-jwt,RkOyT...KjOl + + +
+
+
+ + data:application/vc+sd-jwt... + + + + + +
+
+
+ + type + +
+
+
+ + type + + + + +
+
+
+ + + enveloped verifiable credential graph +
+ (serialized in JSON) +
+ + +
+
+
+ + enveloped verifia... + + + + + +
+
+
+ verifiableCredential +
+
+
+ + verifiableCredential + + diff --git a/transitions/2024/CR2/diagrams/vp-jwt.svg b/transitions/2024/CR2/diagrams/vp-jwt.svg new file mode 100644 index 000000000..f8fa6d79f --- /dev/null +++ b/transitions/2024/CR2/diagrams/vp-jwt.svg @@ -0,0 +1,353 @@ + + + + + +
+
+
+ + + SD-JWT (Decoded) + + +
+
+
+ + SD-JWT (Decoded) + + + + + + +
+
+
+ Header +
+
+
+ + Header + + + + +
+
+
+ Payload +
+
+
+ + Payload   + + + + +
+
+
+ Signature +
+
+
+ + Signature + + + + + + + + + +
+
+
+ XaOOh4ljklxH7L99RTVSfOl... +
+
+
+ + XaOOh4ljklxH7L99RTVSfOl... + + + + + +
+
+
+ + kid: aB8J-_Z + +
+
+
+ + kid: aB8J-_Z + + + + +
+
+
+ + iss: https://example.com + +
+
+
+ + iss: https://example.c... + + + + +
+
+
+ + alg: ES384 + +
+
+
+ + alg: ES384 + + + + +
+
+
+ + iat: + + 1704690029 +
+
+
+ + iat: 1704690029 + + + + +
+
+
+ + cty: vp + +
+
+
+ + cty: vp + + + + +
+
+
+ + typ: vp+sd-jwt + +
+
+
+ + typ: vp+sd-jwt + + + + + + +
+
+
+ + + verifiable presentation graph +
+ (serialized in JSON) +
+ + +
+
+
+ + verifiable presentation gr... + + + + + +
+
+
+ + + Presentation ABC + + +
+
+
+ + Presentation ABC + + + + +
+
+
+ + + VerifiablePresentation + + +
+
+
+ + VerifiablePresentation + + + + +
+
+
+ + + DoNotArchive + + +
+
+
+ + DoNotArchive + + + + + +
+
+
+ termsOfUse +
+
+
+ +  termsOfUse  + + + + + +
+
+
+ type +
+
+
+ +  type  + + + + + +
+
+
+ verifiableCredential +
+
+
+ + verifiableCredential + + + + +
+
+
+ + + enveloped verifiable credential graph +
+ (serialized in JSON) +
+ + +
+
+
+ + enveloped verifiable credent... + + + + +
+
+
+ + EnvelopedVerifiableCredential + +
+
+
+ + EnvelopedVerifiableCredential + + + + +
+
+
+ + data:application/vc+sd-jwt,QzVjV...RMjU + +
+
+
+ + data:application/vc+sd-jwt,QzVjV...RMjU + + + + + +
+
+
+ + type + +
+
+
+ + type + + diff --git a/transitions/2024/CR2/diagrams/zkp-cred-pres.svg b/transitions/2024/CR2/diagrams/zkp-cred-pres.svg new file mode 100644 index 000000000..24457454f --- /dev/null +++ b/transitions/2024/CR2/diagrams/zkp-cred-pres.svg @@ -0,0 +1,3 @@ + + +
%3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%2F%3E%3CmxCell%20id%3D%221%22%20parent%3D%220%22%2F%3E%3CmxCell%20id%3D%222%22%20value%3D%22%26lt%3Bi%26gt%3B%26lt%3Bb%26gt%3B%26lt%3Bfont%20style%3D%26quot%3Bfont-size%3A%2019px%3B%26quot%3B%26gt%3BVerifiable%20Credential%201%26lt%3B%2Ffont%26gt%3B%26lt%3B%2Fb%26gt%3B%26lt%3B%2Fi%26gt%3B%22%20style%3D%22text%3Bhtml%3D1%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3BwhiteSpace%3Dwrap%3Brounded%3D0%3BfontSize%3D16%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-1107%22%20y%3D%22-788%22%20width%3D%22220%22%20height%3D%2231.94%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3C%2Froot%3E%3C%2FmxGraphModel%3E
%3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%...
Verifiable Credential 1
Verifiable Credential 1
Verifiable Credential 2
Verifiable Credential 2
Presentation
Presentation
Derived Verifiable Credential 1
Derived Verifiable Credenti...
  
  
  
  
Derived Verifiable Credential 2
Derived Verifiable Credenti...
  
  
 
 
Context
Type
ID
…
Context...
Credential Subject:

Credential Subjec...
Given Name
Family Name
Birth Date
…
Given Name...
Proof:

Proof:
Signature
Proof of Correctness
Attributes
…
Signature...
Context
Type
ID
Issuer
Issue Date
Expiration Date
…
Context...
Context
Type
ID
Issuer
Issue Date
Expiration Date
…
Context...
Proof:

Proof:
Signature
Proof of Correctness
Attributes
…
Signature...
Credential Subject:
Credential Subjec...
University
Department
Degree Awarded
…
University...
Context
Type
ID
Issuer
Issue Date
Context...
Context
Type
ID
Issuer
Issue Date
Context...
Credential Subject:

Credential Subjec...
Degree
Degree
Proof:

Proof:
Knowledge of Signature
Knowledge of Signature
Proof:

Proof:
Knowledge of Signature
Knowledge of Signature
Credential Subject:

Credential Subjec...
Age Over 18
Age Over 18
Proof:

Proof:
Knowledge of Link Secret
Knowledge of Link Sec...Text is not SVG - cannot display \ No newline at end of file diff --git a/transitions/2024/CR2/index.html b/transitions/2024/CR2/index.html new file mode 100644 index 000000000..b4398b4a6 --- /dev/null +++ b/transitions/2024/CR2/index.html @@ -0,0 +1,13364 @@ + + + + + + + + +Verifiable Credentials Data Model v2.0 + + + + + + + + + + + + + + + + + + + + +
+

+

Verifiable Credentials Data Model v2.0

+

W3C Candidate Recommendation Snapshot

+
+ More details about this document +
+
This version:
+ https://www.w3.org/TR/2024/CR-vc-data-model-2.0-20241105/ +
+
Latest published version:
+ https://www.w3.org/TR/vc-data-model-2.0/ +
+
Latest editor's draft:
https://w3c.github.io/vc-data-model/
+
History:
+ https://www.w3.org/standards/history/vc-data-model-2.0/ +
+ Commit history +
+ +
Implementation report:
+ https://w3c.github.io/vc-data-model-2.0-test-suite/ +
+ + + +
Editors:
+ Manu Sporny (Digital Bazaar) (v1.0, v1.1, v2.0) +
+ Ted Thibodeau Jr (OpenLink Software) (v2.0) +
+ Ivan Herman + + + + (W3C) (v2.0) +
+ Michael B. Jones (Invited Expert) (v2.0) +
+ Gabe Cohen (Block) (v2.0) +
+
+ Former editors: +
+ Grant Noble (ConsenSys) (v1.0) +
+ Dave Longley (Digital Bazaar) (v1.0) +
+ Daniel C. Burnett (ConsenSys) (v1.0) +
+ Brent Zundel (Evernym) (v1.0) +
+ Kyle Den Hartog (MATTR) (v1.1) +
+ Orie Steele (Transmute) (v2.0) +
+ Oliver Terbu (Spruce Systems) (v2.0) +
+
Authors:
+ Manu Sporny (Digital Bazaar) +
+ Dave Longley (Digital Bazaar) +
+ David Chadwick (Crossword Cybersecurity PLC) +
+ Orie Steele (Transmute) (v2.0) +
+
Feedback:
+ GitHub w3c/vc-data-model + (pull requests, + new issue, + open issues) +
+ + +
+
+ + +

+ Copyright + © + 2024 + + World Wide Web Consortium. + W3C® + liability, + trademark and + permissive document license rules apply. +

+
+
+

Abstract

+

+Credentials are integral to our daily lives: driver's licenses confirm +our capability to operate motor vehicles; university degrees assert our level +of education; and government-issued passports attest to our citizenship when +traveling between countries. This specification provides a mechanism for +expressing these sorts of credentials on the Web in a way that is +cryptographically secure, privacy respecting, and machine verifiable. These +credentials provide benefits to us when used in the physical world, but +their use on the Web continues to be elusive. +

+
+ +

Status of This Document

This section describes the status of this + document at the time of its publication. A list of current W3C + publications and the latest revision of this technical report can be found + in the W3C technical reports index at + https://www.w3.org/TR/.

+

+The Working Group is actively seeking implementation feedback for this +specification. In order to exit the Candidate Recommendation phase, the +Working Group has set the requirement of at least two independent +implementations for each mandatory feature in the specification. Please see +the +implementation report for more details. +

+ +
(Feature at Risk) Issue: Features with less than two independent implementations

+Any feature with less than two independent implementations in the + +implementation report is an "at risk" feature and might be +removed before the transition to W3C Proposed Recommendation. +

+ +

+Comments regarding this specification are welcome at any time. +Please file issues directly on +GitHub, +or send them to +public-vc-comments@w3.org +if that is not possible. +(subscribe, +archives). +

+ +

+ This document was published by the Verifiable Credentials Working Group as + a Candidate Recommendation Snapshot using the + Recommendation track. +

Publication as a Candidate Recommendation does not + imply endorsement by W3C and its Members. A Candidate Recommendation Snapshot has received + wide review, is intended to + gather + implementation experience, + and has commitments from Working Group members to + royalty-free licensing + for implementations.

+ This Candidate Recommendation is not expected to advance to Proposed + Recommendation any earlier than 05 December 2024. +

+ + This document was produced by a group + operating under the + W3C Patent + Policy. + + + W3C maintains a + public list of any patent disclosures + made in connection with the deliverables of + the group; that page also includes + instructions for disclosing a patent. An individual who has actual + knowledge of a patent which the individual believes contains + Essential Claim(s) + must disclose the information in accordance with + section 6 of the W3C Patent Policy. + +

+ This document is governed by the + 03 November 2023 W3C Process Document. +

+ +

1. Introduction

This section is non-normative.

+ + +

+Credentials are integral to our daily lives: driver's licenses confirm +our capability to operate motor vehicles; university degrees assert our level +of education; and government-issued passports attest to our citizenship when +traveling between countries. This specification provides a mechanism for +expressing these sorts of credentials on the Web in a way that is +cryptographically secure, privacy respecting, and machine verifiable. These +credentials provide benefits to us when used in the physical world, but +their use on the Web continues to be elusive. +

+ +

+It is currently difficult to express educational qualifications, healthcare +data, financial account details, and other third-party-verified +personal information in a machine readable way on the Web. The challenge of +expressing digital credentials on the Web hinders our ability to receive +the same benefits from them that physical credentials provide in the +real world. +

+

+For those unfamiliar with the concepts related to +verifiable credentials, the following sections provide an overview of: +

+ + +

+The use cases and requirements that informed this specification can be found +in Verifiable Credentials Use Cases [VC-USE-CASES]. +

+ +

1.1 What is a Verifiable Credential?

This section is non-normative.

+ + +

+In the physical world, a credential might consist of: +

+ + + +

+A verifiable credential can represent all the same information that a +physical credential represents. Adding technologies such as +digital signatures can make verifiable credentials more tamper-evident and +trustworthy than their physical counterparts. +

+ +

+Holders of verifiable credentials can generate +verifiable presentations and then share these +verifiable presentations with verifiers to prove they possess +verifiable credentials with specific characteristics. +

+ +

+Both verifiable credentials and verifiable presentations can be +transmitted rapidly, making them more convenient than their physical +counterparts when establishing trust at a distance. +

+ +

+While this specification attempts to improve the ease of expressing digital +credentials, it also aims to balance this goal with several +privacy-preserving goals. The persistence of digital information, and the ease +with which disparate sources of digital data can be collected and correlated, +comprise a privacy concern that the use of verifiable and easily +machine-readable credentials threatens to make worse. This document +outlines and attempts to address several of these issues in Section +8. Privacy Considerations. Examples of how to use this data model +using privacy-enhancing technologies, such as zero-knowledge proofs, are also +provided throughout this document. +

+ +

+The word "verifiable" in the terms verifiable credential and +verifiable presentation refers to the characteristic of a credential +or presentation as being able to be verified by a verifier, +as defined in this document. Verifiability of a credential does not imply +the truth of claims encoded therein. Instead, upon establishing the +authenticity and currency of a verifiable credential or +verifiable presentation, a verifier validates the included claims using +their own business rules before relying on them. Such reliance only occurs after +evaluating the issuer, the proof, the subject, and the claims against one or +more verifier policies. +

+
+ +

1.2 Ecosystem Overview

This section is non-normative.

+ + +

+This section describes the roles of the core actors and the relationships +between them in an ecosystem where one expects verifiable credentials +to be useful. A role is an abstraction that might be implemented in many +different ways. The separation of roles suggests likely interfaces and +protocols for standardization. This specification introduces the following +roles: +

+ +
+
holder
+
+A role an entity might perform by possessing one or more verifiable credentials and generating verifiable presentations from them. A holder is +often, but not always, a subject of the verifiable credentials they are +holding. Holders store their credentials in credential repositories. +Example holders include students, employees, and customers. +
+
issuer
+
+A role an entity can perform by asserting claims about one or more +subjects, creating a verifiable credential from these claims, and +transmitting the verifiable credential to a holder. For example, issuers +include corporations, non-profit organizations, trade associations, governments, +and individuals. +
+
subject
+
+A thing about which claims are made. Example subjects include human beings, +animals, and things. +
+
verifier
+
+A role an entity performs by receiving one or more verifiable credentials, optionally inside a verifiable presentation for processing. +Example verifiers include employers, security personnel, and websites. +
+
verifiable data registry
+
+A role a system might perform by mediating the creation and verification of +identifiers, verification material, and other relevant data, such as +verifiable credential schemas, revocation registries, and so on, which might +require using verifiable credentials. Some configurations might require +correlatable identifiers for subjects. Some registries, such as ones for +UUIDs and verification material, might just act as namespaces for +identifiers. Examples of verifiable data registries include trusted databases, +decentralized databases, government ID databases, and distributed ledgers. Often, +more than one type of verifiable data registry used in an ecosystem. +
+
+ +
+ diagram showing how + credentials flow from issuer to holder and + presentations flow from holder to verifier where all + three parties can use information from a logical + verifiable data registry +
Figure 1 + The roles and information flows forming the basis for this + specification. +
+
+ +
Note: Other types of ecosystems exist

+Figure 1 above provides an example ecosystem to ground the +rest of the concepts in this specification. Other ecosystems exist, such as +protected environments or proprietary systems, where +verifiable credentials also provide benefits. +

+ +

+This ecosystem contrasts with the typical two-party or federated identity +provider models. An identity provider, sometimes abbreviated as IdP, +is a system for creating, maintaining, and managing identity information for +holders while providing authentication services to relying party +applications within a federation or distributed network. In a federated +identity model, the holder is tightly bound to the identity provider. +This specification avoids using "identity provider," "federated identity," or +"relying party" terminology, except when comparing or mapping these concepts +to other specifications. This specification decouples the identity provider +concept into two distinct concepts: the issuer and the holder. +

+ +
Note: Subjects are not always Holders

+In many cases, the holder of a verifiable credential is the subject, but +in some instances it is not. For example, a parent (the holder) might hold +the verifiable credentials of a child (the subject), or a pet owner (the +holder) might hold the verifiable credentials of their pet (the +subject). For more information about these exceptional cases, see the + +Subject-Holder Relationships section in the Verifiable Credentials Implementation Guidelines 1.0. +

+ +

+For a deeper exploration of the verifiable credentials ecosystem and +a concrete lifecycle example, please refer to Verifiable Credentials Use Cases [VC-USE-CASES]. +

+
+ +

1.3 Conformance

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 words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHOULD, and SHOULD NOT in this document + are to be interpreted as described in + BCP 14 + [RFC2119] [RFC8174] + when, and only when, they appear in all capitals, as shown here. +

+

+A conforming document is a +compacted JSON-LD +document that complies with all of the relevant "MUST" statements in this +specification. Specifically, the relevant normative "MUST" statements in +Sections 4. Basic Concepts, 5. Advanced Concepts, and +6. Syntaxes of this document MUST be enforced. +A conforming document MUST be either a verifiable credential +with a media type of application/vc or a verifiable presentation +with a media type of application/vp. A conforming document MUST be +secured by at least one securing mechanism as described in Section +4.12 Securing Mechanisms. +

+ +

+A conforming issuer implementation produces +conforming documents, MUST include all required properties in the +conforming documents it produces, and MUST secure the conforming documents it produces using a securing mechanism described in Section +4.12 Securing Mechanisms. +

+ +

+A conforming verifier implementation +consumes conforming documents, MUST perform verification on a +conforming document as described in Section +4.12 Securing Mechanisms, MUST check that each +required property satisfies the normative requirements for that property, and +MUST produce errors when non-conforming documents are detected. +

+ +

+This specification includes both required and optional properties. Optional +properties MAY be ignored by conforming issuer implementations and +conforming verifier implementations. +

+ +

+This document also contains examples that contain characters that are invalid +JSON, such as inline comments (//) and the use of ellipsis +(...) to denote information that adds little value to the example. +Implementers are cautioned to remove this content if they desire to use the +information as a valid document. +

+ +
Note: Human-readable texts in English are illustrative

+Examples provided throughout this document include descriptive properties, such as +name and description, with values in English to simplify the concepts in each +example of the specification. These examples do not necessarily reflect the data +structures needed for international use, described in more detail in +Section 11. Internationalization Considerations. +

+ +
+ +
+ +

2. Terminology

+ + +

+The following terms are used to describe concepts in this specification. +

+ +
+
claim
+
+An assertion made about a subject. +
+
credential
+
+A set of one or more claims made by an issuer. The claims +in a credential can be about different subjects. The definition of +credential used in this specification differs from, +NIST's definitions of +credential. +
+
decentralized identifier
+
+A portable URL-based identifier, also known as a DID, +is associated with an entity. These identifiers are most often used in a +verifiable credential and are associated with subjects such that a +verifiable credential can be easily ported from one +credential repository to another without reissuing the credential. +An example of a DID is did:example:123456abcdef. See the +Decentralized Identifiers (DIDs) v1.0 specification for further details. +
+ + +
default graph
+
+The graph containing all claims that are not explicitly part of +a named graph. +
+ + +
entity
+
+Anything that can be referenced in statements as an abstract or concrete noun. +Entities include but are not limited to people, organizations, physical things, +documents, abstract concepts, fictional characters, and arbitrary text. Any +entity might perform roles in the ecosystem, if it can do so. Note +that some entities fundamentally cannot take actions, for example, the string "abc" +cannot issue credentials. +
+
graph
+
+A set of claims, forming a network of information composed of subjects +and their relationship to other subjects or data. Each claim is +part of a graph; either explicit in the case of named graphs, or +implicit for the default graph. +
+
holder
+
+A role an entity might perform by possessing one or more +verifiable credentials and generating verifiable presentations +from them. A holder is often, but not always, a subject of the +verifiable credentials they are holding. Holders store their +credentials in credential repositories. +
+
issuer
+
+A role an entity can perform by asserting claims about one or +more subjects, creating a verifiable credential from these +claims, and transmitting the verifiable credential to a +holder. +
+
named graph
+
+A graph associated with specific properties, such as +verifiableCredential. These properties +result in separate graphs that contain all claims defined in the +corresponding JSON objects. +
+
presentation
+
+Data derived from one or more verifiable credentials issued by one or +more issuers that is shared with a specific verifier. +
+
credential repository
+
+Software, such as a file system, storage vault, or personal verifiable credential wallet, that stores and protects access to holders' +verifiable credentials. +
+
selective disclosure
+
+The ability of a holder to make fine-grained decisions about what +information to share. +
+
unlinkable disclosure
+
+A type of selective disclosure where presentations cannot be correlated +between verifiers. +
+
subject
+
+A thing about which claims are made. +
+ + +
validation
+
+The assurance that a claim from a specific issuer satisfies the business +requirements of a verifier for a particular use. This specification defines +how verifiers verify verifiable credentials and verifiable presentations. It also specifies that verifiers validate claims in +verifiable credentials before relying on them. However, the means for such +validation vary widely and are outside the scope of this specification. +Verifiers trust certain issuers for certain claims and apply their own +rules to determine which claims in which credentials are suitable for use by +their systems. +
+
verifiable credential
+
+A tamper-evident credential whose authorship can be cryptographically +verified. Verifiable credentials can be used to build +verifiable presentations, which can also be cryptographically verifiable. +
+
verifiable data registry
+
+A role a system might perform by mediating the creation and verification +of identifiers, verification material, and other relevant data, such as +verifiable credential schemas, revocation registries, +and so on, which might require using verifiable credentials. Some +configurations might require correlatable identifiers for subjects. Some +registries, such as ones for UUIDs and verification material, might act +as namespaces for identifiers. +
+
verifiable presentation
+
+A tamper-evident presentation of information encoded in such a way that +authorship of the data can be trusted after a process of cryptographic +verification. Certain types of verifiable presentations might contain data that +is synthesized from, but does not contain, the original verifiable credentials +(for example, zero-knowledge proofs). +
+
verification
+
+The evaluation of whether a verifiable credential or verifiable presentation is an authentic and current statement of the issuer or presenter, +respectively. This includes checking that the credential or presentation +conforms to the specification, the securing mechanism is satisfied, and, if +present, the status check succeeds. Verification of a credential does not imply +evaluation of the truth of claims encoded in the credential. +
+
verifier
+
+A role an entity performs by receiving one or more +verifiable credentials, optionally inside a +verifiable presentation for processing. Other specifications might refer +to this concept as a relying party. +
+
verification material
+
+Information that is used to verify the security of cryptographically +protected information. For example, a cryptographic public key is used to verify +a digital signature associated with a verifiable credential. +
+
URL
+
+A Uniform Resource Locator, as defined by the URL Standard. URLs can be +dereferenced to result in a resource, such as a document. The rules +for dereferencing, or fetching, a URL are defined by the URL scheme. +This specification does not use the term URI or IRI because those terms have +been deemed to be confusing to Web developers. +
+
+
+ +

3. Core Data Model

This section is non-normative.

+ + +

+The following sections outline core data model concepts, such as claims, +credentials, presentations, verifiable credentials, and +verifiable presentations, which form the foundation of this +specification. +

+ +
Note: The difference between a credential and a verifiable credential

+Readers might note that some concepts described in this section, such as +credentials and presentations, do not have media types defined by +this specification. However, the concepts of a verifiable credential or a +verifiable presentation are defined as conforming documents and +have associated media types. The concrete difference between these concepts +— between credential and presentation vs. verifiable credential and verifiable presentation — is simply the fact +that the "verifiable" objects are secured in a cryptographic +way, and the others are not. For more details, see Section +4.12 Securing Mechanisms. +

+ +

3.1 Claims

This section is non-normative.

+ + +

+A claim is a statement about a subject. A subject is a +thing about which claims can be made. Claims are expressed using +subject- +property-value relationships. +

+ +
+ subject has a property which + has a value +
Figure 2 +The basic structure of a claim. +
+
+ +

+The data model for claims, illustrated in Figure 2 +above, is powerful and can be used to express a large variety of statements. For +example, whether someone graduated from a particular university can be expressed +as shown in Figure 3 below. +

+ +
+ Pat has an alumniOf + property whose value is Example University +
Figure 3 +A basic claim expressing that Pat is an alum of "Example University". +
+
+ +

+Individual claims can be merged together to express a graph of +information about a subject. The example shown in +Figure 4 below extends the previous claim by +adding the claims that Pat knows Sam and that Sam is employed as a +professor. +

+ +
+ extends previous + diagram with another property called knows whose value is + Sam, and Sam has a property jobTitle whose value is Professor +
Figure 4 +Multiple claims can be combined to express a graph of information. +
+
+ +

+To this point, the concepts of a claim and a graph of information +are introduced. More information is expected to be added to the graph in order +to be able to trust claims, more information is +expected to be added to the graph. +

+
+ +

3.2 Credentials

This section is non-normative.

+ + +

+A credential is a set of one or more claims made by the same entity. +Credentials might also include an identifier and metadata to describe +properties of the credential, such as the issuer, the validity date and +time period, a representative image, verification material, status +information, and so on. A +verifiable credential is a set of tamper-evident claims and metadata +that cryptographically prove who issued it. Examples of verifiable credentials include, but are not limited to, digital employee identification +cards, digital driver's licenses, and digital educational certificates. +

+ +
+ a Verifiable + Credential contains Credential Metadata, Claim(s), and + Proof(s) +
Figure 5 +Basic components of a verifiable credential. +
+
+ +

+Figure 5 above shows the basic components of a +verifiable credential, but abstracts the details about how claims +are organized into information graphs, which are then organized into +verifiable credentials. +

+

+Figure 6 below shows a more complete depiction of a +verifiable credential using an embedded proof based on +Verifiable Credential Data Integrity 1.0. It is composed of at least two information graphs. +The first of these information graphs, the verifiable credential graph +(the default graph), expresses the verifiable credential +itself through credential metadata and other claims. The second +information graph, referred to by the proof property, is the +proof graph of the verifiable credential and is a separate +named graph. The proof graph expresses the digital proof, which, in this +case, is a digital signature. Readers who are interested in the need for +multiple information graphs can refer to Section +5.12 Verifiable Credential Graphs. +

+ +
+ Diagram with a collections of +claims for a 'verifiable credential graph' on top +connected via a proof property (or predicate) to a 'verifiable credential proof +graph' on the bottom. The claims for a verifiable credential include 'Credential +123' as a subject with 4 properties: 'type' of value ExampleAlumniCredential, +'issuer' of Example University, 'validFrom' of 2010-01-01T19:23:24Z, and +credentialSubject of Pat, who also has an alumniOf property with value of +Example University. The verifiable credential proof graph has an object +'Signature 456' subject with 5 properties: 'type' of DataIntegrityProof, +'verificationMethod' of Example University Public Key 7, 'created' of +2017-06-18T21:19:10Z, a 'nonce' of 34dj239dsj328, and 'proofValue' of +'zBavE110…3JT2pq'. The verifiable credential graph is also annotated with the +parenthetical remark '(the default graph)', the verifiable credential proof +graph is annotated with the parenthetical remark '(a named graph)'. +
Figure 6 +Information graphs associated with a basic verifiable credential, using an embedded proof +based on Verifiable Credential Data Integrity 1.0 [VC-DATA-INTEGRITY]. +
+
+ +

+Figure 7 below shows the same verifiable credential +as Figure 6, but secured using JOSE [VC-JOSE-COSE]. The +payload contains a single information graph, which is the verifiable credential graph containing credential metadata and other claims. +

+ +
+ Diagram with, on the left, a box, labeled as +'SD-JWT (Decoded)', and with three textual labels stacked vertically, +namely 'Header', 'Payload', and 'Signature'. The 'Header' label is +connected, with an arrow, to a separate rectangle on the right hand +side containing six text fields: 'kid: aB8J-_Z', 'alg: ES384', and +'cty: vc', 'iss: https://example.com', 'iat: 1704690029', and 'typ: +vc+sd-jwt'. The 'Payload' label on the left side is connected, +with an arrow, to a separate rectangle, containing a single graph. The +rectangle has a label: 'verifiable credential graph (serialized in +JSON)' The claims in the graph include 'Credential 123' as a subject +with 4 properties: 'type' with value 'ExampleAlumniCredential', +'issuer' with value 'Example University', 'validFrom' with value +'2010-01-01T19:23:24Z', and 'credentialSubject' with value 'Pat', who +also has an 'alumniOf' property with value 'Example University'. +Finally, the 'Signature' label on the left side is connected, with an +arrow, to a separate rectangle, containing a single text field: +'DtEhU3ljbEg8L38VWAfUA...'. + +
Figure 7 + Information graphs associated with a basic verifiable credential, + using an enveloping proof based on Securing Verifiable Credentials using JOSE and COSE + [VC-JOSE-COSE]. +
+
+ +
+ +

3.3 Presentations

This section is non-normative.

+ + +

+Enhancing privacy is a key design feature of this specification. Therefore, it +is crucial for entities using this technology to express only +the portions of their personas that are appropriate for given situations. The +expression of a subset of one's persona is called a verifiable presentation. +Examples of different personas include a person's professional persona, +online gaming persona, family persona, or incognito persona. +

+ +

+A verifiable presentation is created by a +holder, can express data from multiple verifiable credentials, and can +contain arbitrary additional data. They are used to present claims to a +verifier. It is also possible to present verifiable credentials +directly. +

+ +

+The data in a presentation is often about the same subject but might +have been issued by multiple issuers. The aggregation of this information +expresses an aspect of a person, organization, or entity. +

+ +
+ A Verifiable + Presentation contains Presentation Metadata, Verifiable + Credential(s), and Proof(s) +
Figure 8 +Basic components of a verifiable presentation. +
+
+ +

+Figure 8 above shows the components of a +verifiable presentation but abstracts the details about how +verifiable credentials are organized into information graphs, +which are then organized into verifiable presentations. +

+

+Figure 9 below shows a more complete depiction of a +verifiable presentation using an embedded proof +based on Verifiable Credential Data Integrity 1.0. +It is composed of at least four information graphs. +The first of these information graphs, the verifiable presentation graph +(the default graph), expresses the verifiable presentation +itself through presentation metadata. +The verifiable presentation refers, via the verifiableCredential property, +to a verifiable credential. +This credential is a self-contained verifiable credential graph +containing credential metadata and other claims. This credential +refers to a verifiable credential proof graph via a proof property, +expressing the proof (usually a digital signature) of the credential. +This verifiable credential graph and its linked proof graph constitute +the second and third information graphs, respectively, and each is a +separate named graph. The presentation also refers, via the proof +property, to the presentation's proof graph, the fourth information +graph (another named graph). This presentation proof graph +represents the digital signature of the verifiable presentation graph, +the verifiable credential graph, and the proof graph linked from the +verifiable credential graph. +

+ +
+ Diagram with a +'verifiable presentation graph' on top connected via a 'proof' to +a 'verifiable presentation proof graph on the bottom. The verifiable +presentation graph has and object 'Presentation ABC' with 3 properties: 'type' +of value VerifiablePresentation, 'termsOfUse' of value 'Do Not Archive'. The +graph is annotated with the parenthetical remark '(the default graph)'. This +graph is connected, through 'verifiableCredential', to the part of the figure +which is identical to Figure 6, except that the verifiable credential graph is +annotated to be a named graph instead of a default graph. +The verifiable presentation proof graph has an object with 'Signature 8910' +with 5 properties: 'type' with value 'DataIntegrityProof'; 'verificationMethod' +with value 'Example Presenter Public Key 11'; 'created' with value +'2018-01-15T12:43:56Z'; 'nonce' with value 'd28348djsj3239'; and 'proofValue' +with value 'zp2KaZ...8Fj3K='. This graph is annotated with the parenthetical +remark '(a named graph)' +
Figure 9 +Information graphs associated with a basic verifiable presentation that +uses an embedded proof based on Verifiable Credential Data Integrity 1.0. +
+
+ +

+Figure 10 below shows the same verifiable presentation as Figure 9, but using an enveloping proof based on [VC-JOSE-COSE]. The payload contains only two information +graphs: the verifiable presentation graph expressing the verifiable presentation through presentation metadata and the corresponding +verifiable credential graph, referred to by the verifiableCredential +property. The verifiable credential graph contains a single +EnvelopedVerifiableCredential +instance referring, via a data: URL [RFC2397], to the verifiable credential +secured via an enveloping proof shown in Figure 7. +

+ +
+ Diagram with, on the left, a box, labeled as +'JWT (Decoded)', and with three textual labels stacked vertically, +namely 'Header', 'Payload', and 'Signature'. The 'Header' label is +connected, with an arrow, to a separate rectangle on the right hand +side containing six text fields: 'kid: aB8J-_Z', 'alg: ES384', and +'cty: vc', 'iss: https://example.com', 'iat: 1704690029', and 'typ: +vp+sd-jwt'. The 'Payload' label of the left side is connected, +with an arrow, to a separate rectangle, consisting of two related +graphs (stacked vertically) connected by a an arrow labeled +'verifiableCredential'. The two graphs have each a label 'verifiable +presentation graph (serialized in JSON)' and 'verifiable credential +graph (serialized in JSON)', respectively. The top graph in the +rectangle has and object 'Presentation ABC' with 3 properties: 'type' +of value VerifiablePresentation, 'termsOfUse' of value 'Do Not +Archive'. The bottom graph includes +'data:application/vc+sd-jwt,QzVjV...RMjU' as a subject with a +single property: 'type' of value `EnvelopedVerifiableCredential`. +Finally, the 'Signature' label on the left side is connected, with an +arrow, to a separate rectangle, containing a single text field: +'XaOOh4ljklxH7L99RTVSfOl...'. + +
Figure 10 +Information graphs associated with a basic verifiable presentation that is +using an enveloping proof based on Securing Verifiable Credentials using JOSE and COSE. The data: URL +refers to the verifiable credential shown in +Figure 7. +
+
+ + +
Note: Presentations can contain multiple verifiable credentials

+It is possible to have a presentation, such as a collection of university +credentials, which draws on multiple credentials about different subjects +that are often, but not required to be, related. This is achieved by using the +verifiableCredential property to refer to multiple verifiable credentials. +See Appendix D. Additional Diagrams for Verifiable Presentations for more +details. +

+ +
Note: Presentations can be presented by issuers and verifiers

+As described in Section 1.2 Ecosystem Overview, an entity can take +on one or more roles as they enter a particular credential exchange. +While a holder is typically expected to generate presentations, an +issuer or verifier might generate a presentation to identify itself +to a holder. This might occur if the holder needs higher assurance +from the issuer or verifier before handing over sensitive information +as part of a verifiable presentation. +

+ +
+ +
+ +

4. Basic Concepts

+ + +

+This section introduces some basic concepts for the specification in +preparation for Section 5. Advanced Concepts later in the +document. +

+ +

4.1 Getting Started

This section is non-normative.

+ + +

+This specification is designed to ease the prototyping of new types of +verifiable credentials. Developers can copy the template below and paste it +into common verifiable credential tooling to start issuing, holding, and +verifying prototype credentials. +

+ +

+A developer will change MyPrototypeCredential below to the type of credential +they would like to create. Since verifiable credentials talk about subjects, +each property-value pair in the credentialSubject object expresses a +particular property of the credential subject. Once a developer has added a +number of these property-value combinations, the modified object can be sent to +a conforming issuer implementation, and a verifiable credential will be +created for the developer. From a prototyping standpoint, that is all a +developer needs to do. +

+ +
+
+ Example 1: A template for creating prototype verifiable credentials + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "type": ["VerifiableCredential", "MyPrototypeCredential"],
+  "credentialSubject": {
+    "mySubjectProperty": "mySubjectValue"
+  }
+}
+
+ +

+After stabilizing all credential properties, developers are advised to generate +and publish vocabulary and context files at stable URLs to facilitate +interoperability with other developers. The +https://www.w3.org/ns/credentials/examples/v2 URL above +would then be replaced with the URL of a use-case-specific context. This +process is covered in Section 5.2 Extensibility. Alternatively, +developers can reuse existing vocabulary and context files that happen to fit +their use case. They can explore the Verifiable Credential Extensions +for reusable resources. +

+ +
+ +

4.2 Verifiable Credentials

+ + +

+Verifiable credentials are used to express properties of one or more +subjects as well as properties of the credential itself. The following +properties are defined in this specification for a verifiable credential: +

+ +
+
@context
+
+Defined in Section 4.3 Contexts. +
+
id
+
+Defined in Section 4.4 Identifiers. +
+
type
+
+Defined in Section 4.5 Types. +
+
name
+
+Defined in Section 4.6 Names and Descriptions. +
+
description
+
+Defined in Section 4.6 Names and Descriptions. +
+
issuer
+
+Defined in Section 4.7 Issuer. +
+
credentialSubject
+
+Defined in Section 4.8 Credential Subject. +
+
validFrom
+
+Defined in Section 4.9 Validity Period. +
+
validUntil
+
+Defined in Section 4.9 Validity Period. +
+
status
+
+Defined in Section 4.10 Status. +
+
credentialSchema
+
+Defined in Section 4.11 Data Schemas. +
+
refreshService
+
+Defined in Section 5.4 Refreshing. +
+
termsOfUse
+
+Defined in Section 5.5 Terms of Use. +
+
evidence
+
+Defined in Section 5.6 Evidence. +
+
+ +

+A verifiable credential can be extended to have additional properties +through the extension mechanism defined in Section 5.2 Extensibility. +

+ +
+ +

4.3 Contexts

+ + +

+When two software systems need to exchange data, they need to use terminology +that both systems understand. Consider how two people communicate effectively +by using the same language, where the words they use, such as "name" and +"website," mean the same thing to each individual. This is sometimes referred +to as the context of a conversation. This specification uses a similar +concept to achieve similar results for software systems by establishing a +context in which to communicate. +

+

+Software systems that process verifiable credentials and verifiable presentations identify terminology by using URLs for each term. However, +those URLs can be long and not very human-friendly, while short-form, +human-friendly aliases can be more helpful. This specification uses the +@context property to map short-form aliases to the URLs. +

+

+Verifiable credentials and verifiable presentations MUST include a +@context property. Application developers MUST understand every JSON-LD +context used by their application, at least to the extent that it affects the +meaning of the terms used by their application. One mechanism for +doing so is described in the Section on +Validating Contexts in +the Verifiable Credential Data Integrity 1.0 specification. Other specifications that build +upon this specification MAY require that JSON-LD contexts be integrity protected +by using the relatedResource feature described in Section +5.3 Integrity of Related Resources or any effectively equivalent mechanism. +

+ +
+
@context
+
+The value of the @context property MUST be an ordered set +where the first item is a URL with the value +https://www.w3.org/ns/credentials/v2. +Subsequent items in the ordered set MUST be composed of any combination of +URLs and objects, where each is processable as a +JSON-LD Context. +
+
+ +
+
+ Example 2: Use of the @context property + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/58473",
+  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
+  "issuer": "did:example:2g55q912ec3476eba2l9812ecbfe",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "alumniOf": {
+      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
+      "name": "Example University"
+    }
+  }
+}
+
+ +

+The example above uses the base context URL +(https://www.w3.org/ns/credentials/v2) to establish that the data exchange is +about a verifiable credential. This concept is further detailed in +Section 5.2 Extensibility. The data available at +https://www.w3.org/ns/credentials/v2 is a permanently cacheable static +document with instructions for processing it provided in Appendix +B.1 Base Context. The associated human-readable vocabulary document for the +Verifiable Credentials Data Model is available at +https://www.w3.org/2018/credentials/. +

+ +

+The second URL (https://www.w3.org/ns/credentials/examples/v2) is used to +demonstrate examples. Implementations are expected to not use +this URL for any other purpose, such as in pilot or production systems. +

+ +
Note: See JSON-LD for more information about @context.

+The @context property is further elaborated upon in +Section 3.1: The Context +of the JSON-LD 1.1 specification. +

+ +
+ +

4.4 Identifiers

+ + +

+When expressing statements about a specific thing, such as a person, product, or +organization, using a globally unique identifier for that thing can be useful. +Globally unique identifiers enable others to express statements +about the same thing. This specification defines the optional id +property for such identifiers. The id property +allows for expressing statements about specific things in the +verifiable credential and is set by an issuer when expressing +objects in a verifiable credential or a holder when expressing +objects in a verifiable presentation. The id property expresses an +identifier that others are expected to use when expressing statements about the +specific thing identified by that identifier. Example id values +include UUIDs (urn:uuid:0c07c1ce-57cb-41af-bef2-1b932b986873), HTTP URLs +(https://id.example/things#123), and DIDs (did:example:1234abcd). +

+ +
Note: Identifiers of any kind increase correlatability

+Developers are reminded that identifiers might be harmful +when pseudonymity is required. When considering such scenarios, developers are +encouraged to read Section 8.4 Identifier-Based Correlation carefully +There are also other types of access and correlation mechanisms documented +in Section 8. Privacy Considerations that create privacy concerns. +Where privacy is a vital consideration, it is permissible to omit the +id property. Some use cases do not need or explicitly need to omit, +the id property. Similarly, special attention is to be given to the choice +between publicly resolvable URLs and other forms of identifiers. Publicly +resolvable URLs can facilitate ease of verification and interoperability, yet +they might also inadvertently grant access to potentially sensitive information +if not used judiciously. +

+
+
id
+
+The id property is OPTIONAL. If present, id property's value +MUST be a single URL, which MAY be dereferenceable. It is +RECOMMENDED that the URL in the id be one which, if dereferenceable, results +in a document containing machine-readable information about the id. +
+
+ +
+
+ Example 3: Use of the id property +
+ 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaejVxRHiNEeErsTWAZkLcwGTeWFjUUoeXqTuX
+eBcdSxd5V",
+    "cryptosuite": "ecdsa-rdfc-2019",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "zCjQGZXHzYDbMMeKqrj31S1L7rn4QdV2FsdLaCZ9Wxmwx2EpGM6qXMQE
+uBSHksvCkG9K3U3j3d2jpr1G9QRLSGV6"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:z6MktYiRGUrwMhySggEFsb7GaqwmnYxPL2FQ4bXY
+bUPedzyE",
+    "cryptosuite": "eddsa-rdfc-2022",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z3xHiaoVmYdyNtDdGojgC2tsVGVMFy2qz1EgvdqD8QubtLLgQnZesygD
+7gXxZEek19Zt56iKZzwAGn9hubVm8ywJ"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaefuEErdxr11EqxbUY6Kqyg1WFDyVxDviNgTn
+HheVQEtMd",
+    "cryptosuite": "ecdsa-sd-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0AhVhAJztAQlZCuxIq76wkSYPU9raDfPweLONs-gKX9b6Dipwl6kD
+5AfMB5a7uNd1ilVc_YIpxUGYoTRz57a_QXPj4qVgjgCQDjvyqpFscSBok74meLCKQZ49_vFuT7j
+lK3CqMX34wIeJYIOkpM16CnPS59klqRtocXkz4pZb3PfWlJz45huC_AabzhVhA37976uHQ_ehPB
+gjWV1vCKRu01lFqLlUyCM5XUZ3qbhrz-NesfJpGCy8Tn_Ie13O8Jsv2BJKuuAkl-vbbmzTzl1hA
+qZiM5vNzfn5ZzVXjj1cd6bQR53M45xWKWDXiPVrd1YAYl2Zd_QJiSNshQP0ZrX3cJadr4egqJhW
+l5upBclOvLlhA8yzOd3YhLmCRIKb9zfOpTx9uuxeXhcfZSquFTocc6IaiNmJQZyg3dVYrZcyZxZ
+I7hppR4FUUi44ogc-BNEm7aFhAFLT9rgy-CF4XHCfPHl7r_5vKcL_3mwCT6iUy5buPuBXPh_4wg
+FA0bGud3_HBmcZX6mhMMTBOmYGMXnRVfCKtNFhAx9o6a-qvsvt3kGbERIuPiUN-Bu-5zO30Us_R
+mUsJNmyV57nMG81E0eDkHwNDuLh1lN8sfxC9CbflgjzVps1MhYFnL2lzc3Vlcg"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "verificationMethod": "did:key:zUC78HfmP56g14bJAYnJ11eYYdxL5oZL5cygjdjU
+ZYYtQ2Fy8bWQpT4cjy2pnraoXRidkJX84LEmzHQa1GzxnCpZwGRzZj4VampB7QyNWb8hXUBwqUA
+mh8PXati5E2QkviTpgzR",
+    "cryptosuite": "bbs-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0ChVhQlEqaKQHsWrlNW4X5E3OGWhXlCbcPooZshfjj9VpVO90UWBl
+YmzGFBxcfXdYqCS2SHHkI-ykMuLG4cPxOU7lkn4csFY2nV-v2VHc5uM_n3gRYQMP43Uz2_6ZROr
+tDIN3VDGofNQzGXJkDEdiK-_jrt6ZMS1r7HKFDPyyrvPGqNF8bjgNELvoomOjpbD9JEvaGI1pYY
+JVb1Iuc8U5sJ7Y-R2-kazKqPIAU0h0cDtIgnqLQMDWY0XJbO0ZGXDCt_w1vJrys9A31LmjPonEZ
+zliSnHCKmnu30eOgsaNuglz726TLGvw7kEmLryKBj9RFgvjlXehI1lggqUB6g0-uQZTEc4E6UO5
+Myaf9JtiFfxPQJIZ1pRJavamBZy9pc3N1ZXI"
+  }
+}
+
+
+Protected Headers +
{
+  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
+  "alg": "ES256"
+}
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
+
+application/vc-ld+jwt +
+
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiZGVncmVlIjp7InR5cGUiOiJFeGFtcGxlQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyJ9fX0 +.FcTZt4flXRiLeIlox6nYwX3kFWaI8AgaxYwDhKVuJLJd00hLXvJ9efEImaJE6_ZdqxoIsjPoWq-uHomdAgtILQ +
+
+
+
+
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
+
+application/cbor-diagnostic +
+
/ cose-sign1 / 18([
+  / protected / << {
+    / alg / 1 : -35 / ES384 /
+  } >>,
+  / unprotected / {
+  },
+  / payload / h'7b224063...227d7d7d',
+  / signature / h'de689cff...f6d45eb3'
+])
+
+application/vc-ld+cose +
+d28444a1013822a05901be7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f353635303439222c2276616c696446726f6d223a22323031302d30312d30315430303a30303a30305a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d5840de689cfffc3ddd947931cef596ebecb896485111f16947a76b19462def6b50b0c857aae75d3fc6f6e44f7c2153ce1b938c09a471bb88fd95812da589f6d45eb3 +
+
+
+ +
+ + + +
    +
  • + +
    • +
  • + +
    • +
  • + +
    • +
+
+ +
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJfc2RfYWxnIjoic2hhLTI1NiIsIkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzU2NTA0OSIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMDA6MDA6MDBaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiZGVncmVlIjp7Im5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIiwiX3NkIjpbIlA1Y0FzRTB0bmNHWmVnSW1XanFwSXpMQUg3ZEFNYUNSX1gxd1F4UmpPZWsiXX0sIl9zZCI6WyJPMzRSc29RNVZ1eDdMblJuUGNCU010ZnhwSEFaY3k2TXVOZ2ZRaGpwV0tFIl19LCJfc2QiOlsiMmJvcjFzSEtFRFF6Mjk2czJDZ0NxMzB1SXZTaVI0M2Q4TEZmbDRETmFOcyIsIkxLMk9BNGYyWlZfX3B0VEM4RGJaNjgwaG1ZV2czeUJvdktQYmR2dWFtN0kiXX0 +.ekcc2fEdNxgASjpVRilp2CMIh9s1z1piAa2u3ClEoi7qfUVH3fHuUkijqx078ChkjADNNeqURj1N_gSuVCSqaQ +~WyJoVG1Rc3NGVElWTnQzS1NpWTdpbk9nIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd~WyJ2dG41WERHWHdaanotREVjLS1fQTZ3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d~WyJJRFVxU0tLdktQTG1XeW1BM25IZXFRIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd~WyIyRjh4Q1llVEV6WkRobVpWQXd3T1pBIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 +
+
+
+ 
{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES256"
}
+ 
{
  "_sd_alg": "sha-256",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "issuer": "https://university.example/issuers/565049",
  "validFrom": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "degree": {
      "name": "Bachelor of Science and Arts",
      "_sd": [
        "P5cAsE0tncGZegImWjqpIzLAH7dAMaCR_X1wQxRjOek"
      ]
    },
    "_sd": [
      "O34RsoQ5Vux7LnRnPcBSMtfxpHAZcy6MuNgfQhjpWKE"
    ]
  },
  "_sd": [
    "2bor1sHKEDQz296s2CgCq30uIvSiR43d8LFfl4DNaNs",
    "LK2OA4f2ZV__ptTC8DbZ680hmYWg3yBovKPbdvuam7I"
  ]
}
+
+
+
+
+

Claim: id

+

SHA-256 Hash: LK2OA4f2ZV__ptTC8DbZ680hmYWg3yBovKPbdvuam7I

+

Disclosure(s): WyJoVG1Rc3NGVElWTnQzS1NpWTdpbk9nIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd

+

Contents: [
  "hTmQssFTIVNt3KSiY7inOg",
  "id",
  "http://university.example/credentials/3732"
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: 2bor1sHKEDQz296s2CgCq30uIvSiR43d8LFfl4DNaNs

+

Disclosure(s): WyJ2dG41WERHWHdaanotREVjLS1fQTZ3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d

+

Contents: [
  "vtn5XDGXwZjz-DEc--_A6w",
  "type",
  [
    "VerifiableCredential",
    "ExampleDegreeCredential"
  ]
]

+
+ + +
+

Claim: id

+

SHA-256 Hash: O34RsoQ5Vux7LnRnPcBSMtfxpHAZcy6MuNgfQhjpWKE

+

Disclosure(s): WyJJRFVxU0tLdktQTG1XeW1BM25IZXFRIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd

+

Contents: [
  "IDUqSKKvKPLmWymA3nHeqQ",
  "id",
  "did:example:ebfeb1f712ebc6f1c276e12ec21"
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: P5cAsE0tncGZegImWjqpIzLAH7dAMaCR_X1wQxRjOek

+

Disclosure(s): WyIyRjh4Q1llVEV6WkRobVpWQXd3T1pBIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0

+

Contents: [
  "2F8xCYeTEzZDhmZVAwwOZA",
  "type",
  "ExampleBachelorDegree"
]

+
+
+
+
+ +
+ +

+The example above uses two types of identifiers. The first identifier is for +the verifiable credential and uses an HTTP-based URL. The second +identifier is for the subject of the verifiable credential (the +thing the claims are about) and uses a decentralized identifier, +also known as a DID. +

+ +
Note: Decentralized Identifiers are optional

+DIDs are a type of identifier which are not necessary for verifiable credentials to be useful. Specifically, verifiable credentials do not +depend on DIDs and DIDs do not depend on verifiable credentials. +However, many verifiable credentials will use DIDs, and software +libraries implementing this specification will need to resolve DIDs. +DID-based URLs are used to express identifiers associated with +subjects, issuers, holders, credential status lists, cryptographic +keys, and other machine-readable information associated with a verifiable credential. +

+
+ +

4.5 Types

+ + +

+Software systems that process the kinds of objects specified in this document +use type information to determine whether or not a provided +verifiable credential or verifiable presentation is appropriate +for the intended use-case. This specification defines a type +property for expressing object type information. This type +information can be used during validation processes, as described in Appendix +A. Validation. +

+ +

+Verifiable credentials and verifiable presentations MUST contain a +type property with an associated value. +

+ +
+
type
+
+The value of the type property MUST be one or more +terms and +absolute URL strings. If more than +one value is provided, the order does not matter. +
+
+ +
+
+ Example 4: Use of the type property +
+ 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaejVxRHiNEeErsTWAZkLcwGTeWFjUUoeXqTuX
+eBcdSxd5V",
+    "cryptosuite": "ecdsa-rdfc-2019",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z4npP1737DytqW1ahFpqpPf7GQbyUT8SVVMdyGVQeMXS4H1S7NBCEJXZ
+minZCrWGN33dEQscrL1YCmSFgBiDYiXyv"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:z6MktYiRGUrwMhySggEFsb7GaqwmnYxPL2FQ4bXY
+bUPedzyE",
+    "cryptosuite": "eddsa-rdfc-2022",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z3xHiaoVmYdyNtDdGojgC2tsVGVMFy2qz1EgvdqD8QubtLLgQnZesygD
+7gXxZEek19Zt56iKZzwAGn9hubVm8ywJ"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaefuEErdxr11EqxbUY6Kqyg1WFDyVxDviNgTn
+HheVQEtMd",
+    "cryptosuite": "ecdsa-sd-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0AhVhAQbkTihzbdlOntvw9N__-ockXRES4iP9ztueJOC4JbS9p7dx
+I7n-zVN0P3s1ME2MotXzPBngHq2UMSL-x6TtRr1gjgCQCpjwhvUkooOdObceM9ou6PQrZJvTNgV
+kDZlvWn1MhzZFYIDGe4jKSHd6H-X5T-DA0cN2rsGnSZ3RfOK3bTb7AbBcDhVhAfN_MKHGI46mUi
+QMSKClOA0niXcFvnqknzfrzIbzmVkF4zI4B-uIIR1mcSp1PJ--RVu4Il0QxwLzet86KvdWsmVhA
+1NdmadhFFFX7Pq-usnhfKrGVbPlydQLvh1mGLu29luhOru7ijNGmBbEsCSF_gZzruL6sxsglVf4
+zRCHJ7WERdlhAB9TjLzFZgjX5A37WyJib7a89TBLJP4tXSHPwqh9YzQQ6Dde992Z07BVHROgh39
+amMCEJC8SKVyxsCV2_meI55FhAPzwy_ba3P31Mw2YxCtTjpHNrrGTHrgn9o8UIC8HK6oJHtCGl1
+IXR3Bi8K9jvV77anfYCpv3SX1E1VNdbevCKFVhAk7JLVcfCpmyU57Y08ACJRZAvhCoizSORrRNG
+mfnk5jht9IFcKqmlSxHnBA4ONjK1C8SQHdMsxWpJ53homZn8wYFnL2lzc3Vlcg"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "verificationMethod": "did:key:zUC78HfmP56g14bJAYnJ11eYYdxL5oZL5cygjdjU
+ZYYtQ2Fy8bWQpT4cjy2pnraoXRidkJX84LEmzHQa1GzxnCpZwGRzZj4VampB7QyNWb8hXUBwqUA
+mh8PXati5E2QkviTpgzR",
+    "cryptosuite": "bbs-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0ChVhQlEqaKQHsWrlNW4X5E3OGWhXlCbcPooZshfjj9VpVO90UWBl
+YmzGFBxcfXdYqCS2SHHkI-ykMuLG4cPxOU7lkn4csFY2nV-v2VHc5uM_n3gRYQMP43Uz2_6ZROr
+tDIN3VDGofNQzGXJkDEdiK-_jrt6ZMS1r7HKFDPyyrvPGqNF8bjgNELvoomOjpbD9JEvaGI1pYY
+JVb1Iuc8U5sJ7Y-R2-kazKqPIAU0h0cDtIgnqLQMDWY0XJbO0ZGXDCt_w1vJrys9A31LmjPonEZ
+zliSnHCKmnu30eOgsaNuglz726TLGvw7kEmLryKBj9RFgvjlXehI1lggww3FXcHnBbzgtv_xoeq
+d8aS-QugfCDbcGpd9xcKZDAaBZy9pc3N1ZXI"
+  }
+}
+
+
+Protected Headers +
{
+  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
+  "alg": "ES256"
+}
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
+
+application/vc-ld+jwt +
+
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiZGVncmVlIjp7InR5cGUiOiJFeGFtcGxlQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyJ9fX0 +.kA9a56-2Gc8iNYvlx7qBrVmBjA5ueSSIT6Gwj-RK3UlTKaWPV2xiW7p940ekj3c6LGGwG0Dxh7VxTh6aPXCJNQ +
+
+
+
+
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
+
+application/cbor-diagnostic +
+
/ cose-sign1 / 18([
+  / protected / << {
+    / alg / 1 : -35 / ES384 /
+  } >>,
+  / unprotected / {
+  },
+  / payload / h'7b224063...227d7d7d',
+  / signature / h'16434f55...e61f9cf8'
+])
+
+application/vc-ld+cose +
+d28444a1013822a05901be7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f353635303439222c2276616c696446726f6d223a22323031302d30312d30315430303a30303a30305a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d584016434f55969aa8b71af3fe41524c33239dc21f25b54f53d8c461891266bdecaae8f2f4919c6ae5b2df93a486eb31b85ca673a868c12df4abfcac1b2ee61f9cf8 +
+
+
+ +
+ + + +
    +
  • + +
    • +
  • + +
    • +
  • + +
    • +
+
+ +
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJfc2RfYWxnIjoic2hhLTI1NiIsIkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzU2NTA0OSIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMDA6MDA6MDBaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiZGVncmVlIjp7Im5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIiwiX3NkIjpbIjUzanBvZnVVc2pWbzV1TDV4Y2xfRXdJMUViTXFpaDdyaDl2Vk9VX0ZuTzQiXX0sIl9zZCI6WyJFOGhVTUxfWkxEZGtJcmJxdm8wOFljWnh5X0lqdGtULUNvSUwyX0YtdmZzIl19LCJfc2QiOlsiOWdRaU5HSWk4R3A5YlUybXpuY3FVV1ZRTnRFeGwzZVVwV08xeXJUQThwMCIsImZ4VUZOYVZJRlNaTlFSeC1MQm9BQ0NsLUZWcXkwaXJLSF9aMnN2SWlrbjgiXX0 +.fpNaZ2o9jiw0bDvl21_XlXXUOxa8TAXwiXIIz03W8fwYvXcoTi6CiZ6QBdGmRh15Y79qg1y3fXV4h9Rck1bJyA +~WyJtSzRySzZtS2ppSjZWSGtFSjU2WUVBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd~WyJZanZYUUc2UmdBMGJfcEZXZ3lSajNBIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d~WyJtdjRkQ0ZxdnpjU0FoWG5IclNBek13IiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd~WyJ0SjJoNmZnR1pOSzM1WFRkbUdtOXdBIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 +
+
+
+ 
{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES256"
}
+ 
{
  "_sd_alg": "sha-256",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "issuer": "https://university.example/issuers/565049",
  "validFrom": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "degree": {
      "name": "Bachelor of Science and Arts",
      "_sd": [
        "53jpofuUsjVo5uL5xcl_EwI1EbMqih7rh9vVOU_FnO4"
      ]
    },
    "_sd": [
      "E8hUML_ZLDdkIrbqvo08YcZxy_IjtkT-CoIL2_F-vfs"
    ]
  },
  "_sd": [
    "9gQiNGIi8Gp9bU2mzncqUWVQNtExl3eUpWO1yrTA8p0",
    "fxUFNaVIFSZNQRx-LBoACCl-FVqy0irKH_Z2svIikn8"
  ]
}
+
+
+
+
+

Claim: id

+

SHA-256 Hash: 9gQiNGIi8Gp9bU2mzncqUWVQNtExl3eUpWO1yrTA8p0

+

Disclosure(s): WyJtSzRySzZtS2ppSjZWSGtFSjU2WUVBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd

+

Contents: [
  "mK4rK6mKjiJ6VHkEJ56YEA",
  "id",
  "http://university.example/credentials/3732"
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: fxUFNaVIFSZNQRx-LBoACCl-FVqy0irKH_Z2svIikn8

+

Disclosure(s): WyJZanZYUUc2UmdBMGJfcEZXZ3lSajNBIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d

+

Contents: [
  "YjvXQG6RgA0b_pFWgyRj3A",
  "type",
  [
    "VerifiableCredential",
    "ExampleDegreeCredential"
  ]
]

+
+ + +
+

Claim: id

+

SHA-256 Hash: E8hUML_ZLDdkIrbqvo08YcZxy_IjtkT-CoIL2_F-vfs

+

Disclosure(s): WyJtdjRkQ0ZxdnpjU0FoWG5IclNBek13IiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd

+

Contents: [
  "mv4dCFqvzcSAhXnHrSAzMw",
  "id",
  "did:example:ebfeb1f712ebc6f1c276e12ec21"
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: 53jpofuUsjVo5uL5xcl_EwI1EbMqih7rh9vVOU_FnO4

+

Disclosure(s): WyJ0SjJoNmZnR1pOSzM1WFRkbUdtOXdBIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0

+

Contents: [
  "tJ2h6fgGZNK35XTdmGm9wA",
  "type",
  "ExampleBachelorDegree"
]

+
+
+
+
+ +
+ +

+Concerning this specification, the following table lists the objects that +MUST have a type specified. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ObjectType
+Verifiable credential object + +VerifiableCredential and, optionally, a more specific +verifiable credential type. For example,
+"type": ["VerifiableCredential", "OpenBadgeCredential"] +
+Verifiable presentation object + +VerifiablePresentation and, optionally, a more specific +verifiable presentation type. For example,
+"type": "VerifiablePresentation" +
+credentialStatus object + +A valid credential status type. For example,
+"type": "BitstringStatusListEntry" +
+termsOfUse object + +A valid terms of use type. For example,
+"type": "TrustFrameworkPolicy" +
+evidence object + +A valid evidence type. For example,
+"type": "Evidence" +
+refreshService object + +A valid refreshService type. For example,
+"type": "VerifiableCredentialRefreshService2021" +
+credentialSchema object + +A valid credentialSchema type. For example,
+"type": "JsonSchema" +
+ +
Note: The Verifiable Credentials Data Model is based on JSON-LD

+The type system for the Verifiable Credentials Data Model is the same as +for JSON-LD 1.1 and is detailed in +Section 3.5: +Specifying the Type and +Section 9: JSON-LD +Grammar. When using a JSON-LD context (see Section +5.2 Extensibility), this specification aliases the +@type keyword to type to make the JSON-LD documents +more easily understood. While application developers and document authors do +not need to understand the specifics of the JSON-LD type system, implementers +of this specification who want to support interoperable extensibility do. +

+ +

+All credentials, presentations, and encapsulated objects SHOULD +specify, or be associated with, additional, more narrow types (like +ExampleDegreeCredential, for example) so software systems can +more easily detect and process this additional information. +

+ +

+When processing encapsulated objects defined in this specification, such as +objects associated with the credentialSubject object or deeply nested therein, +software systems SHOULD use the type information specified in encapsulating +objects higher in the hierarchy. Specifically, an encapsulating object, such as +a credential, SHOULD convey the associated object types so that +verifiers can quickly determine the contents of an associated object based +on the encapsulating object type. +

+ +

+For example, a credential object with the type of +ExampleDegreeCredential, signals to a verifier that the +object associated with the credentialSubject property contains the +identifier for the: +

+ + + +

+This enables implementers to rely on values associated with the type property +for verification. Object types and their associated values are +expected to be documented in at least a human-readable specification that can +be found at the URL for the type. For example, the human-readable +definition for the BitstringStatusList type can be found at + +https://www.w3.org/ns/credentials/status/#BitstringStatusList. It is also +suggested that a + +machine-readable version be provided through HTTP content negotiation at +the same URL. +

+ +
Note: See the Implementation Guide for creating new credential types

+Explaining how to create a new type of verifiable credential is beyond +the scope of this specification. Readers interested in doing so are +advised to read the + +Creating New Credential Types section in the Verifiable Credentials Implementation Guidelines 1.0. +

+ +
+ +

4.6 Names and Descriptions

+ + +

+When displaying a credential, it can be helpful to have +text provided by the issuer that furnishes the +credential with a name and a short description of its +purpose. The name and description properties +serve these purposes. +

+ +
+
name
+
+An OPTIONAL property that expresses the name of the credential. If +present, the value of the name property MUST be a string or +a language value object as described in +11.1 Language and Base Direction. Ideally, the name of a +credential is concise, human-readable, and could enable an individual to +quickly differentiate one credential from any other credentials +they might hold. +
+
description
+
+An OPTIONAL property that conveys specific details about a credential. If +present, the value of the description property MUST be a +string or a language value object as described in +11.1 Language and Base Direction. Ideally, the description of a +credential is no more than a few sentences in length and conveys enough +information about the credential to remind an individual of its contents +without having to look through the entirety of the claims. +
+
+ +
+
+ Example 5: Use of the name and description properties +
+ 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
+  "issuer": {
+    "id": "https://university.example/issuers/565049",
+    "name": "Example University",
+    "description": "A public university focusing on teaching examples."
+  },
+  "validFrom": "2015-05-10T12:30:00Z",
+  "name": "Example University Degree",
+  "description": "2015 Bachelor of Science and Arts Degree",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": {
+    "id": "https://university.example/issuers/565049",
+    "name": "Example University",
+    "description": "A public university focusing on teaching examples."
+  },
+  "validFrom": "2015-05-10T12:30:00Z",
+  "name": "Example University Degree",
+  "description": "2015 Bachelor of Science and Arts Degree",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaejVxRHiNEeErsTWAZkLcwGTeWFjUUoeXqTuX
+eBcdSxd5V",
+    "cryptosuite": "ecdsa-rdfc-2019",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z2gUQvRMQYEDxxHJZTX75aH3gTiJspzuZoQc1TQEfGSVUiKptL61qbme
+eNFVojveD9HP2BtpGL7FXzM3TC2SUibV4"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": {
+    "id": "https://university.example/issuers/565049",
+    "name": "Example University",
+    "description": "A public university focusing on teaching examples."
+  },
+  "validFrom": "2015-05-10T12:30:00Z",
+  "name": "Example University Degree",
+  "description": "2015 Bachelor of Science and Arts Degree",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:z6MktYiRGUrwMhySggEFsb7GaqwmnYxPL2FQ4bXY
+bUPedzyE",
+    "cryptosuite": "eddsa-rdfc-2022",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z3hbJdW2gnTLGF7XeYMz5L2bUCFU9twUvJUxwZgAoeGdoV19YCWDsgCq
+UoEGb5Q1U8bDr8PuPFtNi93DreeESbb39"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": {
+    "id": "https://university.example/issuers/565049",
+    "name": "Example University",
+    "description": "A public university focusing on teaching examples."
+  },
+  "validFrom": "2015-05-10T12:30:00Z",
+  "name": "Example University Degree",
+  "description": "2015 Bachelor of Science and Arts Degree",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaefuEErdxr11EqxbUY6Kqyg1WFDyVxDviNgTn
+HheVQEtMd",
+    "cryptosuite": "ecdsa-sd-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0AhVhAhxlY01M19iEcJXU_HTHHe6MKPkSb9WG7ktOrdY9B37-0NrH
+bUwno9EJ5rrh0HMYl6mybf77HWhgpqiy21dRXS1gjgCQCyZVi-9_8-Je8NiXFwgJMDkCffSbnKe
+XuzqwCoJFI5jpYIBgQe4qNB9QodXOxA5yLCIkgvTEe1c6XZO2bPdCNlOgCh1hAEFhReCAEGqIq1
+jyM-fO6w_YSdcU2Llvael2uTSh24ftQ5paoDvM7cVuB3hZj9s-baRbQG-5idhXHbn29qFk4VlhA
+fhI71PclNy3nGDgUGF_7NMAtQGZAbS_gApG35mjWUrJer0g0F-Y8wu6pWBM1SwqAahWXS5SwS06
+81q_QjbLLqFhAYtWaB_n4gvvjtzKQUB2ZyT8evcAc0zgGAwbspI0VRvWlZiZC1fiXYe-TwIqQ7g
+SzPPqkfsd0ZHid5E4ltS8sn1hAq9XKK1feWQ6mps0YaLtF72-aqCo3FWJXQzYsc4cFy-kckDasB
+CF-cgiCi91taD4lcmepLBnjdRNuUIdiSVyw3FhAE19mA4KT4nrD9vUp4pZSECDfZKCv3WmaNAUG
+xPBMPK60IdwL1fofDmmvFxQWyz9lQfch25VhI_8vjwdZwJdlXlhAZ5-vS-oZ4pSWJ3J2Cy9gvZm
+LTZQZLbuLe7bz4safOuAgjj6HdsK_LvO9jH5Dlov4FHGKg2Q86gSxG-Om2XWAj1hAudLXquzak9
+pxzSykbemAgpHwDMI8zLfbtPXvyHa1Y1YSaGqq_NGbCwGvywW9mlYeRBdGWiGuLo1v1V38b3xKJ
+YFnL2lzc3Vlcg"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": {
+    "id": "https://university.example/issuers/565049",
+    "name": "Example University",
+    "description": "A public university focusing on teaching examples."
+  },
+  "validFrom": "2015-05-10T12:30:00Z",
+  "name": "Example University Degree",
+  "description": "2015 Bachelor of Science and Arts Degree",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "verificationMethod": "did:key:zUC78HfmP56g14bJAYnJ11eYYdxL5oZL5cygjdjU
+ZYYtQ2Fy8bWQpT4cjy2pnraoXRidkJX84LEmzHQa1GzxnCpZwGRzZj4VampB7QyNWb8hXUBwqUA
+mh8PXati5E2QkviTpgzR",
+    "cryptosuite": "bbs-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0ChVhQi2ogy9TKRInHhuW7Q9JzvdHvmDBc1MTrK2GF4-zKBj9bf9H
+aCKfvEdpjpZsE34ZAO9s8gKNup2B6XlS74lQw9QfPEkTh4R8G1SgaH_LvcmNYQMP43Uz2_6ZROr
+tDIN3VDGofNQzGXJkDEdiK-_jrt6ZMXFDE8ZX70eeJX1DawHuw0sW9CBV3sa68IaRGcnZiiQpYY
+JVb1Iuc8U5sJ7Y-R2-kazKqPIAU0h0cDtIgnqLQMDWY0XJbO0ZGXDCt_w1vJrys9A31LmjPonEZ
+zliSnHCKmnu30eOgsaNuglz726TLGvw7kEmLryKBj9RFgvjlXehI1lgg8jNz37W-2gX8nefqUhB
+Hm_2DkVgs1A-VIu6Qj-uxAROBZy9pc3N1ZXI"
+  }
+}
+
+
+Protected Headers +
{
+  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
+  "alg": "ES256"
+}
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": {
+    "id": "https://university.example/issuers/565049",
+    "name": "Example University",
+    "description": "A public university focusing on teaching examples."
+  },
+  "validFrom": "2015-05-10T12:30:00Z",
+  "name": "Example University Degree",
+  "description": "2015 Bachelor of Science and Arts Degree",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
+
+application/vc-ld+jwt +
+
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjp7ImlkIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJuYW1lIjoiRXhhbXBsZSBVbml2ZXJzaXR5IiwiZGVzY3JpcHRpb24iOiJBIHB1YmxpYyB1bml2ZXJzaXR5IGZvY3VzaW5nIG9uIHRlYWNoaW5nIGV4YW1wbGVzLiJ9LCJ2YWxpZEZyb20iOiIyMDE1LTA1LTEwVDEyOjMwOjAwWiIsIm5hbWUiOiJFeGFtcGxlIFVuaXZlcnNpdHkgRGVncmVlIiwiZGVzY3JpcHRpb24iOiIyMDE1IEJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMgRGVncmVlIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJkZWdyZWUiOnsidHlwZSI6IkV4YW1wbGVCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fQ +.2AZOLhxdCnnhDSzNeY16v50R0oJJTXoMA0XY6123gv-MgqWBPdntiIpijv17bfgLwvl-ltXpfaqgRigbNnE4XQ +
+
+
+
+
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": {
+    "id": "https://university.example/issuers/565049",
+    "name": "Example University",
+    "description": "A public university focusing on teaching examples."
+  },
+  "validFrom": "2015-05-10T12:30:00Z",
+  "name": "Example University Degree",
+  "description": "2015 Bachelor of Science and Arts Degree",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
+
+application/cbor-diagnostic +
+
/ cose-sign1 / 18([
+  / protected / << {
+    / alg / 1 : -35 / ES384 /
+  } >>,
+  / unprotected / {
+  },
+  / payload / h'7b224063...227d7d7d',
+  / signature / h'7bf7086b...c5f69670'
+])
+
+application/vc-ld+cose +
+d28444a1013822a05902807b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a7b226964223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f353635303439222c226e616d65223a224578616d706c6520556e6976657273697479222c226465736372697074696f6e223a2241207075626c696320756e697665727369747920666f637573696e67206f6e207465616368696e67206578616d706c65732e227d2c2276616c696446726f6d223a22323031352d30352d31305431323a33303a30305a222c226e616d65223a224578616d706c6520556e697665727369747920446567726565222c226465736372697074696f6e223a22323031352042616368656c6f72206f6620536369656e636520616e64204172747320446567726565222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d58407bf7086b12ee8db2548680f25f87df866751d4dd0b30635e80fc23a97e4af09d76c3dea79e73adadb284be92799e917fde3415ed7402326daa026b02c5f69670 +
+
+
+ +
+ + + +
    +
  • + +
    • +
  • + +
    • +
  • + +
    • +
+
+ +
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJfc2RfYWxnIjoic2hhLTI1NiIsIkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOnsibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSIsImRlc2NyaXB0aW9uIjoiQSBwdWJsaWMgdW5pdmVyc2l0eSBmb2N1c2luZyBvbiB0ZWFjaGluZyBleGFtcGxlcy4iLCJfc2QiOlsiZ2xBb3Y2bWM0RDhwdUp4aTBnTUFnMHhsLTBJWl8zcVI0eElxOEp2WGlYYyJdfSwidmFsaWRGcm9tIjoiMjAxNS0wNS0xMFQxMjozMDowMFoiLCJuYW1lIjoiRXhhbXBsZSBVbml2ZXJzaXR5IERlZ3JlZSIsImRlc2NyaXB0aW9uIjoiMjAxNSBCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIERlZ3JlZSIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImRlZ3JlZSI6eyJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyIsIl9zZCI6WyJRNFBGYnpWMXowbjlyYlROM3JtYmc3YlczSUZOeEpESDFTT3k4d2JaRzljIl19LCJfc2QiOlsiTG9ia3JrRnFkZk0tc0I0VkJPNjZpb1pjdVFzOWtmVk9TZ2VNbk56bWJxSSJdfSwiX3NkIjpbIkFLNDQxVWlUa3BVOHU3TGt3WWw1ZEZMRmJHZlNZS2kyQVliSzhhYVRSSk0iLCJjcmdmOThmazFzUXZnSlZia2oxclB6ZGFNUFAwd1VtajZUOVlaLXI5VVFVIl19 +.tWE_MZ4Tz71kjKIczucEN3169l6FhCXE9OcPuQdwlYpXfrFPE0aAJcW4g9TXVK3xlEijj6RbGhOKztHqgWZ86Q +~WyIyWk4xRzhsY1U1VEx0ZWJYZEJrczVnIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd~WyJQQzgxQWozenhQMHNMdTAwRVdJUmt3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d~WyJZcU0xQWZwcEYtY1Mwb19iNVlIUHdBIiwgImlkIiwgImh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5Il0~WyJyd2JjNHk0cEY5ZnllNlpTc2ZTNkhBIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd~WyJjMHIzb3BQYjA3UFpDaDZEdXRGTXpBIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 +
+
+
+ 
{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES256"
}
+ 
{
  "_sd_alg": "sha-256",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "issuer": {
    "name": "Example University",
    "description": "A public university focusing on teaching examples.",
    "_sd": [
      "glAov6mc4D8puJxi0gMAg0xl-0IZ_3qR4xIq8JvXiXc"
    ]
  },
  "validFrom": "2015-05-10T12:30:00Z",
  "name": "Example University Degree",
  "description": "2015 Bachelor of Science and Arts Degree",
  "credentialSubject": {
    "degree": {
      "name": "Bachelor of Science and Arts",
      "_sd": [
        "Q4PFbzV1z0n9rbTN3rmbg7bW3IFNxJDH1SOy8wbZG9c"
      ]
    },
    "_sd": [
      "LobkrkFqdfM-sB4VBO66ioZcuQs9kfVOSgeMnNzmbqI"
    ]
  },
  "_sd": [
    "AK441UiTkpU8u7LkwYl5dFLFbGfSYKi2AYbK8aaTRJM",
    "crgf98fk1sQvgJVbkj1rPzdaMPP0wUmj6T9YZ-r9UQU"
  ]
}
+
+
+
+
+

Claim: id

+

SHA-256 Hash: AK441UiTkpU8u7LkwYl5dFLFbGfSYKi2AYbK8aaTRJM

+

Disclosure(s): WyIyWk4xRzhsY1U1VEx0ZWJYZEJrczVnIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd

+

Contents: [
  "2ZN1G8lcU5TLtebXdBks5g",
  "id",
  "http://university.example/credentials/3732"
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: crgf98fk1sQvgJVbkj1rPzdaMPP0wUmj6T9YZ-r9UQU

+

Disclosure(s): WyJQQzgxQWozenhQMHNMdTAwRVdJUmt3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d

+

Contents: [
  "PC81Aj3zxP0sLu00EWIRkw",
  "type",
  [
    "VerifiableCredential",
    "ExampleDegreeCredential"
  ]
]

+
+ + +
+

Claim: id

+

SHA-256 Hash: glAov6mc4D8puJxi0gMAg0xl-0IZ_3qR4xIq8JvXiXc

+

Disclosure(s): WyJZcU0xQWZwcEYtY1Mwb19iNVlIUHdBIiwgImlkIiwgImh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5Il0

+

Contents: [
  "YqM1AfppF-cS0o_b5YHPwA",
  "id",
  "https://university.example/issuers/565049"
]

+
+ + +
+

Claim: id

+

SHA-256 Hash: LobkrkFqdfM-sB4VBO66ioZcuQs9kfVOSgeMnNzmbqI

+

Disclosure(s): WyJyd2JjNHk0cEY5ZnllNlpTc2ZTNkhBIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd

+

Contents: [
  "rwbc4y4pF9fye6ZSsfS6HA",
  "id",
  "did:example:ebfeb1f712ebc6f1c276e12ec21"
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: Q4PFbzV1z0n9rbTN3rmbg7bW3IFNxJDH1SOy8wbZG9c

+

Disclosure(s): WyJjMHIzb3BQYjA3UFpDaDZEdXRGTXpBIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0

+

Contents: [
  "c0r3opPb07PZCh6DutFMzA",
  "type",
  "ExampleBachelorDegree"
]

+
+
+
+
+ +
+ +

+Names and descriptions also support expressing content in different languages. +To express a string with language and base direction information, +one can use an object that contains the @value, @language, and @direction +properties to express the text value, language tag, and base direction, +respectively. See +11.1 Language and Base Direction for further information. +

+ +
Note: @direction is not required for single-language strings

+The @direction property in the examples below is not required +for the associated single-language strings, as their default directions are the +same as those set by the @direction value. We include the @direction +property here for clarity of demonstration and to make copy+paste+edit deliver +functional results. Implementers are encouraged to read the section on +String Internationalization +in the JSON-LD 1.1 specification. +

+ +
+
+ Example 6: Use of the name and description properties + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
+  "issuer": {
+    "id": "https://university.example/issuers/565049",
+    "name": [{
+      "@value": "Example University",
+      "@language": "en"
+    }, {
+      "@value": "Université Exemple",
+      "@language": "fr"
+    }, {
+      "@value": "جامعة المثال",
+      "@language": "ar",
+      "@direction": "rtl"
+    }],
+    "description": [{
+      "@value": "A public university focusing on teaching examples.",
+      "@language": "en"
+    }, {
+      "@value": "Une université publique axée sur l'enseignement d'exemples.",
+      "@language": "fr"
+    }, {
+      "@value": ".جامعة عامة تركز على أمثلة التدريس",
+      "@language": "ar",
+      "@direction": "rtl"
+    }]
+  },
+  "validFrom": "2015-05-10T12:30:00Z",
+  "name": [{
+    "@value": "Example University Degree",
+    "@language": "en"
+  }, {
+    "@value": "Exemple de Diplôme Universitaire",
+    "@language": "fr"
+  }, {
+    "@value": "مثال الشهادة الجامعية",
+    "@language": "ar",
+    "@direction": "rtl"
+  }],
+  "description": [{
+    "@value": "2015 Bachelor of Science and Arts Degree",
+    "@language": "en"
+  }, {
+    "@value": "2015 Licence de Sciences et d'Arts",
+    "@language": "fr"
+  }, {
+    "@value": "2015 بكالوريوس العلوم والآداب",
+    "@language": "ar",
+    "@direction": "rtl"
+  }],
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": [{
+        "@value": "Bachelor of Science and Arts Degree",
+        "@language": "en"
+      }, {
+        "@value": "Licence de Sciences et d'Arts",
+        "@language": "fr"
+      }, {
+        "@value": "بكالوريوس العلوم والآداب",
+        "@language": "ar",
+        "@direction": "rtl"
+      }]
+    }
+  }
+}
+
+
+ +

4.7 Issuer

+ + +

+This specification defines a property for expressing the issuer of +a verifiable credential. +

+ +

+A verifiable credential MUST have an issuer property. +

+ +
+
issuer
+
+The value of the issuer property MUST be either a +URL or an object containing an id property +whose value is a URL; in either case, the issuer selects this +URL to identify itself in a globally unambiguous +way. It is RECOMMENDED that the URL be one which, if dereferenced, results +in a controller document, as defined in [CONTROLLER-DOCUMENT], about the +issuer that can be used to verify the information expressed in the +credential. +
+
+ +
+
+ Example 7: Use of the issuer property +
+ 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaejVxRHiNEeErsTWAZkLcwGTeWFjUUoeXqTuX
+eBcdSxd5V",
+    "cryptosuite": "ecdsa-rdfc-2019",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z54vzV2CokdqVGT1R72J2x2Eu6fUGGYbi251tZoBmtiv1Kjxf3FiiGj9
+NuyoWjEXpWkUYk4K3W6iQ9cBsWMbn34GS"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:z6MktYiRGUrwMhySggEFsb7GaqwmnYxPL2FQ4bXY
+bUPedzyE",
+    "cryptosuite": "eddsa-rdfc-2022",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z5qtRYWV1nJFQSCuf9xECopLUb9CzD4S4UMnnuG2mjcfXsYUfAouCfGE
+zvUpubhK6fZnktiZXeozPwXrFDfFMpyUt"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaefuEErdxr11EqxbUY6Kqyg1WFDyVxDviNgTn
+HheVQEtMd",
+    "cryptosuite": "ecdsa-sd-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0AhVhAKNPJ_Yx0xT2i5SGtdSKCKTCf_5Fd3iDJ3iUJ7o1l5o4yZrf
+RswvrpmgNLgzCcaA5m8rFxqRpclQOE3JgbKm4hlgjgCQCaLQZTwxdbP6NdA7GI3EtayHK0UOlIF
+FxNZDdryNv6clYINeU_SLmON7rxmdaM2tzq3gF9K5cbKTZ9lmrEvKDagnbhVhAJD4wILIy4kGrS
+yWjLl-Ztn1Rjcvvm0cUKDX2DyBak7qu1P3TNhry6ZfUei_6SYCmQD1UJUg_vOw10VBcnnoy-VhA
+3pP7_1mxPctHgHykht-xd27G3mglTWuOGpyAxrmsPEQ0rhGCQ7x5WagyuvPBCeaqYBJQf235ya3
+y1cM02iwoNlhArbDkEw9Q-yydmrac-QYc888JfpWkNTGVKa7c3dxK8UMywRLRsLmMuU3uHSSXkn
+4Bn1XYQDInxL_jKpTNazkzo1hAkTzNDfh4xw1ps-xLyXjZn34RrrP4OM4RwDluZhihESCRgo4db
+WFeCKLQYO42gWVmWXUNmzHXxq-nDd5PvOIIN1hAFUDgpcNsaIljYNaRY1QWc3eJlIHGElUjaAoA
+SSvTsm8p1VXxZaV5PAGH7H6ojuv09g_xNkF5ZAtM7fpKIL5RLIFnL2lzc3Vlcg"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "verificationMethod": "did:key:zUC78HfmP56g14bJAYnJ11eYYdxL5oZL5cygjdjU
+ZYYtQ2Fy8bWQpT4cjy2pnraoXRidkJX84LEmzHQa1GzxnCpZwGRzZj4VampB7QyNWb8hXUBwqUA
+mh8PXati5E2QkviTpgzR",
+    "cryptosuite": "bbs-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0ChVhQkCResq4bonmaqjLhI0o4i8brUMOWctrP2fRsY5w8xhTyX3p
+7sPyKIZ46oAEexi2fFdWYteJ6wpuvf2p_AZWakBEzRrD-hgOOBzeRVG73DmZYQMP43Uz2_6ZROr
+tDIN3VDGofNQzGXJkDEdiK-_jrt6ZMKnv3N5iX7nvZR0OCXS-uXH4QQ9mW65QM5qlHOfE4GQVYY
+JVb1Iuc8U5sJ7Y-R2-kazKqPIAU0h0cDtIgnqLQMDWY0XJbO0ZGXDCt_w1vJrys9A31LmjPonEZ
+zliSnHCKmnu30eOgsaNuglz726TLGvw7kEmLryKBj9RFgvjlXehI1lggn1S8LFP1bwEtxh_fCny
+Hq62o_QY-7ou61HZEjyLF61SBZy9pc3N1ZXI"
+  }
+}
+
+
+Protected Headers +
{
+  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
+  "alg": "ES256"
+}
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
+
+application/vc-ld+jwt +
+
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy8xNCIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJkZWdyZWUiOnsidHlwZSI6IkV4YW1wbGVCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fQ +.zH8T7ohHAfPR_ZdpBhG-dDd3wsUBo5vig-v7oOZ45RpjLPoM73gw3FPnZRddxalYfLDVB1whf2cUDjS-kbn7YQ +
+
+
+
+
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
+
+application/cbor-diagnostic +
+
/ cose-sign1 / 18([
+  / protected / << {
+    / alg / 1 : -35 / ES384 /
+  } >>,
+  / unprotected / {
+  },
+  / payload / h'7b224063...227d7d7d',
+  / signature / h'6c9b3009...7232386e'
+])
+
+application/vc-ld+cose +
+d28444a1013822a05901ba7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f3134222c2276616c696446726f6d223a22323031302d30312d30315431393a32333a32345a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d58406c9b30093a8bdca54355fdd8713fd4e363476578fe6233cc1c085da401317d384924c063953ac3add1419cbac5950a321dbb907f872af21a9c7936dc7232386e +
+
+
+ +
+ + + +
    +
  • + +
    • +
  • + +
    • +
  • + +
    • +
+
+ +
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJfc2RfYWxnIjoic2hhLTI1NiIsIkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzE0IiwidmFsaWRGcm9tIjoiMjAxMC0wMS0wMVQxOToyMzoyNFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsibGhoUU9vckI0SWtQYUdzQmpTSUhDNFlVd2UwVlMtZmNMY3VYd1UxaG5WRSJdfSwiX3NkIjpbImE1Mzh4bDVmampRczBiVGxSMl9GUUF3TUFmQ29BUkV0S2FmVU5STHRJclUiXX0sIl9zZCI6WyJWQ0czTlptZTRnR3dUczEyVHBhNmF5VHN0U0Z4ZUhmbE55Sm55NmZuRDhBIiwib2JWLWVOYlZIRC15SVljVlFFQjBrTExzc2NPZGJwRW9pdTdHMXF3SE1wcyJdfQ +.XqUArga0p2YgmIYddb9pkFQZVI1-iAy9zKC9MZOttGoOmQBh9lVy88UzKQrBDcJkVkgyTizFF5CYqginBsQR9A +~WyJQYVpQWXV4UWxOcTJmX3cwSm9OcklBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd~WyI2UDlnTDNsc0VyU2x0ems5UndHdUJ3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d~WyJCNmllSlk3UXgta01ubVlRNVp6N2JBIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd~WyI3VEtiZm02eVdid2s2QXMydy1qb0JRIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 +
+
+
+ 
{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES256"
}
+ 
{
  "_sd_alg": "sha-256",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "degree": {
      "name": "Bachelor of Science and Arts",
      "_sd": [
        "lhhQOorB4IkPaGsBjSIHC4YUwe0VS-fcLcuXwU1hnVE"
      ]
    },
    "_sd": [
      "a538xl5fjjQs0bTlR2_FQAwMAfCoAREtKafUNRLtIrU"
    ]
  },
  "_sd": [
    "VCG3NZme4gGwTs12Tpa6ayTstSFxeHflNyJny6fnD8A",
    "obV-eNbVHD-yIYcVQEB0kLLsscOdbpEoiu7G1qwHMps"
  ]
}
+
+
+
+
+

Claim: id

+

SHA-256 Hash: VCG3NZme4gGwTs12Tpa6ayTstSFxeHflNyJny6fnD8A

+

Disclosure(s): WyJQYVpQWXV4UWxOcTJmX3cwSm9OcklBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd

+

Contents: [
  "PaZPYuxQlNq2f_w0JoNrIA",
  "id",
  "http://university.example/credentials/3732"
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: obV-eNbVHD-yIYcVQEB0kLLsscOdbpEoiu7G1qwHMps

+

Disclosure(s): WyI2UDlnTDNsc0VyU2x0ems5UndHdUJ3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d

+

Contents: [
  "6P9gL3lsErSltzk9RwGuBw",
  "type",
  [
    "VerifiableCredential",
    "ExampleDegreeCredential"
  ]
]

+
+ + +
+

Claim: id

+

SHA-256 Hash: a538xl5fjjQs0bTlR2_FQAwMAfCoAREtKafUNRLtIrU

+

Disclosure(s): WyJCNmllSlk3UXgta01ubVlRNVp6N2JBIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd

+

Contents: [
  "B6ieJY7Qx-kMnmYQ5Zz7bA",
  "id",
  "did:example:ebfeb1f712ebc6f1c276e12ec21"
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: lhhQOorB4IkPaGsBjSIHC4YUwe0VS-fcLcuXwU1hnVE

+

Disclosure(s): WyI3VEtiZm02eVdid2s2QXMydy1qb0JRIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0

+

Contents: [
  "7TKbfm6yWbwk6As2w-joBQ",
  "type",
  "ExampleBachelorDegree"
]

+
+
+
+
+ +
+ +

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

+ +
+
+ Example 8: Expanded use of the issuer property +
+ 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
+  "issuer": {
+    "id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
+    "name": "Example University"
+  },
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": {
+    "id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
+    "name": "Example University"
+  },
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaejVxRHiNEeErsTWAZkLcwGTeWFjUUoeXqTuX
+eBcdSxd5V",
+    "cryptosuite": "ecdsa-rdfc-2019",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z2HL5kW2Dh7vJ4KNCaWCnUfww8jLPKKtQruiUDdnGoUNK7Gkr5ADy1yE
+DqzmFC2AJAq9YGCAbe76RC1NdT8KftmvU"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": {
+    "id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
+    "name": "Example University"
+  },
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:z6MktYiRGUrwMhySggEFsb7GaqwmnYxPL2FQ4bXY
+bUPedzyE",
+    "cryptosuite": "eddsa-rdfc-2022",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "zzoz9qToqaigtzPJDQP4ZNPpPEvVVZH4cToqqpRGYY1E3mAN9gW6heqr
+KW7BVeE3t8BjGiTW9y7fmHMvUzTrmDFx"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": {
+    "id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
+    "name": "Example University"
+  },
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaefuEErdxr11EqxbUY6Kqyg1WFDyVxDviNgTn
+HheVQEtMd",
+    "cryptosuite": "ecdsa-sd-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0AhVhAAUMY6wsiqWIKaZBGOH27MvXs6y-MPT-_JvRiWDK-IvKxG3B
+QaOa0ja5M2oyEkUWip-ygE20-vPzSCEt2Cky93FgjgCQChd_xTyXE2Eei0x7FQGEssuwulPyB4k
+9tJTRmuHadHaRYIAop0D2mxVo7M3X9H_k5NSdwrSKePJOTQrDkzsga0HXNhVhAdjwSfAXz-kOMl
+O2x61jjWl4D_NityNs5MtHWdwAXiW5lUiXlOwD1jDNxIyjFKq7SrBJL4adAZMAMEjVh39pNnVhA
+_FyABojCpgAsj-bem-tYi-zdtxadde-t0I3deio7fXXWUKqQwoafuxCWtmP9b8mmHCGlv6Xrqjd
+gV7vX4pK8Z1hAeLCAAvh1lUm4q66B8nOGKJRNIC68qv3H5ztJu0vcvREreBrmNJAu5-yjUsRdBr
+jBzw0m61Rz5hWxnmE1ZLfCc1hAmlprxXQ5ZsfbmXiDVGJmCLToHy_kMIB1aAVOOElUdMl9i7lUX
+xW8Bb69L5Y6VuDrP1_f-8e68A829lRLVrX_XFhAhxrO9llyK-uQUvBWU1TQkAnEKsBnTIPWtVHJ
+1xQK6iQejcQwoyB_dpubboimwl5rBOkxQizs0MiixdzzSIBqcoFnL2lzc3Vlcg"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": {
+    "id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
+    "name": "Example University"
+  },
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "verificationMethod": "did:key:zUC78HfmP56g14bJAYnJ11eYYdxL5oZL5cygjdjU
+ZYYtQ2Fy8bWQpT4cjy2pnraoXRidkJX84LEmzHQa1GzxnCpZwGRzZj4VampB7QyNWb8hXUBwqUA
+mh8PXati5E2QkviTpgzR",
+    "cryptosuite": "bbs-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0ChVhQlDMXc1tJ96mSYlPSrLi99Um3I4D3YMsl2kba2WhzPGSvQqd
+R44iUlCw5l-JeC6HQDUP-qDfo0Dh8h_C54_LHh_F8TB4u1HFUsBsj3Myux6dYQMP43Uz2_6ZROr
+tDIN3VDGofNQzGXJkDEdiK-_jrt6ZMQAGpGXTZS6rwOppAPreXlDb3xQb46PJ_xcVri0glVYJYY
+JVb1Iuc8U5sJ7Y-R2-kazKqPIAU0h0cDtIgnqLQMDWY0XJbO0ZGXDCt_w1vJrys9A31LmjPonEZ
+zliSnHCKmnu30eOgsaNuglz726TLGvw7kEmLryKBj9RFgvjlXehI1lggxFwBKXkk1IRzGmHqbEh
+B0amKXk5TlG7Tfq3lLokefHuBZy9pc3N1ZXI"
+  }
+}
+
+
+Protected Headers +
{
+  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
+  "alg": "ES256"
+}
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": {
+    "id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
+    "name": "Example University"
+  },
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
+
+application/vc-ld+jwt +
+
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjp7ImlkIjoiZGlkOmV4YW1wbGU6NzZlMTJlYzcxMmViYzZmMWMyMjFlYmZlYjFmIiwibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSJ9LCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiZGVncmVlIjp7InR5cGUiOiJFeGFtcGxlQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyJ9fX0 +.fRmCNkdJq6kJZd_rIOj5MRoJroMDsBlCMov57yWGPGOp_ZAdk0Zbq-1I8Ujf2H3iVrSYADKzbT1v0O601b40Zg +
+
+
+
+
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": {
+    "id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
+    "name": "Example University"
+  },
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
+
+application/cbor-diagnostic +
+
/ cose-sign1 / 18([
+  / protected / << {
+    / alg / 1 : -35 / ES384 /
+  } >>,
+  / unprotected / {
+  },
+  / payload / h'7b224063...227d7d7d',
+  / signature / h'072d9359...345acb6c'
+])
+
+application/vc-ld+cose +
+d28444a1013822a05901df7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a7b226964223a226469643a6578616d706c653a373665313265633731326562633666316332323165626665623166222c226e616d65223a224578616d706c6520556e6976657273697479227d2c2276616c696446726f6d223a22323031302d30312d30315431393a32333a32345a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d5840072d9359fd93f96443ed3d2d05b7130a5d78d0b1b33fa67e6a53b9612c64cf970bc5b7e142e33aaa216d00f88c65d2a0a3770e66b805f91a3681fa83345acb6c +
+
+
+ +
+ + + +
    +
  • + +
    • +
  • + +
    • +
  • + +
    • +
+
+ +
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJfc2RfYWxnIjoic2hhLTI1NiIsIkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOnsibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSIsIl9zZCI6WyJ1dmlhT1V1OVVkOEtDNFRTMVZtX3FWcFd0YWtzV2VvaGVpWEJGZjZMSXpFIl19LCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImRlZ3JlZSI6eyJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyIsIl9zZCI6WyI1WW5ubXNGRnlOTHFXM0NGTFBZdmc5eFAwYmRqeURqNzhnSjhwMnlYd3dJIl19LCJfc2QiOlsieUhJOXRtTG4yXzl6TVRDWFh5VEFyWFF1QjRNaXBMZ1JZcGVzeHNRa01WayJdfSwiX3NkIjpbIm9GbzRQQVhwT2d5TUZSVVBVZW94VTlBOG9jQUJydjczejdTMEtwdEFWNU0iLCJwbHFpNnkxOUQ4M1JPdllZM0kwMUJDZklhQU02ZkNTS0ZlaEphWjl2TFBRIl19 +.PCjjbzYM5OjT2I-kxbMLNwQ-WQbVTYF4peVfdV2rlOa50Yh424Qcdhv-t3cVO9POhK20KqkoblldXorZEYV1-w +~WyJvWWo3UElJZ2dNa0VqMUFoWlloVEJnIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd~WyJXdExoNzBTRUNwNTI1aE9KY1BwY2hRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d~WyJLUWRNZEd0bml3WDZFb1VGbktWeDdRIiwgImlkIiwgImRpZDpleGFtcGxlOjc2ZTEyZWM3MTJlYmM2ZjFjMjIxZWJmZWIxZiJd~WyJLakpoZGtvaDVTSE5razl3RmhtNzVnIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd~WyJDcE15VVpLbkFFZmtWbmlheW1tSllnIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 +
+
+
+ 
{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES256"
}
+ 
{
  "_sd_alg": "sha-256",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "issuer": {
    "name": "Example University",
    "_sd": [
      "uviaOUu9Ud8KC4TS1Vm_qVpWtaksWeoheiXBFf6LIzE"
    ]
  },
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "degree": {
      "name": "Bachelor of Science and Arts",
      "_sd": [
        "5YnnmsFFyNLqW3CFLPYvg9xP0bdjyDj78gJ8p2yXwwI"
      ]
    },
    "_sd": [
      "yHI9tmLn2_9zMTCXXyTArXQuB4MipLgRYpesxsQkMVk"
    ]
  },
  "_sd": [
    "oFo4PAXpOgyMFRUPUeoxU9A8ocABrv73z7S0KptAV5M",
    "plqi6y19D83ROvYY3I01BCfIaAM6fCSKFehJaZ9vLPQ"
  ]
}
+
+
+
+
+

Claim: id

+

SHA-256 Hash: oFo4PAXpOgyMFRUPUeoxU9A8ocABrv73z7S0KptAV5M

+

Disclosure(s): WyJvWWo3UElJZ2dNa0VqMUFoWlloVEJnIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd

+

Contents: [
  "oYj7PIIggMkEj1AhZYhTBg",
  "id",
  "http://university.example/credentials/3732"
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: plqi6y19D83ROvYY3I01BCfIaAM6fCSKFehJaZ9vLPQ

+

Disclosure(s): WyJXdExoNzBTRUNwNTI1aE9KY1BwY2hRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d

+

Contents: [
  "WtLh70SECp525hOJcPpchQ",
  "type",
  [
    "VerifiableCredential",
    "ExampleDegreeCredential"
  ]
]

+
+ + +
+

Claim: id

+

SHA-256 Hash: uviaOUu9Ud8KC4TS1Vm_qVpWtaksWeoheiXBFf6LIzE

+

Disclosure(s): WyJLUWRNZEd0bml3WDZFb1VGbktWeDdRIiwgImlkIiwgImRpZDpleGFtcGxlOjc2ZTEyZWM3MTJlYmM2ZjFjMjIxZWJmZWIxZiJd

+

Contents: [
  "KQdMdGtniwX6EoUFnKVx7Q",
  "id",
  "did:example:76e12ec712ebc6f1c221ebfeb1f"
]

+
+ + +
+

Claim: id

+

SHA-256 Hash: yHI9tmLn2_9zMTCXXyTArXQuB4MipLgRYpesxsQkMVk

+

Disclosure(s): WyJLakpoZGtvaDVTSE5razl3RmhtNzVnIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd

+

Contents: [
  "KjJhdkoh5SHNkk9wFhm75g",
  "id",
  "did:example:ebfeb1f712ebc6f1c276e12ec21"
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: 5YnnmsFFyNLqW3CFLPYvg9xP0bdjyDj78gJ8p2yXwwI

+

Disclosure(s): WyJDcE15VVpLbkFFZmtWbmlheW1tSllnIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0

+

Contents: [
  "CpMyUZKnAEfkVniaymmJYg",
  "type",
  "ExampleBachelorDegree"
]

+
+
+
+
+ +
+ +
Note: The identifier for an issuer can be any URL

+The value of the issuer property can also be a JWK (for +example, "https://jwk.example/keys/foo.jwk") or a DID (for +example, "did:example:abfe13f712120431c276e12ecab"). +

+ +
+ +

4.8 Credential Subject

+ + +

+A verifiable credential contains claims about one or more subjects. +This specification defines a credentialSubject property for the expression +of claims about one or more subjects. +

+ +

+A verifiable credential MUST contain a credentialSubject property. +

+ +
+
credentialSubject
+
+The value of the credentialSubject property is a set of objects where each +object MUST be the subject of one or more claims, which MUST be +serialized inside the credentialSubject property. Each object MAY also +contain an id property to identify the subject, as described in +Section 4.4 Identifiers. +
+
+ +
+
+ Example 9: Use of the credentialSubject property +
+ 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaejVxRHiNEeErsTWAZkLcwGTeWFjUUoeXqTuX
+eBcdSxd5V",
+    "cryptosuite": "ecdsa-rdfc-2019",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z5jK3yNH9jbSLqFgUFomcLrPv8dd4wSovzi31rTVt5S7MepkfwRGiGDe
+R3LEnFSvYqBmtp24rhv82pjuhB2xWuq6Y"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:z6MktYiRGUrwMhySggEFsb7GaqwmnYxPL2FQ4bXY
+bUPedzyE",
+    "cryptosuite": "eddsa-rdfc-2022",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z3xHiaoVmYdyNtDdGojgC2tsVGVMFy2qz1EgvdqD8QubtLLgQnZesygD
+7gXxZEek19Zt56iKZzwAGn9hubVm8ywJ"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaefuEErdxr11EqxbUY6Kqyg1WFDyVxDviNgTn
+HheVQEtMd",
+    "cryptosuite": "ecdsa-sd-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0AhVhApzTEha9SupPmXgJ-OnysxgMSGkC65HK6ESC90Fx_MTHGa5d
+yb3jTP1C6oGrBM9sZ_053uDV4oTBhNyubBJuMyVgjgCQDhIZ6gcJ-TXm_lkdOlCtc9P_oE12atE
+OanllDq9HdOxBYIIvBNc5d5jJIn8PShXJ8-gVnlQUL_p8wyno1hvYXmXkchVhA8TFMWb9zsfk7O
+yqMnbZ9f2gm9QBYNmsj0u-JmXm8VknbjDRhHjUdGYnxk2aIMfjGHyc9Qv5SLpRkEOtnE9xcI1hA
+bKuS81bRxDBkpReOhbkbJr6fvtIaYa6WnTUNPwHQj9oEh2Hm98ltWbxWXF3EGGxRVOYmaRPhN1i
+3sIc6lteDMVhADTBMkzxuMx6CBm6fo03M0Y_9JJFYhL-FBaUU5nLxoDrew_PARjE23fPNItdeGn
+11hyfnZN89GWGvz8du-6z2dlhA58gQuwT3wjkGg9UDdUGlD4wsW1FZq96ETk29H-5qUoNd-MVPc
+-2Tmr_sqHZ1R70DjYUVeYVtSfnr-Rxb9ytMTFhAa0qkBceYLM7K1qd14lk_CqhB62wa60Uboo4C
+uT97U8IzCvnQ3ucni0Gz10451g4qaScfX2eAMLCZfzfql3Z4woFnL2lzc3Vlcg"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "verificationMethod": "did:key:zUC78HfmP56g14bJAYnJ11eYYdxL5oZL5cygjdjU
+ZYYtQ2Fy8bWQpT4cjy2pnraoXRidkJX84LEmzHQa1GzxnCpZwGRzZj4VampB7QyNWb8hXUBwqUA
+mh8PXati5E2QkviTpgzR",
+    "cryptosuite": "bbs-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0ChVhQlEqaKQHsWrlNW4X5E3OGWhXlCbcPooZshfjj9VpVO90UWBl
+YmzGFBxcfXdYqCS2SHHkI-ykMuLG4cPxOU7lkn4csFY2nV-v2VHc5uM_n3gRYQMP43Uz2_6ZROr
+tDIN3VDGofNQzGXJkDEdiK-_jrt6ZMS1r7HKFDPyyrvPGqNF8bjgNELvoomOjpbD9JEvaGI1pYY
+JVb1Iuc8U5sJ7Y-R2-kazKqPIAU0h0cDtIgnqLQMDWY0XJbO0ZGXDCt_w1vJrys9A31LmjPonEZ
+zliSnHCKmnu30eOgsaNuglz726TLGvw7kEmLryKBj9RFgvjlXehI1lggvSxziRSudY8hOWpinXH
+LO4VAUqiHIMNezXpKjS0Ng5uBZy9pc3N1ZXI"
+  }
+}
+
+
+Protected Headers +
{
+  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
+  "alg": "ES256"
+}
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
+
+application/vc-ld+jwt +
+
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiZGVncmVlIjp7InR5cGUiOiJFeGFtcGxlQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyJ9fX0 +.PRs-CivuiLnIH7OVt7hYfyOxoZgjJi--Qu2hoT4S6AGSw5HshMcNTqehMkQwRRQ3g5vqLMw1tEbihfEYcji_sQ +
+
+
+
+
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
+
+application/cbor-diagnostic +
+
/ cose-sign1 / 18([
+  / protected / << {
+    / alg / 1 : -35 / ES384 /
+  } >>,
+  / unprotected / {
+  },
+  / payload / h'7b224063...227d7d7d',
+  / signature / h'dc88de4c...72f45171'
+])
+
+application/vc-ld+cose +
+d28444a1013822a05901be7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f353635303439222c2276616c696446726f6d223a22323031302d30312d30315430303a30303a30305a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d5840dc88de4c5012d5417c6cceb9cb834c8d8b8488fc59d39a971cb80509ebdd27aef95431412ad70f5e1cbf9393b1b8823f21682bf1b727a9ede5086b3c72f45171 +
+
+
+ +
+ + + +
    +
  • + +
    • +
  • + +
    • +
  • + +
    • +
+
+ +
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJfc2RfYWxnIjoic2hhLTI1NiIsIkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzU2NTA0OSIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMDA6MDA6MDBaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiZGVncmVlIjp7Im5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIiwiX3NkIjpbInBJYzlmSWpDR0xEYlkyVWpHN3B3WnZQekFFZUFXUEI3cXBWWnZjbHdnUFEiXX0sIl9zZCI6WyJlQW0yZjJ4clJNXzdTb3hEVFBabDlrZk84aDlaT1JNc2l2QllWekJzcG1rIl19LCJfc2QiOlsiMEpTR2FvVmNabEZvVlMtcE9uamlzZDRrSUtWc2JQM1hMbVFxdnJncmhLTSIsInRGWGpieU55U0ZSMG92ckFUNE9IX0ZLQ3lXaEtCREVzSmgyNWlxeWxoWHMiXX0 +.0w4OMnX_jv_zFuTXDKRr2l8eaXCpnOrpx31RlmudFzK7KlRBj5f9mxBw82bVx9Rfrx9Ig9Rj1d6eq37bVwFpQw +~WyJ4bkRsNTQ1ODlMTDVrYnRUMDlpMTRRIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd~WyJ2elh5S2x3ellSWkQxTkNPWnhmclBnIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d~WyJXQWdpeWxiOTl5NnNkRDBqcVpsbTlRIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd~WyJxanNTbW4yaVZBbENQazRXX09QWV9RIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 +
+
+
+ 
{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES256"
}
+ 
{
  "_sd_alg": "sha-256",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "issuer": "https://university.example/issuers/565049",
  "validFrom": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "degree": {
      "name": "Bachelor of Science and Arts",
      "_sd": [
        "pIc9fIjCGLDbY2UjG7pwZvPzAEeAWPB7qpVZvclwgPQ"
      ]
    },
    "_sd": [
      "eAm2f2xrRM_7SoxDTPZl9kfO8h9ZORMsivBYVzBspmk"
    ]
  },
  "_sd": [
    "0JSGaoVcZlFoVS-pOnjisd4kIKVsbP3XLmQqvrgrhKM",
    "tFXjbyNySFR0ovrAT4OH_FKCyWhKBDEsJh25iqylhXs"
  ]
}
+
+
+
+
+

Claim: id

+

SHA-256 Hash: tFXjbyNySFR0ovrAT4OH_FKCyWhKBDEsJh25iqylhXs

+

Disclosure(s): WyJ4bkRsNTQ1ODlMTDVrYnRUMDlpMTRRIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd

+

Contents: [
  "xnDl54589LL5kbtT09i14Q",
  "id",
  "http://university.example/credentials/3732"
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: 0JSGaoVcZlFoVS-pOnjisd4kIKVsbP3XLmQqvrgrhKM

+

Disclosure(s): WyJ2elh5S2x3ellSWkQxTkNPWnhmclBnIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d

+

Contents: [
  "vzXyKlwzYRZD1NCOZxfrPg",
  "type",
  [
    "VerifiableCredential",
    "ExampleDegreeCredential"
  ]
]

+
+ + +
+

Claim: id

+

SHA-256 Hash: eAm2f2xrRM_7SoxDTPZl9kfO8h9ZORMsivBYVzBspmk

+

Disclosure(s): WyJXQWdpeWxiOTl5NnNkRDBqcVpsbTlRIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd

+

Contents: [
  "WAgiylb99y6sdD0jqZlm9Q",
  "id",
  "did:example:ebfeb1f712ebc6f1c276e12ec21"
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: pIc9fIjCGLDbY2UjG7pwZvPzAEeAWPB7qpVZvclwgPQ

+

Disclosure(s): WyJxanNTbW4yaVZBbENQazRXX09QWV9RIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0

+

Contents: [
  "qjsSmn2iVAlCPk4W_OPY_Q",
  "type",
  "ExampleBachelorDegree"
]

+
+
+
+
+ +
+ +

+Expressing information related to multiple subjects in a +verifiable credential is possible. The example below specifies two +subjects who are spouses. Note the use of array notation to associate +multiple subjects with the credentialSubject property. +

+ +
+
+ Example 10: Specifying multiple subjects in a verifiable credential + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": ["VerifiableCredential", "RelationshipCredential"],
+  "issuer": "https://issuer.example/issuer/123",
+  "validFrom": "2010-01-01T00:00:00Z",
+  "credentialSubject": [{
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "name": "Jayden Doe",
+    "spouse": "did:example:c276e12ec21ebfeb1f712ebc6f1"
+  }, {
+    "id": "https://subject.example/subject/8675",
+    "name": "Morgan Doe",
+    "spouse": "https://subject.example/subject/7421"
+  }]
+}
+
+ +
+ +

4.9 Validity Period

+ + +

+This specification defines the validFrom property to help an +issuer to express the date and time when a credential becomes valid and +the validUntil property to express the date and time +when a credential ceases to be valid. +

+ +

+When comparing dates and times, the calculation is done "temporally", +meaning that the string value is converted to a "temporal value" which exists +as a point on a timeline. Temporal comparisons are then performed by checking +to see where the date and time being compared are in relation to +a particular point on the timeline. +

+ +
+
validFrom
+
+If present, the value of the validFrom property MUST be a +[XMLSCHEMA11-2] +dateTimeStamp string value representing the date and time the +credential becomes valid, which could be a date and time in the future or +the past. Note that this value represents the earliest point in time at which +the information associated with the credentialSubject +property becomes valid. If a validUntil value also exists, the +validFrom value MUST express a point in time that is temporally the same or +earlier than the point in time expressed by the validUntil value. +
+
validUntil
+
+If present, the value of the validUntil property MUST be a +[XMLSCHEMA11-2] +dateTimeStamp string value representing the date and time the +credential ceases to be valid, which could be a date and time in the past +or the future. Note that this value represents the latest point in time at +which the information associated with the credentialSubject +property is valid. If a validFrom value also exists, the validUntil +value MUST express a point in time that is temporally the same or later than the +point in time expressed by the validFrom value. +
+
+ +
+
+ Example 11: Use of the validFrom and validUntil properties +
+ 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "validUntil": "2020-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "validUntil": "2020-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaejVxRHiNEeErsTWAZkLcwGTeWFjUUoeXqTuX
+eBcdSxd5V",
+    "cryptosuite": "ecdsa-rdfc-2019",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "zyC7fsRp8peCK4xGMmtdeZXTdz7Ndp77H9XeydmBYT8ZUJCfHx62oQBn
+ieY31N3SVWycJk4EFdm56eUvo1tbyZQf"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "validUntil": "2020-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:z6MktYiRGUrwMhySggEFsb7GaqwmnYxPL2FQ4bXY
+bUPedzyE",
+    "cryptosuite": "eddsa-rdfc-2022",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z3DdxMSrSd2CJ1yARtKK2S2DQHnSpd8jioxMyeK78bx3uguKCryJwpWw
+Fds5wqyPFoU9bJmtyWr1zHAoowFb7kAc4"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "validUntil": "2020-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaefuEErdxr11EqxbUY6Kqyg1WFDyVxDviNgTn
+HheVQEtMd",
+    "cryptosuite": "ecdsa-sd-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0AhVhAHC0dG_Gg57-fQMBFyrjmiIo9YnKAqPxS5qph0R8AUgz7v9k
+JWLlC8648QgxYHXblsOVu5aIAEofN0T4aofbNplgjgCQDOHJQpGz4_7UXb_saqbrFtP4OOl2Krv
+PSXz9VOHpezpZYIASOMn7SUPiWo0uEY1soElskRYmf27ST7QykfLhv4IGLhlhAoEBY4BOUxouxI
+15OXbVGySnwM01nvnkg8HrVVy20JqJjQnszjB2wPMyAFvfxWSEUDgtcvn3ndgnnlmeKRW1ftlhA
+xk-JFbmGU4P6rxMGK-T9tNe3cQir6MIl2r0hMh1D3gO0Qq-GopZQ_XkGvQAxs2YMbr8cOz1XKo8
+K08ubQIEWYlhAEGUl5mepnU2M6MOC-APrBWORw1CmDCpXIxhpOiDJ-0SCQEGnyJ8wGQr9hnS1c3
+e5AjP5iyS5HQasVdnUS7y_tVhAWt6eHT28v1D6p-cuO1i3pDJjEhoH-mHIEnLgbKGWzYMe2lDD2
+AZ89KKCy3SN1sSJ0HNfuFVkdcsJW4wuNab841hAtAkTdVp31QqQHfPgcw5lh3WE0Y0_94_zhiKu
+0GJSBJdVpVX0Q2q5y0E1EDCu6Gv74KJlueqABPRekjSa-U1ExVhAhDWqN97gYVXcUOFMEn4iD8t
+FjH9Bph-owYd1NPKe0-uWbW7PtyktyBF9pqjqlYMoxAbNh5xh6hJDkkLB3rIyboFnL2lzc3Vlcg
+"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "validUntil": "2020-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "verificationMethod": "did:key:zUC78HfmP56g14bJAYnJ11eYYdxL5oZL5cygjdjU
+ZYYtQ2Fy8bWQpT4cjy2pnraoXRidkJX84LEmzHQa1GzxnCpZwGRzZj4VampB7QyNWb8hXUBwqUA
+mh8PXati5E2QkviTpgzR",
+    "cryptosuite": "bbs-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0ChVhQji6a43zi3dByfc31UjgsXWP9RCyPTDzTCuguDbzAjy6A7iK
+VnX2XmoM1hIOjBv5uMd2t_3JDxAQzZcbOsfyA6jUjVI4TACD3oyjnpRfncehYQMP43Uz2_6ZROr
+tDIN3VDGofNQzGXJkDEdiK-_jrt6ZMKnv3N5iX7nvZR0OCXS-uXH4QQ9mW65QM5qlHOfE4GQVYY
+JVb1Iuc8U5sJ7Y-R2-kazKqPIAU0h0cDtIgnqLQMDWY0XJbO0ZGXDCt_w1vJrys9A31LmjPonEZ
+zliSnHCKmnu30eOgsaNuglz726TLGvw7kEmLryKBj9RFgvjlXehI1lggviZxsyDt9l_sM6vehQF
+B-5oO1pll4NojjZliQ6PEr_6BZy9pc3N1ZXI"
+  }
+}
+
+
+Protected Headers +
{
+  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
+  "alg": "ES256"
+}
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "validUntil": "2020-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
+
+application/vc-ld+jwt +
+
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy8xNCIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwidmFsaWRVbnRpbCI6IjIwMjAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJkZWdyZWUiOnsidHlwZSI6IkV4YW1wbGVCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fQ +.Tg1sCjdrjCIeO-vSzI_S-EpgKw8nPYciI91O982AFYaOVZVoErQ1pGg2JGyMbHFr0MqO_4BnwE2TmoaAiPqnNQ +
+
+
+
+
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "validUntil": "2020-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
+
+application/cbor-diagnostic +
+
/ cose-sign1 / 18([
+  / protected / << {
+    / alg / 1 : -35 / ES384 /
+  } >>,
+  / unprotected / {
+  },
+  / payload / h'7b224063...227d7d7d',
+  / signature / h'17d175aa...6097f4f1'
+])
+
+application/vc-ld+cose +
+d28444a1013822a05901de7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f3134222c2276616c696446726f6d223a22323031302d30312d30315431393a32333a32345a222c2276616c6964556e74696c223a22323032302d30312d30315431393a32333a32345a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d584017d175aa60af6e2ec0ddff39263ec649eddb4cebc5b7244f7bc6c58e02a2d577743e98a5674d9b0fc803edb473704bee1ca51fe4ab7e65a5e00404ba6097f4f1 +
+
+
+ +
+ + + +
    +
  • + +
    • +
  • + +
    • +
  • + +
    • +
+
+ +
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJfc2RfYWxnIjoic2hhLTI1NiIsIkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzE0IiwidmFsaWRGcm9tIjoiMjAxMC0wMS0wMVQxOToyMzoyNFoiLCJ2YWxpZFVudGlsIjoiMjAyMC0wMS0wMVQxOToyMzoyNFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsieDdFYjlXSVZSZmlLMlBERVMzT1ZsR2Z0d1hHS3o5eC0xSlliM1RKM3ZSWSJdfSwiX3NkIjpbIjZrbmZTeVN0Ry0tc1NObkpqa1BHV2c4NzBwNFBqa3NrVmZhTGt6TFNEclkiXX0sIl9zZCI6WyJIWnhSU1Zod1RhN2V2RjB0LU1oUVQyWTJ5bVdpdGpRdEs3dHFBUVBia1FzIiwiYzJEZ0haRkJTNEE0c1M3dURnZ2J3OXlHMkRTMlBXMExCenZ1VVZrcnFhWSJdfQ +.iSS6fMu7RTvUMhVTaEy9nUuhIse2csbS0S4yAi7_ixCz_iwSeSfNDeEDYIinNQuXjoHltg8WTfw8a7_rG2HISQ +~WyJUWVRJN1ZQYWlOX0g0UFd4bGRYTE9RIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd~WyJnbUFKbURlTkNldUdUNFlSNS1qb3p3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d~WyJYVjAzd0ZIZ0xmbUwxUGZua1pvMkdBIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd~WyI5dTFwZVo4Qk9mdi1uY0hzeTFDZHBBIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 +
+
+
+ 
{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES256"
}
+ 
{
  "_sd_alg": "sha-256",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2010-01-01T19:23:24Z",
  "validUntil": "2020-01-01T19:23:24Z",
  "credentialSubject": {
    "degree": {
      "name": "Bachelor of Science and Arts",
      "_sd": [
        "x7Eb9WIVRfiK2PDES3OVlGftwXGKz9x-1JYb3TJ3vRY"
      ]
    },
    "_sd": [
      "6knfSyStG--sSNnJjkPGWg870p4PjkskVfaLkzLSDrY"
    ]
  },
  "_sd": [
    "HZxRSVhwTa7evF0t-MhQT2Y2ymWitjQtK7tqAQPbkQs",
    "c2DgHZFBS4A4sS7uDggbw9yG2DS2PW0LBzvuUVkrqaY"
  ]
}
+
+
+
+
+

Claim: id

+

SHA-256 Hash: HZxRSVhwTa7evF0t-MhQT2Y2ymWitjQtK7tqAQPbkQs

+

Disclosure(s): WyJUWVRJN1ZQYWlOX0g0UFd4bGRYTE9RIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd

+

Contents: [
  "TYTI7VPaiN_H4PWxldXLOQ",
  "id",
  "http://university.example/credentials/3732"
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: c2DgHZFBS4A4sS7uDggbw9yG2DS2PW0LBzvuUVkrqaY

+

Disclosure(s): WyJnbUFKbURlTkNldUdUNFlSNS1qb3p3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d

+

Contents: [
  "gmAJmDeNCeuGT4YR5-jozw",
  "type",
  [
    "VerifiableCredential",
    "ExampleDegreeCredential"
  ]
]

+
+ + +
+

Claim: id

+

SHA-256 Hash: 6knfSyStG--sSNnJjkPGWg870p4PjkskVfaLkzLSDrY

+

Disclosure(s): WyJYVjAzd0ZIZ0xmbUwxUGZua1pvMkdBIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd

+

Contents: [
  "XV03wFHgLfmL1PfnkZo2GA",
  "id",
  "did:example:ebfeb1f712ebc6f1c276e12ec21"
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: x7Eb9WIVRfiK2PDES3OVlGftwXGKz9x-1JYb3TJ3vRY

+

Disclosure(s): WyI5dTFwZVo4Qk9mdi1uY0hzeTFDZHBBIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0

+

Contents: [
  "9u1peZ8BOfv-ncHsy1CdpA",
  "type",
  "ExampleBachelorDegree"
]

+
+
+
+
+ +
+ +
Note: Validity start period for Verifiable Credentials

+If validFrom and validUntil are not present, the +verifiable credential validity period is considered valid +indefinitely. In such cases, the verifiable credential is assumed to be +valid from the time the verifiable credential was created. +

+ +
+ +

4.10 Status

+ + +

+This specification defines the +credentialStatus property for +discovering information related to the status of a verifiable credential, such as whether it is suspended or revoked. +

+ +

+If present, the value associated with the credentialStatus property is a +single object or a set of one or more objects. The following properties +are defined for every object: +

+ +
+
id
+
+The id property is OPTIONAL. It MAY be used to provide a +unique identifier for the credential status object. If present, the +normative guidance in Section 4.4 Identifiers MUST be followed. +
+
type
+
+The type property is REQUIRED. It is used to express the +type of status information expressed by the object. The related normative +guidance in Section 4.5 Types MUST be followed. +
+
+ +

+The precise content of the credential status information is determined by +the specific credentialStatus type definition and varies +depending on factors such as whether it is simple to implement or if it is +privacy-enhancing. The value will provide enough information to determine the +current status of the credential and whether machine-readable information will +be retrievable from the URL. For example, the object could contain a link to an +external document that notes whether the credential is suspended or revoked. +

+ +
+
+ Example 12: Use of the status property + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "credentialStatus": {
+    "id": "https://university.example/credentials/status/3#94567",
+    "type": "BitstringStatusListEntry",
+    "statusPurpose": "revocation",
+    "statusListIndex": "94567",
+    "statusListCredential": "https://university.example/credentials/status/3"
+  }
+}
+
+ +

+A credential can have more than one status associated +with it, such as whether it has been revoked or suspended. +

+ +
+
+ Example 13: Use of multiple entries for the status property + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://license.example/credentials/9837",
+  "type": ["VerifiableCredential", "ExampleDrivingLicenseCredential"],
+  "issuer": "https://license.example/issuers/48",
+  "validFrom": "2020-03-14T12:10:42Z",
+  "credentialSubject": {
+    "id": "did:example:f1c276e12ec21ebfeb1f712ebc6",
+    "license": {
+      "type": "ExampleDrivingLicense",
+      "name": "License to Drive a Car"
+    }
+  },
+  "credentialStatus": [{
+    "id": "https://license.example/credentials/status/84#14278",
+    "type": "BitstringStatusListEntry",
+    "statusPurpose": "revocation",
+    "statusListIndex": "14278",
+    "statusListCredential": "https://license.example/credentials/status/84"
+  }, {
+    "id": "https://license.example/credentials/status/84#82938",
+    "type": "BitstringStatusListEntry",
+    "statusPurpose": "suspension",
+    "statusListIndex": "82938",
+    "statusListCredential": "https://license.example/credentials/status/84"
+  }]
+}
+
+ +

+Implementers are cautioned that credentials with multiple status entries +might contain conflicting information. Reconciling such conflicts is a part of +the validation process, hence part of the verifier's business logic, and +therefore out of scope for this specification. +

+ +

+Defining the data model, formats, and protocols for status schemes is out of the +scope of this specification. The Verifiable Credential Extensions document contains +available status schemes for implementers who want to implement verifiable credential status checking. +

+ +

+Credential status specifications MUST NOT enable tracking of individuals, such +as an issuer being notified (either directly or indirectly) when a +verifier is interested in a specific holder or subject. Unacceptable +approaches include "phoning home," such that every use of a credential contacts +the issuer of the credential to check the status for a specific individual, +or "pseudonymity reduction," such that every use of the credential causes a +request for information from the issuer that the issuer can use +to deduce verifier interest in a specific individual. +

+ +
+ +

4.11 Data Schemas

+ + +

+Data schemas are useful when enforcing a specific structure on a given +data collection. There are at least two types of data schemas that this +specification considers: +

+ + + +

+It is important to understand that data schemas serve a different purpose from +the @context property, which neither enforces data structure or +data syntax nor enables the definition of arbitrary encodings to alternate +representation formats. +

+

+This specification defines the following property for expressing a +data schema, which an issuer can include in the verifiable credentials +that it issues: +

+ +
+
credentialSchema
+
+

+The value of the credentialSchema property MUST be one or +more data schemas that provide verifiers with enough information to +determine whether the provided data conforms to the provided schema(s). Each +credentialSchema MUST specify its type (for example, +JsonSchema) and an id property +that MUST be a URL identifying the schema file. The specific type +definition determines the precise contents of each data schema. +

+

+If multiple schemas are present, validity is determined according to the +processing rules outlined by each associated type property. +

+
+
+ +
Note: Credential type-specific syntax checking is possible

+The credentialSchema property allows one to +annotate type definitions or lock them to specific versions of the vocabulary. +Authors of verifiable credentials can include a static version of their +vocabulary using credentialSchema that is secured by some content +integrity protection mechanism. The credentialSchema +property also makes it possible to perform syntactic checking on the +credential and to use verification mechanisms such as JSON Schema +[VC-JSON-SCHEMA] validation. +

+ +
+
+ Example 14: Using the credentialSchema property to perform JSON schema validation + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/3732",
+  "type": ["VerifiableCredential", "ExampleDegreeCredential", "ExamplePersonCredential"],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    },
+    "alumniOf": {
+      "name": "Example University"
+    }
+  },
+  "credentialSchema": [{
+    "id": "https://example.org/examples/degree.json",
+    "type": "JsonSchema"
+  },
+  {
+    "id": "https://example.org/examples/alumni.json",
+    "type": "JsonSchema"
+  }]
+}
+
+ +

+In the example above, the issuer is specifying two credentialSchema +objects, each of which point to a JSON Schema [VC-JSON-SCHEMA] file that a +verifier can use to determine whether the verifiable credential is +well-formed. +

+ +
+ +

4.12 Securing Mechanisms

+ + +

+This specification recognizes two classes of +securing mechanisms: +those that use enveloping proofs and those that use embedded proofs. +

+ +

+An enveloping proof wraps a serialization +of this data model. One such RECOMMENDED enveloping proof mechanism is defined +in Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]. +

+ +

+An embedded proof is a mechanism where the proof is +included in the serialization of the data model. One such RECOMMENDED embedded +proof mechanism is defined in Verifiable Credential Data Integrity 1.0 [VC-DATA-INTEGRITY]. +

+ +

+These two classes of securing mechanisms are not mutually exclusive. Additional +securing mechanism specifications might also be defined according to the rules +in Section 5.13 Securing Mechanism Specifications. +

+ +
+
+ Example 15: A verifiable credential using an embedded proof + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://example.gov/credentials/3732",
+  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
+  "issuer": "did:example:6fb1f712ebe12c27cc26eebfe11",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "https://subject.example/subject/3921",
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "cryptosuite": "eddsa-rdfc-2022",
+    "created": "2021-11-13T18:19:39Z",
+    "verificationMethod": "https://university.example/issuers/14#key-1",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z58DAdFfa9SkqZMVPxAQp...jQCrfFPP2oumHKtz"
+  }
+}
+
+ +

+The embedded proof above secures the original credential by decorating +the original data with a digital signature via the proof property. This +results in a verifiable credential that is easy to manage in modern +programming environments and database systems. +

+ +
+
+ Example 16: A verifiable credential that uses an enveloping proof in SD-JWT format + 
eyJhbGciOiJFUzM4NCIsImtpZCI6IkdOV2FBTDJQVlVVMkpJVDg5bTZxMGM3U3ZjNDBTLWJ2UjFTT0
+Q3REZCb1UiLCJ0eXAiOiJ2YytsZCtqc29uK3NkLWp3dCIsImN0eSI6InZjK2xkK2pzb24ifQ
+.
+eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwcz
+ovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6
+Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLT
+AxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiX3NkIjpbIlNFOHp4bmduZTNNbWEwLUNm
+S2dlYW1rNUVqU1NfOXRaNlN5NDdBdTdxRWMiLCJjT3lySEVrSlZwdEtSdURtNkNZVTREajJvRkExd0
+JQRjFHcTJnWEo1NXpzIl19LCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJh
+Y2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsibVNfSVBMa0JHcTIxbVA3Z0VRaHhOck
+E0ZXNMc1ZKQ1E5QUpZNDFLLVRQSSJdfSwiX3NkIjpbIlhTSG9iU05Md01PVl9QNkhQMHNvMnZ1clNy
+VXZ3UURYREJHQWtyTXk3TjgiXX0sIl9zZCI6WyJQNE5qWHFXa2JOc1NfRzdvdmlLdm1NOG0yckhDTm
+5XVVV2SXZBbW9jb2RZIiwieFNvSHBKUXlCNGV1dmg4SkFJdDFCd1pjNFVEOHY5S3ZOTmVLMk9OSjFC
+QSJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2
+lzc3VlcnMvNTY1MDQ5IiwiaWF0IjoxNzAzNjI1OTAxLCJleHAiOjE3MzUyNDgzMDEsImNuZiI6eyJq
+d2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsImFsZyI6IkVTMzg0IiwieCI6Inl1Zlo1SFUzcU
+NfOTRMbkI3Zklzd0hmT0swQlJra0Z5bzVhd1QyX21ld0tJWUpLMVNfR0QySVB3UjRYUTZpdFEiLCJ5
+IjoiRmEtV2pOd2NLQ1RWWHVDU2tCY3RkdHJOYzh6bXdBTTZWOWxudmxxd1QyQnRlQ0ZHNmR6ZDJoMF
+VjeXluTDg0dCJ9fX0
+.
+M7BFJB9LEV_xEylSJpP00fd_4WjrOlXshh0dUv3QgOzw2MEGIfSfi9PoCkHJH7TI0InsqkD6XZVz38
+MpeDKekgBW-RoDdJmxnifYOEJhKpJ5EN9PvA007UPi9QCaiEzX
+~
+WyJFX3F2V09NWVQ1Z3JNTkprOHNXN3BBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbG
+UvY3JlZGVudGlhbHMvMTg3MiJd
+~
+WyJTSEc4WnpfRDVRbFMwU0ZrZFUzNXlRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIi
+wgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d
+~
+WyJqZzJLRno5bTFVaGFiUGtIaHV4cXRRIiwgImlkIiwgImh0dHBzOi8vZXhhbXBsZS5vcmcvZXhhbX
+BsZXMvZGVncmVlLmpzb24iXQ
+~
+WyItQmhzaE10UnlNNUVFbGt4WGVXVm5nIiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyJ0SEFxMEUwN
+nY2ckRuUlNtSjlSUWRBIiwgImlkIiwgImRpZDpleGFtcGxlOjEyMyJd
+~
+WyJ1Ynd6bi1kS19tMzRSMGI0SG84QTBBIiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ
+
+ +

+The enveloping proof above secures the original credential by +encapsulating the original data in a digital signature envelope, resulting in a +verifiable credential that can be processed using tooling that understands +the SD-JWT format. +

+ +
+ +

4.13 Verifiable Presentations

+ + +

+Verifiable presentations MAY be used to aggregate information from +multiple verifiable credentials. +

+

+Verifiable presentations SHOULD be extremely short-lived and bound to a +challenge provided by a verifier. Details for accomplishing this depend +on the securing mechanism, the transport protocol, and verifier policies. +Unless additional requirements are defined by the particular securing mechanism +or embedding protocol, a verifier cannot generally assume that the +verifiable presentation correlates with the presented +verifiable credentials. +

+ +

+The default graph of a verifiable presentation is also referred to +as the verifiable presentation graph. +

+ + +

+The following properties are defined for a verifiable presentation: +

+ +
+
id
+
+The id property is optional. It MAY be used to provide a +unique identifier for the verifiable presentation. If present, the +normative guidance in Section 4.4 Identifiers MUST be followed. +
+
type
+
+The type property MUST be present. It is used to express the +type of verifiable presentation. One value of this property MUST be +VerifiablePresentation, but additional types MAY be included. The +related normative guidance in Section 4.5 Types MUST be followed. +
+
verifiableCredential
+
+The verifiableCredential property MAY be present. The value +MUST be one or more verifiable credential and/or +enveloped verifiable credential +objects (the values MUST NOT be non-object values such as +numbers, strings, or URLs). These objects are called +verifiable credential graphs and +MUST express information that is secured using a +securing mechanism. +See Section 5.12 Verifiable Credential Graphs for further details. +
+
holder
+
+The verifiable presentation MAY include a holder +property. If present, the value MUST be either a URL or an object +containing an id property. It is RECOMMENDED that the +URL in the holder or its id be one which, if +dereferenced, results in a document containing machine-readable information +about the holder that can be used to verify the information +expressed in the verifiable presentation. +If the holder property is absent, information about the +holder is obtained either via the securing mechanism or +does not pertain to the validation of the verifiable presentation. +
+
+ +

+The example below shows a verifiable presentation: +

+ +
+
+ Example 17: Basic structure of a presentation + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
+  "type": ["VerifiablePresentation", "ExamplePresentation"],
+  "verifiableCredential": [{ ... }]
+}
+
+ +

+The contents of the verifiableCredential property shown +above are verifiable credential +graphs, as described by this specification. +

+ +

Enveloped Verifiable Credentials

+ + +

+It is possible for a verifiable presentation to include one or more +verifiable credentials that have been secured using a securing mechanism +that "envelopes" the payload, such as Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]. +This can be accomplished by associating the verifiableCredential property with +an object that has a type of EnvelopedVerifiableCredential. +

+ +
+
EnvelopedVerifiableCredential
+
+They are used to associate an object containing an enveloped +verifiable credential with the verifiableCredential property in a +verifiable presentation. The @context property of the object MUST be +present and include a context, such as the base context +for this specification, that defines at least the id, type, and +EnvelopedVerifiableCredential terms as defined by the base context provided +by this specification. The id value of the object MUST be a data: URL +[RFC2397] that expresses a secured verifiable credential using an +enveloping security scheme, such as +Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]. The type value of the object MUST be +EnvelopedVerifiableCredential. +
+
+ +

+The example below shows a verifiable presentation that contains an +enveloped verifiable credential: +

+ +
+
+ Example 18: Basic structure of a presentation + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "type": ["VerifiablePresentation", "ExamplePresentation"],
+  "verifiableCredential": [{
+    "@context": "https://www.w3.org/ns/credentials/v2",
+    "id": "data:application/vc+sd-jwt,QzVjV...RMjU",
+    "type": "EnvelopedVerifiableCredential"
+  }]
+}
+
+ +
Note: Processing enveloped content as RDF

+It is possible that an implementer might want to process the object described in +this section and the enveloped presentation expressed by the id value in an +RDF environment and create linkages between the objects that are relevant to +RDF. The desire and mechanisms for doing so are use case dependent and will, +thus, be implementation dependent. +

+ +
+ +

Enveloped Verifiable Presentations

+ + +

+It is possible to express a verifiable presentation that has been secured +using a mechanism that "envelops" the payload, such as +Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]. This can be accomplished by using an +object that has a type of EnvelopedVerifiablePresentation. +

+ +
+
EnvelopedVerifiablePresentation
+
+Used to express an enveloped verifiable presentation. +The @context property of the object MUST be present and include a context, +such as the base context for this specification, +that defines at least the id, type, and EnvelopedVerifiablePresentation +terms as defined by the base context provided by this specification. The id +value of the object MUST be a data: URL [RFC2397] that expresses a secured +verifiable presentation using an +enveloping securing mechanism, such as +Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]. The type value of the object MUST be +EnvelopedVerifiablePresentation. +
+
+ +

+The example below shows an enveloped verifiable presentation: +

+ +
+
+ Example 19: Basic structure of an enveloped verifiable presentation + 
{
+  "@context": "https://www.w3.org/ns/credentials/v2",
+  "id": "data:application/vp+jwt,eyJraWQiO...zhwGfQ",
+  "type": "EnvelopedVerifiablePresentation"
+}
+
+ +
+ +

Presentations Using Derived Credentials

+ + +

+Some zero-knowledge cryptography schemes might enable holders to +indirectly prove they hold claims from a verifiable credential +without revealing all claims in that verifiable credential. In these +schemes, a verifiable credential might be used to derive presentable +data, which is cryptographically asserted such that a verifier can trust +the value if they trust the issuer. +

+

+Some selective disclosure schemes can share a subset of claims +derived from a verifiable credential. +

+ +
Note: Presentations using Zero-Knowledge Proofs are possible

+For an example of a ZKP-style verifiable presentation containing +derived data instead of directly embedded verifiable credentials, see +Section 5.7 Zero-Knowledge Proofs. +

+ +
+ Pat has a property + overAge whose value is 21 +
Figure 11 +A basic claim expressing that Pat is over the age of 21. +
+
+
+

Presentations Including Holder Claims

+ +

+A holder MAY use the verifiableCredential property in +a verifiable presentation to include verifiable credentials from +any issuer, including themselves. When the issuer of a +verifiable credential is the holder, the claims in that +verifiable credential are considered self-asserted. +Such self-asserted claims can be secured by the same mechanism that secures +the verifiable presentation in which they are included or by any +mechanism usable for other verifiable credentials. +

+

+The subject(s) of these self-asserted claims +are not limited, so these claims can include statements about the +holder, one of the other included verifiable credentials or even +the verifiable presentation in which the self-asserted verifiable credential is included. In each case, the id property +is used to identify the specific subject, in the object where the +claims about it are made, just as it is done in +verifiable credentials that are not self-asserted. +

+

+A verifiable presentation that includes a self-asserted +verifiable credential, which is secured only using the same mechanism as +the verifiable presentation, MUST include a holder +property. +

+

+All of the normative requirements defined for verifiable credentials +apply to self-asserted verifiable credentials. +

+

+When a self-asserted verifiable credential is secured using the same +mechanism as the verifiable presentation, the value of the +issuer property of the verifiable credential +MUST be identical to the holder property of the +verifiable presentation. +

+

+The example below shows a verifiable presentation that embeds a +self-asserted verifiable credential that is secured using the same +mechanism as the verifiable presentation. +

+ +
+
+ Example 20: A verifiable presentation, secured with an embedded Data Integrity proof, with a self-asserted verifiable credential + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "type": ["VerifiablePresentation", "ExamplePresentation"],
+  "holder": "did:example:12345678",
+  "verifiableCredential": [{
+    "@context": [
+      "https://www.w3.org/ns/credentials/v2",
+      "https://www.w3.org/ns/credentials/examples/v2"
+    ],
+    "type": ["VerifiableCredential", "ExampleFoodPreferenceCredential"],
+    "issuer": "did:example:12345678",
+    "credentialSubject": {
+      "favoriteCheese": "Gouda"
+    },
+    { ... }
+  }],
+  "proof": [{ ... }]
+}
+
+

+The example below shows a verifiable presentation that embeds a +self-asserted verifiable credential holding claims about the +verifiable presentation. It is secured using the same mechanism as the +verifiable presentation. +

+ +
+
+ Example 21: A verifiable presentation, secured with an embedded Data Integrity proof, with a self-asserted verifiable credential about the verifiable presentation + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "type": ["VerifiablePresentation", "ExamplePresentation"],
+  "id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b",
+  "holder": "did:example:12345678",
+  "verifiableCredential": [{
+    "@context": [
+      "https://www.w3.org/ns/credentials/v2",
+      "https://www.w3.org/ns/credentials/examples/v2"
+    ],
+    "type": ["VerifiableCredential", "ExampleAssertCredential"],
+    "issuer": "did:example:12345678",
+    "credentialSubject": {
+      "id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b",
+      "assertion": "This VP is submitted by the subject as evidence of a legal right to drive"
+    },
+    "proof": { ... }
+  }],
+  "proof": { ... }
+}
+
+
+
+ +
+ +

5. Advanced Concepts

+ + +

+Building on the concepts introduced in Section 4. Basic Concepts, +this section explores more complex topics about verifiable credentials. +

+ +

5.1 Trust Model

This section is non-normative.

+ + +

+The verifiable credentials trust model is based on the following +expectations: +

+ + + +

+This trust model differentiates itself from other trust models by ensuring +the following: +

+ + + +

+How verifiers decide which issuers to trust, and for what data or +purposes, is out of scope for this recommendation. Some issuers, such as +well-known organizations, might be trusted by many verifiers simply because +of their reputation. Some issuers and verifiers might be members of a +community in which all members trust each other due to the rules of membership. +Some verifiers might trust a specific trust-service provider whose +responsibility is to vet issuers and list them in a trust list such as those +specified in Electronic Signatures and Infrastructures (ESI); Trusted Lists [ETSI-TRUST-LISTS] or the +Adobe +Approved Trust List. +

+ +

+By decoupling the expectations between the issuer and the verifier, +a more flexible and dynamic trust model is created, such that market +competition and customer choice is increased. +

+ +

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

+ +
Note: Trust model differs from the traditional Certificate Authority system

+The data model detailed in this specification does not imply a transitive trust +model, such as that provided by more traditional Certificate Authority trust +models. In the Verifiable Credentials Data Model, a verifier either +directly trusts or does not trust an issuer. While it is possible to +build transitive trust models using the Verifiable Credentials Data Model, +implementers are urged to +learn +about the security weaknesses introduced by + +broadly delegating trust in the manner adopted by Certificate Authority +systems. +

+
+ +

5.2 Extensibility

+ + +

+One of the goals of the Verifiable Credentials Data Model is to enable +permissionless innovation. To achieve this, the data model needs to be +extensible in a number of different ways. The data model is required to: +

+ + + +

+This approach to data modeling is often called an +open world assumption, meaning that any entity can say anything about +any other entity. While this approach seems to conflict with building simple and +predictable software systems, balancing extensibility with program correctness +is always more challenging with an open world assumption than with closed +software systems. +

+ +

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

+ +

+Let us assume we start with the credential shown below. +

+ +
+
+ Example 22: A simple credential +
+ 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://vc.example/credentials/4643",
+  "type": ["VerifiableCredential"],
+  "issuer": "https://issuer.example/issuers/14",
+  "validFrom": "2018-02-24T05:28:04Z",
+  "credentialSubject": {
+    "id": "did:example:abcdef1234567",
+    "name": "Jane Doe"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://vc.example/credentials/4643",
+  "type": [
+    "VerifiableCredential"
+  ],
+  "issuer": "https://issuer.example/issuers/14",
+  "validFrom": "2018-02-24T05:28:04Z",
+  "credentialSubject": {
+    "id": "did:example:abcdef1234567",
+    "name": "Jane Doe"
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaejVxRHiNEeErsTWAZkLcwGTeWFjUUoeXqTuX
+eBcdSxd5V",
+    "cryptosuite": "ecdsa-rdfc-2019",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z3P13q4iUDMftCMi54LWLSShb4B3opHJpcUyMYqsSedqDWd1yzo3X9gY
+XiitAt9Q7q5jSdG4JFHCwcwya43YzDEj2"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://vc.example/credentials/4643",
+  "type": [
+    "VerifiableCredential"
+  ],
+  "issuer": "https://issuer.example/issuers/14",
+  "validFrom": "2018-02-24T05:28:04Z",
+  "credentialSubject": {
+    "id": "did:example:abcdef1234567",
+    "name": "Jane Doe"
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:z6MktYiRGUrwMhySggEFsb7GaqwmnYxPL2FQ4bXY
+bUPedzyE",
+    "cryptosuite": "eddsa-rdfc-2022",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z3a482fcJPm8tMCNWrC2Xsh5Njdy7zE7sb6vdcZKGpmLiuWrbibVdDcS
+v1f5U32SmpdtQt8fZTMnuiz147CxyrnsV"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://vc.example/credentials/4643",
+  "type": [
+    "VerifiableCredential"
+  ],
+  "issuer": "https://issuer.example/issuers/14",
+  "validFrom": "2018-02-24T05:28:04Z",
+  "credentialSubject": {
+    "id": "did:example:abcdef1234567",
+    "name": "Jane Doe"
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaefuEErdxr11EqxbUY6Kqyg1WFDyVxDviNgTn
+HheVQEtMd",
+    "cryptosuite": "ecdsa-sd-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0AhVhAP-AwNzy16CpU6yAO133-oy62pQ5p4k3D6JxHnRj36Q5A0pW
+QD63bi87PswXZmMAi6nB72Xa1wMi0ckYl5EOX8VgjgCQDDZeS01Ehm9gE42wwlnxk6hHo-R4jlQ
+cU5VppzdO2MKFYILay-MwrDAb0DDpus_wB9iplCWaYINEG_Gx-6jcIAakqg1hAaG7xO4HjbiFRG
+RFl7PR2V66Ws3CyIVlmuHDrZyinh6KmOxIQ1NQOdS_w1XCwb1pF3sXx2jRe4CRgQpt3oN36z1hA
+vMmNvy_3RMxkeox0XAM-9vKS1CCytMwb7LX9EaRNwyEd80CkCT23tCy7Tnd1XBdXd74OFTtlYUe
+NbC-WYk-N71hAt60K7pSD7givOjTa2sBDdMJ1zObF5umoSkqu4QIC2djcn13c2aYS1Ne7SwRh9S
+mwNcG9Hp9ZlOE5hcw0W6bIh4FnL2lzc3Vlcg"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://vc.example/credentials/4643",
+  "type": [
+    "VerifiableCredential"
+  ],
+  "issuer": "https://issuer.example/issuers/14",
+  "validFrom": "2018-02-24T05:28:04Z",
+  "credentialSubject": {
+    "id": "did:example:abcdef1234567",
+    "name": "Jane Doe"
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "verificationMethod": "did:key:zUC78HfmP56g14bJAYnJ11eYYdxL5oZL5cygjdjU
+ZYYtQ2Fy8bWQpT4cjy2pnraoXRidkJX84LEmzHQa1GzxnCpZwGRzZj4VampB7QyNWb8hXUBwqUA
+mh8PXati5E2QkviTpgzR",
+    "cryptosuite": "bbs-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0ChVhQivl1718Tr73fLAbR_JGfrWPH09SlSTThjchhtqhh258m2lq
+dkXWrUBsWe73f3MB2LveSq0jWRGMek16sqWGKlSQ3Ar6yu0CqcqFoKkNnKVNYQMP43Uz2_6ZROr
+tDIN3VDGofNQzGXJkDEdiK-_jrt6ZMvqENcCm8D2khyMGr7-FGFdx818_ufbFmo8hKn_2FgMpYY
+JVb1Iuc8U5sJ7Y-R2-kazKqPIAU0h0cDtIgnqLQMDWY0XJbO0ZGXDCt_w1vJrys9A31LmjPonEZ
+zliSnHCKmnu30eOgsaNuglz726TLGvw7kEmLryKBj9RFgvjlXehI1lggmxR-E1Da2UZdlinvdfB
+eqYc1cw1z3jWH7mRn77SOVAmBZy9pc3N1ZXI"
+  }
+}
+
+
+Protected Headers +
{
+  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
+  "alg": "ES256"
+}
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://vc.example/credentials/4643",
+  "type": [
+    "VerifiableCredential"
+  ],
+  "issuer": "https://issuer.example/issuers/14",
+  "validFrom": "2018-02-24T05:28:04Z",
+  "credentialSubject": {
+    "id": "did:example:abcdef1234567",
+    "name": "Jane Doe"
+  }
+}
+
+application/vc-ld+jwt +
+
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdmMuZXhhbXBsZS9jcmVkZW50aWFscy80NjQzIiwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJodHRwczovL2lzc3Vlci5leGFtcGxlL2lzc3VlcnMvMTQiLCJ2YWxpZEZyb20iOiIyMDE4LTAyLTI0VDA1OjI4OjA0WiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6YWJjZGVmMTIzNDU2NyIsIm5hbWUiOiJKYW5lIERvZSJ9fQ +.O0Kl5ooWwTj2llx6M1fLzpxY0oYzS4elrGdyw-Y96HnbDT7qcOwQBppjNHUhL3_sRucQOuBL2lSC9IxGS2OgMQ +
+
+
+
+
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://vc.example/credentials/4643",
+  "type": [
+    "VerifiableCredential"
+  ],
+  "issuer": "https://issuer.example/issuers/14",
+  "validFrom": "2018-02-24T05:28:04Z",
+  "credentialSubject": {
+    "id": "did:example:abcdef1234567",
+    "name": "Jane Doe"
+  }
+}
+
+application/cbor-diagnostic +
+
/ cose-sign1 / 18([
+  / protected / << {
+    / alg / 1 : -35 / ES384 /
+  } >>,
+  / unprotected / {
+  },
+  / payload / h'7b224063...65227d7d',
+  / signature / h'8e7b9f3e...fdb0e958'
+])
+
+application/vc-ld+cose +
+d28444a1013822a05901487b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f76632e6578616d706c652f63726564656e7469616c732f34363433222c2274797065223a5b2256657269666961626c6543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f6973737565722e6578616d706c652f697373756572732f3134222c2276616c696446726f6d223a22323031382d30322d32345430353a32383a30345a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a61626364656631323334353637222c226e616d65223a224a616e6520446f65227d7d58408e7b9f3e376de234d9cc7f2ca1216adf994a8a5759da0c48d36ed231dbfb1a4ecd55e647dce5f3ebbea99ff43d311772a2098a15db25f15ad99d9d83fdb0e958 +
+
+
+ +
+ + + +
    +
  • + +
    • +
  • + +
    • +
  • + +
    • +
+
+ +
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJfc2RfYWxnIjoic2hhLTI1NiIsIkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOiJodHRwczovL2lzc3Vlci5leGFtcGxlL2lzc3VlcnMvMTQiLCJ2YWxpZEZyb20iOiIyMDE4LTAyLTI0VDA1OjI4OjA0WiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7Im5hbWUiOiJKYW5lIERvZSIsIl9zZCI6WyJMM01OYU1HWFZWRHZUQkRSdmpOOGR5UkNFMEJuakQ5UUdkVGdfTXNBTHlRIl19LCJfc2QiOlsiWjBiX2FISk1UMUhISmRrR2xJMXZZb0p5YVY0WHdrNERQRi1uRWJUSnNTQSIsInNtZElfRGJZaEFDV1Vjb01pUjdHS2dxbWRyMV9BNXpMQ2dWSnJWRGFwNlEiXX0 +.9b46YEj6Z-uVOCTa6Flajouxn5eykosuRhBFuDeWV7jkzz9ZNFdMxYJSxdJl_XZQik3jbFO1yBW-r0kkVuOsMg +~WyJzUXhoVVBHeVQyTl9TMkFIWm5oWElnIiwgImlkIiwgImh0dHA6Ly92Yy5leGFtcGxlL2NyZWRlbnRpYWxzLzQ2NDMiXQ~WyIwZE9WcUsyNm9RNEdjNk9vLTJaa01RIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIl1d~WyJvVExVb2VpUS1TdUc3YTAyWUFYWDZ3IiwgImlkIiwgImRpZDpleGFtcGxlOmFiY2RlZjEyMzQ1NjciXQ +
+
+
+ 
{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES256"
}
+ 
{
  "_sd_alg": "sha-256",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "issuer": "https://issuer.example/issuers/14",
  "validFrom": "2018-02-24T05:28:04Z",
  "credentialSubject": {
    "name": "Jane Doe",
    "_sd": [
      "L3MNaMGXVVDvTBDRvjN8dyRCE0BnjD9QGdTg_MsALyQ"
    ]
  },
  "_sd": [
    "Z0b_aHJMT1HHJdkGlI1vYoJyaV4Xwk4DPF-nEbTJsSA",
    "smdI_DbYhACWUcoMiR7GKgqmdr1_A5zLCgVJrVDap6Q"
  ]
}
+
+
+
+
+

Claim: id

+

SHA-256 Hash: smdI_DbYhACWUcoMiR7GKgqmdr1_A5zLCgVJrVDap6Q

+

Disclosure(s): WyJzUXhoVVBHeVQyTl9TMkFIWm5oWElnIiwgImlkIiwgImh0dHA6Ly92Yy5leGFtcGxlL2NyZWRlbnRpYWxzLzQ2NDMiXQ

+

Contents: [
  "sQxhUPGyT2N_S2AHZnhXIg",
  "id",
  "http://vc.example/credentials/4643"
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: Z0b_aHJMT1HHJdkGlI1vYoJyaV4Xwk4DPF-nEbTJsSA

+

Disclosure(s): WyIwZE9WcUsyNm9RNEdjNk9vLTJaa01RIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIl1d

+

Contents: [
  "0dOVqK26oQ4Gc6Oo-2ZkMQ",
  "type",
  [
    "VerifiableCredential"
  ]
]

+
+ + +
+

Claim: id

+

SHA-256 Hash: L3MNaMGXVVDvTBDRvjN8dyRCE0BnjD9QGdTg_MsALyQ

+

Disclosure(s): WyJvVExVb2VpUS1TdUc3YTAyWUFYWDZ3IiwgImlkIiwgImRpZDpleGFtcGxlOmFiY2RlZjEyMzQ1NjciXQ

+

Contents: [
  "oTLUoeiQ-SuG7a02YAXX6w",
  "id",
  "did:example:abcdef1234567"
]

+
+
+
+
+ +
+ +

+This verifiable credential states that the entity associated with +did:example:abcdef1234567 has a name with a value of +Jane Doe. +

+ +

+Now let us assume a developer wants to extend the verifiable credential +to store two additional pieces of information: an internal corporate reference +number, and Jane's favorite food. +

+ +

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

+ +
+
+ Example 23: A JSON-LD context + 
{
+  "@context": {
+    "referenceNumber": "https://extension.example/vocab#referenceNumber",
+    "favoriteFood": "https://extension.example/vocab#favoriteFood"
+  }
+}
+
+ +

+After this JSON-LD context is created, the developer publishes it somewhere so +it is accessible to verifiers who will be processing the +verifiable credential. Assuming the above JSON-LD context is published at +https://extension.example/my-contexts/v1, we can extend this +example by including the context and adding the new properties and +credential type to the verifiable credential. +

+ +
+
+ Example 24: A verifiable credential with a custom extension + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2",
+    "https://extension.example/my-contexts/v1"
+  ],
+  "id": "http://vc.example/credentials/4643",
+  "type": ["VerifiableCredential", "CustomExt12"],
+  "issuer": "https://issuer.example/issuers/14",
+  "validFrom": "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 a +permissionless and decentralized way. The mechanism shown also ensures that +verifiable credentials created in this way provide a way to prevent +namespace conflicts and semantic ambiguity. +

+ +

+A dynamic extensibility model such as this does increase the implementation +burden. Software written for such a system has to determine whether +verifiable credentials with extensions are acceptable based on the risk +profile of the application. Some applications might accept only certain +extensions while highly secure environments might not accept any extensions. +These decisions are up to the developers of these applications and are +specifically not the domain of this specification. +

+ +

+Extension specification authors are urged to ensure that their documents, such +as JSON-LD Contexts, are highly available. Developers using these documents +might use software that produces errors when these documents cannot be +retrieved. Strategies for ensuring that extension JSON-LD contexts are always +available include bundling these documents with implementations, content +distribution networks with long caching timeframes, or using +content-addressed URLs for contexts. These approaches are covered in further +detail in Appendix +B. Contexts, Vocabularies, Types, and Credential Schemas. +

+ +

+Implementers are advised to pay close attention to the extension points in this +specification, such as in Sections 4.10 Status, 4.11 Data Schemas, +4.12 Securing Mechanisms, 5.4 Refreshing, 5.5 Terms of Use, and +5.6 Evidence. While this specification does not define concrete +implementations for those extension points, the Verifiable Credential Extensions document +provides an unofficial, curated list of extensions that developers can use from +these extension points. +

+ +

Semantic Interoperability

+ + +

+When defining new terms in an application-specific vocabulary, vocabulary +authors SHOULD follow the detailed +checklist in Best Practices for Publishing Linked Data. Specifically, the following guidance is of +particular importance: +

+ +
    +
  • +Whenever possible, it is RECOMMENDED to re-use terms — and their corresponding +URLs — defined by well-known, public vocabularies, such as Schema.org. +
    • +
  • +New terms MUST define a new URL for each term. When doing so, the +general guidelines for [LINKED-DATA] are expected to be followed, in +particular: +
      +
    • +Human-readable documentation MUST be published, describing the semantics of and +the constraints on the use of each term. +
      • +
    • +It is RECOMMENDED to also publish the collection of all new terms as a +machine-readable vocabulary using RDF Schema 1.1. +
      • +
    • +It SHOULD be possible to dereference the URL of a term, resulting in its +description and/or formal definition. +
      • +
    +
    • +
+ +

+Furthermore, a machine-readable description (that is, a +JSON-LD Context document) MUST be +published at the URL specified in the @context property for the +vocabulary. This context MUST map each term to its corresponding URL, possibly +accompanied by further constraints like the type of the property value. A +human-readable document describing the expected order of values for the +@context property is also expected to be published by any implementer +seeking interoperability. +

+ +
Note: Term redefinition is not allowed

+When processing the active +context defined by the base JSON-LD Context document defined in this specification, compliant JSON-LD-based +processors produce an error when a JSON-LD context redefines any term. +The only way to change the definition of existing terms is to introduce a new +term that clears the active context within the scope of that new term. Authors +that are interested in this feature should read about the +@protected +keyword in the JSON-LD 1.1 specification. +

+ +

+A conforming document SHOULD NOT use the +@vocab feature in production +as it can lead to JSON term clashes, resulting in semantic ambiguities with +other applications. Instead, to achieve proper interoperability, a conforming document SHOULD use JSON-LD Contexts that define all terms used by their +applications, as described earlier in Section 5.2 Extensibility. If a +conforming document does not use JSON-LD Contexts that define all terms +used, it MUST include the https://www.w3.org/ns/credentials/undefined-terms/v2 +as the last value in the @context property. +

+
+
+ + + +

5.4 Refreshing

+ + +

+It is useful for systems to enable the manual or automatic refresh of an expired +verifiable credential. For more information about validity periods for +verifiable credentials, see Section A.7 Validity Periods. +This specification defines a refreshService property, which +enables an issuer to include a link to a refresh service. +

+

+The issuer can include the refresh service as an element inside the +verifiable credential if it is intended for either the verifier or +the holder (or both), or inside the verifiable presentation if it +is intended for the holder only. In the latter case, this enables the +holder to refresh the verifiable credential before creating a +verifiable presentation to share with a verifier. In the former +case, including the refresh service inside the verifiable credential +enables either the holder or the verifier to perform future +updates of the credential. +

+

+The refresh service is only expected to be used when either the +credential has expired or the issuer does not publish +credential status information. Issuers are advised not to put the +refreshService property in a verifiable credential +that does not contain public information or whose refresh service is not +protected in some way. +

+ +
+
refreshService
+
+The value of the refreshService property MUST be one or more +refresh services that provides enough information to the recipient's software +such that the recipient can refresh the verifiable credential. Each +refreshService value MUST specify its type. The precise content of each +refresh service is determined by the specific refreshService type +definition. +
+
+ +
+
+ Example 27: Use of the refreshService property by an issuer + 
{
+  "@context": [
+    "https://www.w3.org/2018/credentials/v1",
+    "https://w3id.org/age/v1",
+    "https://w3id.org/security/suites/ed25519-2020/v1"
+  ],
+  "type": ["VerifiableCredential", "AgeVerificationCredential"],
+  "issuer": "did:key:z6MksFxi8wnHkNq4zgEskSZF45SuWQ4HndWSAVYRRGe9qDks",
+  "issuanceDate": "2024-04-03T00:00:00.000Z",
+  "expirationDate": "2024-12-15T00:00:00.000Z",
+  "name": "Age Verification Credential",
+  "credentialSubject": {
+    "overAge": 21
+  },
+  "refreshService": {
+    "type": "VerifiableCredentialRefreshService2021",
+    "url": "https://registration.provider.example/flows/reissue-age-token",
+    "refreshToken": "z2BJYfNtmWRiouWhDrbDQmC2zicUPBxsPg"
+  }
+}
+
+ +

+In the example above, the issuer specifies an automatic +refreshService that can be used by POSTing the verifiable credential to +the refresh service url. Note that this particular verifiable credential is +not intended to be shared with anyone except for the original issuer. +

+ +
Note: Non-authenticated credential refresh

+Placing a refreshService property in a +verifiable credential so that it is available to verifiers can +remove control and consent from the holder and allow the +verifiable credential to be issued directly to the verifier, +thereby bypassing the holder. +

+ +
+ +

5.5 Terms of Use

+ + +

+Terms of use can be used by an issuer or a holder to +communicate the terms under which a verifiable credential or +verifiable presentation was issued. The issuer places their terms +of use inside the verifiable credential. The holder places their +terms of use inside a verifiable presentation. This specification defines +a termsOfUse property for expressing terms of use +information. +

+ +

+The value of the termsOfUse property might be used +to tell the verifier any or all of the following, among other things: +

+ + + +
+
termsOfUse
+
+The value of the termsOfUse property MUST specify one or +more terms of use policies under which the creator issued the credential +or presentation. If the recipient (a holder or +verifier) is not willing to adhere to the specified terms of use, then +they do so on their own responsibility and might incur legal liability if they +violate the stated terms of use. Each termsOfUse value MUST specify +its type, for example, TrustFrameworkPolicy, and MAY specify its +instance id. The precise contents of each term of use is determined +by the specific termsOfUse type definition. +
+
+ +
+
+ Example 28: Use of the termsOfUse property by an issuer + 
{
+  {
+    "@context": [
+      "https://www.w3.org/ns/credentials/v2",
+      "https://www.w3.org/ns/credentials/undefined-terms/v2"
+    ],
+    "id": "urn:uuid:08e26d22-8dca-4558-9c14-6e7aa7275b9b",
+    "type": [
+      "VerifiableCredential",
+      "VerifiableAttestation",
+      "VerifiableTrustModel",
+      "VerifiableAuthorisationForTrustChain"
+    ],
+    "issuer": "did:ebsi:zZeKyEJfUTGwajhNyNX928z",
+    "validFrom": "2021-11-01T00:00:00Z",
+    "validUntil": "2024-06-22T14:11:44Z",
+    "credentialSubject": {
+      "id": "did:ebsi:zvHWX359A3CvfJnCYaAiAde",
+      "reservedAttributeId": "60ae46e4fe9adffe0bc83c5e5be825aafe6b5246676398cd1ac36b8999e088a8",
+      "permissionFor": [{
+        "schemaId": "https://api-test.ebsi.eu/trusted-schemas-registry/v3/schemas/zHgbyz9ajVuSProgyMhsiwpcp8g8aVLFRNARm51yyYZp6",
+        "types": [
+          "VerifiableCredential",
+          "VerifiableAttestation",
+          "WorkCertificate"
+        ],
+        "jurisdiction": "https://publications.europa.eu/resource/authority/atu/EUR"
+      }]
+    },
+    "termsOfUse": {
+      "type": "TrustFrameworkPolicy",
+      "trustFramework": "Employment&Life",
+      "policyId": "https://policy.example/policies/125",
+      "legalBasis": "professional qualifications directive"
+    },
+    "credentialStatus": {
+      "id": "https://api-test.ebsi.eu/trusted-issuers-registry/v5/issuers/did:ebsi:zvHWX359A3CvfJnCYaAiAde/attributes/60ae46e4fe9adffe0bc83c5e5be825aafe6b5246676398cd1ac36b8999e088a8",
+      "type": "EbsiAccreditationEntry"
+    },
+    "credentialSchema": {
+      "id": "https://api-test.ebsi.eu/trusted-schemas-registry/v3/schemas/zCSHSDwrkkd32eNjQsMCc1h8cnFaxyTXP5ByozyVQXZoH",
+      "type": "JsonSchema"
+    }
+  }
+}
+
+ +

+In the example above, the issuer is asserting that the legal basis +under which the verifiable credential has been issued is the +"professional qualifications directive" using the "Employment&Life" trust +framework, with a specific link to the policy. +

+ +

+This feature is expected to be used by government-issued verifiable credentials to instruct digital wallets to limit their use to similar +government organizations in an attempt to protect citizens from unexpected use +of sensitive data. Similarly, some verifiable credentials issued by private +industry are expected to limit use to within departments inside the +organization, or during business hours. Implementers are urged to read more +about this evolving feature in the appropriate section of the Verifiable +Credentials Implementation Guidelines [VC-IMP-GUIDE] document. +

+ +
+ +

5.6 Evidence

+ + +

+Evidence can be included by an issuer to provide the verifier with +additional supporting information in a verifiable credential. This could be +used by the verifier to establish the confidence with which it relies on the +claims in the verifiable credential. For example, an issuer could check +physical documentation provided by the subject or perform a set of +background checks before issuing the credential. In certain scenarios, this +information is useful to the verifier when determining the risk associated +with relying on a given credential. +

+ +

+This specification defines the evidence property for expressing evidence +information. +

+ +
+
evidence
+
+If present, the value of the evidence property MUST be either a single +object or a set of one or more objects. The following properties are defined +for every evidence object: +
+
id
+
+The id property is OPTIONAL. It MAY be used to provide a unique identifier +for the evidence object. If present, the normative guidance in Section +4.4 Identifiers MUST be followed. +
+
type
+
+The type property is REQUIRED. It is used to express the type of evidence +information expressed by the object. The related normative guidance in Section +4.5 Types MUST be followed. +
+
+
+
+ +
Note: See Implementation Guide for strategies for providing evidence

+For information about how attachments and references to credentials and +non-credential data might be supported by the specification, see Section +5.3 Integrity of Related Resources. +

+ +
+
+ Example 29: Example of evidence supporting a skill achievement credential + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
+  ],
+  "id": "http://1edtech.edu/credentials/3732",
+  "type": [
+    "VerifiableCredential",
+    "OpenBadgeCredential"
+  ],
+  "issuer": {
+    "id": "https://1edtech.edu/issuers/565049",
+    "type": "Profile"
+  },
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "type": "AchievementSubject",
+    "name": "Alice Smith",
+    "activityEndDate": "2023-12-02T00:00:00Z",
+    "activityStartDate": "2023-12-01T00:00:00Z",
+    "awardedDate": "2024-01-01T00:00:00Z",
+    "achievement": [{
+      "id": "urn:uuid:d46e8ef1-c647-419b-be18-5e045d1c4e64",
+      "type": ["Achievement"],
+      "name": "Basic Barista Training",
+      "criteria": {
+        "narrative": "Team members are nominated for this badge by their supervisors, after passing the Basic Barista Training course."
+      },
+      "description": "This achievement certifies that the bearer is proficient in basic barista skills."
+    }]
+  },
+  "evidence": [{
+      // url to an externally hosted evidence file/artifact
+      "id": "https://videos.example/training/alice-espresso.mp4",
+      "type": ["Evidence"],
+      "name": "Talk-aloud video of double espresso preparation",
+      "description": "This is a talk-aloud video of Alice demonstrating preparation of a double espresso drink.",
+      // digest hash of the mp4 video file
+      "digestMultibase": "uELq9FnJ5YLa5iAszyJ518bXcnlc5P7xp1u-5uJRDYKvc"
+    }
+  ]
+}
+
+

+In the evidence example above, the issuer is asserting that they have +video of the subject of the credential demonstrating the achievement. +

+ +
Note: Evidence has a different purpose from securing mechanisms

+The evidence property provides information that is different from and +information to the securing mechanism used. The evidence property is +used to express supporting information, such as documentary evidence, related to +the verifiable credential. In contrast, the securing mechanism is used to +express machine-verifiable mathematical proofs related to the authenticity of +the issuer and integrity of the verifiable credential. For more +information about securing mechanisms, see Section 4.12 Securing Mechanisms. +

+ +
+ +

5.7 Zero-Knowledge Proofs

+ + +

+Zero-knowledge proofs are securing mechanisms +which enable a holder to prove that they hold a verifiable credential +containing a value without disclosing the actual value such as being able to +prove that an individual is over the age of 25 without revealing their birthday. +This data model supports being secured using zero-knowledge proofs. +

+

+Some capabilities that are compatible with verifiable credentials which are +made possible by zero-knowledge proof mechanisms include: +

+ +

+Specification authors that create +securing mechanisms MUST NOT design them in +such a way that they leak information that would enable the verifier to +correlate a holder across multiple verifiable presentations to different +verifiers. +

+

+Not all capabilities are supported in all zero-knowledge proof mechanisms. +Specific details about the capabilities and techniques provided by a particular +zero knowledge proof mechanism, along with any normative requirements for using +them with verifiable credentials, would be found in a specification for +securing verifiable credentials with that zero-knowledge proof mechanism. +For an example of such a specification, refer to the Data Integrity BBS Cryptosuites v1.0. +

+

+We note that in most instances, for the holder to make use of zero knowledge +mechanisms with verifiable credentials, the issuer is required to secure +the verifiable credential in a manner that supports these capabilities. +

+

+The diagram below highlights how the data model might be used to issue and +present verifiable credentials in zero-knowledge. +

+ +
+ Verifiable + Credential 1 and Verifiable Credential 2 on the left map + to Derived Credential 1 and Derived Credential 2 inside a + Presentation on the right. Verifiable Credential 1 + contains Context, Type, ID, Issuer, Issue Date, Expiration + Date, CredentialSubject, and Proof, where + CredentialSubject contains GivenName, FamilyName, and + Birthdate and Proof contains Signature, Proof of + Correctness, and Attributes. Verifiable Credential 2 + contains Context, Type, ID, Issuer, Issue Date, Expiration + Date, CredentialSubject, and Proof, where + CredentialSubject contains University, which contains + Department, which contains DegreeAwarded, and Proof contains Signature, Proof of + Correctness, and Attributes. The Presentation diagram on + the right contains Context, Type, ID, + VerifiableCredential, and Proof, where + VerifiableCredential contains Derived Credential 1 and + Derived Credential 2 and Proof contains Common Link + Secret. Derived Credential 1 contains Context, Type, ID, + Issuer, Issue Date, CredentialSubject, and Proof, where + CredentialSubject contains AgeOver18 and Proof contains + Knowledge of Signature. Derived Credential 2 contains + Context, Type, ID, Issuer, Issue Date, CredentialSubject, + and Proof, where CredentialSubject contains Degree and + Proof contains Knowledge of Signature. A line links + Birthdate in Verifiable Credential 1 to AgeOver18 in + Derived Credential 1. A line links DegreeAwarded in + Verifiable Credential 2 to Degree in Derived Credential 2. +
Figure 12 +A visual example of the relationship between credentials and derived +credentials in a ZKP presentation. +
+
+ +

+An example of a verifiable credential and a verifiable presentation +using the Data Integrity BBS Cryptosuites v1.0 unlinkable selective disclosure securing mechanism is +shown below. +

+ +
+
+ Example 30: Verifiable credential using the Data Integrity BBS Cryptosuite with a Base Proof + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://w3id.org/citizenship/v3"
+  ],
+  "type": ["VerifiableCredential", "PermanentResidentCard"],
+  "issuer": {
+    "id": "did:web:credentials.utopia.example",
+    "image": "data:image/png;base64,iVBORw0KGgo...YII="
+  },
+  "identifier": "83627465",
+  "name": "Permanent Resident Card",
+  "description": "Government of Utopia Permanent Resident Card.",
+  "validFrom": "2024-08-01T00:00:00Z",
+  "validUntil": "2029-12-01T00:00:00Z",
+  "credentialSubject": {
+    "type": ["PermanentResident", "Person"],
+    "givenName": "JANE",
+    "familyName": "SMITH",
+    "gender": "Female",
+    "image": "data:image/png;base64,iVBORw0KGgoAA...Jggg==",
+    "residentSince": "2015-01-01",
+    "lprCategory": "C09",
+    "lprNumber": "999-999-999",
+    "commuterClassification": "C1",
+    "birthCountry": "Arcadia",
+    "birthDate": "1978-07-17"
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "verificationMethod": "did:web:playground.alpha.chapi.io#zUC75LjjCLGKRxSissX1nAebRDmY4Bv4T6MAbzgaap9Q8rAGf6SEjc2Hf4nH6bUPDwky3GWoYcUjMCcEqRRQfXEiNwfeDwNYLoeqk1J1W2Ye8vCdwv4fSd8AZ1yS6UoNzcsQoPS",
+    "cryptosuite": "bbs-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0ChVhQjYs9O7wUb3KRSMaIRX7jmafVHYDPYBLD4ta85_qmuXTBU_t2Ir7pNujwRE6fERsBUEZRSjJjtI-hqOqDs3VvBvH6gd3o2KeUS2V_zpuphPpYQEkapOeQgRTak9lHKSTqEQqa4j2lyHqekEeGvzPlqcHQGFccGifvLUXtP59jCuGJ86HDA9HL5kDzUT6n4Gi50HlYYIzNqhbjIxlqOuxO2IgIppSTWjQGeer34-PmKnOzKX8m_9DHPhif7TUf5uTV4OQWdhb0SxHnJ-CPu_z9FJ5ACekBQhz6YWS0_CY6j_ibucXzeVfZwLv1W47pjbt-l1Vl5VggSn2xVt69Q0GD9mPKpOhkKV_hyOL7i6haf7bq-gOKAwWDZy9pc3N1ZXJtL2lzc3VhbmNlRGF0ZW8vZXhwaXJhdGlvbkRhdGU"
+  }
+}
+
+ +

+The example above is a verifiable credential where the issuer has +enabled a BBS-based unlinkable disclosure scheme to create a base proof that +can then be used by the holder to create a derived proof that reveals only +particular pieces of information from the original verifiable credential. +

+ +
+
+ Example 31: Verifiable presentation using the Data Integrity BBS Cryptosuite with a derived credential and proof + 
{
+  @context: "https://www.w3.org/ns/credentials/v2"
+  type: "VerifiablePresentation",
+  verifiableCredential: {
+    "@context": [
+      "https://www.w3.org/ns/credentials/v2",
+      "https://w3id.org/citizenship/v3"
+    ],
+    "type": ["VerifiableCredential", "PermanentResidentCard"],
+    "issuer": {
+      "id": "did:web:issuer.utopia.example",
+      "image": "data:image/png;base64,iVBORw0KGgo...YII="
+    },
+    "name": "Permanent Resident Card",
+    "description": "Government of Utopia Permanent Resident Card.",
+    "validFrom": "2024-08-01T00:00:00Z",
+    "validUntil": "2029-12-01T00:00:00Z",
+    "credentialSubject": {
+      "type": ["PermanentResident", "Person"],
+      "birthCountry": "Arcadia"
+    },
+    "proof": {
+      type: "DataIntegrityProof",
+      verificationMethod: "did:web:issuer.utopia.example#zUC75LjjCLGKRxSissX1nAebRDmY4Bv4T6MAbzgaap9Q8rAGf6SEjc2Hf4nH6bUPDwky3GWoYcUjMCcEqRRQfXEiNwfeDwNYLoeqk1J1W2Ye8vCdwv4fSd8AZ1yS6UoNzcsQoPS",
+      cryptosuite: "bbs-2023",
+      proofPurpose: "assertionMethod",
+      proofValue: "u2V0DhVkCkLdnshxHtgeHJBBUGPBqcEooPp9ahgqs08RsoqW5EJFmsi70jqf2X368VcmfdJdYcYJwObPIg5dlyaoBm34N9BqcZ4RlTZvgwX79ivGnqLALC0EqKn2wOj5hRO76xUakfLGIcT4mE-G7CxA1FTs8sRCWy5p6FozelBYiZU2YlhUpJ7pBwelZ9wnlcbj4q-KyxAj5GU2iWp7-FxU-E624DmdT-yvCkAGRRrYej6lMwg7jB9uCHypOXXH2dVZ-jpf74YBaE4rMTxPFh60GN4o3S65F1fMsJbEMLdrXa8Vs6ZSlmveUcY1X7oPr1UIxo17ehVTCjOxWunYqrtLi9cVkYOD2s9XMk1oFVWBB3UY29axXQQXlZVfvTIUsfVc667mnlYbF7a-ko_SUfeY2n3s1DOAap5keeNU0v2KVPCbxA2WGz7UJy4xJv2a8olMOWPKjAEUruCx_dsbyicd-9KGwhYoUEO3HoAzmtI6qXVhMbJKxPrhtcp8hOdD9izVS5ed4CxHNaDGPSopF_MBwjxwPcpUufNNNdQwesrbtFJo0-P-1CrX_jSxKFMle2b3t24UbHRbZw7QnX4OG-SSVucem5jpMXTDFZ8PLFCqXX0zncJ_MQ-_u-liE-MwJu3ZemsXBp1JoB2twS0TqDVzSWR7bpFZKI9_07fKUAmQNSV_no9iAgYRLuPrnnsW1gQgCV-nNqzbcCOpzkHdCqro6nPSATq5Od3Einfc683gm5VGWxIldM0aBPytOymNz7PIZ6wkgcMABMe5Vw46B54ftW-TN5YZPDmCJ_kt7Mturn0OeQr9KJCu7S0I-SN14mL9KtGE1XDnIeR-C_YZhSA3vX4923v1l3vNFsKasqy9iEPHKM0hcogABAQCGAAECBAUGhAMJCgtYUnsiY2hhbGxlbmdlIjoiNGd2OFJyaERPdi1OSHByYlZNQlM1IiwiZG9tYWluIjoiaHR0cHM6Ly9wbGF5Z3JvdW5kLmFscGhhLmNoYXBpLmlvIn0"
+    }
+  }
+}
+
+ +

+The verifiable presentation above includes a verifiable credential that +contains an unlinkable subset of the information from the previous example and a +derived proof that the verifier can use to verify that the information +originated from the expected issuer and is bound to this particular +exchange of information. +

+ +
+ +

5.8 Representing Time

+ + +

+Implementers are urged to understand that representing and processing time +values is not as straight-forward as it might seem and have a variety of +idiosyncrasies that are not immediately obvious nor uniformly observed in +different regions of the world. For example: +

+ + + +

+These are just a few examples that illustrate that the actual time of day, as +would be seen on a clock on the wall, can exist in one region but not exist in +another region. For this reason, implementers are urged to use time values +that are more universal, such as values anchored to the Z time zone over +values that are affected by Daylight Saving/Summer Time. +

+ +

+This specification attempts to increase the number of universally recognized +combinations of dates and times, and reduce the potential for +misinterpretation of time values, by using the +dateTimeStamp construction first established by the [XMLSCHEMA11-2] specification. In +order to reduce misinterpretations between different time zones, all time values +expressed in conforming documents SHOULD be specified in dateTimeStamp +format, either in Universal Coordinated Time (UTC), denoted by a Z at the end +of the value, or with a time zone offset relative to UTC. Time values that are +incorrectly serialized without an offset MUST be interpreted as UTC. Examples of +valid time zone offsets relative to UTC include Z, +01:00, -08:00, and ++14:00. See the regular expression at the end of this section for a formal +definition of all acceptable values. +

+ +

+Time zone definitions are occasionally changed by their governing body. When +replacing or issuing new verifiable credentials, implementers are advised +to ensure that changes to local time zone rules do not result in unexpected gaps +in validity. For example, consider the zone America/Los_Angeles, which has +a raw offset of UTC-8 and had voted to stop observing daylight savings time in +the year 2024. A given verifiable credential that had a validUtil +value of 2024-07-12T12:00:00-07:00, might be re-issued to have a +validFrom value of 2024-07-12T12:00:00-08:00, which would create a gap of +an hour where the verifiable credential would not be valid. +

+ +

+Implementers that desire to check dateTimeStamp values for validity +can use the regular expression provided below, which is reproduced from the [XMLSCHEMA11-2] specification for +convenience. To avoid doubt, the regular expression in [XMLSCHEMA11-2] is the +normative definition. Implementers are advised that not all +dateTimeStamp values that pass the regular expression below are +valid moments in time. For example, the regular expression below allows for 31 +days in every month, which allows for leap years, and leap seconds, as well as +days in places where they do not exist. That said, modern system libraries that +generate dateTimeStamp values are often error-free in their +generation of valid dateTimeStamp values. The regular +expression shown below (minus the whitespace included here for readability), +is often adequate when processing library-generated dates and times on +modern systems. +

+ +
+
+ Example 32: Regular expression to detect a valid XML Schema 1.1: Part 2 dateTimeStamp + 
-?([1-9][0-9]{3,}|0[0-9]{3})
+-(0[1-9]|1[0-2])
+-(0[1-9]|[12][0-9]|3[01])
+T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?|(24:00:00(\.0+)?))
+(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))
+
+ +
+ +

5.9 Authorization

This section is non-normative.

+ + +

+Verifiable credentials are intended as a means of reliably identifying +subjects. While it is recognized that Role Based Access Controls (RBACs) +and Attribute Based Access Controls (ABACs) rely on this identification as a +means of authorizing subjects to access resources, this specification +does not provide a complete solution for RBAC or ABAC. Authorization is not an +appropriate use for this specification without an accompanying authorization +framework. +

+ +

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

+
+ +

5.10 Reserved Extension Points

+ + +

+This specification reserves a number of properties to serve as possible +extension points. While some implementers signaled interest in these properties, +their inclusion in this specification was considered to be premature. It is +important to note that none of these properties are defined by this +specification. Consequently, implementers are cautioned that use of these +properties is considered experimental. +

+

+Implementers MAY use these properties, but SHOULD expect them and/or +their meanings to change during the process of normatively specifying them. +Implementers SHOULD NOT use these properties without a publicly disclosed +specification describing their implementation. +

+ +

+In order to avoid collisions regarding how the following properties are used, +implementations MUST specify a type property in the value associated with the +reserved property. For more information related to adding type information, +see Section 4.5 Types. +

+ + + + + + + + + + + + + + + + + + + +
Reserved PropertyDescription
confidenceMethod +A property used for specifying one or more methods that a verifier might use to +increase their confidence that the value of a property in or of a verifiable +credential or verifiable presentation is accurate. The associated vocabulary +URL MUST be https://www.w3.org/2018/credentials#confidenceMethod. +
renderMethod +A property used for specifying one or more methods to render a credential into a +visual, auditory, haptic, or other format. The associated vocabulary URL MUST be +https://www.w3.org/2018/credentials#renderMethod. +
+ + +

+An unofficial list of specifications that are associated with the extension +points defined in this specification, as well as the reserved extension points +defined in this section, can be found in the Verifiable Credential Extensions. Items in the +directory that refer to reserved extension points SHOULD be treated as +experimental. +

+ +
+ +

5.11 Ecosystem Compatibility

+ + +

+There are a number of digital credential formats that do not natively use the +data model provided in this document, but are aligned with a number of concepts +in this specification. At the time of publication, examples of these digital +credential formats include + +JSON Web Tokens (JWTs), + +CBOR Web Tokens (CWTs), + +JSON Advanced Electronic Signature (JAdES), +ISO-18013-5:2021 +(mDLs), + +AnonCreds, + +Gordian Envelopes, and + +Authentic Chained Data Containers (ACDCs). +

+ +

+If conceptually aligned digital credential formats can be transformed into a +conforming document according to the rules provided in this section, they +are considered "compatible with the W3C Verifiable Credentials +ecosystem". Specification authors are advised to adhere to the following +rules when documenting transformations that enable compatibility with the +Verifiable Credentials ecosystem. The transformation specification — +

+ + + +
Note: What constitutes a verifiable credential?

+Readers are advised that a digital credential is only considered compatible with +the W3C Verifiable Credentials ecosystem if it is a conforming document +and it uses at least one securing mechanism, as described by their +respective requirements in this specification. While some communities might call +some digital credential formats that are not conforming documents +"verifiable credentials", doing so does NOT make that digital credential +compliant to this specification. +

+ +
+ +

5.12 Verifiable Credential Graphs

+ + +

+When expressing verifiable credentials (for example in a +presentation), it is important to ensure that data in one verifiable credential is not mistaken to be the same data in another verifiable credential. For example, if one has two verifiable credentials, each +containing an object of the following form: {"type": "Person", "name": "Jane +Doe"}, it is not possible to tell if one object is describing the same person +as the other object. In other words, merging data between two verifiable credentials without confirming that they are discussing the same entities +and/or properties, can lead to a corrupted data set. +

+ +

+To ensure that data from different verifiable credentials are not +accidentally co-mingled, the concept of a verifiable +credential graph is used to encapsulate each verifiable credential. +For simple verifiable credentials, that is, when the JSON-LD document +contains a single credential with, possibly, associated proofs, this graph is +the default graph. For presentations, each value associated with +the verifiableCredential property of the presentation is a separate +named graph of type VerifiableCredentialGraph +which contains a single verifiable credential or an +enveloped verifiable credential. +

+

+Using these graphs has a concrete effect when performing JSON-LD +processing, which properly separates graph node identifiers in one graph from +those in another graph. Implementers that limit their inputs to +application-specific JSON-LD documents will also need to keep this in mind if +they merge data from one verifiable credential with data from another, +such as when the credentialSubject.id is the same in both verifiable credentials, but the object might contain objects of the "Jane Doe" form +described in the previous paragraph. It is important to not merge objects that +seem to have similar properties but do not contain an id property that uses a +global identifier, such as a URL. +

+
+ +

5.13 Securing Mechanism Specifications

+ + +

+As described in Section 4.12 Securing Mechanisms, there are +multiple strategies that an implementer can use when securing a +conforming document. In order to maximize utility and interoperability, +specification authors that desire to author new ways of securing +conforming documents are provided with the guidance in this section. +

+ +

+Securing mechanism specifications MUST document normative algorithms that +provide content integrity protection for conforming documents. The +algorithms MAY be general in nature and MAY be used to secure data other than +conforming documents. +

+ +

+Securing mechanism specifications MUST provide a verification algorithm that +returns the information in the conforming document that has been secured, in +isolation, without including any securing mechanism information, such as proof or +JOSE/COSE header parameters and signatures. Verification algorithms MAY return +additional information that might be helpful (for example, during validation or +for debugging purposes), such as details of the securing mechanism. A verification +algorithm MUST provide an interface that receives a media type (string +inputMediaType) and input data (byte sequence or map inputData). +Securing mechanism specifications MAY provide algorithms and interfaces in +addition to the ones specified in this document. The verification algorithm +returns a verification result with at least the following items: +

+ +
+
boolean verified
+
+A verification status whose value is true if the verification succeeded and +false if it did not. +
+
map verifiedDocument
+
+A document that only contains information that was successfully secured. +
+
string mediaType
+
+A media type as defined in [RFC6838]. +
+
+ +

+Securing mechanism specifications SHOULD provide integrity protection for any +information referenced by a URL that is critical to validation. Mechanisms that +can achieve this protection are discussed in Section +5.3 Integrity of Related Resources and Section +B.1 Base Context. +

+ +

+A securing mechanism specification that creates a new type of embedded proof +MUST specify a property that relates the verifiable credential or +verifiable presentation to a proof graph. +The requirements on the securing mechanism are as follow: +

+ + +
Note

+The last requirement means that the securing mechanism secures the default graph and, for verifiable presentations, each verifiable credential +of the presentation, together with their respective proof graphs. +See also Figure 9 or Figure 14. +

+ +

+The proof property as defined in [VC-DATA-INTEGRITY] MAY be used by the +embedded securing mechanism. +

+ +

+Securing mechanism specifications SHOULD register the securing mechanism in the +Securing Mechanisms +section of the Verifiable Credential Extensions document. +

+ +
Note: Choice of securing mechanism is use-case dependent

+There are multiple acceptable securing mechanisms, and this specification does +not mandate any particular securing mechanism for use with +verifiable credentials or verifiable presentations. +The Working Group that produced this specification did standardize two +securing mechanism options, which are: +Verifiable Credential Data Integrity 1.0 [VC-DATA-INTEGRITY] and Securing Verifiable Credentials using JOSE and COSE +[VC-JOSE-COSE]. Other securing mechanisms that are known to the community +can be found in the +Securing Mechanisms +section of the Verifiable Credential Extensions document. +

+ +
+ +
+ +

6. Syntaxes

+ + +

+The data model as described in Sections 3. Core Data Model, +4. Basic Concepts, and 5. Advanced Concepts is the canonical structural +representation of a verifiable credential or verifiable presentation. +All syntaxes are representations of that data model in a specific format. This +section specifies how the data model is serialized in JSON-LD for +application/vc and application/vp, the base media types for verifiable credentials and verifiable presentations, respectively. Although syntactic +mappings are only provided for JSON-LD, applications and services can use any +other data representation syntax (such as XML, YAML, or CBOR) that is capable of +being mapped back to application/vc or application/vp. As the +verification and validation requirements are defined in terms of the +data model, all serialization syntaxes have to be deterministically translated +to the data model for processing, validation, or comparison. +

+ +

+The expected arity of the property values in this specification, and the +resulting datatype which holds those values, can vary depending on the property. +If present, the following properties are represented as a single value: id +(Section 4.4 Identifiers), issuer (Section 4.7 Issuer), and +validFrom/validUntil (Section 4.9 Validity Period). All other properties, +if present, are represented as either a single value or an array of values. +

+ +

6.1 JSON-LD

+ + +

+This specification uses JSON-LD 1.1 to serialize the data model described in +this specification. JSON-LD is useful because it enables the expression of the +graph-based data model on which verifiable credentials are based, +machine-readable +semantics, and is also useful when extending the data model (see Sections +3. Core Data Model and 5.2 Extensibility). +

+ +

+JSON-LD is a JSON-based format used to serialize +Linked Data. Linked +Data is modeled using Resource Description Framework (RDF) [RDF11-CONCEPTS]. +RDF is a technology for modeling graphs of statements. Each statement is a +single subject→property→value (also known as +entity→attribute→value) relationship, which is referred to as a +claim in this specification. JSON-LD is a technology that enables the +expression of RDF using idiomatic JSON, enabling developers familiar with JSON +to write applications that consume RDF as JSON. See +Relationship of JSON-LD to RDF +for more details. +

+ +

Notable JSON-LD Features

+ + +

+In general, the data model and syntax described in this document enables +developers to largely treat verifiable credentials as JSON documents, +allowing them to copy and paste examples, with minor modification, into their +software systems. The design goal of this approach is to provide a low barrier +to entry while still ensuring global interoperability between a heterogeneous +set of software systems. This section describes some of the JSON-LD features +that are used to make this possible, which will likely go unnoticed by most +developers, but whose details might be of interest to implementers. The most +noteworthy features in JSON-LD 1.1 used by this specification include: +

+ +
    +
  • +The @id and @type keywords are aliased to +id and type respectively, enabling developers to use +this specification as idiomatic JSON. +
    • +
  • +Data types, such as integers, dates, units of measure, and URLs, are +automatically typed to provide stronger type guarantees for use cases that +require them. +
    • +
  • +The verifiableCredential property +is defined as a +JSON-LD 1.1 graph +container. This requires the creation of named graphs, used to isolate +sets of data asserted by different entities. This ensures, for example, proper +cryptographic separation between the data graph provided by each issuer +and the one provided by the holder presenting the verifiable credential to ensure the provenance of the information for each graph is +preserved. +
    • +
  • +The @protected properties feature of JSON-LD 1.1 is used to ensure that +terms defined by this specification cannot be overridden. This means that as +long as the same @context declaration is made at the top of a verifiable credential or verifiable presentation, interoperability is guaranteed for +all terms understood by users of the data model whether or not they use a +JSON-LD 1.1 processor. +
    • +
+
+ +

Restrictions on JSON-LD

+ + +

+In order to increase interoperability, this specification restricts the use of +JSON-LD representations of the data model. JSON-LD compacted document +form MUST be used for all representations of the data model using the +application/vc or application/vp media type. +

+ +

+As elaborated upon in Section +6.3 Type-Specific Credential Processing, some software applications +might not perform generalized JSON-LD processing. Authors of conforming documents are advised that interoperability might be reduced if JSON-LD +keywords in the @context value are used to globally affect values in a +verifiable credential or verifiable presentation, such as by +setting either or both of the @base or @vocab keywords. For example, setting +these values might trigger a failure in a mis-implemented JSON Schema test of +the @context value in an implementation that is performing type-specific credential processing and not expecting the @base and/or @vocab value to +be expressed in the @context value. +

+ +

+In order to increase interoperability, conforming document authors are +urged to not use JSON-LD features that are not easily detected when performing +type-specific credential processing. These features include: +

+ +
    +
  • +In-line declaration of JSON-LD keywords in the @context value that globally +modify document term and value processing, such as setting @base or @vocab +
    • +
  • +Use of JSON-LD contexts that override declarations in previous contexts, such as +resetting @vocab +
    • +
  • +In-line declaration of JSON-LD contexts in the @context property +
    • +
  • +Use of full URLs for JSON-LD terms and types (for example, +https://www.w3.org/2018/credentials#VerifiableCredential or +https://vocab.example/myvocab#SomeNewType) instead of the short forms of +any such values (for example, VerifiableCredential or SomeNewType) that are +explicitly defined in JSON-LD @context mappings (for example, in +https://www.w3.org/ns/credentials/v2) +
    • +
+ +

+While this specification cautions against the use of @vocab, there are +legitimate uses of the feature, such as to ease experimentation, development, +and localized deployment. If an application developer wants to use @vocab in +production, which is advised against to reduce term collisions and leverage the +benefits of semantic interoperability, they are urged to understand that any use +of @vocab will disable reporting of "undefined term" errors, and +later use(s) will override any previous @vocab declaration(s). Different values +of @vocab can change the semantics of the information contained in the document, +so it is important to understand whether and how these changes will affect the +application being developed. +

+ +
+ +

Lists and Arrays

+ +

+Lists, arrays, and even lists of lists, are possible when using JSON-LD 1.1. +We encourage those who want RDF semantics in use cases requiring lists and +arrays to follow the guidance on +lists in JSON-LD 1.1. +

+

+In general, a JSON array is ordered, while a JSON-LD array is not ordered unless +that array uses the @list keyword. +

+
Note: Array order might not matter

+While it is possible to use this data model by performing type-specific credential processing, those who do so and make use of arrays need to be aware +that unless the above guidance is followed, the order of items in an array +are not guaranteed in JSON-LD. This might lead to unexpected behavior. +

+

+If JSON structure or ordering is important to your application, we recommend you +mark such elements as @json via an @context that is specific to your +use case. An example of such a declaration is shown below. +

+
+
+ Example 33: A @context file that defines a matrix as an embedded JSON data structure + 
{
+  "@context":
+    {
+      "matrix": {
+        "@id": "https://website.example/vocabulary#matrix",
+        "@type": "@json"
+      }
+    }
+}
+
+ +

+When the context shown above is used in the example below, by including the +https://website.example/matrix/v1 context in the @context property, the +value in credentialSubject.matrix retains its JSON semantics; the exact order +of all elements in the two dimensional matrix is preserved. +

+ +
+
+ Example 34: A verifiable credential with an embedded JSON data structure + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2",
+    "https://website.example/matrix/v1"
+  ],
+  "id": "http://university.example/credentials/1872",
+  "type": [
+    "VerifiableCredential",
+    "ExampleMatrixCredential"
+  ],
+  "issuer": "https://university.example/issuers/565049",
+  "validFrom": "2010-01-01T19:23:24Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "matrix": [
+      [1,2,3,4,5,6,7,8,9,10,11,12],
+      [1,1,1,1,1,1,1,1,0,0,0,0],
+      [0,0,1,1,1,1,1,1,1,0,0,0]
+    ]
+  }
+}
+
+
+
+

6.2 Media Types

+ + +

+Media types, as defined in [RFC6838], identify the syntax used to express a +verifiable credential as well as other useful processing guidelines. +

+

+Syntaxes used to express the data model in this specification SHOULD be +identified by a media type, and conventions outlined in this section SHOULD be +followed when defining or using media types with verifiable credentials. +

+

+There are two media types associated with the core data model, which are +listed in the Section C. IANA Considerations: +application/vc and application/vp. +

+

+The application/vc and application/vp media types do not +imply any particular securing mechanism, but are intended to be used in +conjunction with securing mechanisms. A securing mechanism needs to be applied +to protect the integrity of these media types. Do not assume security of content +regardless of the media type used to communicate it. +

+ +

Media Type Precision

This section is non-normative.

+ + +

+At times, developers or systems might use lower precision media types to convey +verifiable credentials or verifiable presentations. Some of the reasons +for use of lower precision media types include: +

+ +
    +
  • +A web server defaults to text/plain or application/octet-stream when a file +extension is not available and it cannot determine the media type. +
    • +
  • +A developer adds a file extension that leads to a media type that is less +specific than the content of the file. For example, .json could result in a +media type of application/json and .jsonld might result in a media type of +application/ld+json. +
    • +
  • +A protocol requires a less precise media type for a particular transaction; for +example, application/json instead of application/vp, +
    • +
+ +

+Implementers are urged to not raise errors when it is possible to determine the +intended media type from a payload, provided that the media type used is +acceptable in the given protocol. For example, if an application only accepts +payloads that conform to the rules associated with the application/vc media +type, but the payload is tagged with application/json or application/ld+json +instead, the application might perform the following steps to determine whether +the payload also conforms to the higher precision media type: +

+ +
    +
  1. +Parse the payload as a JSON document. +
    2. +
  2. +Ensure that the first element of the @context property matches +https://www.w3.org/ns/credentials/v2. +
    3. +
  3. +Assume an application/vp media type if the JSON document contains a top-level +type property containing a VerifiablePresentation element. Additional +subsequent checks are still expected to be performed (according to this +specification) to ensure the payload expresses a conformant +verifiable presentation. +
    4. +
  4. +Assume an application/vc media type if the JSON document contains a top-level +type property containing a VerifiableCredential element. Additional +subsequent checks are still expected to be performed (according to this +specification) to ensure the payload expresses a conformant +verifiable credential. +
    5. +
+ +

+Whenever possible, implementers are advised to use the most precise (the highest +precision) media type for all payloads defined by this specification. +Implementers are also advised to recognize that a payload tagged with a lower +precision media type does not mean that the payload does not meet the rules +necessary to tag it with a higher precision type. Similarly, a payload tagged +with a higher precision media type does not mean that the payload will meet the +requirements associated with the media type. Receivers of payloads, regardless +of their associated media type, are expected to perform appropriate checks to +ensure that payloads conform with the requirements for their use in a given +system. +

+

+HTTP clients and servers use media types associated with verifiable credentials and verifiable presentations in accept headers and when +indicating content types. Implementers are warned that HTTP servers might ignore +the accept header and return another content type, or return an error code such +as 415 Unsupported Media Type. +

+
+
+ +

6.3 Type-Specific Credential Processing

This section is non-normative.

+ + +

+As JSON can be used to express different kinds of information, a consumer of +a particular JSON document can only properly interpret the author's intent if they +possess information that contextualizes and disambiguates it from other possible +expressions. Information to assist with this interpretation can either be wholly +external to the JSON document or linked from within it. Compacted JSON-LD documents +include a @context property that internally expresses or links to +contextual information to express claims. These features +enable generalized processors to be written to convert JSON-LD documents from one +context to another, but this is not needed when consumers receive JSON-LD documents +that already use the context and shape that they expect. Authors of JSON-LD +documents, such as issuers of verifiable credentials, are required +to provide proper JSON-LD contexts and follow these rules in order to facilitate +interoperability. +

+ +

+The text below helps consumers understand how to ensure a JSON-LD document is +expressed in a context and shape that their application already understands +such that they do not need to transform it in order to consume its contents. +Notably, this does not mean that consumers do not need to understand any +context at all; rather, consuming applications only need to understand a chosen +set of contexts and document shapes to work with and not others. Issuers can +publish contexts and information about their verifiable credentials to +aid consumers who do not use generalized processors, just as can be done +with any other JSON-formatted data. +

+ +

+General JSON-LD processing is defined as a mechanism that uses a +JSON-LD software library to process a conforming document by performing +various transformations. +Type-specific credential processing is defined as a lighter-weight +mechanism for processing conforming documents, that doesn't require +a JSON-LD software library. Some consumers of verifiable credentials +only need to consume credentials with specific types. These consumers can use +type-specific credential processing instead of generalized processing. Scenarios +where type-specific credential processing can be desirable include, but are not +limited to, the following: +

+ + + +

+That is, type-specific credential processing is allowed as long as the +document being consumed or produced is a conforming document. +

+ +

+If type-specific credential processing is desired, an implementer is advised +to follow this rule: +

+Ensure that all values associated with a @context property are in the expected +order, the contents of the context files match known good cryptographic hashes +for each file, and domain experts have deemed that the contents are appropriate +for the intended use case. +

+ +

+Using static context files with a JSON Schema is one acceptable approach to +implementing the rule above. This can ensure proper term identification, +typing, and order, when performing type-specific credential processing. +

+ +

+The rule above guarantees semantic interoperability between the two processing +mechanisms for mapping literal JSON keys to URIs via the @context mechanism. +While general JSON-LD processing can use previously unseen @context +values provided in its algorithms to verify that all terms are correctly +specified, implementations that perform type-specific credential processing only accept specific @context values which the implementation +is engineered ahead of time to understand, resulting in the same semantics +without invoking any JSON-LD APIs. In other words, the context in which the data +exchange happens is explicitly stated for both processing mechanisms by using +@context in a way that leads to the same conforming document semantics. +

+ +
+ +
+ +

7. Algorithms

+ + +

+This section contains algorithms that can be used by implementations to perform +common operations, such as verification. Conformance requirements phrased as +algorithms use normative concepts from the Infra Standard [INFRA]. See the +section on Algorithm Conformance +in the Infra Standard for more guidance on implementation requirements. +

+ +
Note: Implementers can include additional checks, warnings, and errors.

+Implementers are advised that the algorithms in this section contain the bare +minimum set of checks used by implementations to test conformance to this +specification. Implementations are expected to provide additional checks that +report helpful warnings for developers to help debug potential issues. +Similarly, implementations are likely to provide additional checks that +could result in new types of errors being reported in order to stop harmful +content. Any of these additional checks might be integrated into future +versions of this specification. +

+ +

7.1 Verification

+ + +

+This section contains an algorithm that conforming verifier implementations +MUST run when verifying a verifiable credential or a verifiable presentation. This algorithm takes a media type (string inputMediaType) +and secured data (byte sequence inputData) and returns a map that +contains the following: +

+ + + +

+The verification algorithm is as follows: +

+ +
    +
  1. +Ensure that the securing mechanism has properly protected the +conforming document by performing the following steps: +
      +
    1. +Set the verifyProof function by using the inputMediaType and the +Securing Mechanisms +section of the Verifiable Credential Extensions document, or other mechanisms known to the +implementation, to determine the cryptographic suite to use when verifying the +securing mechanism. The verifyProof function MUST implement the interface +described in 5.13 Securing Mechanism Specifications. +
      2. +
    2. +If the verifyProof function expects a byte sequence, provide +inputMediaType and inputData to the algorithm. If the verifyProof function +expects a map, provide inputMediaType and the result of parsing JSON bytes to an Infra value given inputData. Set result to the result of the +call to the verifyProof function. If the call was successful, result will +contain the status, document, mediaType, controller, +controllerDocument, warnings, and errors properties. +
      3. +
    3. +If result.status is set to false, add a +CRYPTOGRAPHIC_SECURITY_ERROR to +result.errors. +
      4. +
    +
    2. +
  2. +If result.status is set to true, ensure that +result.document is a conforming document. If it is +not, set result.status to false, remove the +document property from result, and add at least +one MALFORMED_VALUE_ERROR to +result.errors. Other warnings and errors MAY be included +to aid any debugging process. +
    3. +
  3. +Return result. +
    4. +
+ +

+The steps for verifying the state of the securing mechanism and verifying +that the input document is a conforming document MAY be performed in +a different order than that provided above as long as the +implementation returns errors for the same invalid inputs. +Implementations MAY produce different errors than described above. +

+ +
+ +

7.2 Problem Details

+ + +

+When an implementation detects an anomaly while processing a document, a +ProblemDetails object can be used to report the issue to other +software systems. The interface for these objects follow [RFC9457] +to encode the data. A ProblemDetails object consists of the following +properties: +

+ +
+
type
+
+The type property MUST be present and its value MUST be a URL +identifying the type of problem. +
+
title
+
+The title property MUST be present and its value SHOULD provide a short +but specific human-readable string for the problem. +
+
detail
+
+The detail property MUST be present and its value SHOULD provide a +longer human-readable string for the problem. +
+
+ +

+The following problem description types are defined by this specification: +

+ +
+
+https://www.w3.org/TR/vc-data-model#PARSING_ERROR +
+
+There was an error while parsing input. +
+
+https://www.w3.org/TR/vc-data-model#CRYPTOGRAPHIC_SECURITY_ERROR +
+
+The securing mechanism for the document has detected a +modification in the contents of the document since it was created; +potential tampering detected. See Section +7.1 Verification. +
+
+https://www.w3.org/TR/vc-data-model#MALFORMED_VALUE_ERROR +
+
+The value associated with a particular property is malformed. The +name of the property and the path to the property SHOULD be provided +in the ProblemDetails object. See Section +7.1 Verification. +
+
+https://www.w3.org/TR/vc-data-model#RANGE_ERROR +
+
+A provided value is outside of the expected range of an associated value, +such as a given index value for an array being larger than the current size +of the array. +
+
+ +

+Implementations MAY extend the ProblemDetails object by specifying +additional types or properties. See the +Extension Member section +in [RFC9457] for further guidance on using this mechanism. +

+ +
+ +
+ +

8. Privacy Considerations

This section is non-normative.

+ + +

+This section details the general privacy considerations and specific privacy +implications of deploying the Verifiable Credentials Data Model into production +environments. +

+ +

8.1 Spectrum of Privacy

This section is non-normative.

+ + +

+It is important to recognize there is a spectrum of privacy ranging from +pseudonymous to strongly identified. Depending on the use case, people have +different comfort levels about the information they are willing to provide +and the information that can be derived from it. +

+ +
+ Horizontal bar with + red on the left, orange in the middle, and green on the + right. The red has the text 'Highly correlatable (global + IDs), for example, government ID, shipping address, credit card + number'. The orange has the text 'Correlatable via collusion + (personally identifiable info), for example, name, birthday, zip + code'. The green has the text 'Non-correlatable + (pseudonyms), for example, age over 21'. +
Figure 13 +Privacy spectrum ranging from pseudonymous to fully identified. +
+
+ +

+Privacy solutions are use case specific. +For example, many people would prefer to remain anonymous when purchasing +alcohol because the regulation is only to verify whether a purchaser is +above a specific age. In contrast, when filling prescriptions written by +a medical professional for a patient, the pharmacy is legally required +to more strongly identify both the prescriber and the patient. No single +approach to privacy works for all use cases. +

+ +
Note: Proof of age might be insufficient for some use cases

+Even those who want to remain anonymous when purchasing alcohol might need +to provide photo identification to appropriately assure the merchant. The +merchant might not need to know your name or any details other than that +you are over a specific age, but in many cases, simple proof of age might +be insufficient to meet regulations. +

+ +

+The Verifiable Credentials Data Model strives to support the full privacy +spectrum and does not take philosophical positions on the correct level of +anonymity for any specific transaction. The following sections will guide +implementers who want to avoid specific scenarios that are hostile to +privacy. +

+
+ +

8.2 Software Trust Boundaries

This section is non-normative.

+ + +

+A variety of trust relationships exist in the +ecosystem described by this specification. An +individual using a web browser trusts the web browser, also known as a user agent, to preserve +that trust by not uploading their personal information to a data broker; +similarly, entities filling the roles in the ecosystem described by this +specification trust the software that operates on behalf of each of those roles. +Examples include the following: +

+ + + +

+The examples above are not exhaustive, and the users in these roles can also +expect various other things from the software they use to achieve their +goals. In short, the user expects the software to operate in the user's best +interests; any violations of this expectation breach trust and can lead to the +software's replacement with a more trustworthy alternative. Implementers are +strongly encouraged to create software that preserves user trust. Additionally, +they are encouraged to include auditing features that enable users or trusted +third parties to verify that the software is operating in alignment with their +best interests. +

+ +

+Readers are advised that some software, like a website providing services +to a single verifier and multiple holders, might operate as a +user agent to both +roles but might not always be able to operate simultaneously in the best +interests of all parties. For example, suppose a website detects an attempt at +fraudulent verifiable credential use among multiple holders. In that +case, it might report such an anomaly to the verifier, which might be +considered not to be in all holders' best interest, but would be in the +best interest of the verifier and any holders not committing +such a violation. It is imperative that when software operates in this manner, +it is made clear in whose best interest(s) the software is operating, through +mechanisms such as a website use policy. +

+
+ +

8.3 Personally Identifiable Information

This section is non-normative.

+ + +

+Data associated with verifiable credentials stored in the +credential.credentialSubject property is susceptible to privacy violations +when shared with verifiers. Personally identifying data, such as a +government-issued identifier, shipping address, or full name, can be easily +used to determine, track, and correlate an entity. Even information that +does not seem personally identifiable, such as the combination of a +birthdate and a postal code, has powerful correlation and de-anonymization +capabilities. +

+ +

+Implementers of software used by holders are strongly advised to warn +holders when they share data with these kinds of characteristics. +Issuers are strongly advised to provide privacy-protecting verifiable credentials when possible — for example, by issuing ageOver verifiable credentials instead of dateOfBirth verifiable credentials for use when a +verifier wants to determine whether an entity is at least 18 years of age. +

+ +

+Because a verifiable credential often contains personally identifiable +information (PII), implementers are strongly advised to use mechanisms while +storing and transporting verifiable credentials that protect the data from +those who ought not have access to it. Mechanisms that could be considered include +Transport Layer Security (TLS) or other means of encrypting the data while in +transit, as well as encryption or access control mechanisms to protect +the data in a verifiable credential when at rest. +

+ +

+Generally, individuals are advised to assume that a verifiable credential, +like most physical credentials, will leak personally identifiable information +when shared. To combat such leakage, verifiable credentials and their +securing mechanisms need to be carefully designed to prevent correlation. +Verifiable credentials specifically designed to protect against leakage +of personally identifiable information are available. Individuals and +implementers are encouraged to choose these credential types over those not +designed to protect personally identifiable information. +

+
+ +

8.4 Identifier-Based Correlation

This section is non-normative.

+ + +

+Verifiable credentials might contain long-lived identifiers that could be +used to correlate individuals. These identifiers include subject +identifiers, email addresses, government-issued identifiers, organization-issued +identifiers, addresses, healthcare vitals, and many other long-lived +identifiers. Implementers of software for holders are encouraged to +detect identifiers in verifiable credentials that could be used +to correlate individuals and to warn holders before they share this +information. The rest of this section elaborates on guidance related to +using long-lived identifiers. +

+ +

+Subjects of verifiable credentials are identified using the id +property, as defined in Section 4.4 Identifiers and used in places such +as the credentialSubject.id property. The identifiers used to identify a +subject create a greater correlation risk when the identifiers are +long-lived or used across more than one web domain. Other types of identifiers +that fall into this category are email addresses, government-issued identifiers, +and organization-issued identifiers. +

+ +

+Similarly, disclosing the credential identifier (as in +Example 3) can lead to situations where multiple +verifiers, or an issuer and a verifier, can collude to correlate the +holder. +

+ +

+Holders aiming to reduce correlation are encouraged to use verifiable credentials from issuers that support selectively disclosing correlating +identifiers in a verifiable presentation. Such approaches expect the +holder to generate the identifier and might even allow hiding the identifier +from the issuer through techniques like +blind signatures, +while still keeping the identifier embedded and signed in the verifiable credential. +

+ +

+Securing mechanism specification authors are advised to avoid enabling +identifier-based correlation by designing their technologies to avoid the use +of correlating identifiers that cannot be selectively disclosed. +

+ +

+If strong anti-correlation properties are required in a verifiable credentials system, it is essential that identifiers meet one or more +of the following criteria: +

+ + +
+ +

8.5 Signature-Based Correlation

This section is non-normative.

+ + +

+The contents of a verifiable credential are secured using a securing mechanism. Values representing the securing mechanism pose a greater +risk of correlation when they remain the same across multiple sessions +or domains. Examples of these include the following values: +

+ + + +

+When strong anti-correlation properties are required, issuers are encouraged +to produce verifiable credentials where signature values and metadata can +be regenerated for each verifiable presentation. This can be achieved using +technologies that support unlinkable disclosure, such as the Data Integrity BBS Cryptosuites v1.0 +specification. When possible, verifiers are encouraged to prefer +verifiable presentations that use this technology in order to enhance +privacy for holders and subjects. +

+ +
Note: Unlinkability is not a complete solution

+Even with unlinkable signatures, a verifiable credential might contain +other information that undermines the anti-correlation properties of the +cryptography used. See Sections 8.3 Personally Identifiable Information, +8.4 Identifier-Based Correlation, 8.6 Metadata-based Correlation, +8.11 Correlation During Validation, and most other subsections of +Section 8. Privacy Considerations. +

+
+ +

8.6 Metadata-based Correlation

This section is non-normative.

+ + +

+Different extension points, such as those described in Section +4. Basic Concepts and Section 5. Advanced Concepts, can +unintentionally or undesirably serve as a correlation mechanism, if relatively +few issuers use a specific extension type or combination of types. +For example, using certain cryptographic methods unique to particular +nation-states, revocation formats specific to certain jurisdictions, +or credential types employed by specific localities, can serve as mechanisms +that reduce the pseudonymity a holder might expect when selectively +disclosing information to a verifier. +

+ +

+Issuers are encouraged to minimize metadata-based correlation risks when +issuing verifiable credentials intended for pseudonymous use by limiting +the types of extensions that could reduce the holder's pseudonymity. +Credential types, extensions, and technology profiles with global adoption are +most preferable, followed by those with national use; those with only local +use are least preferable. +

+
+ +

8.7 Device Tracking and Fingerprinting

This section is non-normative.

+ + +

+There are mechanisms external to verifiable credentials that +track and correlate individuals on the Internet and the Web. These +mechanisms include Internet protocol (IP) address tracking, web browser +fingerprinting, evercookies, advertising network trackers, mobile network +position information, and in-application Global Positioning System (GPS) APIs. +Using verifiable credentials cannot prevent the use of these other +tracking technologies; rather, using these technologies alongside +verifiable credentials can reveal new correlatable information. For +instance, a birthdate combined with a GPS position can strongly correlate +an individual across multiple websites. +

+ +

+Privacy-respecting systems ought to aim to prevent the combination of other +tracking technologies with verifiable credentials. In some instances, +tracking technologies might need to be disabled on devices that +transmit verifiable credentials on behalf of a holder. +

+ +

+The Oblivious HTTP protocol [RFC9458] is one mechanism implementers +might consider using when fetching external resources associated with a +verifiable credential or a verifiable presentation. +Oblivious HTTP allows a client to make multiple requests to an origin server +without that server being able to link those requests to that client or even to +identify those requests as having come from a single client, while placing only +limited trust in the nodes used to forward the messages. Oblivious HTTP +is one privacy-preserving mechanism that can reduce the possibility +of device tracking and fingerprinting. Below are some concrete examples of +ways that Oblivious HTTP can benefit ecosystem participants. +

+ + +
+ +

8.8 Favor Abstract Claims

This section is non-normative.

+ + +

+Issuers are encouraged to limit the information included in a verifiable credential to the smallest set required for the intended purposes, so as to +allow recipients to use them in various situations without disclosing more +personally identifiable information (PII) than necessary. One way to avoid +placing PII in a verifiable credential is to use an abstract property +that meets the needs of verifiers without providing overly specific +information about a subject. +

+

+For example, this document uses the ageOver property +instead of a specific birthdate, which would represent more sensitive PII. If +retailers in a particular market commonly require purchasers to be older than +a certain age, an issuer trusted in that market might choose to offer +verifiable credentials that claim that subjects have met that +requirement rather than offering verifiable credentials that contain +claims about the customers' birthdays. This practice enables individual +customers to make purchases without disclosing more PII than necessary. +

+
+ +

8.9 The Principle of Data Minimization

This section is non-normative.

+ + +

+Privacy violations occur when information divulged in one context leaks into +another. One accepted best practice for preventing such a violation is for +verifiers to limit the information requested and received, to the absolute +minimum necessary for a particular transaction. Regulations in multiple +jurisdictions, including the Health Insurance Portability and Accountability +Act (HIPAA) in the United States and the General Data Protection Regulation +(GDPR) in the European Union, mandate this data minimization approach. +

+

+With verifiable credentials, data minimization for issuers means +limiting the content of a verifiable credential to the minimum required by +potential verifiers for expected use. For verifiers, data minimization +means restricting the scope of information requested or required for +accessing services. +

+

+For example, a driver's license containing a driver's ID number, height, weight, +birthday, and home address expressed as a verifiable credential contains +more information than is necessary to establish that the person is above a +certain age. +

+ +

+It is considered best practice for issuers to atomize information or use a +securing mechanism that allows for selective disclosure. For example, an +issuer of driver's licenses could issue a verifiable credential +containing every property that appears on a driver's license, and allow the +holder to disclose each property selectively. It could also issue more +abstract verifiable credentials (for example, a verifiable credential +containing only an ageOver property). One possible adaptation would be for +issuers to provide secure HTTP endpoints for retrieving single-use bearer credentials that promote the pseudonymous use of verifiable credentials. +Implementers that find this impractical or unsafe might consider using +selective disclosure schemes that eliminate dependence on issuers at +proving time and reduce the risk of temporal correlation by issuers. +

+ +

+Verifiers are urged to only request information that is strictly necessary +for a specific transaction to occur. This is important for at least +two reasons: +

+ + + +

+Implementers of software used by holders are encouraged to disclose the +information being requested by a verifier, allowing the holder to +decline to share specific information that is unnecessary for the +transaction. Implementers of software used by holders are also advised +to give holders access to logs of information shared with verifiers, +enabling the holders to provide this information to authorities if they +believe that they have been subjected to information overreach or coerced to +share more information than necessary for a particular transaction. +

+ +
Note: Minimum disclosure can still lead to unique identification

+While it is possible to practice the principle of minimum disclosure, it might +be impossible to avoid the strong identification of an individual for +specific use cases during a single session or over multiple sessions. The +authors of this document cannot stress how difficult it is to meet this +principle in real-world scenarios. +

+
+ +

8.10 Bearer Credentials

This section is non-normative.

+ + +

+A bearer credential is a +privacy-enhancing piece of information, such as a concert ticket, that entitles +its holder to a specific resource without requiring the holder to +divulge sensitive information. In low-risk scenarios, entities often use bearer +credentials where multiple holders presenting the same verifiable credential +is not a concern or would not result in large economic or reputational losses. +

+ +

+Verifiable credentials that are bearer credentials are made +possible by not specifying the subject identifier, expressed using the +id property, which is nested in the +credentialSubject property. For example, the following +verifiable credential is a bearer credential: +

+ +
+
+ Example 35: Use of issuer properties +
+ 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/temporary/28934792387492384",
+  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2017-10-22T12:23:48Z",
+  "credentialSubject": {
+    // note that the 'id' property is not specified for bearer credentials
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/temporary/28934792387492384"
+,
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2017-10-22T12:23:48Z",
+  "credentialSubject": {
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaejVxRHiNEeErsTWAZkLcwGTeWFjUUoeXqTuX
+eBcdSxd5V",
+    "cryptosuite": "ecdsa-rdfc-2019",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z59ghS7rnjvFxh7FV3p6BeeF4MSoBykbnXTrmivAgJmjoGmSQh8Tv4Vs
+LQadn2HBKx7riKtDErDv2w5nmhNsCW3Fr"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/temporary/28934792387492384"
+,
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2017-10-22T12:23:48Z",
+  "credentialSubject": {
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:z6MktYiRGUrwMhySggEFsb7GaqwmnYxPL2FQ4bXY
+bUPedzyE",
+    "cryptosuite": "eddsa-rdfc-2022",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z3dk5o13NC93pWC5LgMxDNq3NfWfBXPxMdzb2zbBLXpmnmFvyVE2oCNE
+hF91ETERz8cTPK2G63HLQMgAFBLu1AhpL"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/temporary/28934792387492384"
+,
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2017-10-22T12:23:48Z",
+  "credentialSubject": {
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "created": "2024-10-05T21:25:38Z",
+    "verificationMethod": "did:key:zDnaefuEErdxr11EqxbUY6Kqyg1WFDyVxDviNgTn
+HheVQEtMd",
+    "cryptosuite": "ecdsa-sd-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0AhVhAiGCY5EHfTxnzTPtky-L_2Qbd-uP9WpF89iQC1PiFqKmAlzu
+eso8K6PC5gymQu39B_jJ2gwpN23Um4qO5vkJxGlgjgCQDSFOPUbVHnDgbwjdRfjqVjDodYb7sey
+58_OrzclqXPSVYIH0cXvYNStqNX9hknS3PSPh1WtdE2SuOTHSpRrsSrlNGhVhACHjysoYlPPCW1
+MG-CAAb1sYwla0yU8-YqElIphT4CSYvb9yGb-q3XbIR_LMEweOEW6jC_nNreNHGp8d1U_ujZlhA
+qYpBlkBPwawVARwb-Ey7kkCsYTbmd6lwaRBugqMnVhr3cpifKPzsQd_kd2IggDyKkilYY2KHyn9
+3n6rd2JdHllhAxi0aWAhLAsT8GH_7r01-wGiB0lNHf3KUv8O5Rcc60A12BZj2Wnk6FKOxV5XUUe
+KjbNu1wge2qDkzjIw8QJCEL1hAl2M16yZcZ6T2gyiGyvx19XjOwz-Hnr4gANaYFs6kzhp7eNd4n
+u1nhTHbFvQHnxkZ-n6j1Pue2SU61oAFoyKpalhAUbHKh3CqceCa3ZxYRgnG2xFb3zrPvwkwQ14H
+PpaMCc9cdFQBN3CgAohxON7SUgPHQJyHKIhn6i-V39W57DtIYYFnL2lzc3Vlcg"
+  }
+}
application/vc + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/temporary/28934792387492384"
+,
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2017-10-22T12:23:48Z",
+  "credentialSubject": {
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "proof": {
+    "type": "DataIntegrityProof",
+    "verificationMethod": "did:key:zUC78HfmP56g14bJAYnJ11eYYdxL5oZL5cygjdjU
+ZYYtQ2Fy8bWQpT4cjy2pnraoXRidkJX84LEmzHQa1GzxnCpZwGRzZj4VampB7QyNWb8hXUBwqUA
+mh8PXati5E2QkviTpgzR",
+    "cryptosuite": "bbs-2023",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "u2V0ChVhQlO-unB-xREG5rtHclDPEqrQAbvunAXG6LOdf_y8-9yNgj7B
+lHCsWlkfJ5L0_byZZSTrXKoERZBhhzH4p5hgdQ9b-u_XgFrefY6VgfyIEvSFYQMP43Uz2_6ZROr
+tDIN3VDGofNQzGXJkDEdiK-_jrt6ZMdrHmhnEXifHmmlKM3zCnc0pq4l3ZkBkIESZ4DrQomVNYY
+JVb1Iuc8U5sJ7Y-R2-kazKqPIAU0h0cDtIgnqLQMDWY0XJbO0ZGXDCt_w1vJrys9A31LmjPonEZ
+zliSnHCKmnu30eOgsaNuglz726TLGvw7kEmLryKBj9RFgvjlXehI1lggfsBLKHUbLOqa70i-zQ1
+a4TEXF64PIEna4_wuFY169bKBZy9pc3N1ZXI"
+  }
+}
+
+
+Protected Headers +
{
+  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
+  "alg": "ES256"
+}
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/temporary/28934792387492384",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2017-10-22T12:23:48Z",
+  "credentialSubject": {
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
+
+application/vc-ld+jwt +
+
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzL3RlbXBvcmFyeS8yODkzNDc5MjM4NzQ5MjM4NCIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJFeGFtcGxlRGVncmVlQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzE0IiwidmFsaWRGcm9tIjoiMjAxNy0xMC0yMlQxMjoyMzo0OFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsidHlwZSI6IkV4YW1wbGVCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fQ +.zYMAMfyW14ScJkuSHUg_3fjJa6enf981UtKB-k6Oc2jas6kG5SSETS-tnbDG6xYiv_MIbKFaAb0Zx7Ow81kglA +
+
+
+
+
+
+application/vc +
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://www.w3.org/ns/credentials/examples/v2"
+  ],
+  "id": "http://university.example/credentials/temporary/28934792387492384",
+  "type": [
+    "VerifiableCredential",
+    "ExampleDegreeCredential"
+  ],
+  "issuer": "https://university.example/issuers/14",
+  "validFrom": "2017-10-22T12:23:48Z",
+  "credentialSubject": {
+    "degree": {
+      "type": "ExampleBachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  }
+}
+
+application/cbor-diagnostic +
+
/ cose-sign1 / 18([
+  / protected / << {
+    / alg / 1 : -35 / ES384 /
+  } >>,
+  / unprotected / {
+  },
+  / payload / h'7b224063...227d7d7d',
+  / signature / h'7a579395...85b63866'
+])
+
+application/vc-ld+cose +
+d28444a1013822a05901a27b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f74656d706f726172792f3238393334373932333837343932333834222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f3134222c2276616c696446726f6d223a22323031372d31302d32325431323a32333a34385a222c2263726564656e7469616c5375626a656374223a7b22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d58407a579395a34ee8b0581ec2b5f174cdef73a2fc13d10526223574ce08ee4b49ed58586c10b13111a221da02f97cbd5e66b16b0918ae36db8a38e8853185b63866 +
+
+
+ +
+ + + +
    +
  • + +
    • +
  • + +
    • +
  • + +
    • +
+
+ +
+eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ +.eyJfc2RfYWxnIjoic2hhLTI1NiIsIkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzE0IiwidmFsaWRGcm9tIjoiMjAxNy0xMC0yMlQxMjoyMzo0OFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsiMklJTWViN3hkS1ptanJoRmJ4bE9rWkpOdF9JbnI2Q3hZUVk0blpmbFUtMCJdfX0sIl9zZCI6WyJPOEFqTnlnZ0cyV3RWTGVLRUh4VEprM3ZZejVNb1lQRXhhRmV0YVN3bDRFIiwibkJmQllieExnZ01Na1JURmpFc1R6X3RwaXJmeFVUMHpxUmhyNkYybDUzcyJdfQ +.RskPnoJ6yDtNEqUI3adr5xQkInmTG0FvxQ2i594pav2FyEJJNPFUf88vGTyHdHsikrGGeEHX5UWkth3DeDqotQ +~WyJJeTVQdENoR0F3dEFtWHgyeDZVcG1BIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvdGVtcG9yYXJ5LzI4OTM0NzkyMzg3NDkyMzg0Il0~WyJuSTVRenZEN3lMdFdiRVpvMjc0eWJRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d~WyJyVUVrQW9Fd3ZMX2c4dnJyY1NzNjFRIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 +
+
+
+ 
{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES256"
}
+ 
{
  "_sd_alg": "sha-256",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2017-10-22T12:23:48Z",
  "credentialSubject": {
    "degree": {
      "name": "Bachelor of Science and Arts",
      "_sd": [
        "2IIMeb7xdKZmjrhFbxlOkZJNt_Inr6CxYQY4nZflU-0"
      ]
    }
  },
  "_sd": [
    "O8AjNyggG2WtVLeKEHxTJk3vYz5MoYPExaFetaSwl4E",
    "nBfBYbxLggMMkRTFjEsTz_tpirfxUT0zqRhr6F2l53s"
  ]
}
+
+
+
+
+

Claim: id

+

SHA-256 Hash: nBfBYbxLggMMkRTFjEsTz_tpirfxUT0zqRhr6F2l53s

+

Disclosure(s): WyJJeTVQdENoR0F3dEFtWHgyeDZVcG1BIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvdGVtcG9yYXJ5LzI4OTM0NzkyMzg3NDkyMzg0Il0

+

Contents: [
  "Iy5PtChGAwtAmXx2x6UpmA",
  "id",
  "http://university.example/credentials/temporary/28934792387492384"
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: O8AjNyggG2WtVLeKEHxTJk3vYz5MoYPExaFetaSwl4E

+

Disclosure(s): WyJuSTVRenZEN3lMdFdiRVpvMjc0eWJRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d

+

Contents: [
  "nI5QzvD7yLtWbEZo274ybQ",
  "type",
  [
    "VerifiableCredential",
    "ExampleDegreeCredential"
  ]
]

+
+ + +
+

Claim: type

+

SHA-256 Hash: 2IIMeb7xdKZmjrhFbxlOkZJNt_Inr6CxYQY4nZflU-0

+

Disclosure(s): WyJyVUVrQW9Fd3ZMX2c4dnJyY1NzNjFRIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0

+

Contents: [
  "rUEkAoEwvL_g8vrrcSs61Q",
  "type",
  "ExampleBachelorDegree"
]

+
+
+
+
+ +
+ +

+While bearer credentials are privacy-enhancing, issuers still need to +take care in their design to avoid unintentionally divulging more information +than the holder of the bearer credential expects. For example, +repeated use of the same bearer credential across multiple sites can +enable these sites to collude in illicitly tracking or correlating the +holder. Similarly, information that might seem non-identifying, such as +a birthdate and postal code, can be used together to statistically identify +an individual when used in +the same bearer credential or session. +

+ +

+Issuers of bearer credentials should ensure that the +bearer credentials provide privacy-enhancing benefits that: +

+ + + +

+Holders ought to be warned by their software if it detects that bearer credentials +containing sensitive information have been issued or requested, or that a +correlation risk is posed by the combination of two or more bearer credentials across one +or more sessions. While detecting all correlation risks might be impossible, +some might certainly be detectable. +

+ +

+Verifiers ought not request bearer credentials known to carry +information which can be used to illicitly correlate the holder. +

+
+ +

8.11 Correlation During Validation

This section is non-normative.

+ + +

+When processing verifiable credentials, verifiers +evaluate relevant claims before relying upon them. This +evaluation might be done in any manner desired as long as it satisfies +the requirements of the verifier doing the validation. +Many verifiers will perform the checks listed in Appendix A. Validation as +well as a variety of specific business process checks such as: +

+ + + +

+The process of performing these checks might result in information leakage that +leads to a privacy violation of the holder. For example, a simple +operation, such as checking an improperly configured revocation list, can +notify the issuer that a specific business is likely interacting +with the holder. This could +enable issuers to collude to correlate individuals without their +knowledge. +

+ +

+Issuers are urged to not use mechanisms, such as credential +revocation lists that are unique per credential, during the +verification process, which could lead to privacy violations. Organizations +providing software to holders ought to warn when credentials include +information that could lead to privacy violations during the verification +process. Verifiers are urged to consider rejecting credentials that +produce privacy violations or that enable substandard privacy practices. +

+
+ +

8.12 Storage Providers and Data Mining

This section is non-normative.

+ + +

+When a holder receives a verifiable credential from an +issuer, the verifiable credential needs to be stored somewhere +(for example, in a credential repository). Holders need to be aware +that the information in a verifiable credential can be sensitive and highly +individualized, making it a prime target for data mining. Services offering +"free of charge" storage of verifiable credentials might mine personal data +and sell it to organizations interesting in building individualized profiles +on people and organizations. +

+

+Holders need to be aware of the terms of service for their +credential repository, specifically the correlation and data mining +protections in place for those who store their verifiable credentials +with the service provider. +

+

+Some effective mitigations for data mining and profiling include using: +

+ + + +

+In addition to the mitigations above, civil society and regulatory +participation in vendor analysis and auditing can help ensure that legal +protections are enacted and enforced for individuals affected by practices +that are not aligned with their best interests. +

+
+ +

8.13 Aggregation of Credentials

This section is non-normative.

+ + +

+Having two pieces of information about the same subject often reveals +more about the subject than the combination of those two pieces, even +when the pieces are delivered through different channels. Aggregating +verifiable credentials poses a privacy risk, and all participants in +the ecosystem need to be aware of the risks of data aggregation. +

+ +

+For example, suppose two bearer credentials, one for an email address and +one stating the holder is over 21, are provided to the same verifier +across multiple sessions. The verifier of the information now has a unique +identifier (the email address) along with age-related ("over 21") information +for that individual. It is now easy to create a profile for the holder, +building it by adding more and more information as it leaks over time. +Aggregation of such credentials can also be performed by multiple sites +in collusion with each other, leading to privacy violations. +

+ +

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

+ +

+The solution to the privacy implications of correlation or aggregation tends +not to be technological in nature, but policy-driven instead. Therefore, if a +holder wishes to avoid the aggregation of their information, they need to +express this in the verifiable presentations they transmit, and +by the holders and verifiers to whom they transmit their +verifiable presentations. +

+
+ +

8.14 Patterns of Use

This section is non-normative.

+ + +

+Despite best efforts by all involved to assure privacy, using +verifiable credentials can potentially lead to de-anonymization and a +loss of privacy. This correlation can occur when any of the following occurs: +

+ + + +

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

+ + + +

+Unfortunately, these mitigation techniques are only sometimes practical or +even compatible with necessary use. Sometimes, correlation is a requirement. +

+

+For example, in some prescription drug monitoring programs, monitoring prescription +use is a requirement. Enforcement entities need to be able to confirm that individuals +are not cheating the system to get multiple prescriptions for controlled +substances. This statutory or regulatory need to correlate prescription +use overrides individual privacy concerns. +

+ +

+Verifiable credentials will also be used to intentionally correlate +individuals across services. For example, when using a common persona to log in +to multiple services, all activity on each of those services is +intentionally linked to the same individual. This is not a privacy issue as +long as each of those services uses the correlation in the expected manner. +

+ +

+Privacy violations related to the use of verifiable credentials occur when +unintended or unexpected correlation arises from the presentation of those +verifiable credentials. +

+
+ + + +

8.16 Sharing Information with the Wrong Party

This section is non-normative.

+ + +

+When a holder chooses to share information with a verifier, it +might be the case that the verifier is acting in bad faith and requests +information that could harm the holder. For example, a +verifier might ask for a bank account number, which could then be used +with other information to defraud the holder or the bank. +

+ +

+Issuers ought to strive to tokenize as much information as possible so +that if a holder accidentally transmits credentials to the wrong +verifier, the situation is not catastrophic. +

+ +

+For example, instead of including a bank account number to check +an individual's bank balance, provide a token that enables the +verifier to check if the balance is above a certain amount. In this +case, the bank could issue a verifiable credential containing a balance +checking token to a holder. The holder would then include the +verifiable credential in a verifiable presentation and bind the +token to a credit checking agency using a digital signature. The +verifier could then wrap the verifiable presentation in their +digital signature and hand it back to the issuer to check the +account balance dynamically. +

+ +

+Using this approach, even if a holder shares the account balance token +with the wrong party, an attacker cannot discover the bank account number or +the exact value of the account. Also, given the validity period of the +counter-signature, the attacker gains access to the token for only a +few minutes. +

+
+ +

8.17 Data Theft

This section is non-normative.

+ + +

+The data expressed in verifiable credentials and +verifiable presentations are valuable since they contain authentic +statements made by trusted third parties (such as issuers) or +individuals (such as holders or subjects). The storage and +accessibility of this data can inadvertently create honeypots of +sensitive data for malicious actors. These adversaries often seek to +exploit such reservoirs of sensitive information, aiming to +acquire and exchange that data for financial gain. +

+

+Issuers are advised to retain the minimum amount of data +necessary to issue verifiable credentials to holders and +to manage the status and revocation of those credentials. Similarly, +issuers are advised to avoid creating publicly +accessible credentials that include personally identifiable information +(PII) or other sensitive data. Software implementers are advised +to safeguard verifiable credentials using robust consent +and access control measures, ensuring that they remain +inaccessible to unauthorized entities. +

+

+Holders are advised to use implementations that appropriately +encrypt their data in transit and at rest and protect sensitive +material (such as cryptographic secrets) in ways that cannot be easily +extracted from hardware or other devices. It is further suggested that +holders store and manipulate their data only on devices they +control, away from centralized systems, to reduce the likelihood of +an attack on their data or inclusion in a large-scale theft if an attack is +successful. Furthermore, holders are encouraged to rigorously control +access to their credentials and presentations, allowing access only to those +with explicit authorization. +

+

+Verifiers are advised to ask only for data necessary for a particular +transaction and to retain no data beyond the needs of any particular +transaction. +

+

+Regulators are advised to reconsider existing audit requirements such that +mechanisms that better preserve privacy can be used to achieve similar +enforcement and audit capabilities. For example, audit-focused regulations +that insist on the collection and long-term retention of personally +identifiable information can cause harm to individuals and organizations +if that same information is later compromised and accessed by an attacker. +The technologies described by this specification enable holders to +prove properties about themselves and others more readily, reducing the +need for long-term data retention by verifiers. Alternatives include +keeping logs that the information was collected and checked, as well as +random tests to ensure that compliance regimes are operating as expected. +

+
+ +

8.18 Frequency of Claim Issuance

This section is non-normative.

+ + +

+As detailed in Section 8.14 Patterns of Use, patterns of use can be +correlated with certain types of behavior. This correlation is partially +mitigated when a holder uses a verifiable credential without the +knowledge of the issuer. Issuers can defeat this protection +however, by making their verifiable credentials short lived and renewal +automatic. +

+ +

+For example, an ageOver verifiable credential is helpful in +gaining access to a bar. If an issuer issues such a +verifiable credential with a very short validity period and an automatic +renewal mechanism, then the issuer could correlate the holder's +behavior in a way that negatively impacts the holder. +

+ +

+Organizations providing software to holders ought to warn them if they +repeatedly use credentials with short lifespans, which could result in +behavior correlation. Issuers ought to avoid issuing credentials that +enable them to correlate patterns of use. +

+
+ +

8.19 Prefer Single-Use Credentials

This section is non-normative.

+ + +

+An ideal privacy-respecting system would require only the information necessary +for interaction with the verifier to be disclosed by the holder. +The verifier then records that the disclosure requirement has been met +and discards any sensitive information disclosed. In many cases, +competing priorities, such as regulatory burden, prevent this ideal system from +being employed. In other instances, long-lived identifiers prevent single use. +The designer of any verifiable credentials ecosystem ought to strive +to make it as privacy-respecting as possible by preferring single-use +verifiable credentials whenever possible. +

+ +

+Using single-use verifiable credentials provides several benefits. The +first benefit is to verifiers who can be sure that the data in a +verifiable credential is fresh. The second benefit is to holders, +who know that if there are no long-lived identifiers in the +verifiable credential, the verifiable credential itself cannot be +used to track or correlate them online. Finally, there is nothing for attackers +to steal, making the entire ecosystem safer to operate within. +

+
+ +

8.20 Private Browsing

This section is non-normative.

+ + +

+In an ideal private browsing scenario, no PII will be revealed. Because many +credentials include PII, organizations providing software to +holders ought to warn them about the possibility of this information +being revealed if they use credentials and presentations while in +private browsing mode. As each browser vendor handles private browsing +differently, and some browsers might not have this feature, it is +important that implementers not depend on private browsing mode to provide +any privacy protections. Instead, implementers are advised to rely on +tooling that directly usable by their software to provide privacy guarantees. +

+ +
+ +

8.21 Issuer Cooperation Impacts on Privacy

This section is non-normative.

+ + +

+Verifiable credentials rely on a high degree of trust in issuers. +The degree to which a holder might take advantage of possible privacy +protections often depends strongly on the support an issuer provides for +such features. In many cases, privacy protections which make use of +zero-knowledge proofs, data minimization techniques, bearer credentials, +abstract claims, and protections against signature-based correlation require +active support by the issuer, who need to incorporate those capabilities +into the verifiable credentials they issue. +

+

+It is crucial to note that holders not only depend on issuer +participation to provide verifiable credential capabilities that help +preserve holder and subject privacy, but also rely on issuers to +not deliberately subvert these privacy protections. For example, an +issuer might sign verifiable credentials using a signature scheme +that protects against signature-based correlation. This would protect the +holder from being correlated by the signature value as it is shared among +verifiers. However, if the issuer creates a unique key for each +issued credential, it might be possible for the issuer to track +presentations of the credential, regardless of a verifier's +inability to do so. +

+

+In addition to previously described privacy protections an issuer might +offer, issuers need to be aware of data they leak that is associated with +identifiers and claim types they use when issuing credentials. One +example of this would be an issuer issuing driver's licenses which reveal +both the location(s) in which they have jurisdiction and the location of the +subject's residence. Verifiers might take advantage of this by +requesting a credential to check that the subject is licensed to +drive when, in fact, they are interested in metadata about the +credential, such as which issuer issued the credential, and tangential +information that might have been leaked by the issuer, such as the +subject's home address. To mitigate such leakage, issuers might +use common identifiers to mask specific location information or other sensitive +metadata; for example, a shared issuer identifier at a state or national +level instead of at the level of a county, city, town, or other smaller +municipality. Further, verifiers can use holder attestation mechanisms +to preserve privacy, by providing proof that an issuer exists in a set of +trusted entities without needing to disclose the exact issuer. +

+
+
+ +

9. Security Considerations

This section is non-normative.

+ + +

+Issuers, holders, and verifiers should be aware of a number of +security considerations when processing data described by this specification. +Ignoring or not understanding the implications of this section can result in +security vulnerabilities. +

+ +

+While this section highlights a broad set of security considerations, it is a +partial list. Implementers of mission-critical systems using the technology +described in this specification are strongly encouraged to consult security and +cryptography professionals for comprehensive guidance. +

+ +

9.1 Cryptography Suites and Libraries

This section is non-normative.

+ + +

+Cryptography can protect some aspects of the data model described in this +specification. It is important for implementers to understand the cryptography +suites and libraries used to create and process credentials and +presentations. Implementing and auditing cryptography systems generally +requires substantial experience. Effective +red teaming can also +help remove bias from security reviews. +

+ +

+Cryptography suites and libraries have a shelf life and eventually succumb to +new attacks and technological advances. Production quality systems need to take +this into account and ensure mechanisms exist to easily and proactively upgrade +expired or broken cryptography suites and libraries, and to invalidate and +replace existing credentials. Regular monitoring is important to +ensure the long term viability of systems processing credentials. +

+
+ +

9.2 Key Management

This section is non-normative.

+ +

+The security of most digital signature algorithms, used to secure verifiable credentials and verifiable presentations, depends on the quality and +protection of their private signing keys. The management of +cryptographic keys encompasses a vast and complex field. For comprehensive +recommendations and in-depth discussion, readers are directed to +[NIST-SP-800-57-Part-1]. As strongly recommended in both [FIPS-186-5] and +[NIST-SP-800-57-Part-1], a private signing key is not to be used for multiple +purposes; for example, a private signing key is not to be used for encryption +as well as signing. +

+

+[NIST-SP-800-57-Part-1] strongly advises that private signing keys and +public verification keys have limited cryptoperiods, where +a cryptoperiod is "the time span during which a specific key is +authorized for use by legitimate entities or the keys for a given system will +remain in effect." [NIST-SP-800-57-Part-1] gives extensive +guidance on cryptoperiods for different key types under various conditions +and recommends a one to three year cryptoperiod for a private signing key. +

+

+To deal with potential private key compromises, [NIST-SP-800-57-Part-1] +provides recommendations for protective measures, harm reduction, and +revocation. Although this section focuses primarily on the security of the +private signing key, [NIST-SP-800-57-Part-1] also highly recommends +confirmation of the validity of all verification material before using it. +

+
+ +

9.3 Content Integrity Protection

This section is non-normative.

+ + +

+Verifiable credentials often contain URLs to data that resides outside +the verifiable credential. Linked content that exists outside a +verifiable credential — such as images, JSON-LD extension contexts, +JSON Schemas, and other machine-readable data — is not protected +against tampering because the data resides outside of the protection of the +securing mechanism on the +verifiable credential. +

+ +

+Section 5.3 Integrity of Related Resources of this specification provides an +optional mechanism for ensuring the integrity of the content of external +resources. This mechanism is not necessary for external resources that do not +impact the verifiable credential's security. However, its implementation +is crucial for external resources where content changes could potentially +introduce security vulnerabilities. +

+ +

+Implementers need to recognize the potential security risks associated with +unprotected URLs of external machine-readable content. Such vulnerabilities +could lead to successful attacks on their applications. Where changes to +external resources might compromise security, implementers will benefit by +employing the content integrity protection mechanism outlined in this +specification. +

+ +
+ +

9.4 Unsigned Claims

This section is non-normative.

+ + +

+This specification enables the creation of credentials without signatures +or proofs. These credential classes are often useful for intermediate +storage or self-asserted information, analogous to filling out a form on a web +page. Implementers ought to be aware that these credential types are not +verifiable because the authorship either is unknown or cannot be trusted. +

+
+ +

9.5 Man-in-the-Middle (MITM), Replay, and Cloning Attacks

This section is non-normative.

+ + +

+The data model does not inherently prevent +Man-in-the-Middle (MITM), +replay, and +spoofing attacks. +Both online and offline use cases might be susceptible to these attacks, where +an adversary intercepts, modifies, re-uses, and/or replicates the verifiable credential data during transmission or storage. +

+

9.5.1 Man-in-the-Middle (MITM) Attack

+ +

+A verifier might need to ensure it is the intended recipient of a +verifiable presentation and not the target of a + +man-in-the-middle attack. Some securing +mechanisms, like Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] and +Verifiable Credential Data Integrity 1.0 [VC-DATA-INTEGRITY], provide an +option to specify a presentation's intended audience or domain, which can +help reduce this risk. +

+

+Other approaches, such as token binding [RFC8471], which ties the request for +a verifiable presentation to the response, can help secure the protocol. +Any unsecured protocol is susceptible to man-in-the-middle attacks. +

+

9.5.2 Replay Attack

+ +

+A verifier might wish to limit the number of times that +verifiable presentation can be used. For example, multiple individuals +presenting the same verifiable credential representing an event ticket +might be granted entry to the event, undermining the purpose of the ticket +from the perspective of its issuer. To prevent such replay attacks, +verifiers require holders to include additional security measures +in their verifiable presentations. Examples include the following: +

+

+

9.5.3 Spoofing Attack

+ +

+Verifiers might have a vested interest in knowing that a holder is +authorized to present the claims inside of a verifiable presentation. +While the data model outlines the structure and data elements necessary for a +verifiable credential, it does not include a mechanism to ascertain the +authorization of presented credentials. To address this concern, +implementers might need to explore supplementary methods, such as binding +verifiable credentials to strong authentication mechanisms or using +additional properties in verifiable presentations +to enable proof of control. +

+
+

9.6 Bundling Dependent Claims

This section is non-normative.

+ + +

+It is considered best practice for issuers to atomize information in a +credential or use a signature scheme that allows for selective +disclosure. When atomizing information, if it is not done securely by the +issuers, the holders might bundle together claims from different +credentials in ways that the issuers did not intend. +

+ +

+Consider a university issuing two verifiable credentials to an individual. +Each credential contains two properties that, when combined, indicate the +person's "role" in a specific "department." For instance, one credential +pair might designate "Staff Member" in the "Department of Computing," while +another could signify "Post Graduate Student" in the "Department of Economics." +Atomizing these verifiable credentials results in the university issuing +four separate credentials to the individual. Each credential contains +a single designation: "Staff Member", "Post Graduate Student", "Department of +Computing", or "Department of Economics". The holder might then present +the "Staff Member" and "Department of Economics" verifiable credentials to +a verifier, which, together, would comprise a false claim. +

+
+ +

9.7 Highly Dynamic Information

This section is non-normative.

+ + +

+When verifiable credentials contain highly dynamic information, careful +consideration of validity periods becomes crucial. Issuing verifiable credentials with validity periods that extend beyond their intended use creates +potential security vulnerabilities that malicious actors could exploit. Validity +periods shorter than the timeframe where the information expressed by the +verifiable credential is expected to be used creates a burden on +holders and verifiers. It is, therefore, important to set validity +periods for verifiable credentials appropriate to the use case and the +expected lifetime of the information contained in the verifiable credential. +

+
+ +

9.8 Device Theft and Impersonation

This section is non-normative.

+ + +

+Storing verifiable credentials on a device poses risks if the device is +lost or stolen. An attacker gaining possession of such a device potentially +acquires unauthorized access to systems using the victim's verifiable credentials. Ways to mitigate this type of attack include: +

+ + + +

+Furthermore, instances of impersonation can manifest in various forms, +including situations where an entity attempts to disavow its actions. +Elevating trust and security within the realm of verifiable credentials +entails more than averting impersonation; it also involves implementing +non-repudiation mechanisms. These mechanisms solidify an entity's +responsibility for its actions or transactions, reinforcing accountability and +deterring malicious behavior. Attainment of non-repudiation is a +multifaceted endeavor, encompassing an array of techniques including +securing mechanisms, proofs of possession, +and authentication schemes in various protocols designed to foster trust and +reliability. +

+
+

9.9 Acceptable Use

This section is non-normative.

+ + +

+Ensuring alignment between an entity's actions — such as presentation, +and the intended purpose of those actions — is essential. It involves having the +authorization to use verifiable credentials and using credentials in a +manner that adheres to their designated scope(s) and objective(s). Two critical +aspects in this context are Unauthorized Use and Inappropriate Use. +

+

9.9.1 Unauthorized Use

+

+Entities using verifiable credentials and verifiable presentations +beyond their intended purpose are engaging in unauthorized activity. One class +of unauthorized use is a confidentiality violation. Consider a holder +that shares a verifiable presentation with a verifier +to establish their age and residency status. If the verifier then proceeds +to employ the holder's data without proper consent, such as by selling the +data to a data broker, that would constitute an unauthorized use of the data, +violating an expectation of privacy that the holder might have in the +transaction. +

+

+Similarly, an issuer can employ a termsOfUse +property to specify how and when a holder might be permitted and expected +to use a credential. A holder using credentials outside of the +scope(s) defined in the termsOfUse would be considered to be unauthorized. +

+
Note: Digital Rights Management is out of scope

+Further study is required to determine how a holder can assert and +enforce authorized use of their data after presentation. +

+

9.9.2 Inappropriate Use

+

+While valid cryptographic signatures and successful status checks signify the +reliability of credentials, they do not signify that all +credentials are interchangeable for all contexts. It is crucial that +verifiers also validate any relevant claims, +considering the source and nature of the claim alongside the purpose +for which the holder presents the credential. +

+

+For instance, in scenarios where a certified medical diagnosis is required, a +self-asserted credential carrying the necessary data might not suffice +because it lacks validity from an authoritative medical source. To ensure proper +credential use, stakeholders need to assess the +credential's relevance and authority within the +specific context of their intended application. +

+
+ +

9.10 Code Injection

This section is non-normative.

+ + +

+Data in verifiable credentials can include injectable code or code from +scripting languages. Authors of verifiable credentials benefit from avoiding +such inclusions unless necessary and only after mitigating associated risks to +the fullest extent possible. + +

+ +

+For example, a single natural language string containing multiple languages or +annotations often requires additional structure or markup for correct +presentation. Markup languages, such as HTML, can label text spans in different +languages or supply string-internal markup needed to display bidirectional text properly. It is also possible to use the rdf:HTML datatype to encode +such values accurately in JSON-LD. +

+ +

+Despite the ability to encode information as HTML, implementers are strongly +discouraged from doing so for the following reasons: +

+ + + +

+If implementers feel they need to use HTML, or other markup languages capable of +containing executable scripts, to address a specific use case, they are advised +to analyze how an attacker could use the markup to mount injection attacks +against a consumer of the markup. This analysis should be followed by the +proactive deployment of mitigations against the identified attacks, such as +running the HTML rendering engine in a sandbox with no ability to access the +network. +

+
+ +
+ +

10. Accessibility Considerations

This section is non-normative.

+ + +

+There are a number of accessibility considerations implementers should be +aware of when processing data described in this specification. As with +implementation of any web standard or protocol, ignoring accessibility issues +makes this information unusable by a large subset of the population. It is +important to follow accessibility guidelines and standards, such as [WCAG21], +to ensure that all people, regardless of ability, can make use of this data. +This is especially important when establishing systems using cryptography, +which have historically created problems for assistive technologies. +

+ +

+This section details the general accessibility considerations to take into +account when using this data model. +

+ +

10.1 Data First Approaches

This section is non-normative.

+ + +

+Many physical credentials in use today, such as government identification +cards, have poor accessibility characteristics, including, but not limited to, +small print, reliance on small and high-resolution images, and no affordances +for people with vision impairments. +

+ +

+When using this data model to create verifiable credentials, it is +suggested that data model designers use a data first approach. For +example, given the choice of using data or a graphical image to depict a +credential, designers should express every element of the image, such as +the name of an institution or the professional credential, in a +machine-readable way instead of relying on a viewer's interpretation of the +image to convey this information. Using a data first approach is preferred +because it provides the foundational elements of building different interfaces +for people with varying abilities. +

+
+
+ +

11. Internationalization Considerations

This section is non-normative.

+ + +

+Implementers are advised to be aware of a number of internationalization +considerations when publishing data described in this specification. +As with any web standards or protocols implementation, ignoring +internationalization makes it difficult for data to be produced and consumed +across a disparate set of languages and societies, which limits the +applicability of the specification and significantly diminishes its value as a +standard. +

+ +

+Implementers are strongly advised to read the +Strings on the Web: Language and Direction Metadata document +[STRING-META], published by the W3C Internationalization Activity, which +elaborates on the need to provide reliable metadata about text to support +internationalization. For the latest information on internationalization +considerations, implementers are also urged to read the Verifiable Credentials +Implementation Guidelines [VC-IMP-GUIDE] document. +

+ +

+This section outlines general internationalization considerations to take into +account when using this data model and is intended to highlight specific +parts of the Strings on the Web: Language and Direction Metadata +document [STRING-META] that implementers might be interested in reading. +

+ +

11.1 Language and Base Direction

+ + +

+Data publishers are strongly encouraged to read the section on +Cross-Syntax Expression in the Strings on the Web: Language and Direction +Metadata document [STRING-META] to ensure that expressing +language and base direction information is +possible across multiple expression syntaxes, such as [JSON-LD11], [JSON], +and CBOR [RFC7049]. +

+ +

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

+ +
+
+ Example 36: Design pattern for natural language strings + 
"myProperty": {
+  "@value": "The string value",
+  "@language": "LANGUAGE"
+  "@direction": "DIRECTION"
+}
+
+ +

+When the language value object is used in place of a string value, the object +MUST contain a @value property whose value is a string, and SHOULD contain a +@language property whose value is a string containing a well-formed +Language-Tag as defined by [BCP47], and MAY contain a @direction property +whose value is a base direction string defined by the @direction +property in [JSON-LD11]. The language value object MUST NOT include any other +keys beyond @value, @language, and @direction. +

+ +

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

+ +
+
+ Example 37: Expressing natural language text as English + 
"title": {
+  "@value": "HTML and CSS: Designing and Creating Websites",
+  "@language": "en"
+}
+
+ +

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

+ +
+
+ Example 38: Arabic text with a base direction of right-to-left + 
"title": {
+  "@value": "HTML و CSS: تصميم و إنشاء مواقع الويب",
+  "@language": "ar",
+  "@direction": "rtl"
+}
+
+ +
Note: Properly rendering internationalized text is challenging

+The text above would most likely be rendered incorrectly as left-to-right +without the explicit expression of language and direction because many systems +use the first character of a text string to determine its base direction. +

+ +

+Multiple language value objects MAY be provided as an array value for the +property: +

+ +
+
+ Example 39: Multiple language texts provided for title + 
"title": [
+  {
+    "@value": "HTML and CSS: Designing and Creating Websites",
+    "@language": "en"
+  },
+  {
+    "@value": "HTML و CSS: تصميم و إنشاء مواقع الويب",
+    "@language": "ar",
+    "@direction": "rtl"
+  }
+]
+
+ +
+
+ Example 40: Example dual language credential + 
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2",
+    "https://achievement.example/multilingual/v2"
+  ],
+  "type": [ "VerifiableCredential", "ExampleAchievementCredential" ],
+  "issuer": {
+    "id": "did:example:2g55q912ec3476eba2l9812ecbfe",
+    "type": "Profile"
+  },
+  "validFrom": "2024-03-14T22:32:52Z",
+  "validUntil": "2025-01-01T00:00:00Z",
+
+  "credentialSubject": {
+    "type": [ "AchievementSubject" ],
+    "achievement": {
+      "id": "urn:uuid:9a652678-4616-475d-af12-aca21cfbe06d",
+      "type": [ "Achievement" ],
+      "name": {
+        "en": "Successful installation of the Example application",
+        "es": "Instalación exitosa de la aplicación Example"
+      },
+      "criteria": {
+        "narrative": {
+          "es": "Instaló exitosamente de la aplicación Example.",
+          "en": "Successfully installed the Example application."
+        }
+      }
+    }
+  }
+}
+
+
+ +

11.2 Providing Default Language and Direction

+ + +

+The language and base direction of each natural language string property value +SHOULD be provided, either via the language value structure for each property +value, or via a default language and base direction for all values in the entire +credential. Using the per-value language value structure is preferred, because +using document defaults can result in a requirement that downstream processors +perform JSON-LD expansion-based transformation which is otherwise optional. See +the +String Internationalization section of the [JSON-LD11] specification for +more information. Natural language string values that do not have a language +associated with them SHOULD be treated as if the language value is undefined +(language tag "und"). Natural language string values that do not have a base +direction associated with them SHOULD be treated as if the direction value is +"auto". +

+
+ +
+ +

A. Validation

This section is non-normative.

+ + +

+While this specification does not provide conformance criteria for the process +of the validation of verifiable credentials or +verifiable presentations, readers might be curious about how the +information in this data model is expected to be used by verifiers +during the process of validation. This section captures a selection of +conversations held by the Working Group related to the expected use of the +properties in this specification by verifiers. +

+ +

A.1 Credential Type

This section is non-normative.

+ + +

+When a verifier requests one or more verifiable credentials from a +holder, they can specify the type of credential(s) +that they would like to receive. Credential types, as well as validation schemas +for each type and each of their claims, are defined by specification authors +and are published in places like the Verifiable Credential Extensions. +

+ +

+The type of a credential is expressed via the type +property. A verifiable credential of a specific type contains specific +properties (which might be deeply nested) that can be used to determine +whether or not the presentation satisfies a set of processing rules that the +verifier executes. By requesting verifiable credentials of a particular +type, the verifier is able to gather specific information from the +holder, which originated with the issuer of each verifiable credential, that will enable the verifier to determine the next stage of +an interaction with a holder. +

+ +

+When a verifier requests a verifiable credential of a specific type, +there will be a set of mandatory and optional claims that are associated +with that type. A verifier's validation of a verifiable credential will +fail when mandatory claims are not included, and any claim that is +not associated with the specific type will be ignored. In other words, a +verifier will perform input validation on the verifiable credential it +receives and will reject malformed input based on the credential type +specification. +

+ +
+ +

A.2 Credential Subject

This section is non-normative.

+ + +

+In the verifiable credentials presented by a holder, the value +associated with the id property for each credentialSubject identifies a +subject to the verifier. If the holder is also the subject, then +the verifier could authenticate the holder if they have verification +metadata related to the holder. The verifier could then authenticate the +holder using a signature generated by the holder contained in the +verifiable presentation. The id property is optional. Verifiers +could use other properties in a verifiable credential to uniquely +identify a subject. +

+ +
Note: Authentication is out of scope

+For information on how authentication and WebAuthn might work with +verifiable credentials, see the Verifiable Credentials Implementation Guidelines 1.0 document. +

+ +
+ +

A.3 Issuer

This section is non-normative.

+ + +

+The value associated with the issuer property identifies an issuer +to the verifier. +

+ +

+Metadata related to the issuer property is available to the +verifier through the verification +algorithm as defined in Section 7.1 Verification. +This metadata includes identification of the verified controller of the +verification method used by the securing mechanism to secure each verifiable credential or verifiable presentation, of which the controller is +typically the respective issuer or holder. +

+ +

+Some ecosystems might have more complex relationships between issuers +and controllers of verification methods and might use lists of verified +issuers in addition to, or instead of, the mapping described above. +

+
+ +

A.4 Holder

This section is non-normative.

+ +

+The value associated with the holder property is used to identify the +holder to the verifier. +

+

+Often relevant metadata about the holder, as identified by the value of +the holder property, is available to, or retrievable by, the +verifier. For example, a holder can publish information containing +the verification material used to secure verifiable presentations. This +metadata is used when checking proofs on verifiable presentations. +Some cryptographic identifiers contain all necessary metadata in the identifier +itself. In those cases, no additional metadata is required. Other identifiers +use verifiable data registries where such metadata is automatically published +for use by verifiers, without any additional action by the holder. +

+

+See the Verifiable Credentials Implementation Guidelines 1.0 and +Verifiable Credentials Use Cases for additional examples related to +subject and holder. +

+ +
Note: Validation is the process of applying business rules

+Validation is the process by which verifiers apply business rules to +evaluate the propriety of a particular use of a verifiable credential. +

+

+A verifier might need to validate a given verifiable presentation +against complex business rules; for example, the verifier might need confidence +that the holder is the same entity as a subject of a verifiable credential. In such a situation, the following factors can provide a +verifier with reasonable confidence that the claims expressed regarding +that identifier, in included verifiable credentials, are, in fact, about +the current presenter: +

+ +
+ +

A.5 Issuance Date

This section is non-normative.

+ + +

+The validFrom is expected to be within an expected range for the +verifier. For example, a verifier can check that the start of +the validity period for a verifiable credential is not in the future. +

+
+ +

A.6 Proofs (Signatures)

This section is non-normative.

+ + +

+The securing mechanism used to prove that the information in a verifiable credential or verifiable presentation was not tampered with is called a +cryptographic proof. There are many types of cryptographic proofs +including, but not limited to, digital signatures and zero-knowledge proofs. In +general, when verifying cryptographic proofs, implementations are expected to +ensure: +

+ + + +

+In general, when verifying digital signatures, implementations are expected to +ensure: +

+ + + +
+ +

A.7 Validity Periods

This section is non-normative.

+ + +

+The verifier expects that the validFrom and +validUntil properties will be within a certain range. For example, +a verifier can check that the end of the validity period of a +verifiable credential is not in the past. Because some credentials can be +useful for secondary purposes even if their original validity period has +expired, validity period, as expressed using the validFrom and +validUntil properties, is always considered a component of +validation, which is performed after verification. +

+
+ +

A.8 Status

This section is non-normative.

+ + +

+If the credentialStatus property is available, the status of a +verifiable credential is expected to be evaluated by the verifier +according to the credentialStatus type definition for the +verifiable credential and the verifier's own status evaluation +criteria. For example, a verifier can ensure the status of the +verifiable credential is not "withdrawn for cause by the issuer". +

+
+ +

A.9 Schema

This section is non-normative.

+ + +

+If the credentialSchema property is available, the schema of a +verifiable credential is expected to be evaluated by the verifier +according to the credentialSchema type definition for the +verifiable credential and the verifier's own schema evaluation +criteria. For example, if the credentialSchema's type +value is [VC-JSON-SCHEMA], then a verifier can ensure a credential's +data is valid against the given JSON Schema. +

+
+ +

A.10 Fitness for Purpose

This section is non-normative.

+ + +

+Fitness for purpose is about whether the custom properties in the +verifiable credential are appropriate for the verifier's purpose. +For example, if a verifier needs to determine whether a subject is +older than 21 years of age, they might rely on a specific birthdate +property, or on more abstract properties, such as +ageOver. +

+ +

+The issuer is trusted by the verifier to make the claims at +hand. For example, a franchised fast food restaurant location trusts the +discount coupon claims made by the corporate headquarters of the +franchise. Policy information expressed by the issuer in the +verifiable credential should be respected by holders and +verifiers unless they accept the liability of ignoring the policy. +

+
+ +

A.11 "Artificial Intelligence" and "Machine Learning"

This section is non-normative.

+ + +

+Systems using what is today commonly referred to as "artificial intelligence" +and/or "machine learning" might be capable of performing complex tasks at a +level that meets or exceeds human performance. This might include tasks such as +the acquisition and use of verifiable credentials. Using such tasks to +distinguish between human and automated "bot" activity, as is commonly done +today with a CAPTCHA, +for instance, might thereby cease to provide adequate or acceptable protection. +

+ +

+Implementers of security architectures that use verifiable credentials +and/or perform validation on their content are urged to consider the existence +of machine-based actors, such as those which are today commonly referred to as +"artificial intelligence", that might legitimately hold verifiable credentials for use in interactions with other systems. Implementers might +also consider how threat actors could couple such "artificial intelligence" +systems with verifiable credentials to pose as humans when interacting with +their systems. Such systems might include, but not be limited to, global +infrastructure such as social media, election, energy distribution, supply +chain, and autonomous vehicle systems. +

+ +
+ +
+ +

B. Contexts, Vocabularies, Types, and Credential Schemas

+ + +

B.1 Base Context

+ + +
(Feature at Risk) Issue 1437: Hash values might change during Candidate Recommendation pr existsnormativebefore-PRCR1

+This section lists cryptographic hash values that might change during the +Candidate Recommendation phase based on implementer feedback that requires +the referenced files to be modified. +

+The Working Group is expecting all of the terms and URLs supplied in the +JSON-LD Context to be either stabilized, or removed, before the publication of +this specification as a Proposed Recommendation. While that means that this +specification could be delayed if dependencies such as [VC-DATA-INTEGRITY], +[VC-JOSE-COSE], SD-JWT, [VC-JSON-SCHEMA], or status list +do not enter the Proposed Recommendation phase around the same time frame, the +Working Group is prepared to remove the dependencies if an undue burden is +placed on transitioning to the Recommendation phase. This is a calculated +risk that the Working Group is taking and has a mitigation strategy in place +to ensure the timely transition of this specification to a Recommendation. +

+

+Implementations MUST treat the base context value, located at +https://www.w3.org/ns/credentials/v2, as already retrieved; +the following value is the hexadecimal encoded SHA2-256 digest value of the base +context file: 24a18c90e9856d526111f29376e302d970b2bd10182e33959995b0207d7043b9. It is possible to confirm +the cryptographic digest above by running the following command from a modern +Unix command interface line: +curl -s https://www.w3.org/ns/credentials/v2 | openssl dgst -sha256. +

+

+It is strongly advised that all JSON-LD Context URLs used by an +application use the same mechanism, or a functionally equivalent mechanism, +to ensure end-to-end security. Implementations are expected to throw errors +if a cryptographic hash value for a resource does not match the expected hash +value. +

+

+Implementations that apply the base context above, as well as other contexts +and values in any @context property, during operations such as + +JSON-LD Expansion or + +transformation to RDF, are expected to do so without experiencing any +errors. If such operations are performed and result in an error, +the verifiable credential or verifiable presentation MUST result +in a verification failure. +

+
Note: See errata if hash value changes are detected

+It is extremely unlikely that the files that have associated cryptographic hash +values in this specification will change. However, if critical errata are +found in the specification and corrections are required to ensure +ecosystem stability, the cryptographic hash values might change. As such, the +HTTP cache times for the files are not set to infinity and implementers are +advised to check for errata if a cryptographic hash value change is detected. +

+

+This section serves as a reminder of the importance of ensuring that, when +verifying verifiable credentials and verifiable presentations, the +verifier has information that is consistent with what the issuer +or holder had when securing the credential or presentation. +This information might include at least: +

+
    +
  1. +The contents of the credential itself, which are secured in +verifiable credentials and verifiable presentations by using +securing mechanisms. See Section 4.12 Securing Mechanisms for further +information. +
    2. +
  2. +The content in a credential whose meaning depends on a link to an external URL, +such as a JSON-LD Context, which can be secured by using a local static copy +or a cryptographic digest of the file. See Section +5.3 Integrity of Related Resources for more details. +
    3. +
+

+Verifiers are warned that other data that is referenced from within a +credential, such as resources that are linked to via URLs, are not +cryptographically protected by default. It is considered a best practice to +ensure that the same sorts of protections are provided for any URL that is +critical to the security of the verifiable credential through the use of +permanently cached files and/or cryptographic hashes. Ultimately, knowing the +cryptographic digest of any linked external content enables a verifier to +confirm that the content is the same as what the issuer or holder +intended. +

+
+ +

B.2 Vocabularies

+ + +
(Feature at Risk) Issue: URL values might change during Candidate Recommendation

+This section lists URL values that might change during the Candidate +Recommendation phase based on migration of documents to time-stamped locations, +migration of documents to the W3C Technical Reports namespace, and/or +implementer feedback that requires the referenced URLs to be modified. +

+ +

+Implementations that depend on RDF vocabulary processing MUST ensure that the +following vocabulary URLs used in the base context ultimately resolve to the +following files when loading the JSON-LD serializations, which are normative. +Other semantically equivalent serializations of the vocabulary files MAY be used +by implementations. A cryptographic hash is provided for each JSON-LD document +to ensure that developers can verify that the content of each file is correct. +

+ + + + + + + + + + + + + + + +
JSON-LD Documents and Hashes
+URL: https://www.w3.org/2018/credentials#
+Resolved Document: https://www.w3.org/2018/credentials/index.jsonld
+SHA2-256 Digest: 7d21e1769cb38284a9bd8ae1150b6b8c69d452b29f45e777f53b36e78d9ddaa1 +
+URL: https://w3id.org/security#
+Resolved Document: https://w3c.github.io/vc-data-integrity/vocab/security/vocabulary.jsonld
+SHA2-256 Digest: b3b13c6db415597cd65af7816351829832e8d74002b76d3676443802a4ac4409 +
+ +

+It is possible to confirm the cryptographic digests listed above by running +a command like the following, replacing <DOCUMENT_URL> +with the appropriate value, through a modern UNIX-like OS command line interface: +curl -sL -H "Accept: application/ld+json" <DOCUMENT_URL> | openssl dgst -sha256 +

+ +
Note: schema.org changes regularly, but is considered stable

+Implementers and document authors might note that cryptographic digests for +schema.org are not provided. This is because the schema.org vocabulary +undergoes regular changes; any digest provided would be out of date within +weeks of publication. The Working Group discussed this concern and concluded +that the vocabulary terms from schema.org, that are used by this +specification, have been stable for years and are highly unlikely to change in +their semantic meaning. +

+ +

+The following base classes are defined in this specification for processors +and other specifications that benefit from such definitions: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Base ClassPurpose
+CredentialEvidence + +Serves as a superclass for specific evidence types that are placed into the +evidence property. +
+CredentialSchema + +Serves as a superclass for specific schema types that are placed into the +credentialSchema property. +
+CredentialStatus + +Serves as a superclass for specific credential status types that are placed into +the credentialStatus property. +
+ConfidenceMethod + +Serves as a superclass for specific confidence method types that are placed into +the confidenceMethod property. +
+RefreshService + +Serves as a superclass for specific refresh service types that are placed into +the credentialRefresh property. +
+RenderMethod + +Serves as a superclass for specific render method types that are placed into +the renderMethod property. +
+TermsOfUse + +Serves as a superclass for specific terms of use types that are placed into +the termsOfUse property. +
+ +
+ +

B.3 Datatypes

+ +

+ This section defines datatypes that are used by this specification. +

+ +

B.3.1 The sriString Datatype

+ + +

+The sriString datatype is associated with a value to provide the integrity +information for a resource using the method specified in the Subresource Integrity +specification. The sriString datatype is defined as follows: +

+ +
+
The URL denoting this datatype
+
https://www.w3.org/2018/credentials#sriString
+
The lexical space
+
+See the ABNF +grammar, defining the integrity attribute in the [SRI] specification, +for the restrictions on the string format. +
+
The value space
+
+A (possibly empty) list of (alg,val) pairs, where alg identifies a +hash function, and val is an integer as a standard mathematical concept. +
+
The lexical-to-value mapping
+
+Any element of the lexical space is mapped to the value space by following the +parse metadata algorithm +based on the ABNF +grammar in the [SRI] specification. +
+
The canonical mapping
+
+The canonical mapping consists of the lexical-to-value mapping. +
+
+
+ + +
+ +

B.4 Differences between Contexts, Types, and CredentialSchemas

This section is non-normative.

+ + +

+The verifiable credential and verifiable presentation data models +leverage a variety of underlying technologies including [JSON-LD11] and +[VC-JSON-SCHEMA]. This section will provide a comparison of the +@context, type, and credentialSchema +properties, and cover some of the more specific use cases where it is possible +to use these features of the data model. +

+ +

+The type property is used to uniquely identify the type of the +verifiable credential in which it appears, that is, to indicate which set of +claims the verifiable credential contains. This property, and the value +VerifiableCredential within the set of its values, are mandatory. +Whilst it is good practice to include one additional value depicting the unique +subtype of this verifiable credential, it is permitted to either omit or +include additional type values in the array. Many verifiers will request a +verifiable credential of a specific subtype, then omitting the subtype +value could make it more difficult for verifiers to inform the holder which +verifiable credential they require. When a verifiable credential +has multiple subtypes, listing all of them in the type +property is sensible. The use of the type property in a +[JSON-LD11] representation of a verifiable credential enables to enforce +the semantics of the verifiable credential because the machine is able to +check the semantics. With [JSON-LD11], 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 of the properties in the graph. In +[JSON-LD11], this represents the type of the node in the graph which is why some +[JSON-LD11] representations of a verifiable credential will use the +type property on many objects in the verifiable credential. +

+ +

+The primary purpose of the @context property, from a [JSON-LD11] +perspective, is to convey the meaning of the data and term definitions of the +data in a verifiable credential, in a machine-readable way. The +@context property is used to map the globally unique URLs for +properties in verifiable credentials and verifiable presentations +into short-form alias names, making [JSON-LD11] representations more +human-friendly to read. From a [JSON-LD11] perspective, this mapping also allows +the data in a credential to be modeled in a network of machine-readable +data, by enhancing how the data in the verifiable credential or +verifiable presentation relates to a larger machine-readable data graph. +This is useful for telling machines how to relate the meaning of data to other +data in an ecosystem where parties are unable to coordinate. This property, with +the first value in the set being +https://www.w3.org/ns/credentials/v2, is mandatory. +

+ +

+Since the @context property is used to map data to a graph +data model, and the type property in [JSON-LD11] is used to +describe nodes within the graph, the type property becomes +even more important when using the two properties in combination. For example, +if the type property is not included within the resolved +@context resource using [JSON-LD11], it could lead to claims being +dropped and/or their integrity no longer being protected during production and +consumption of the verifiable credential. Alternatively, it could lead to +errors being raised during production or consumption of a verifiable credential. This will depend on the design choices of the implementation and +both paths are used in implementations today, so it's important to pay attention +to these properties when using a [JSON-LD11] representation of a verifiable credential or verifiable presentation. +

+ +

+The primary purpose of the credentialSchema property is to define +the structure of the verifiable credential, and the datatypes for the +values of each property that appears. A credentialSchema is useful +for defining the contents and structure of a set of claims in a verifiable credential, whereas [JSON-LD11] and a @context in a +verifiable credential are best used only for conveying the semantics and +term definitions of the data, and can be used to define the structure of the +verifiable credential as well. +

+ +

+While it is possible to use some [JSON-LD11] features to allude to the +contents of the verifiable credential, it's not generally suggested to use +@context to constrain the data types of the data model. For example, +"@type": "@json" is useful for leaving the semantics open-ended and not +strictly defined. This can be dangerous if the implementer is looking to +constrain the data type of the claims in the credential, and is expected +not to be used. +

+ +

+When the credentialSchema and @context properties +are used in combination, both producers and consumers can be more confident +about the expected contents and data types of the verifiable credential +and verifiable presentation. +

+
+
+ +

C. IANA Considerations

This section is non-normative.

+ + +

+This section will be submitted to the Internet Engineering Steering Group +(IESG) for review, approval, and registration with IANA. +

+ +

C.1 application/vc

+ +

+This specification registers the application/vc media type specifically for +identifying documents conforming to the verifiable credentials format. +

+ + + + + + + + + + + + + + + + + + + + + + + + + +
Type name: application
Subtype name: vc
Required parameters: None
Encoding considerations: +Resources that use the application/vc media type are required to conform to +all of the requirements for the application/ld+json media type and are +therefore subject to the same encoding considerations specified in Section 11 +of The JavaScript Object Notation (JSON) Data Interchange Format. +
Security considerations: As defined in the Verifiable Credentials Data Model v2.0.
Contact: +W3C Verifiable Credentials Working Group +public-vc-wg@w3.org +
+ +

+Note that while the verifiable credentials format uses JSON-LD conventions, +there are a number of constraints and additional requirements for verifiable credential implementations that justify the use of a specific media type. +

+ +

+This media type can be used in an enveloping proof to denote the enveloped +payload. +

+ +

+The credential is expected to be a valid +JSON-LD document. +Verifiable credentials served with the application/vc media type are +expected to have all JSON-LD 1.1 context information, including references +to external contexts, within the body of the document. Contexts linked via a +http://www.w3.org/ns/json-ld#context HTTP Link Header +(see Section 6.1 +of JSON-LD 1.1) are ignored. +

+
+ +

C.2 application/vp

+ +

+This specification registers the application/vp media type specifically for +identifying documents conforming to the verifiable presentations format. +

+ + + + + + + + + + + + + + + + + + + + + + + + + +
Type name: application
Subtype name: vp
Required parameters: None
Encoding considerations: +Resources that use the application/vp media type are required to conform to +all of the requirements for the application/ld+json media type and are +therefore subject to the same encoding considerations specified in Section 11 +of The JavaScript Object Notation (JSON) Data Interchange Format. +
Security considerations: As defined in Verifiable Credentials Data Model v2.0.
Contact: +W3C Verifiable Credentials Working Group +public-vc-wg@w3.org +
+ +

+Note that while the verifiable presentations format uses JSON-LD +conventions, there are a number of constraints and additional requirements for +verifiable presentation implementations that justify the use of a specific +media type. +

+ +

+This media type can be used in an enveloping proof to denote the enveloped +payload. +

+

+The presentation is expected to be a valid +JSON-LD document. Verifiable presentations served with the application/vp media type are expected to have +all JSON-LD 1.1 context information, including references to external +contexts, within the body of the document. Contexts linked via a +http://www.w3.org/ns/json-ld#context HTTP Link Header (see Section 6.1 +of [JSON-LD11]) are ignored. +

+
+ +
+ +

D. Additional Diagrams for Verifiable Presentations

This section is non-normative.

+ + +

+Figure 14 below is a variant of Figure 9: a +verifiable presentation referring to two verifiable credentials, and +using embedded proofs based on [VC-DATA-INTEGRITY]. Each verifiable credential graph is connected to its own separate proof graph; the +verifiableCredential property is used to connect the verifiable presentation to the verifiable credential graphs. The presentation +proof graph represents the digital signature of the verifiable presentation graph, both verifiable credential graphs, and the proof graphs linked from the verifiable credential graphs. The complete +verifiable presentation consists, in this case, of six information +graphs. +

+ +
+ +Diagram with a 'verifiable presentation graph' on top, connected via a +'proof' to a 'verifiable presentation proof graph' on the bottom. The +verifiable presentation graph has an object, 'Presentation ABC', with 3 +properties: 'type' with value 'VerifiablePresentation'; 'termsOfUse' with +value 'Do Not Archive'; and two instances of 'verifiableCredential', +detailed below. This graph is annotated with a parenthetical remark, '(the +default graph)'. This graph is connected, through 'verifiableCredential', +to the part of the figure that consists two variants of Figure 6 (one is +identical; the other has minor differences in the labels referring to +validity dates, the name of the person, and the values for the nonce and +the signature), except that these verifiable credential graphs are +annotated to be named graphs instead of a default graph. The verifiable +presentation proof graph has an object labeled 'Signature 8920' with 5 +properties: 'type' with value 'DataIntegrityProof'; 'verificationMethod' +with value 'Example Presenter Public Key 11'; 'created' with value +'2024-01-02T12:43:56Z'; 'nonce' with value 'hasdkyruod87j'; and +'proofValue' with value 'zpewJHoan87='. This graph is annotated with the +parenthetical remark '(a named graph)' + +
Figure 14 + A variant of Figure 9: information graphs associated + with a verifiable presentation referring to two verifiable + credentials, using an embedded proof based on + Verifiable Credential Data Integrity 1.0 [VC-DATA-INTEGRITY]. +
+
+ +

+ Figure 15 below shows the same + verifiable presentation as Figure 14, but + using an enveloping proof based on [VC-JOSE-COSE]. + Each verifiable credential graph contains a single + EnvelopedVerifiableCredential + instance, referring, via a data: URL [RFC2397], to a verifiable + credential secured via an enveloping proof. +

+ +
+ +Diagram with, on the left, a box, labeled as 'JWT (Decoded)', and with +three textual labels stacked vertically, namely 'Header', 'Payload', and +'Signature'. The 'Header' label is connected, with an arrow, to a +separate rectangle on the right hand side containing six text fields: +'kid: aB8J-_Z', 'alg: ES384', 'cty: vc', 'iss: +https://example.com', 'iat: 1704690029', and 'typ: vp+sd-jwt'. The +'Payload' label of the left side is connected, with an arrow, to a +separate rectangle, consisting of three related graphs (stacked +vertically) connected by two arrows labeled 'verifiableCredential' +starting from the top graph and connecting it to the two other graphs, +respectively. The top graph has a label 'verifiable presentation graph +(serialized in JSON)'; the other two are both labeled by 'verifiable +credential graph (serialized in JSON)'. The top graph in the rectangle +has and object 'Presentation ABC' with 3 properties: 'type' of value +VerifiablePresentation, 'termsOfUse' of value 'Do Not Archive'. One of +the the bottom graphs includes +'data:application/vc+sd-jwt,QzVjV...RMjU' as a subject with a +single property: 'type' of value `EnvelopedVerifiableCredential`. The +last bottom graph is identical other, except for the subject which is +labeled as 'data:application/vc+sd-jwt,RkOyT...KjOl'. Finally, +the 'Signature' label on the left side is connected, with an arrow, to a +separate rectangle, containing a single text field: +'cYjaSdfIoJH45NIqw3MYnasGIba...'. + +
Figure 15 + A variant of Figure 10: information graphs + associated with a verifiable presentation referring to two + verifiable credentials using enveloping proofs based on JOSE + [VC-JOSE-COSE]. +
+
+ + +
+ +

E. Revision History

+ + +

+This section contains the substantive changes that have been made to this +specification over time. +

+ +

+Changes since the + +v2.0 First Candidate Recommendation: +

+ + +

+Changes since the + +v1.1 Recommendation: +

+ + +

+Changes since the + +v1.0 Recommendation: +

+ +
+ +

F. Acknowledgements

This section is non-normative.

+ + +

+The Working Group thanks the following individuals not only for their +contributions toward the content of this document, but also for yeoman's work +in this standards community that drove changes, discussion, and consensus among +a sea of varied opinions: Matt Stone, Gregg Kellogg, Ted Thibodeau Jr, Oliver +Terbu, Joe Andrieu, David I. Lehn, Matthew Collier, and Adrian Gropper. +

+ +

+Work on this specification has been supported by the Rebooting the +Web of Trust community facilitated by Christopher Allen, Shannon Appelcline, +Kiara Robles, Brian Weller, Betty Dhamers, Kaliya Young, Manu Sporny, +Drummond Reed, Joe Andrieu, Heather Vescent, Kim Hamilton Duffy, Samantha Chase, +and Andrew Hughes. The participants in the Internet Identity Workshop, +facilitated by Phil Windley, Kaliya Young, Doc Searls, and Heidi Nobantu Saul, +also supported the refinement of this work through numerous working sessions +designed to educate about, debate on, and improve this specification. +

+ +

+The Working Group also thanks our Chairs, Dan Burnett, Matt Stone, Brent Zundel, +Wayne Chang, and Kristina Yasuda as well as our W3C Staff Contacts, Kazuyuki +Ashimura and Ivan Herman, for their expert management and steady guidance of the +group through the W3C standardization process. +

+ +

+Portions of the work on this specification have been funded by the +United States Department of Homeland Security's Science and Technology +Directorate under contract HSHQDC-17-C-00019. The content of this specification +does not necessarily reflect the position or the policy of the U.S. Government +and no official endorsement should be inferred. +

+ +

+The Working Group would like to thank the following individuals for reviewing +and providing feedback on the specification (in alphabetical order): +

+ +

+Christopher Allen, David Ammouial, Joe Andrieu, Bohdan Andriyiv, Ganesh +Annan, Kazuyuki Ashimura, Tim Bouma, Pelle Braendgaard, Dan Brickley, +Allen Brown, Jeff Burdges, Daniel Burnett, ckennedy422, David Chadwick, +Chaoxinhu, Kim (Hamilton) Duffy, Lautaro Dragan, enuoCM, Ken Ebert, Eric +Elliott, William Entriken, David Ezell, Nathan George, Reto Gmür, Ryan +Grant, glauserr, Adrian Gropper, Joel Gustafson, Amy Guy, Lovesh +Harchandani, Daniel Hardman, Dominique Hazael-Massieux, Jonathan Holt, +David Hyland-Wood, Iso5786, Renato Iannella, Richard Ishida, Ian Jacobs, +Anil John, Tom Jones, Rieks Joosten, Gregg Kellogg, Kevin, Eric Korb, +David I. Lehn, Michael Lodder, Dave Longley, Christian Lundkvist, Jim +Masloski, Pat McBennett, Adam C. Migus, Liam Missin, Alexander Mühle, +Anthony Nadalin, Clare Nelson, Mircea Nistor, Grant Noble, Darrell +O'Donnell, Nate Otto, Matt Peterson, Addison Phillips, Eric Prud'hommeaux, +Liam Quin, Rajesh Rathnam, Drummond Reed, Yancy Ribbens, Justin Richer, +Evstifeev Roman, RorschachRev, Steven Rowat, Pete Rowley, Markus +Sabadello, Kristijan Sedlak, Tzviya Seigman, Reza Soltani, Manu Sporny, +Orie Steele, Matt Stone, Oliver Terbu, Ted Thibodeau Jr, John Tibbetts, +Mike Varley, Richard Varn, Heather Vescent, Christopher Lemmer Webber, +Benjamin Young, Kaliya Young, Dmitri Zagidulin, and Brent Zundel. +

+
+ + +

G. References

G.1 Normative references

+ +
[CONTROLLER-DOCUMENT]
+ Controller Documents 1.0. Manu Sporny; Michael Jones. W3C. 8 September 2024. W3C Working Draft. URL: https://www.w3.org/TR/controller-document/ +
[i18n-glossary]
+ Internationalization Glossary. Richard Ishida; Addison Phillips. W3C. 22 April 2024. W3C Working Group Note. URL: https://www.w3.org/TR/i18n-glossary/ +
[INFRA]
+ Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/ +
[JSON-LD11]
+ JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11/ +
[JSON-LD11-API]
+ JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg; Dave Longley; Pierre-Antoine Champin. W3C. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11-api/ +
[LINKED-DATA]
+ Linked Data Design Issues. Tim Berners-Lee. W3C. 27 July 2006. W3C-Internal Document. URL: https://www.w3.org/DesignIssues/LinkedData.html +
[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 +
[RFC2397]
+ The "data" URL scheme. L. Masinter. IETF. August 1998. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc2397 +
[RFC6838]
+ Media Type Specifications and Registration Procedures. N. Freed; J. Klensin; T. Hansen. IETF. January 2013. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc6838 +
[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 +
[RFC9457]
+ Problem Details for HTTP APIs. M. Nottingham; E. Wilde; S. Dalal. IETF. July 2023. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc9457 +
[SRI]
+ Subresource Integrity. Devdatta Akhawe; Frederik Braun; Francois Marier; Joel Weinberger. W3C. 23 June 2016. W3C Recommendation. URL: https://www.w3.org/TR/SRI/ +
[URL]
+ URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/ +
[VC-DATA-INTEGRITY]
+ Verifiable Credential Data Integrity 1.0. Manu Sporny; Dave Longley; Greg Bernstein; Dmitri Zagidulin; Sebastian Crane. W3C. 3 August 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-data-integrity/ +
[VC-JOSE-COSE]
+ Securing Verifiable Credentials using JOSE and COSE. Michael Jones; Michael Prorock; Gabe Cohen. W3C. 7 September 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-jose-cose/ +
[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/ +
+

G.2 Informative references

+ +
[BCP47]
+ Tags for Identifying Languages. A. Phillips, Ed.; M. Davis, Ed.. IETF. September 2009. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc5646 +
[DEMOGRAPHICS]
+ Simple Demographics Often Identify People Uniquely. Latanya Sweeney. Data Privacy Lab. URL: https://dataprivacylab.org/projects/identifiability/paper1.pdf +
[DID-CORE]
+ Decentralized Identifiers (DIDs) v1.0. Manu Sporny; Amy Guy; Markus Sabadello; Drummond Reed. W3C. 19 July 2022. W3C Recommendation. URL: https://www.w3.org/TR/did-core/ +
[ETSI-TRUST-LISTS]
+ Electronic Signatures and Infrastructures (ESI); Trusted Lists. ETSI. ETSI. ETSI Standard TS 119 612 V2.1.1 (2015-07). URL: https://www.etsi.org/deliver/etsi_ts/119600_119699/119612/02.01.01_60/ts_119612v020101p.pdf +
[FIPS-186-5]
+ FIPS PUB 186-5: Digital Signature Standard (DSS). U.S. Department of Commerce/National Institute of Standards and Technology. 3 February 2023. National Standard. URL: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf +
[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 +
[LD-BP]
+ Best Practices for Publishing Linked Data. Bernadette Hyland; Ghislain Auguste Atemezing; Boris Villazón-Terrazas. W3C. 9 January 2014. W3C Working Group Note. URL: https://www.w3.org/TR/ld-bp/ +
[NIST-SP-800-57-Part-1]
+ Recommendation for Key Management: Part 1 – General. Elaine Barker. National Institute of Standards and Technology. May 2020. URL: https://doi.org/10.6028/NIST.SP.800-57pt1r5 +
[RDF-SCHEMA]
+ RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/ +
[RDF11-CONCEPTS]
+ RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/ +
[RFC7049]
+ Concise Binary Object Representation (CBOR). C. Bormann; P. Hoffman. IETF. October 2013. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7049 +
[RFC7159]
+ The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. March 2014. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7159 +
[RFC7231]
+ Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html +
[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 +
[RFC9110]
+ HTTP Semantics. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. IETF. June 2022. Internet Standard. URL: https://httpwg.org/specs/rfc9110.html +
[RFC9458]
+ Oblivious HTTP. M. Thomson; C. A. Wood. IETF. January 2024. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc9458 +
[SCHEMA-ORG]
+ Schema.org. W3C Schema.org Community Group. W3C. 6.0. URL: https://schema.org/ +
[STRING-META]
+ Strings on the Web: Language and Direction Metadata. Richard Ishida; Addison Phillips. W3C. 18 July 2024. W3C Working Group Note. URL: https://www.w3.org/TR/string-meta/ +
[VC-DATA-MODEL-2.0]
+ Verifiable Credentials Data Model v2.0. Manu Sporny; Ted Thibodeau Jr; Ivan Herman; Michael Jones; Gabe Cohen. W3C. 28 August 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-data-model-2.0/ +
[VC-DI-BBS]
+ Data Integrity BBS Cryptosuites v1.0. Greg Bernstein; Manu Sporny. W3C. 28 August 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-di-bbs/ +
[VC-EXTENSIONS]
+ Verifiable Credential Extensions. Manu Sporny. W3C Verifiable Credentials Working Group. W3C Editor's Draft. URL: https://w3c.github.io/vc-extensions/ +
[VC-IMP-GUIDE]
+ Verifiable Credentials Implementation Guidelines 1.0. Andrei Sambra. W3C. 24 September 2019. W3C Working Group Note. URL: https://www.w3.org/TR/vc-imp-guide/ +
[VC-JSON-SCHEMA]
+ Verifiable Credentials JSON Schema Specification. Gabe Cohen; Orie Steele. W3C Verifiable Credentials Working Group. FPWD. URL: https://www.w3.org/TR/vc-json-schema/ +
[VC-USE-CASES]
+ Verifiable Credentials Use Cases. Shane McCarron; Joe Andrieu; Matt Stone; Tzviya Siegman; Gregg Kellogg; Ted Thibodeau Jr. 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. Michael Cooper; Andrew Kirkpatrick; Joshue O'Connor; Alastair Campbell. W3C. 21 September 2023. W3C Recommendation. URL: https://www.w3.org/TR/WCAG21/ +
+
\ No newline at end of file