This is an experimental specification and is undergoing regular revisions. It is not fit for production deployment.
Introduction to be written...
A conforming document is any concrete expression of the data model that complies with the normative statements in this specification. Specifically, all relevant normative statements in Section of this document MUST be enforced.
A conforming processor is any algorithm realized as software and/or hardware that generates or consumes a conforming document. Conforming processors MUST produce errors when non-conforming documents are consumed.
This document also contains examples that contain JSON and JSON-LD content. Some of these examples 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 valid JSON or JSON-LD.
The following sections outline the data model that is used by this specification for Verifiable Issuer and Verifier Lists.
The data model described in this section has been built using input from a variety of the prior art evaluated for this paper including input from the EBSI Trusted Issuer Registry, ETSI TS 119 612, eSSIF-Lab TRAIN, the Trust over IP Foundation Trust Registry Protocol, and Rebooting the Web of Trust input documents. The data model described in this section is capable of expressing many, but not all, of the concepts described in those other specifications.
The unified data model for this work can be represented as a list of service providers that represent entities or organizations that provide services such as credential issuance or validation. The data model also includes the details of the list operator description.
The properties in this section can be added to objects found in a `VerifiableRecognitionCredential` as defined in Section [[[#verifiablerecognitioncredential]]]. Each general property listed in this section is OPTIONAL; none of the values are required to be provided by an [=issuer=].
| Property | Description |
|---|---|
| id | A URL that identifies the entity in a globally unambiguous way. The value for this property is defined in Section 4.4: Identifiers of the [[[VC-DATA-MODEL]]] specification. |
| type | The type of the entity. The value for this property is defined in Section 4.5: Types of the [[[VC-DATA-MODEL]]] specification. The `type` property MUST be `RecognizedIssuer` if the entity is an [=issuer=] of [=verifiable credentials=]. |
| name | A human-readable name for the entity. The value for this property is defined in Section 4.6: Names and Descriptions of the [[[VC-DATA-MODEL]]] specification. |
| legalName | The official legal name of an organization or entity, as registered with legal authorities, which can differ from the commonly used name. The value MUST be a [=string=]. |
| image | A URL or image data representing a visual identifier for the entity, such as a logo, photograph, or icon. The value MUST be a [=URL=]. |
| url | A URL pointing to the primary website or web resource associated with the entity. The value MUST be a [=URL=]. |
| sameAs | One or more URLs that refer to the same entity in other contexts or systems, enabling cross-reference and verification across different platforms. Each value MUST be a [=URL=]. |
| description | A human-readable description providing details about the entity. The value for this property is defined in Section 4.6: Names and Descriptions of the [[[VC-DATA-MODEL]]] specification. |
| digestMultibase | One or more cryptographic digests used to verify the integrity of resources associated with the entity. The values for this property are defined in Section 5.3: Integrity of Related Resources of the [[[VC-DATA-MODEL]]] specification. |
A recognized entity is any entity that is recognized by an [=issuer=] of a `VerifiableRecognitionCredential` to perform a specific action.
| Property | Description |
|---|---|
| id | A URL that identifies the entity in a globally unambiguous way. The value for this property is defined in Section 4.4: Identifiers of the [[[VC-DATA-MODEL]]] specification. |
| type | The `type` property MUST be `RecognizedEntity`. The value for this property is defined in Section 4.5: Types of the [[[VC-DATA-MODEL]]] specification. |
| recognizedTo | A specific action that the [=recognized entity=] is expected to perform as defined in Section [[[#recognizedaction]]]. This property may occur more than once if the [=recognized entity=] is expected to perform more than one action. |
| recognizedIn | An object that contains a reference to a document of recognized entities that contains this particular [=recognized entity=] as well as the actions it is known to perform. The `id` value of the object MUST be a [=URL=]. The `type` value of the object MUST conform to the type value space defined in the [[[VC-DATA-MODEL]]] specification and SHOULD be `EtsiTrustServiceList`, `x509CertificateAuthorityList`, or `VerifiableRecognitionCredential`. |
Properties from Section [[[#general-properties]]] can be included in addition to the properties above.
A `recognizedIn` with a `type` property of `EtsiTrustServiceList` MUST conform to the [[[ETSI-TRUST-LISTS]]] specification. A list with `type` property of `x509CertificateAuthorityList` MUST conform to the [[[RFC5280]]] specification. A list with a `type` property of `VerifiableRecognitionCredential` MUST conform to this specification.
A recognized action is an action that a [=recognized entity=] is expected to perform.
| Property | Description |
|---|---|
| type | The `type` property MUST be `RecognizedAction`. |
| action | A [=string=] that specifies the name of the action to be performed such as `issue` or `verify`. |
| recognizedBy | A [=URL=], or object containing properties from Section [[[#general-properties]]], of the entity that performed the task of recognizing. |
| outputValidation | The value of the `outputValidation` 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 validator 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. |
When a verifiable recognition credential is published, it MUST be a conforming [=verifiable credential=], as defined in [[[VC-DATA-MODEL-2.0]]], that expresses the data model specified in the section that follows. It describes the format of a [=verifiable credential=] that encapsulates the recognized entities.
A recognized entity is expressed inside a [=verifiable credential=], enabling a [=holder=] to provide it directly to a [=verifier=]. This mechanism, sometimes called "certificate stapling", increases privacy for the [=holder=] by ensuring that the [=verifier=] does not need to contact the [=issuer=] to retrieve the recognition credential. Still, a [=verifier=] might choose to ignore the [=holder=]-provided [=recognition credential=], even when its authenticity is verifiable, if, for instance, it desires a more recent version of the [=recognition credential=].
| Property | Description |
|---|---|
| id | A [=verifiable credential=] that contains a set of recognized entities MAY express an `id` property to make its retrieval easier for other systems. |
| type | A [=verifiable credential=] that contains a set of recognized entities MUST express a `type` property that includes the `VerifiableRecognitionCredential` value. |
| issuer | The [=issuer=] of the [=verifiable credential=] as defined in the Verifiable Credentials Data Model specification in Section 4.76: Issuer. This object MAY also include other properties listed in Section [[[#general-properties]]]. |
| validFrom | The earliest point in time at which the credential is valid. This property is defined in the Verifiable Credentials Data Model specification in Section 4.6: Validity Period. |
| validUntil | The latest point in time at which the credential is valid. This property is defined in the Verifiable Credentials Data Model specification in Section 4.6: Validity Period. |
| credentialSubject | A set of one or more `RecognizedEntity` objects as defined in Section [[[#recognizedentity]]]. |
The following examples demonstrate how verifiable recognition credentials can be employed in a variety of use cases. The first example below is used to publish information about a set of known universities in a particular nation.
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": [
"VerifiableCredential",
"VerifiableRecognitionCredential"
],
"issuer": {
"id": "did:web:learning-commission.example",
"type": "RecognizedIssuer"
},
"validFrom": "2025-01-01T00:00:00Z",
"validUntil": "2030-01-01T00:00:00Z",
"credentialSubject": [{
"id": "did:web:university.example",
"type": "RecognizedEntity",
"name": "Example Tech",
"legalName": "Example Polytechnic University",
"image": "https://university.example/logo.png",
"url": "https://www.university.example/",
"description": "A university providing a great education in Utopia Valley.",
}, {
"id": "did:web:college.example",
"type": "RecognizedEntity",
"name": "Exemplar Community College",
"legalName": "Community College of Examples and ",
"image": "https://college.example/graphics/ecc.png",
"url": "https://college.example/",
"description": "The backbone of learning in the Utopia community.",
}],
"proof": {
"type": "DataIntegrityProof",
"created": "2026-04-10T20:08:22Z",
"verificationMethod": "did:web:accreditor.example#issuance-key-1",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z36XPGByaH3rvtKfwoEQXsnUXUAjwd2Ceiqke1GPfjAPAFYoXKo5ftPdwE7QZ8Mw22SC5LSRQg1d8bhe3252hYJoH"
}
}
The next example is used to publish information about a set of known issuers for a particular type of [=verifiable credential=].
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": [
"VerifiableCredential",
"VerifiableRecognitionCredential"
],
"issuer": {
"id": "did:web:learning-commission.example",
"type": "RecognizedIssuer"
},
"validFrom": "2025-01-01T00:00:00Z",
"validUntil": "2030-01-01T00:00:00Z",
"credentialSubject": [{
"id": "did:web:university.example",
"type": "RecognizedEntity",
"name": "Example Tech",
"legalName": "Example Polytechnic University",
"image": "https://university.example/logo.png",
"url": "https://www.university.example/",
"description": "A university providing a great education in Utopia Valley.",
"recognizedTo": {
"type": "RecognizedAction",
"action": "issue",
"recognizedBy": "did:web:learning-commission.example",
"outputValidation": {
"id": "https://learning-commission.example/credentials/bachelors.json",
"type": "JsonSchema",
"digestMultibase": "uEiBZl963sknNAHgPyslVv6VztZpfWQoRvW1htfx-UwirFo",
}
}
}, {
"id": "did:web:college.example",
"type": "RecognizedEntity",
"name": "Exemplar Community College",
"legalName": "Community College of Examples and ",
"image": "https://college.example/graphics/ecc.png",
"url": "https://college.example/",
"description": "The backbone of learning in the Utopia community.",
"recognizedTo": {
"type": "RecognizedAction",
"action": "issue",
"recognizedBy": "did:web:learning-commission.example",
"outputValidation": {
"id": "https://learning-commission.example/credentials/associates.json",
"type": "JsonSchema",
"digestMultibase": "uEiWQoRvpfWW1htfsknNAHgPyslVv6VztZpfwirFoBZl963",
}
}
}],
"proof": {
"type": "DataIntegrityProof",
"created": "2026-04-10T20:08:22Z",
"verificationMethod": "did:web:accreditor.example#issuance-key-1",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z36XPGByaH3rvtKfwoEQXsnUXUAjwd2Ceiqke1GPfjAPAFYoXKo5ftPdwE7QZ8Mw22SC5LSRQg1d8bhe3252hYJoH"
}
}
The final example below is used to publish information about an entity that publishes an European Union ETSI Trust Services list [[ETSI-TRUST-LISTS]].
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": [
"VerifiableCredential",
"VerifiableRecognitionCredential"
],
"issuer": "did:web:ec.europa.example",
"validFrom": "2025-01-01T00:00:00Z",
"validUntil": "2030-01-01T00:00:00Z",
"credentialSubject": [{
"id": "did:web:ec.europa.example",
"type": "RecognizedEntity",
"name": "Utopian Commission",
"legalName": "The Utopian Commission",
"image": "https://ec.europa.example/logo.png",
"url": "https://ec.europa.example/",
"recognizedIn": {
"id": "https://ec.europa.example/tsl/lotl.xml",
"type": "EtsiTrustServiceList",
"name": "Utopian Commission List of the Lists"
}
}],
"proof": {
"type": "DataIntegrityProof",
"created": "2026-04-10T20:08:22Z",
"verificationMethod": "did:web:ec.europa.example#issuance-key-1",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z36XPGByaH3rvtKfwoEQXsnUXUAjwd2Ceiqke1GPfjAPAFYoXKo5ftPdwE7QZ8Mw22SC5LSRQg1d8bhe3252hYJoH"
}
}
This recommendation specifies a data model for trusted lists of verifiable issuers and verifiers but it does not say how such lists should be secured. Other recommendations will specify the security mechanisms that may be used. One security mechanism may be to encapsulate the list as a verifiable credential, signed by the list operator, and a non-normative example of this is given in Section 5. Another mechanism may be for the list operator to issue the list as a JWT. In other eco-systems a block chain may be used to publish the list.
The Working Group thanks the following individuals for significant contributions to the community: TBD
Work on this specification has been supported by the Rebooting the Web of Trust community facilitated by Christopher Allen, Joe Andrieu, and Erica Connell. 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 would like to thank the following individuals for reviewing and providing feedback on the specification (in alphabetical order):