This is a interoperability report for implementers for the Verifiable Credentials Data Model v2.0 specification.

Conformance Testing Results

These tests were run on

Key

🚫
Pending
Passed
Failed
Access Denied
Timeout
Not Implemented

The results of the tests are shown below:

Basic Conformance

Contexts

Identifiers

Types

Names and Descriptions

Issuer

Credential Subject

Validity Period

Status

Data Schemas

Verifiable Presentations

Enveloped Verifiable Credentials

Implementer ⇒
Test Name

Enveloped Verifiable Presentations

Implementer ⇒
Test Name

Advanced Concepts

Algorithms

At Risk

Reason ⇒
Statement
At least 2 passing implementations
A conforming document MUST be secured by at least one securing mechanism as described in Section 4.12 Securing Mechanisms.
A conforming issuer implementation MUST include all required properties in the conforming documents it produces.
A conforming issuer implementation MUST secure the conforming documents it produces using a securing mechanismdescribed in Section 4.12 Securing Mechanisms.
A conforming verifier implementation MUST perform verification on a conforming document as described inSection 4.12 Securing Mechanisms.
A conforming verifier implementation MUST produce errors when non-conforming documents are detected.
Verifiable credentials MUST include a @context property.
Verifiable presentations MUST include a @context property.
Verifiable credentials: 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.
Verifiable presentations: 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.
Verifiable Credential `@context`: "Subsequent items in the ordered set MUST be composed of any combination of URLs and/or objects where each is processable as a JSON-LD Context."
Verifiable Presentation `@context`: "Subsequent items in the ordered set MUST be composed of any combination of URLs and/or objects where each is processable as a JSON-LD Context."
If present, the value of the id property MUST be a single URL, which MAY be dereferenceable.
Verifiable credentials MUST contain a type property with an associated value.
Verifiable presentations MUST contain a type property with an associated value.
The value of the type property MUST be one or more terms and/or absolute URL strings.
If more than one (type) value is provided, the order does not matter.
Verifiable Presentation objects MUST have a type specified.
`credentialStatus` objects MUST have a type specified.
`termsOfUse` objects MUST have a type specified.
`evidence` objects MUST have a type specified.
`refreshService` objects MUST have a type specified.
`credentialSchema` objects MUST have a type specified.
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.
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.
If present (on `issuer`), the value of the name property MUST be a string or a language value object as described in 11.1 Language and Base Direction.
If present (on `issuer`), the value of the description property MUST be a string or a language value object as described in 11.1 Language and Base Direction.
A verifiable credential MUST have an issuer property.
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.
A verifiable credential MUST contain a credentialSubject property.
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.
If present, the value of the validFrom property MUST be an [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 in the past.
If present, the value of the validUntil property MUST be an [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 in the future.
If a validUntil value also exists, the validFrom value MUST express a datetime that is temporally the same or earlier than the datetime expressed by the validUntil value.
If a validFrom value also exists, the validUntil value MUST express a datetime that is temporally the same or later than the datetime expressed by the validFrom value.
The type property is REQUIRED.
The related normative guidance in Section 4.5 Types MUST be followed.
If present (credentialStatus.id), the normative guidance in Section 4.4 Identifiers MUST be followed.
(If a credentialStatus property is present), 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 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.
If multiple schemas are present, validity is determined according to the processing rules outlined by each associated type property
If [the `id` field is] present, the normative guidance in Section 4.4 Identifiers MUST be followed.
The type property MUST be present.
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.
The verifiableCredential property MAY be present. The value MUST beone or more verifiable credential and/or enveloped verifiable credential objects (the values MUST NOT be non-object values such as numbers, strings, or URLs).
If present (holder), the value MUST be either a URL or an object containing an id property.
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 value of the relatedResource property MUST be one or more objects of the following form:
The identifier for the resource is REQUIRED and conforms to the format defined in Section 4.4 Identifiers.
The value MUST be unique among the list of related resource objects.
Each object associated with relatedResource MUST contain at least a digestSRI or a digestMultibase value.
If the digest provided by the issuer does not match the digest computed for the retrieved resource, the conforming verifier implementation MUST produce an error.
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 value of the termsOfUse property MUST specify one or more terms of use policies under which the creator issued the credential or presentation.
Each termsOfUse value MUST specify its type, for example, IssuerPolicy, and MAY specify its instance id.
If present, the value associated with the evidence property is a single object or a set of one or more objects.
This section contains an algorithm that conforming verifier implementations MUST run when verifying a verifiable credential or a verifiable presentation.