Copyright © 2026 the Contributors to the Verifiable Credentials for Recognition v0.9 Specification, published by the Credentials Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available.
This specification describes a data model with which one or more recognized entities, such as one or more persons and/or organizations, can be described as known to perform specific actions, such as issuing or verifying a verifiable credential. The data model enables the publication or direct sharing of such information, providing a cryptographically-verifiable and privacy-preserving mechanism through which a holder can demonstrate that an entity whose credential they are using is recognized within a particular ecosystem. The specification is designed to interoperate with existing "trust infrastructures", such as X.509 certificate authority lists and ETSI Trust Service Lists, while enabling new decentralized ecosystems to be built using verifiable credentials.
This specification was published by the Credentials Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Final Specification Agreement (FSA) other conditions apply. Learn more about W3C Community and Business Groups.
This is an experimental specification and is undergoing regular revisions. It is not fit for production deployment.
GitHub Issues are preferred for discussion of this specification. Alternatively, you can send comments to our mailing list. Please send them to public-credentials@w3.org (subscribe, archives).
The verifiable credential ecosystem relies on the ability of verifiers to determine whether a particular issuer is recognized to perform a particular action, such as issuing a certain type of verifiable credential. Historically, this determination has often been made through out-of-band processes, bilateral agreements, or proprietary registries that are difficult to discover, query, or reason about in an automated way. As verifiable credentials are increasingly deployed across sectors such as education, healthcare, financial services, and government, the need for a standardized, interoperable mechanism to express and communicate recognition of entities that perform known actions has become critical. Without such a mechanism, ecosystem participants are forced to build bespoke "trust infrastructure", leading to fragmentation, increased integration costs, and barriers to cross-border and cross-sector interoperability.
This specification addresses the challenge of expressing recognized entities,
such as people and organizations, and the actions they perform, such as issuing
and verifying, in a decentralized manner by defining a data model that any
entity can use to publish or share recognition information as a verifiable credential. Rather than mandating a single central registry, the model allows
any entity — a government body, an industry consortium, a standards
organization, or even a single individual — to issue a
VerifiableRecognitionCredential asserting that they know of one or more
entities that are recognized to perform specific actions. This design enables a
web of overlapping, competing, and complementary "trust registries" to coexist,
allowing ecosystem participants to choose the entities they trust and to reason
across multiple registries. The specification also supports interoperability
with existing "trust infrastructure", such as X.509 certificate authority lists
and ETSI Trust Service Lists, allowing existing recognized entity information to
be referenced and composed into new decentralized ecosystems.
Readers who are interested in the variety of use cases supported by this specification are urged to read the use cases document. The remainder of this document is organized into the following sections:
RecognizedEntity, RecognizedAction, and VerifiableRecognitionCredential
types along with their properties and worked examples.
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, OPTIONAL, and SHOULD 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 any concrete expression of the data model that complies with the normative statements in this specification. Specifically, all relevant normative statements in Section 2. Data Model 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
2.4 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 Verifiable Credentials Data Model v2.0 specification. |
| type |
The type of the entity. The value for this property is defined in
Section 4.5: Types
of the Verifiable Credentials Data Model v2.0 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 Verifiable Credentials Data Model v2.0 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 Verifiable Credentials Data Model v2.0 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 Verifiable Credentials Data Model v2.0 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 Verifiable Credentials Data Model v2.0 specification. |
| type |
The type property MUST be RecognizedEntity. The value for
this property is defined in
Section 4.5: Types
of the Verifiable Credentials Data Model v2.0 specification.
|
| recognizedTo | A specific action that the recognized entity is expected to perform as defined in Section 2.3 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 Verifiable Credentials Data Model v2.0 specification and SHOULD be EtsiTrustServiceList,
x509CertificateAuthorityList, or VerifiableRecognitionCredential.
|
Properties from Section 2.1 General Properties can be included in addition to the properties above.
A recognizedIn with a type property of EtsiTrustServiceList MUST conform
to the Electronic Signatures and Infrastructures (ESI); Trusted Lists specification. A list with type property of
x509CertificateAuthorityList MUST conform to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile 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 2.1 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 Verifiable Credentials Data Model v2.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 2.1 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 2.2 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 section details the general privacy considerations and specific privacy implications of deploying this specification into production environments.
Readers are urged to familiarize themselves with the general privacy advice provided in the Privacy Considerations section of the Verifiable Credentials specification before reading this section.
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, publishing a list of
recognized entities in a private group can escape that group if any group
member decides to publish the information outside of the private group.
When a holder presents a recognition credential via certificate stapling, the verifier learns which recognizing authority the holder chose to rely upon, revealing information about the holder's trust network and potentially their ecosystem affiliation. This section should discuss how the act of presenting a recognition credential can itself expose information about the holder and how to mitigate this risk. This isn't really any different from understanding who the issuer of a VC is -- mitigations might include trusted 3rd party witnesses.
The recognizedBy, outputValidation schema URLs within a
RecognizedAction are highly specific and potentially unique identifiers. A
holder presenting a recognition credential that references a narrowly-used
schema or recognizing authority can be strongly correlated across verifiers.
This section should discuss how recognition metadata can serve as a
correlation vector and guidance for reducing that risk.
Verifiers who fetch updated recognition credentials from a remote URL to check freshness or revocation signal to the recognition credential issuer that a particular class of credential is in active use, enabling recognizer-based tracking of verifier behavior. This is especially true for recognition VCs that only list a single entity. This section should discuss the privacy implications of remote fetching and techniques such as Oblivious HTTP that can mitigate tracking.
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
exposes which entities participate in that ecosystem, which may 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.
There are a number of security considerations that implementers should be aware of when processing data described by this specification. Ignoring or not understanding the implications of this section can result in security vulnerabilities.
Readers are urged to familiarize themselves with the general security advice provided in the Security Considerations section of the Verifiable Credentials specification before reading this section.
While this section attempts to highlight a broad set of security considerations, it is not a complete list. Implementers are urged to seek the advice of security and cryptography professionals when implementing mission critical systems using the technology outlined in this specification.
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.
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.
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 validity period selection and
the importance of pairing validity periods with robust revocation mechanisms.
The outputValidation property references external schema files via URL. If
those URLs are not protected by digestMultibase 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.
The recognizedIn property allows recognition credentials to chain to other
registries such as ETSI Trust Service Lists, X.509 certificate authority lists,
or other VerifiableRecognitionCredentials. 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.
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.
This section is non-normative.
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):