§ Verifiable Trust v4 Specification

Latest Draft: spec v4-draft6

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.

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, trust registry, 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 web nodes:
Decentralized web nodes, see DIF spec
decentralized identifier document:
A DID Document, as specified in [DID-CORE].
verifiable public registry:
a public, normally decentralized network, which provides: trust registry features, that can be used by all its participants: create trust registries, for each trust registry, 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, and that is conforming to this spec and has a resolvable proof of trust. This can be a DIDComm service, a DWN service, o any other service.
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 a trust registry, 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…
trust registry
An approved list of issuers and verifiers that are authorized to issue/verify certain credentials in an ecosystem.
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 trust-registry 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",
      "termsAndConditions": "http://example.com",
      "privacyPolicy": "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.

§ 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

§ Trust Registries

This section is non-normative.

Each Trust Registry 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 trust registry controller (Ecosystems). Each Credential Schema includes, at a minimum:

uml diagram

Participant roles are defined in the table below:

Participant Role Description
Ecosystem Create and control trust registries and credential Schemas. Recognize other participants by granting permission(s) to them.
Issuer Grantor Trust Registry operator that grants Issuer permissions to candidate issuers.
Verifier Grantor Trust Registry operator that grants Verifier permissions to 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/v1/js/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 operates the corresponding Trust Registry, the Ecosystem controller of the Trust Registry 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 as the Trust Registry’s Ecosystem identifier 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/v1/js/12345678",
    "type": "JsonSchema",
    "jsonSchema": {
      "$ref": "vpr:verana:vna-mainnet-1/cs/v1/js/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 Trust Registry 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 Trust Registry 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 CreateOrUpdatePermissionSession 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 a Trust Registry in a VPR. There are 4 kinds of ECS:

§ [ECS-TR] Essential Credential Schemas Trust Registry

To provide an Essential Credential Schemas Trust Registry, an Ecosystem creates its Trust Registry in a VPR by creating a TrustRegistry entry tr.

For this Trust Registry to qualify as an ECS Trust Registry and to be used for trust resolution in VSs and VUAs, it MUST provide, associated to the TrustRegistry entry tr, 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 Trust Registry.

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-PVseqJJjEGMVRcht77rE2yLqRnCiLBRLOklSuAshSEXK3eyITmUpDBhpQryJ/XIx
OrganizationCredential sha384-XF10SsOaav+i+hBaXP29coZWZeaCZocFvfP9ZeHh9B7++q7YGA2QLTbFZqtYs/zA
PersonaCredential sha384-4vkQl6Ro6fudr+g5LL2NQJWVxaSTaYkyf0yVPVUmzA2leNNn0sJIsM07NlOAG/2I
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 Trust Registries.

§ [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/v1/js/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"
        },
        "logo": {
          "type": "string",
          "format": "uri",
          "pattern": "^data:image/(png|jpeg|svg\\+xml);base64,",
          "maxLength": 1400000
        },
        "minimumAgeRequired": {
          "type": "integer",
          "minimum": 0,
          "maximum": 255
        },
        "termsAndConditions": {
          "type": "string",
          "format": "uri",
          "maxLength": 4096
        },
        "termsAndConditionsDigestSri": {
          "type": "string",
          "maxLength": 256
        },
        "privacyPolicy": {
          "type": "string",
          "format": "uri",
          "maxLength": 4096
        },
        "privacyPolicyDigestSri": {
          "type": "string",
          "maxLength": 256
        }
      },
      "required": [
        "id",
        "name",
        "type",
        "description",
        "logo",
        "minimumAgeRequired",
        "termsAndConditions",
        "privacyPolicy"
      ]
    }
  }
}

§ [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/v1/js/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
        },
        "logo": {
          "type": "string",
          "format": "uri",
          "pattern": "^data:image/(png|jpeg|svg\\+xml);base64,",
          "maxLength": 1400000
        },
        "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",
        "logo",
        "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/v1/js/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"
        },
        "avatar": {
          "type": "string",
          "format": "uri",
          "pattern": "^data:image/(png|jpeg|svg\\+xml);base64,",
          "maxLength": 1400000
        },
        "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"
      ]
    }
  }
}

§ [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/v1/js/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-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 Trust Registry 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.

§ [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 receive a connection request from a service Service-2 to one of its services specified in DID Document, VS-1 MUST verify service Service-2 complies with [VS-REQ], else VS-1 MUST NOT accept the connection, unless 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 start a session with a service, VUA MUST verify VS complies with [VS-REQ], else VUA MUST NOT connect to 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 the controller of the Trust Registry.

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.

✕
Table of Contents ✕
undefined