§ Verifiable Trust v4 Specification

Latest Draft: spec v4-rc1

Editors:

Fabrice Rochette, (The Verana Foundation)

Contributors:

Ariel Gentile, (The Verana Foundation)

Andres Vallecilla, (Mobiera)

Participate:

GitHub repo

File a bug

Commit history

§ Abstract

Today’s internet has no built-in trust layer. Users cannot verify who operates a service before connecting to it, and service providers have no standardized way to confirm the identity of their users. The result is an environment where phishing, impersonation, spam, and credential theft thrive — not because of missing technology, but because of a missing trust architecture.

Current approaches make the problem worse. Passwords are fragile and reused. Federated login concentrates control in a handful of platforms. Each service imposes its own registration flow, fragmenting the user experience while centralizing personal data in siloed systems that are routinely breached. Privacy is an afterthought, and users have little visibility into who they are really interacting with.

The rapid expansion of AI agents makes this even more urgent. Autonomous agents now interact with services, make requests, and act on behalf of users or organizations — yet there is no trust layer for them to prove who they represent, what they are authorized to do, or whether their claims are legitimate. Without verifiable identity and authorization, AI agents become a new vector for fraud, impersonation, and unauthorized access at machine speed and scale.

Verifiable Trust is an open, decentralized trust layer designed to address these problems at their root. It introduces a model where every service, organization, and user agent can cryptographically prove its identity, authorization, and governance context — before any connection is established.

The core idea is straightforward: a Verifiable Service presents verifiable credentials that identify its operator, describe its purpose, and prove its authorization within a governed ecosystem. A Verifiable User Agent resolves and verifies these credentials, queries a Verifiable Public Registry to confirm that they were issued by recognized authorities, and displays a Proof-of-Trust to the user — all before the first interaction takes place.

A key consequence is that a Verifiable Service is not identified by an opaque URL, but by a resolvable DID. Its DID Document declares one or more service endpoints — at minimum a DIDComm channel used to establish trust and to bootstrap access to the rest of the service, and optionally additional endpoints such as MCP, A2A, or a plain website. A peer resolves the DID, performs trust resolution, and opens a DIDComm session over which it obtains any credentials or access tokens it needs; only then does it consume the other declared endpoints. This inverts the familiar “connect first, verify later” pattern of today’s internet into a “verify first, then connect” model that applies uniformly to humans, applications, and AI agents.

This enables mutual authentication without passwords, verifiable service discovery without centralized directories, privacy-preserving credential exchange with selective disclosure and unlinkability, and ecosystem governance that is transparent, auditable, and decentralized.

Verifiable Trust is container-agnostic, supporting both W3C Verifiable Credentials and Anonymous Credentials to balance transparency with privacy depending on the use case. It is also DID-method-agnostic, allowing ecosystems to operate across different decentralized identifier infrastructures.

This specification defines the Verifiable Trust architecture, its core concepts — Verifiable Services, Verifiable User Agents, Verifiable Trust Credentials, Essential Credential Schemas, and the trust resolution process — and the normative requirements for interoperable implementations.

§ About this Document

In order to fully understand the concepts developed in this document, you should have some basic knowledge of the ToIP stack, DID, DIDComm, ecosystem, and more generally, all terms present in the Terminology section.

§ 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.

§ Terminology

credential schema:
An VPR resource which represents a verifiable credential definition and the associated permissions and business rules for issuing, verifying or holding a credential linked to this credential schema.
decentralized identifier:
A decentralized identifier, as specified in [DID-CORE].
decentralized identifier communication:
DIDComm uses DIDs to establish confidential, ongoing connections.
decentralized identifier document:
A DID Document, as specified in [DID-CORE].
verifiable public registry:
a public, normally decentralized network, which provides: ecosystem features, that can be used by all its participants: create ecosystems, for each ecosystem, define its credential schemas, who can issue, verify credential of a specific credential schema,… For more information, please refer to VPR Spec.
verifiable service:
A service, identified by a resolvable DID, that can be deployed anywhere by its owner, that conforms to this spec, and that has a resolvable proof of trust. A VS declares its service endpoints in its DID Document (see [VS-SVC]); it MUST declare at least a DIDComm endpoint and MAY declare additional services such as MCP, A2A, a website, or any other service type.
verifiable user agent:
A user agent for accessing and using VSs. To be considered a VUA, a user agent must conform and enforce this spec, such as presenting a proof of trust to end user before accepting connecting to VS compliant services, and refuse connecting to not compliant services.
essential credential schema:
Default credential schema, owned by an ecosystem, that provide the basis for a trust layer to exist in the ecosystem so that VUA can generate a proof of trust.
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 organizations, persons, things.
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. Example issuers include corporations, non-profit organizations, trade associations, governments, and individuals.
linked-vp:
A presentation of a verifiable credential as specified in LINKED-VP.
participant:
An entity that uses an VPR and its trust layer to provide or use services.
proof of trust:
Visual representation using essential credential schemas of a trust resolution process of a Verifiable Service, for identifying the VS, its owner, and the issuer of the verifiable credential of its owner.
session:
A session defines a connection to a DID Document provided service from a third party VS or VUA.
subject:
A thing about which claims are made. Example subjects include human beings, animals, things, and organization, a DID…
ecosystem:
A VPR resource, controlled by a corporation, that defines an approved list of participants (issuers, verifiers, grantors, holders) authorized to issue, verify or hold credentials for a given set of credential schemas. The Ecosystem entry plays the role formerly known as “trust registry”. For the canonical data model, see Ecosystem in the VPR spec.
corporation:
A VPR resource representing a legal/organizational entity that controls one or more ecosystems and/or holds one or more participants in ecosystems. See Corporation in the VPR spec.
participant:
A VPR resource, linked to a credential schema in an ecosystem, that records the role (ISSUER, VERIFIER, ISSUER_GRANTOR, VERIFIER_GRANTOR, ECOSYSTEM, HOLDER) granted to a corporation for that schema. The Participant entry replaces what earlier drafts called a “Permission”. See Participant in the VPR spec.
trust resolution:
Process run by, for example a VUA or a VS, which purpose is to recursively resolve DID by digging into DID Documents and look for linked-vp entries and their issuer DIDs, and ecosystem entries to gather whether the service provided by the DID is trustable (and legitimate), or not.
verifier:
A role an entity performs by receiving one or more verifiable credentials, optionally inside a verifiable presentation for processing. Example verifiers include service providers.
verifiable credential:
A verifiable credential as defined in [VC-DATA-MODEL].

§ Understanding Verifiable Trust

This section is non-normative.

When a user is invited to connect to a service, a verifiable trust-compliant user agent performs trust resolution on the service, presents the resulting Proof-of-Trust to the user, and prompts them to either accept or refuse the connection.

proof-of-trust

Trust Resolution is as simple as calling a method passing the DID of the service we want to resolve, to display a Proof-of-Trust to the end-user:

resolve_trust("did:example:gaia")

and receive a response similar to this one:

{
  "did":"did:example:gaia",
  "verified": true,
  "service_provider": {
      "id": "did:example:def",
      "type": "Organization",
      "name": "Gaia Registry LLC",
      "country": "zz",
      "reputation": {
        "issuedCredentials": 1234,
        "verifiedCredentials": 7678,
        "trustDepositValue": 176327.124356,
        "amountSlashed": 0,
        "stars": 5.0
      },
      "issuer": "did:example:zzz",
      ...
  },
  "service": {
      "name": "Gaia Registry",
      "termsAndConditionsUri": "http://example.com",
      "privacyPolicyUri": "http://example.com",
      "minimumAgeRequired": 16,
      "description": "Create your Metaverse ID at Gaia Registry! Protect your identity with biometrics and easily recover it if you loose your phone. Use your Gaia Identity to connect to fancy services with no password."
      ...
  },
  "credentials" : [
    {
      "type": "TrademarkCredential",
      ...
    }
  ]
  ...
}

Let’s explain how the Verifiable Trust does it.

Verifiable Service

The core idea behind Verifiable Trust is simple: trust should not be implicit, but it should be verifiable, transparent, and decentralized.

In this example, a Verifiable Service (VS) presents several Verifiable Credentials to prove:

Additionally, the Verifiable Service presents computed reputation information (data shown in black). While this reputation data may support trust decisions, it is not directly defined by this specification. Refer to the VPR Spec for more information.

Verifiable Trust introduces the following core concepts:

The Proof-of-Trust is established by recursively resolving the credentials presented by (in this example) a service. What makes this trust verifiable is the use of cryptographic mechanisms built into Decentralized Identifiers (DIDs) and Verifiable Credentials, as applied across these five key concepts.

Because these concepts are deeply interdependent, you may need to explore them together, and revisit them several times to fully grasp the Verifiable Trust model.

§ What is a Verifiable Service (VS)?

This section is non-normative.

A Verifiable Service (VS) is a service capable of identifying itself to a peer before any connection is established.

Peers wishing to connect to a VS can review the Verifiable Credentials presented by the service, verify their legitimacy through trust resolution, and decide whether to proceed with the connection based on the outcome.

A VS is also required to verify the trustworthiness of peers attempting to connect to it, whether those peers are other Verifiable Services (VS) or Verifiable User Agents (VUA), and must reject connections from non-verifiable peers.

Furthermore, if a Verifiable Service wants to issue credentials or request credential presentation, it must first prove that it is authorized to perform these actions. Otherwise, the peer must refuse the request.

§ Service Declaration

This section is non-normative.

A fundamental principle of Verifiable Trust is that services are identified by DIDs, not by URLs. Instead of a consumer pointing its client at an opaque endpoint — where neither the identity of the operator nor the legitimacy of the service can be verified — the consumer starts with a resolvable DID and discovers everything it needs from the corresponding DID Document.

The DID Document of a Verifiable Service declares two complementary things:

Every Verifiable Service MUST declare at least a DIDComm service endpoint. DIDComm plays a very specific role in the Verifiable Trust architecture: it is the bootstrapping channel of the service. Over DIDComm, a peer:

In addition to DIDComm, a Verifiable Service MAY declare any number of other service endpoints, for example:

These non-DIDComm endpoints form the data plane of the service; DIDComm is the control plane that authenticates access to them.

Regardless of the protocol used, the interaction flow is always the same:

  1. A peer obtains the service’s DID (via a link, QR code, directory, or any other means).
  2. The peer resolves the DID and fetches its DID Document.
  3. The peer performs trust resolution: it verifies the Linked Verifiable Presentations, checks issuer authorization in the VPR, and recursively resolves the DIDs of the service’s operator and credential issuers.
  4. Once trust is established, the peer opens a DIDComm session with the service. This session is the bootstrap channel: it is used to exchange further credentials, issue access tokens, or otherwise negotiate whatever authentication material is needed to reach the other declared endpoints.
  5. Armed with the artifacts obtained over DIDComm, the peer finally consumes the non-DIDComm endpoint it is interested in (MCP, A2A, website, …), presenting the obtained tokens or credentials as required by that endpoint’s protocol.

Because service endpoints are declared inside a cryptographically controlled DID Document, because the DID itself has been trust-resolved, and because the authentication material for non-DIDComm endpoints originates from the verified DIDComm handshake, any URL reached via those endpoints inherits the trust context of the DID. An MCP call, an A2A message, or a plain website fetch performed through a service entry declared in a verified DID Document is, by construction, an interaction with an identified and accountable operator — not with an anonymous server behind a random URL.

This reverses the common “connect first, verify later” model of today’s internet into a “verify first, then connect” model. The normative requirements for Service Declaration are defined in [VS-SVC].

§ What is a Verifiable User Agent (VUA)?

This section is non-normative.

A Verifiable User Agent (VUA) is software, such as a browser, app, or wallet, designed to connect with Verifiable Services (VS) and other VUAs. When establishing connections, a VUA must verify the identity and trustworthiness of its peers and allow connections only to compliant VS or VUA peers.

As part of this process, the VUA must perform trust resolution by:

This ensures that all connections are based on verifiable trust, not assumptions.

§ What is a Verifiable Public Registry (VPR)?

NOTE

There is a separated VPR spec. The following summarizes the main features of a VPR.

This section is non-normative.

A Verifiable Public Registry (VPR) is a “registry of registries”, a public service that provides foundational infrastructure for decentralized trust ecosystems. It offers:

uml diagram

§ Ecosystems

This section is non-normative.

Each Ecosystem must provide, at a minimum:

The Verifiable Public Registry (VPR) is agnostic to the specific DID methods used. Trust resolution is performed externally, outside the VPR, allowing flexibility and interoperability across ecosystems.

uml diagram

§ Credential Schemas

This section is non-normative.

Credential Schemas are created and managed by Ecosystems (which are themselves controlled by corporations). Each Credential Schema includes, at a minimum:

uml diagram

Participant roles are defined in the table below:

Participant Role Description
Ecosystem Create and control Ecosystems and Credential Schemas. Recognize other corporations by creating Participant entries for them.
Issuer Grantor Ecosystem operator that creates Issuer Participant entries for candidate issuers.
Verifier Grantor Ecosystem operator that creates Verifier Participant entries for candidate verifiers.
Issuer Can issue credentials of this schema.
Verifier Can request presentation of credentials of this schema.
Holder Holds a credential.

Example of a Json Schema credential schema:

{
  "$id": "vpr:verana:VPR_CHAIN_ID:cs:VPR_CREDENTIAL_SCHEMA_ID",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "ExampleCredential",
  "description": "ExampleCredential using JsonSchema",
  "type": "object",
  "properties": {
    "credentialSubject": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "format": "uri"
        },
        "firstName": {
          "type": "string",
          "minLength": 0,
          "maxLength": 256
        },
        "lastName": {
          "type": "string",
          "minLength": 1,
          "maxLength": 256
        },
        "countryOfResidence": {
          "type": "string",
          "minLength": 2,
          "maxLength": 2
        }
      },
      "required": [
        "id",
        "lastName",
        "countryOfResidence"
      ]
    }
  }
}

§ Verifiable Trust Json Schema Credentials (VTJSCs) and Verifiable Trust Credentials (VTCs)

Data stored in a VPR is not verified at the time of storage, nor does it need to be. Verification happens outside the scope of the VPR.

This is not a limitation, it’s a feature. For example, any DID method can be used, and the VPR will never attempt to resolve or validate DIDs itself.

The VPR provides registrations, not validations, leaving trust decisions and verification where they belong: with the relying parties.

To make things verifiable, for a given credential schema:

uml diagram

§ Essential Credential Schemas

Finally, the last concept: to enable fundamental trust operations, such as identifying service providers, service names, and related entities, we define a set of Essential Credential Schemas (ECS) specifically designed for these purposes:

With the Verifiable Trust concept now clearly established, we’re ready to dive into the specifications.

§ Specification

§ [VT-JSON-SCHEMA-CRED-W3C] Verifiable Trust Json Schema Credential

To provide cryptographic evidence that data stored in a VPR (e.g., a credential JSON Schema) is authored and controlled by the Ecosystem that governs it, the corporation controlling the Ecosystem issues a VTJSC (which is a JSON Schema Credential) after creating the CredentialSchema entry in the VPR.

The Json Schema Credential MUST be issued using the Ecosystem DID recorded in the VPR and MUST reference the corresponding CredentialSchema entry.

A VTJSC MUST include, at a minimum, the following attributes:

NOTE

vc-json-schema defines the credentialSchema attribute content. It MUST be exactly as specified in vc-json-schema.

This credential provides verifiable evidence of:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "id": "https://example/vtjsc.json",
  "type": ["VerifiableCredential", "JsonSchemaCredential", "VerifiableTrustJsonSchemaCredential"],
  "issuer": "did:example:ecosystem",

  "credentialSchema": {
    "id": "https://www.w3.org/ns/credentials/json-schema/v2.json",
    "type": "JsonSchema",
    "digestSRI": "sha384-S57yQDg1MTzF56Oi9DbSQ14u7jBy0RDdx0YbeV7shwhCS88G8SCXeFq82PafhCrW"
  },

  "credentialSubject": {
    "id": "vpr:verana:vna-mainnet-1:cs:12345678",
    "type": "JsonSchema",
    "jsonSchema": {
      "$ref": "vpr:verana:vna-mainnet-1:cs:12345678"
    },
    "digestSRI": "sha384-ABCSGyugst67rs67rdbugsy0RDdx0YbeV7shwhCS88G8SCXeFq82PafhCeZ"
  }
}

§ [VT-ECOSYSTEM-DIDDOC] Ecosystem DID Document

Finally, the Ecosystem MUST publish each VTJSC as a Linked Verifiable Presentation in the DID Document associated with the Ecosystem DID registered in the VPR.

Publishing VTJSC in the Ecosystem DID Document ensures that:

The Ecosystem DID Document MUST include a service entry of type LinkedVerifiablePresentation that references a Verifiable Presentation containing one or more VTJSC issued by the Ecosystem DID.

Example:

"service": [
    {
      "id": "did:example:ecosystem#vpr-schemas-example-vtjsc-vp",
      "type": "LinkedVerifiablePresentation",
      "serviceEndpoint": ["https://ecosystem/schemas-example-vtjsc-vp.json"]
    }
    ...
  ]

§ [VT-CRED] Verifiable Trust Credential

Once an Ecosystem has:

authorized issuers MAY issue Verifiable Credentials that conform to those schemas.

Verifiable Credentials that comply with the Verifiable Trust Specification are referred to as Verifiable Trust Credentials (VTCs).

A Verifiable Trust Credential MUST be linked to the applicable VTJSC issued by the Ecosystem DID. For W3C VTCs ([VT-CRED-W3C]), this link is established directly via the credentialSchema property. For AnonCreds VTCs ([VT-CRED-ANON]), the link is indirect: the AnonCreds Credential Definition references the VTJSC via relatedJsonSchemaCredentialId. In both cases, this establishes a verifiable and discoverable trust chain between:

During verification, wallets and verifiers can resolve the referenced VTJSC, verify its authenticity, and determine whether the issuing DID was authorized to issue credentials under that schema. For W3C VTCs, authorization is checked at the objectively determined issuance time (see [VT-CRED-W3C]). For AnonCreds VTCs, authorization is checked at credential reception time (see [VT-CRED-ANON] and [CIT]).

§ Issuance Time and Unlinkability Considerations

This section is non-normative.

Verifiable Trust Credentials are designed to support multiple credential container formats and proof systems in order to balance auditability, interoperability, and privacy. Two recurring challenges must be considered when issuing and presenting credentials: proving issuance time and preventing linkability.

§ Proving Issuance Time

This section is non-normative.

In decentralized systems, relying on issuer-asserted timestamps (such as issuanceDate) is insufficient, as such values can be forged or backdated by the issuer.

To address this, the Verifiable Trust architecture enables objective issuance-time determination for W3C VTCs by anchoring a deterministic cryptographic digest of the credential in the VPR at issuance time. Verifiers can recompute this digest from the presented credential and use the corresponding VPR registration timestamp as the effective issuance time. Note that this mechanism does not apply to AnonCreds VTCs, where unlinkability takes precedence over objective issuance-time anchoring (see [VT-CRED-ANON]).

This approach is:

§ Proving Unlinkability

This section is non-normative.

Unlinkability aims to prevent a verifier from correlating multiple presentations of the same credential or identifying that two credentials were issued to the same subject.

However, strong issuance-time anchoring (e.g., via a stable digest) inherently introduces a linkability vector, as the same digest can be recognized across multiple presentations.

For this reason, unlinkability requirements vary depending on the intended visibility of the credential:

§ Choosing the Appropriate Credential Container

This section is non-normative.

The Verifiable Trust Specification is container-agnostic and supports multiple credential formats to address different requirements:

Depending on the credential format and proof system used, ecosystems can achieve different trade-offs between:

§ Design Principle

The Verifiable Trust framework deliberately avoids mandating a single credential format. Instead, it defines verifiable governance, authorization, and issuance-time semantics that can be enforced across different credential technologies.

Ecosystems MUST clearly specify, for each credential schema, the expected credential container format and privacy properties in order to ensure consistent trust resolution and verifier behavior.

§ [VT-CRED-W3C] W3C Verifiable Trust Credential (VTC)

A W3C Verifiable Trust Credential MUST include, at a minimum, the following attributes:

§ W3C VTC Example

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "id": "urn:uuid:7f3c9a2e-9c8e-4f6e-9c0b-1e3f2d8a91ab",
  "validFrom": "2010-01-01T19:23:24Z",
  "validUntil": "2020-01-01T19:23:24Z",
  "type": [
    "VerifiableCredential",
    "VerifiableTrustCredential",
    "ExampleCredential"
  ],
  "issuer": "did:example:authorized-issuer",
  "credentialSubject": {
    "id": "did:example:holder"
    // ... schema-defined attributes
  },
  "credentialSchema": {
    "id": "https://example/vtjsc.json",
    "type": "JsonSchemaCredential"
  }
}

In this example:

This design ensures that trust decisions remain fully verifiable, ecosystem-governed, and independent of centralized validation services.

§ W3C VTCs: Determining Credential Issuance Time

Verifiable Trust Credentials do not rely on an issuer-asserted issuanceDate field to establish the time of issuance.

Instead, the issuance time of a Verifiable Trust Credential is objectively determined using the credential’s cryptographic digest anchored in the VPR.

When issuing a Verifiable Trust Credential, the issuer MUST:

  1. Canonicalize the credential using the JSON Canonicalization Scheme (JCS) as defined in RFC 8785

  2. Compute a deterministic JCS Digest (digestJCS) of the canonicalized credential using the digest_algorithm specified in the CredentialSchema (SHA384 or SHA512)

  3. Register this digestJCS in the VPR by calling CreateOrUpdateParticipantSession with the digest parameter. The VPR stores the digest with the block timestamp via Store Digest.

During verification, a trust resolution process MUST:

  1. Canonicalize the received credential using JCS (RFC 8785)
  2. Recompute the digestJCS from the canonicalized credential using the digest_algorithm from the CredentialSchema
  3. Query the VPR using Get Digest to locate the corresponding digest entry
  4. Use the created timestamp from the returned Digest entry as the effective issuance time of the credential

This mechanism provides a verifiable, tamper-resistant issuance-time signal that:

§ [VT-CRED-W3C-LINKED-VP] W3C VTC Linked VP

A DID Document MAY present an unlimited number of Verifiable Trust Credential as Linked-VPs. Linked-VPs MUST be signed by the DID controller of the DID Document, and MUST be declared with a fragment that starts with #vpr-schemas- and ends with -vtc-vp. Example:

"service": [
    {
      "id": "did:example:ecosystem#vpr-schemas-example-vtc-vp",
      "type": "LinkedVerifiablePresentation",
      "serviceEndpoint": ["https://ecosystem/schemas-example-vtc-vp.json"]
    }
    ...
  ]

The example component of the fragment identifier is an arbitrary, controller-defined qualifier and MAY be any value chosen by the DID controller to prevent fragment collisions within the same DID Document (e.g., a schema name, logical grouping, version label, or sequence identifier). It has no normative meaning beyond uniqueness within the DID Document.

§ [VT-CRED-ANON] AnonCreds Verifiable Trust Credential (VTC)

An AnonCreds Verifiable Trust Credential is a Verifiable Trust Credential issued using the AnonCreds specification. AnonCreds credentials provide zero-knowledge proof (ZKP) capabilities that are essential for credentials requiring strong privacy guarantees.

AnonCreds VTCs are REQUIRED when:

NOTE

Using AnonCreds for ECS User Agent VTCs is REQUIRED as specified in [VUA-REQ]. See also [VT-ECS-UA-CRED-ANON].

§ AnonCreds VTC Setup

In the Verifiable Trust concept, AnonCreds VTCs do not require publishing a separate AnonCreds Schema to a VDR. Instead, the credential schema is already defined by the [VT-JSON-SCHEMA-CRED-W3C] (VTJSC) issued by the Ecosystem DID, and the AnonCreds Credential Definition references it.

Before issuing AnonCreds VTCs, the following setup MUST be completed:

  1. Credential Definition: The issuer MUST create and publish a Credential Definition. The Credential Definition contains the issuer’s public keys used for signing credentials and is required by holders and verifiers for presentation generation and verification. The Credential Definition MUST include a relatedJsonSchemaCredentialId that references the VTJSC issued by the Ecosystem DID for the corresponding CredentialSchema. The attributes list MUST match the attributes defined in the referenced VTJSC.

  2. Revocation Registry (optional): If credential revocation is needed, the issuer MUST create and publish a Revocation Registry Definition and an initial Revocation Status List.

  3. Link Secret: Each holder MUST create and store a link secret, a private value that enables credential-to-holder binding across multiple credentials without revealing a correlatable identifier.

§ AnonCreds Credential Definition Example
[
  {
    "id": "did:example:issuer/resources/creddef-123",
    "name": "gov-id",
    "version": "1.0",
    "attributes": [
      "birthDate",
      "documentNumber",
      "documentType",
      "firstName",
      "lastName",
      "nationality"
    ],
    "revocationSupported": false,
    "relatedJsonSchemaCredentialId": "https://example-ecosystem/vt/schemas-gov-id-jsc.json"
  }
]

In this example, relatedJsonSchemaCredentialId points to the VTJSC issued by the Ecosystem DID. This establishes the trust chain between the AnonCreds Credential Definition and the ecosystem-governed schema, without duplicating the schema definition in a separate AnonCreds-specific registry.

§ AnonCreds VTC Issuance

AnonCreds credential issuance follows the AnonCreds Issuance Data Flow:

  1. The issuer sends a Credential Offer referencing the Credential Definition.
  2. The holder evaluates the offer, retrieves the Credential Definition from the VDR, and sends a Credential Request that includes a blinded commitment to the holder’s link secret.
  3. The issuer verifies the request and issues the credential with a blind signature over the credential attributes and the blinded link secret.
  4. The holder unblinds the signature, verifies it, and stores the credential.

The issuer never learns the holder’s link secret, and only the holder can unblind the final credential signature.

§ AnonCreds VTC Presentation

AnonCreds holders never present the raw signed credential to verifiers. Instead, the holder derives a verifiable presentation — a zero-knowledge proof that demonstrates:

Presentations follow the AnonCreds Presentation Data Flow. Verifiers create a Presentation Request specifying requested attributes, predicates, and non-revocation intervals.

§ AnonCreds VTCs: Issuance Time

Unlike W3C VTCs, AnonCreds VTCs do not anchor a digest in the VPR to establish issuance time. Because AnonCreds presentations are derived zero-knowledge proofs — not the original credential — a verifier cannot independently recompute a digest from the presentation, making a VPR-anchored digest binding impractical without introducing correlation risks that conflict with AnonCreds’ privacy goals.

Issuer authorization checks at credential reception time are covered by [CIT].

§ AnonCreds VTC W3C Representation

AnonCreds credentials MAY be represented in the W3C Verifiable Credentials format. In this representation:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://raw.githubusercontent.com/anoncreds/anoncreds-spec/main/data/anoncreds-w3c-context.json"
  ],
  "type": [
    "VerifiableCredential",
    "AnonCredsCredential"
  ],
  "issuer": "did:example:authorized-issuer",
  "credentialSchema": {
    "type": "AnonCredsDefinition",
    "definition": "did:example:authorized-issuer/resources/creddef-123"
  },
  "credentialSubject": {
    "userAgentType": "mobile-wallet"
  },
  "proof": {
    "type": "AnonCredsProof2023",
    "signature": "AAAgf9w5.....8Z_x3FqdwRHoWruiF0FlM"
  }
}

§ AnonCreds VTC Privacy Properties

AnonCreds VTCs provide the following privacy properties relevant to the Verifiable Trust framework:

§ [ECS] Essential Credential Schemas

Essential Credential Schemas are the Verifiable Trust basic needed schemas for enabling a minimum trust resolution in Services and User Agents by answering these questions:

Ecosystems can create Essential Credential Schemas (ECS) by creating an Ecosystem in a VPR. There are 4 kinds of ECS:

§ [ECS-EC] Essential Credential Schemas Ecosystem

To provide an Essential Credential Schemas Ecosystem, a corporation creates an Ecosystem entry es in a VPR.

For this Ecosystem to qualify as an ECS Ecosystem and to be used for trust resolution in VSs and VUAs, it MUST provide, associated to the Ecosystem entry es, one CredentialSchema entry for each of [ECS-SERVICE], [ECS-ORG], [ECS-PERSONA], and [ECS-UA], each with a json_schema attribute as defined in the corresponding section.

Additional CredentialSchema entries MAY be provided by the Ecosystem.

To verify that a CredentialSchema entry in a VPR is an Essential Credential Schema, a verifier MUST:

  1. Retrieve the json_schema attribute of the CredentialSchema entry.
  2. Remove the $id property from the object.
  3. Canonicalize it using the JSON Canonicalization Scheme (JCS) as defined in RFC 8785.
  4. Compute the SHA-384 digest of the canonicalized output.
  5. Compare the resulting digest against the following reference values:
Schema Digest
ServiceCredential sha384-0v+BAFGpnBX/RVqH9dUlMglxMrD4AKy4qUtb1lMN4iW9I2gO7XjcUfmGOf0oInP3
OrganizationCredential sha384-UPn4TDqS1nMBAN3FyMzTAZOWp99zBjBD69OjpbhwOKZj7iOrS5qPwJ2SArRz0yzu
PersonaCredential sha384-VfXTfuks02OkoR5USaTfEdc4NU25m4+vNrLATnjC0r0Pn1S3tFTdOvGCfSYdjE2I
UserAgentCredential sha384-yLRK2mCokVjRlGX0nVzdEYQ1o6YWpQqgdg6+HlSxCePP+D7wvs0+70TJACLZfbF/

The $id property is excluded because it contains the VPR-specific schema identifier, which varies across deployments. The remaining schema content is identical for all conforming ECS Ecosystems.

§ [ECS-SERVICE] Service Credential Json Schema

Used to identify Verifiable Services.

Permanent link to schema

Credential subject object of schema MUST contain the following attributes:

the resulting json_schema attribute will be the following Json Schema.

{
  "$id": "vpr:verana:VPR_CHAIN_ID:cs:VPR_CREDENTIAL_SCHEMA_ID",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "ServiceCredential",
  "description": "Identifies a Verifiable Service and defines the minimum trust and access requirements required to interact with it.",
  "type": "object",
  "properties": {
    "credentialSubject": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "format": "uri",
          "maxLength": 2048
        },
        "name": {
          "type": "string",
          "minLength": 1,
          "maxLength": 512
        },
        "type": {
          "type": "string",
          "minLength": 1,
          "maxLength": 128
        },
        "description": {
          "type": "string",
          "maxLength": 4096
        },
        "descriptionFormat": {
          "type": "string",
          "enum": ["text/plain", "text/markdown"],
          "default": "text/plain"
        },
        "logoUri": {
          "type": "string",
          "format": "uri",
          "maxLength": 4096
        },
        "logoDigestSri": {
          "type": "string",
          "maxLength": 256
        },
        "minimumAgeRequired": {
          "type": "integer",
          "minimum": 0,
          "maximum": 255
        },
        "termsAndConditionsUri": {
          "type": "string",
          "format": "uri",
          "maxLength": 4096
        },
        "termsAndConditionsDigestSri": {
          "type": "string",
          "maxLength": 256
        },
        "privacyPolicyUri": {
          "type": "string",
          "format": "uri",
          "maxLength": 4096
        },
        "privacyPolicyDigestSri": {
          "type": "string",
          "maxLength": 256
        }
      },
      "required": [
        "id",
        "name",
        "type",
        "description",
        "logoUri",
        "logoDigestSri",
        "minimumAgeRequired",
        "termsAndConditionsUri",
        "termsAndConditionsDigestSri",
        "privacyPolicyUri",
        "privacyPolicyDigestSri"
      ]
    }
  }
}

§ [ECS-ORG] OrganizationCredential Json Schema

Used to identify Organizations that operate Verifiable Services.

Permanent link to schema

Credential subject object of schema MUST contain the following attributes:

Implementation notes (non-normative):

The resulting json_schema attribute will be the following Json Schema.

{
  "$id": "vpr:verana:VPR_CHAIN_ID:cs:VPR_CREDENTIAL_SCHEMA_ID",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "OrganizationCredential",
  "description": "Identifies a legal organization that operates one or more Verifiable Services.",
  "type": "object",
  "properties": {
    "credentialSubject": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "format": "uri",
          "maxLength": 2048
        },
        "name": {
          "type": "string",
          "minLength": 1,
          "maxLength": 512
        },
        "logoUri": {
          "type": "string",
          "format": "uri",
          "maxLength": 4096
        },
        "logoDigestSri": {
          "type": "string",
          "maxLength": 256
        },
        "registryId": {
          "type": "string",
          "minLength": 1,
          "maxLength": 256
        },
        "registryUri": {
          "type": "string",
          "format": "uri",
          "maxLength": 4096
        },
        "address": {
          "type": "string",
          "minLength": 1,
          "maxLength": 1024
        },
        "countryCode": {
          "type": "string",
          "minLength": 2,
          "maxLength": 2,
          "pattern": "^[A-Z]{2}$"
        },
        "legalJurisdiction": {
          "type": "string",
          "minLength": 1,
          "maxLength": 64,
          "pattern": "^[A-Z]{2}(-[A-Z0-9]{1,3})?$"
        },
        "organizationKind": {
          "type": "string",
          "minLength": 1,
          "maxLength": 64
        },
        "lei": {
          "type": "string",
          "pattern": "^[A-Z0-9]{20}$"
        }
      },
      "required": [
        "id",
        "name",
        "logoUri",
        "logoDigestSri",
        "registryId",
        "address",
        "countryCode"
      ]
    }
  }
}

§ [ECS-PERSONA] Persona Credential Json Schema

Used to identify Personas (human-controlled avatars) that operate Verifiable Services.

Permanent link to schema

Credential subject object of schema MUST contain the following attributes:

Implementation notes (non-normative):

The resulting json_schema attribute will be the following Json Schema.

{
  "$id": "vpr:verana:VPR_CHAIN_ID:cs:VPR_CREDENTIAL_SCHEMA_ID",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "PersonaCredential",
  "description": "Identifies a Persona (human-controlled avatar) that operates one or more Verifiable Services.",
  "type": "object",
  "properties": {
    "credentialSubject": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "format": "uri",
          "maxLength": 2048
        },
        "name": {
          "type": "string",
          "minLength": 1,
          "maxLength": 256
        },
        "description": {
          "type": "string",
          "minLength": 0,
          "maxLength": 16384
        },
        "descriptionFormat": {
          "type": "string",
          "enum": ["text/plain", "text/markdown"],
          "default": "text/plain"
        },
        "avatarUri": {
          "type": "string",
          "format": "uri",
          "maxLength": 4096
        },
        "avatarDigestSri": {
          "type": "string",
          "maxLength": 256
        },
        "controllerCountryCode": {
          "type": "string",
          "minLength": 2,
          "maxLength": 2,
          "pattern": "^[A-Z]{2}$"
        },
        "controllerJurisdiction": {
          "type": "string",
          "minLength": 1,
          "maxLength": 64,
          "pattern": "^[A-Z]{2}(-[A-Z0-9]{1,3})?$"
        }
      },
      "required": [
        "id",
        "name",
        "controllerCountryCode"
      ],
      "dependentRequired": {
        "avatarUri": ["avatarDigestSri"]
      }
    }
  }
}

§ [ECS-UA] User Agent Credential Json Schema

Permanent link to schema

Credential subject object of schema MUST contain the following attributes:

Notes (non-normative):

The resulting json_schema attribute will be the following Json Schema.

{
  "$id": "vpr:verana:VPR_CHAIN_ID:cs:VPR_CREDENTIAL_SCHEMA_ID",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "UserAgentCredential",
  "description": "Identifies a User Agent instance and the software version it runs. The issuer identifies the software product line.",
  "type": "object",
  "properties": {
    "credentialSubject": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "format": "uri",
          "maxLength": 2048
        },
        "version": {
          "type": "string",
          "minLength": 1,
          "maxLength": 64
        },
        "build": {
          "type": "string",
          "minLength": 1,
          "maxLength": 128
        }
      },
      "required": [
        "id",
        "version"
      ]
    }
  }
}

§ [VT-ECS-JSON-SCHEMA-VPR-CONFIG] Essential Schema VPR Configuration

To be considered compliant, CredentialSchema entries for [ECS-SERVICE], [ECS-ORG], and [ECS-PERSONA] MUST set holder_onboarding_mode to ISSUER_ONBOARDING_PROCESS. See vpr spec.

§ [VT-ECS-JSON-SCHEMA-CRED-W3C] Essential Schema VTJSCs

§ [VT-ECS-CRED] Essential Schema Verifiable Trust Credentials

  "service": [
    {
      "id": "did:example:service#vpr-schemas-service-vtc-vp",
      "type": "LinkedVerifiablePresentation",
      "serviceEndpoint": ["https://example.com/vpr-schemas-service-vtc-vp.json"]
    }
  ]

  "service": [
    {
      "id": "did:example:organization#vpr-schemas-org-vtc-vp",
      "type": "LinkedVerifiablePresentation",
      "serviceEndpoint": ["https://example.com/vpr-schemas-org-vtc-vp.json"]
    }
  ]

  "service": [
   {
    "id": "did:example:persona#vpr-schemas-persona-vtc-vp",
    "type": "LinkedVerifiablePresentation",
    "serviceEndpoint": ["https://example.com/vpr-schemas-persona-vtc-vp.json"]
   }
  ]

§ [VT-ECS-ECOSYSTEM-DIDDOC] Ecosystem DID Document for declaring Essential Credential Schemas

If an Ecosystem wishes to provide ECS trust resolution, it MUST present VT Json Schema Credential(s) of all ECSs, as well as the corresponding VPR entry for verification. To do that, Ecosystem MUST define the following entries in its DID Document, for each ECS:

Example:

  "service": [
    {
      "id": "did:example:ecosystem#vpr-schemas-service-vtjsc-vp",
      "type": "LinkedVerifiablePresentation",
      "serviceEndpoint": ["https://ecosystem/ecs-service-vtjsc-vp.json"]
    },
    {
      "id": "did:example:ecosystem#vpr-schemas-org-vtjsc-vp",
      "type": "LinkedVerifiablePresentation",
      "serviceEndpoint": ["https://ecosystem/ecs-org-vtjsc-vp.json"]
    },
    {
      "id": "did:example:ecosystem#vpr-schemas-persona-vtjsc-vp",
      "type": "LinkedVerifiablePresentation",
      "serviceEndpoint": ["https://ecosystem/ecs-persona-vtjsc-vp.json"]
    },
    {
      "id": "did:example:ecosystem#vpr-schemas-ua-vtjsc-vp",
      "type": "LinkedVerifiablePresentation",
      "serviceEndpoint": ["https://ecosystem/ecs-ua-vtjsc-vp.json"]
    }
    
    ...
  ]

§ [VS-REQ] Verifiable Service Basic Requirements and Linked VPs

NOTE

In other words, to qualify as a Verifiable Service:

  • the service MAY directly identify itself by presenting an Organization or Persona Essential Credential; or
  • the issuer of the Service Essential Credential MUST identify itself by presenting an Organization or Persona Essential Credential.

This ensures that every Verifiable Service is ultimately bound to a legally or naturally accountable entity.

§ [VS-SVC] Service Declaration

A Verifiable Service is consumed via service endpoints declared in its DID Document, not via URLs exchanged out of band. This section specifies how a VS MUST declare those endpoints and how peers MUST interact with them.

NOTE

In practice, this means DIDComm acts as the control plane of a Verifiable Service and non-DIDComm endpoints act as its data plane: a peer first performs trust resolution and opens a DIDComm session, uses that session to obtain any credentials or tokens it needs (e.g., bearer tokens for an MCP endpoint, verifiable presentations for an A2A endpoint, signed session cookies for a website), and only then calls the target endpoint with those artifacts.

§ Example: VS DID Document with Multiple Service Endpoints

The following example shows a Verifiable Service DID Document that declares the mandatory DIDComm endpoint alongside optional MCP, A2A and website endpoints, in addition to the identity-layer Linked Verifiable Presentations required by [VS-REQ]:

"service": [
  {
    "id": "did:example:service#vpr-schemas-service-vtc-vp",
    "type": "LinkedVerifiablePresentation",
    "serviceEndpoint": ["https://example.com/vpr-schemas-service-vtc-vp.json"]
  },
  {
    "id": "did:example:service#vpr-schemas-org-vtc-vp",
    "type": "LinkedVerifiablePresentation",
    "serviceEndpoint": ["https://example.com/vpr-schemas-org-vtc-vp.json"]
  },
  {
    "id": "did:example:service#didcomm",
    "type": "DIDCommMessaging",
    "serviceEndpoint": {
      "uri": "https://example.com/didcomm",
      "accept": ["didcomm/v2"],
      "routingKeys": []
    }
  },
  {
    "id": "did:example:service#mcp",
    "type": "MCP",
    "serviceEndpoint": "https://example.com/mcp"
  },
  {
    "id": "did:example:service#a2a",
    "type": "A2A",
    "serviceEndpoint": "https://example.com/a2a"
  },
  {
    "id": "did:example:service#website",
    "type": "LinkedDomains",
    "serviceEndpoint": "https://example.com/"
  }
]

In this example:

A conforming peer would interact with this service as follows:

  1. Trust-resolve did:example:service (per [VS-SVC-4] and [TR]).
  2. Open a DIDComm session to #didcomm.
  3. Over that session, obtain any credentials, access tokens, or other authentication material required by #mcp, #a2a or #website (per [VS-SVC-7]).
  4. Call the target endpoint(s) — #mcp, #a2a or #website — presenting the artifacts obtained in step 3 as that endpoint’s protocol requires.

Per [VS-SVC-5], none of #didcomm, #mcp, #a2a or #website may be used before trust resolution of did:example:service has succeeded.

NOTE

The MCP and A2A service type strings used above are illustrative. Ecosystems are free to standardize type names for emerging protocols; this specification only requires that service entries follow DID Core service syntax and that at least one entry of type DIDCommMessaging is present.

§ [VUA-REQ] Requirements for a User Agent to qualify as a Verifiable User Agent (VUA)

NOTE

Using anoncreds for ECS User Agent VTCs is REQUIRED to reduce correlation and tracking risks, together with selective disclosure and unlinkable presentations.

NOTE

These requirements ensure that a Verifiable User Agent can cryptographically prove the identity and authenticity of the software it represents, while preserving user privacy and enabling policy-based trust decisions by services and peer user agents.

§ [CIB] Credential Issuance by

§ [PRB] Presentation Requested by

§ [CIT] Credential Issued to

§ [PRT] Presentation Requested to

§ [VS-CONN-VS] Requirements for a VS to accept a connection from another service

When a VS VS-1 receives a connection request from a service Service-2 to one of the service endpoints declared in its DID Document (see [VS-SVC]), VS-1 MUST verify that Service-2 complies with [VS-REQ] and [VS-SVC], else VS-1 MUST NOT accept the connection, unless the purpose of the service provided by VS-1 is the issuance of [VT-ECS-ORG-CRED-W3C] or [VT-ECS-PERSONA-CRED-W3C] or [VT-ECS-SERVICE-CRED-W3C] credentials.

§ [VS-CONN-VUA] Requirements for a VS to accept a connection from a User Agent

When a VS receives a connection from a User Agent, it MUST request the presentation of a [VT-ECS-UA-CRED-ANON] credential before starting to provide the service, and verify the presented credential (if any). If no credential is presented or presented credential is not verifiable, VS MUST NOT provide the service.

§ [VUA-CONN-VS] Requirements for a VUA to accept connecting to a service

When a VUA starts a session with a service, the VUA MUST verify that the service complies with [VS-REQ] and [VS-SVC], else the VUA MUST NOT connect to the VS.

§ [VUA-CONN-VUA] Requirements for two VUAs to connect

When a VUA receives a connection from a User Agent, it MUST request the presentation of a [VT-ECS-UA-CRED-ANON] credential before starting to provide the service, and verify the presented credential (if any).

When a VUA initiates a connection to another User Agent, it MUST request the presentation of a [VT-ECS-UA-CRED-ANON] credential before starting to provide the service, and verify the presented credential (if any).

For communication channel between User Agents to be enabled, both User Agents MUST have requested and verified the [VT-ECS-UA-CRED-ANON] credential presented by the peer.

§ [TR] Trust Resolution

§ [WL] ECS Ecosystem whitelists and vpr: scheme resolution

Example:


{ 
  verifiablePublicRegistries: [ 
    { 
      "id": "vna-mainnet-1",
      "scheme": "vpr:verana:vna-mainnet-1",
      "api": [
        "https://idx-mainnet-node-1/",
        "https://idx-mainnet-node-2/"
      ],
      "rpc": [
        "https://rpc-mainnet-node-1/",
        "https://rpc-mainnet-node-2/"
      ],
      "resolver": [
        "https://rsv-mainnet-node-1/",
        "https://rsv-mainnet-node-2/"
      ],
      "version": "1",
      "production": true
    },
    { 
      "id": "vna-testnet-1",
      "scheme": "vpr:verana:vna-testnet-1",
      "api": [
        "https://idx-testnet-node-1/",
        "https://idx-testnet-node-2/"
      ],
      "rpc": [
        "https://rpc-testnet-node-1/",
        "https://rpc-testnet-node-2/"
      ],
      "resolver": [
        "https://rsv-testnet-node-1/",
        "https://rsv-testnet-node-2/"
      ],
      "version": "1",
      "production": true
    }
  ]
}

Example:


{ 
  ecsEcosystems: [ 
    { 
      "did": "did:example:ecosystem",
      "vpr": "vna-mainnet-1"
    },
    { 
      "did": "did:example:ecosystem-test",
      "vpr": "vna-testnet-1"
    }
  ]
}

§ Trust Resolution Examples

This section is non-normative.

Trust resolution in the Verifiable Trust ecosystem is performed outside the VPR itself and relies on auxiliary services (indexers, crawlers, resolvers) that continuously crawl, cache, and index public Verifiable Trust artifacts.

These services do not create trust; they merely make trust resolvable. All trust decisions remain cryptographically verifiable and independently reproducible by relying parties.

Such services typically ingest and index:

Using this indexed data, a relying party (or a wallet acting on its behalf) can answer higher-level trust questions such as the following.

§ Recursive Resolution Principle

Trust resolution is inherently recursive. Every DID encountered during resolution — whether as a credential issuer, a service operator, or a schema controller — MUST itself be resolved and verified. Specifically, any DID that appears as an issuer of a credential MUST be verified as a Verifiable Service (see [VS-REQ]), and all credentials it presents MUST themselves undergo the same resolution steps. This recursion terminates at the Ecosystem DID, which serves as the trust root: it is the issuer of the VTJSC and identifies the Ecosystem itself.

Examples below illustrate how trust resolution is performed assuming that all required Verifiable Trust artifacts are already available to the relying party. No assumptions are made about how the data was obtained; only the logical resolution steps are described.

§ Get the credential with id = "xxxx"

§ Verify the credential is cryptographically valid

§ Resolve the referenced JSON Schema Credential

§ Determine the issuance time of the credential (W3C VTCs only)

This step applies to W3C VTCs only. AnonCreds VTCs do not support objective issuance-time determination (see [VT-CRED-ANON]).

§ Verify issuer authorization

If this check fails, the credential MUST be rejected.

§ Verify the issuer is a Verifiable Service

The credential issuer MUST be a Verifiable Service. To verify this:

§ Determine the governing Ecosystem

This Ecosystem is the ultimate trust root for the credential.

§ Summary

A relying party can therefore answer the following questions deterministically:

All trust decisions are derived from verifiable artifacts and cryptographic proofs, without relying on issuer-asserted claims or implicit trust.

§ Verifiable Trust Agent Flow Examples

This section is non-normative.

The following examples illustrate end-to-end interaction sequences between Verifiable Trust agents and the VPR. They show how the various pieces — DIDComm exchanges, VPR transactions, DID Document updates, and trust resolution — fit together in practice. Each example assumes the participants are conformant VSs (see [VS-REQ]) operating against a single VPR (e.g., a Verana network).

§ Example 1 — Issuing a public W3C credential to a holder

This example shows the action sequence for a holder VS-Agent obtaining a public W3C credential from an issuer and presenting it in its DID Document so that the holder service becomes visible to relying parties through the VPR resolver.

Preconditions:

Sequence:

  1. Start the onboarding process (holder side). The holder VS-Agent submits MsgStartParticipantOP (MOD-PP-MSG-1) on the VPR, targeting the issuer as validator of the requested HOLDER Participant entry against cs. The on-chain entry creates an applicant Participant entry holder_participant in op_state = PENDING whose validator_participant_id points at issuer_participant.

  2. Indexer notifies both parties. Both the holder and the issuer VS-Agents receive an indexer notification for the new onboarding process via their respective DID-scoped subscriptions.

  3. DIDComm session. The holder VS-Agent opens a DIDComm session to the issuer and follows the agent-level credential acquisition protocol (validation request, optional out-of-band steps to provide additional evidence, etc.). The issuer’s VS-Agent collects and validates the evidence on its side.

  4. Validator approves on-chain. Once the issuer is satisfied, its VS-Agent submits MsgSetParticipantOPToValidated (MOD-PP-MSG-3) on the VPR. holder_participant transitions to op_state = VALIDATED and its effective_until is set per the schema’s policy.

  5. Credential issuance over DIDComm. The issuer’s VS-Agent issues a W3C Verifiable Trust Credential to the holder over the existing DIDComm session, using the schema’s VTJSC as credentialSchema.id and anchoring the deterministic digestJCS per [VT-CRED-W3C] and [TR-4].

  6. Holder publishes the credential in its DID Document. The holder VS-Agent updates its DID Document to publish (or update) a linked-vp entry containing the newly received credential, alongside any previously held public credentials.

  7. Holder triggers the resolver. As soon as the updated DID Document is updated, the holder VS-Agent submits MsgTriggerResolver (MOD-PP-MSG-15) for one of its active Participant entries whose did equals the holder DID. The signing parameters use Path 1 of the TriggerResolver authorization model: corporation = holder.corporation, operator = holder.vs_operator. The Msg makes no on-chain state change; it only emits an event.

  8. Trust resolution. The VPR resolver pipeline observes the MsgTriggerResolver event, and trigger the resolver module that fetches the latest holder DID Document, validates each linked-vp credential per [TR-1] through [TR-7], and records the holder DID’s trust state. Subsequent queries to the resolver return trustStatus = TRUSTED for the holder DID.

sequenceDiagram participant Holder as Holder VS-Agent participant Issuer as Issuer VS-Agent participant VPR as VPR (ledger) participant Idx as Indexer + Resolver Holder->>VPR: MsgStartParticipantOP (validator = issuer) VPR-->>Idx: participant-pending event Idx-->>Holder: notify Idx-->>Issuer: notify Holder->>Issuer: DIDComm onboarding flow Issuer->>VPR: MsgSetParticipantOPToValidated Issuer->>Holder: DIDComm credential issuance Holder->>Holder: update DID Document (linked-vp) Holder->>VPR: MsgTriggerResolver VPR-->>Idx: TriggerResolver event Idx->>Idx: re-resolve holder DID -> TRUSTED

§ Example 2 — Revoking a public credential

This example shows the symmetric flow for revoking a previously issued credential and ensuring the resolver and the holder’s DID Document both reflect the revocation.

Preconditions:

Sequence:

  1. Issuer revokes on-chain. The issuer VS-Agent submits MsgRevokeParticipant (MOD-PP-MSG-9) against holder_participant. On confirmation, holder_participant.revoked = now and the Participant entry ceases to be active, which revokes the corresponding credential.

  2. Resolver auto-re-resolves. The VPR resolver pipeline treats MsgRevokeParticipant as an implicit re-resolution signal for the holder DID and re-runs trust resolution. With holder_participant no longer active, the credential it backed is no longer authorised at the current time, so trust resolution against the holder DID’s currently-published linked-vp fails for that credential. The resolver eventually updates the trustStatus = UNTRUSTED for the holder DID (or downgrades it accordingly if it still presents other valid credentials).

  3. Issuer notifies the holder over DIDComm. The issuer’s VS-Agent sends a credential-state-change message to the holder VS-Agent over the existing DIDComm session, informing it that the credential has been revoked. The holder VS-Agent reacts in user-land (display the revocation, request a new credential, stop offering the affected service, etc.).

  4. Holder removes the credential from its DID Document. The holder VS-Agent updates its linked-vp entry to remove the revoked credential. Until the DID Document is updated, the resolver continues to see the (now untrusted) credential.

  5. Holder may trigger the resolver again. The holder VS-Agent may submit MsgTriggerResolver so the resolver picks up the updated DID Document. After this final trigger, the resolver no longer observes the revoked credential at all; the holder DID’s overall trust status is determined by whatever public credentials remain in linked-vp.

sequenceDiagram participant Holder as Holder VS-Agent participant Issuer as Issuer VS-Agent participant VPR as VPR (ledger) participant Idx as Indexer + Resolver Issuer->>VPR: MsgRevokeParticipant (holder_participant) VPR-->>Idx: revoke event (implicit trigger) Idx->>Idx: re-resolve holder DID -> UNTRUSTED Issuer->>Holder: DIDComm credential-state-change (revoked) Holder->>Holder: update DID Document (remove linked-vp entry) Holder->>VPR: MsgTriggerResolver VPR-->>Idx: TriggerResolver event Idx->>Idx: re-resolve holder DID
✕
Table of Contents ✕
undefined