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.

General Properties

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=].

RecognizedEntity

A recognized entity is any entity that is recognized by an [=issuer=] of a `VerifiableRecognitionCredential` to perform a specific action.

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.

RecognizedAction

A recognized action is an action that a [=recognized entity=] is expected to perform.

VerifiableRecognitionCredential

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=].

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

Surveillance of Individuals as Recognized Entities

A `VerifiableRecognitionCredential` publicly lists named organizations and people with their identifiers, legal names, URLs, and images. Aggregating these across multiple lists enables profiling and surveillance of recognized entities. This section should discuss the risks of publishing richly-described entity information, especially for individuals, and guidance for issuers on minimizing disclosure. For example, a list of recognized entities that is published to a private group can escape that group if any group member decides to publish the information outside of the private group. Suggest that selective disclosure does not provide much protection here because it requires honest actors.

Holder-Provided Recognition Credentials

Having holders provide recognition credentials preserves privacy better than having the verifier reach out to the issuer to retrieve the recognition credential.

Harms by Association

A `VerifiableRecognitionCredential` can reveal the membership structure of a private or sensitive ecosystem, such as healthcare credential issuers or financial service providers. Publishing or widely sharing such credentials can expose which entities participate in that ecosystem, which can be commercially sensitive or create targeting risks. This section should discuss when and how to limit the distribution of recognition credentials that describe sensitive ecosystems, possibly suggesting that it is not possible to limit distribution of recognition credentials and thus creating them for sensitive ecosystems might be an anti-pattern. In general, if you build certain lists with certain memberships, it might have negative effects on individuals (harm by association) -- unintended or not.

Validate Before Sharing

When a [=holder=] receives a `VerifiableRecognitionCredential` and shares it with others, there is a risk that the credential has not been properly vetted. A malicious or negligent actor could craft a `VerifiableRecognitionCredential` that lists fraudulent or compromised entities as recognized issuers or verifiers, and propagate it peer-to-peer across an ecosystem. Recipients who accept and act upon such a credential without independent verification might unknowingly accept [=verifiable credentials=] from untrustworthy sources, exposing themselves and others to fraud, data breaches, or credential forgery. The decentralized nature of this specification, while a strength, amplifies this risk: a single unvetted credential shared widely can rapidly corrupt the trust assumptions of many parties in an ecosystem.

To mitigate these dangers, deployments are expected to independently verify the cryptographic integrity and provenance of any `VerifiableRecognitionCredential` before acting upon it or sharing it further. This includes confirming that the [=issuer=] of the credential is a party the implementer has an established reason to trust for the given recognition domain, and that the credential has not expired or been revoked. Implementers cannot rely solely on the fact that a peer has already accepted a credential as evidence of its validity. Instead, a [=verifier=] needs to vet the issuer of the recognition credential as well as the [=recognized action=] independently of receiving the `VerifiableRecognitionCredential` and can only depend on information from the credential once trust has been established on the issuing entity.

Issuer Impersonation

A malicious actor could create a `VerifiableRecognitionCredential` that mimics a well-known recognizing authority by using a similar `issuer` identifier or name. Verifiers who manually add VRCs to their software, that do not independently validate the issuer's identifier against a known root of trust, could be deceived into accepting fraudulent recognition claims. This section should discuss how to detect and prevent issuer impersonation and the importance of verifying issuer identifiers through authoritative out-of-band means.

Note that appropriate bindings to protocols and user interactions (such as an individual receiving a request from origin). It would be good if a wallet communicates: "I have a recognition credential for this origin/issuer from someone you trust" (if there is a check made that binds request to origin -- TLS used, for example) and that's associated with issuer in VRC. It would be good for this section to talk about how protocols can bind this sort of information together to help individuals not fall for scams.

Selecting Appropriate Validity Periods

Recognition credentials with excessively long `validUntil` periods may remain in circulation long after a recognized entity has been suspended, revoked, or compromised. Conversely, overly short validity periods create operational burden. This section should discuss appropriate selection of validity periods and the importance of pairing validity periods with robust revocation mechanisms. The section should speak to organization/individual end of life as well. How long a period should be is dependent on list size and diversity -- the larger the list, the shorter the timeline (24-48 hours?); the smaller the list, the longer the timeline (weeks to months). Want to be able to add entities on reasonable timeframes. Ecosystems might desire list aggregators -- accreditation bodies might have longer periods. The section should explain the justification for having a longer period -- why go longer than 24-48 hours?

External Resource Tampering

The `outputValidation` property references external schema files via URL. If those URLs are not protected by `digestMultibase` or other integrity checks, an attacker who compromises the schema host can alter validation rules without invalidating the recognition credential, causing verifiers to accept credentials that no longer conform to the intended schema. This section should discuss the importance of using content integrity protection for all externally referenced resources.

Verifying Recognition Chains

The `recognizedIn` property allows recognition credentials to chain to other registries such as ETSI Trust Service Lists, X.509 certificate authority lists, or other `VerifiableRecognitionCredential`s. A compromised or malicious entry in a lower-level registry could be transitively trusted if verifiers do not enforce depth limits or validate each link in the chain independently. This section should discuss safe practices for traversing chained recognition structures and the risks of unbounded transitive trust.

Abuse of Recognized Actions

The `action` property is a free-form string (e.g., `issue`, `verify`). Without strict governance of allowable action values within an ecosystem, recognized entities may present credentials claiming broad or undefined actions that verifiers interpret more permissively than intended, leading to unauthorized use beyond the issuer's intent. This section should discuss the importance of ecosystem-level governance of action vocabularies and how verifiers should handle unrecognized action values.