§ Verifiable Trust v2 Specification

Specification Status: Draft

Latest Draft: verana-labs/verifiable-trust-spec

Editors:

Fabrice Rochette, (The Verana Foundation, 2060.io)

Contributors:

Ariel Gentile, (The Verana Foundation, 2060.io)

Andres Vallecilla, (Mobiera)

Participate:

GitHub repo

File a bug

Commit history

§ Abstract

The internet is broken. Existing communication channels are insecure and outdated. Because they rely on public identifiers — like email addresses, usernames, or phone numbers — anyone who knows your identifier can reach you, whether you invited them or not.

Worse, there’s no reliable way to verify the identity of either service providers or users. This leaves the door wide open to spam, phishing, fraud, and identity theft.

On the service side, each provider imposes its own fragmented registration process, often with complex password requirements or forced reliance on federated login systems, effectively handing control over to large third-party platforms.

Although the World Wide Web was originally built for openness and interoperability, dominant players have reshaped it into a closed, centralized system that most people and organizations now depend on. Privacy has become an afterthought, and personal data is routinely harvested, exploited, or leaked.

To rebuild a trustworthy internet, we need new communication channels - channels that are secure by design, based on mutual verification, and governed by decentralized trust.

Connecting to a service, proving who you are, or creating an account should be as simple and safe as presenting a verifiable credential.

A universal, open trust layer is essential for this vision to succeed.

That’s the purpose of Verifiable Trust.

§ 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.
json schema:
A json schema as defined in JSON-SCHEMA.
json schema credential:
A json schema credential as defined in [VC-JSON-SCHEMA].
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:mainnet/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
        },
        "expirationDate": {
          "type": "string",
          "format": "date"
        },
        "countryOfResidence": {
          "type": "string",
          "minLength": 2,
          "maxLength": 2
        }
      },
      "required": [
        "id",
        "lastName",
        "birthDate",
        "expirationDate",
        "countryOfResidence"
      ]
    }
  }
}

§ Verifiable Trust Credentials

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

§ Json Schema Credentials

This section is non-normative.

To prove that data stored in a VPR, such as a credential json schema, is authentic, after creating the JSON Schema, the Ecosystem owner of the Trust Registry issues a JSON Schema Credential using the DID registered as the Trust Registry’s Ecosystem identifier in the VPR.

This credential serves as a verifiable proof of:

{
  "@context": [
      "https://www.w3.org/ns/credentials/v2"
  ],
  "id": "https://ecosystem/shemas-example-jsc.json",
  "type": ["VerifiableCredential", "JsonSchemaCredential"],
  "issuer": "did:example:ecosystem",
  "issuanceDate": "2024-01-01T19:23:24Z",
  "credentialSchema": {
    "id": "https://www.w3.org/ns/credentials/json-schema/v2.json",
    "type": "JsonSchema",
    "digestSRI": "sha384-S57yQDg1MTzF56Oi9DbSQ14u7jBy0RDdx0YbeV7shwhCS88G8SCXeFq82PafhCrW"
  },
  "credentialSubject": {
    "id": "vpr:verana:mainnet/cs/v1/js/12345678",
    "type": "JsonSchema",
    "jsonSchema": {
      "$ref": "vpr:verana:mainnet/cs/v1/js/12345678"
    },
    "digestSRI": "sha384-ABCSGyugst67rs67rdbugsy0RDdx0YbeV7shwhCS88G8SCXeFq82PafhCeZ" 
  }
}

Finally, the Ecosystem must publish both the JSON Schema Credential and the location of the Trust Registry within the DID Document associated with the declared Trust Registry Ecosystem DID in the VPR.

This ensures that the Credential Schema and its controlling Trust Registry are publicly discoverable and cryptographically verifiable.

"service": [
    {
      "id": "did:example:ecosystem#vpr-schemas-example-jsc-vp",
      "type": "LinkedVerifiablePresentation",
      "serviceEndpoint": ["https://ecosystem/schemas-example-jsc-vp.json"]
    },
    {
      "id": "did:example:trust-registry#vpr-schemas-trust-registry-1234",
      "type": "VerifiablePublicRegistry",
      "version": "1.0",
      "serviceEndpoint": ["vpr:verana:mainnet"]
    }
    ...
  ]

§ Issuing Verifiable Trust Credentials

This section is non-normative.

Once the Ecosystem has:

it is now possible to issue Verifiable Credentials based on these schemas.

Credentials that comply with the Verifiable Trust Specification are referred to as Verifiable Trust Credentials (VTC). These credentials must include, in their credentialSchema attribute, a reference to the corresponding JSON Schema Credential issued by the Trust Registry Ecosystem DID. This linkage ensures cryptographic proof of the schema’s origin and trustworthiness.

In our previous example, that would mean and ExampleCredential should look like this example:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "id": "did:example:holder",
  "type": ["VerifiableCredential", "VerifiableTrustCredential", "ExampleCredential"],
  "issuer": "did:example:authorized-issuer",
  "credentialSubject": {
     "id": "did:example:holder",
    ...
  },
  ...
  "credentialSchema": {
    "id": "https://ecosystem/schemas-example-jsc.json",
    "type": "JsonSchemaCredential"
  }
}

§ 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] Verifiable Trust Json Schema Credential

A Verifiable Trust Json Schema Credential is a json schema credential self-issued by a Trust Registry Ecosystem DID, that MUST refer to the json schema of a CredentialSchema entry created in a VPR. Issuer of the Verifiable Trust Json Schema Credential MUST be the same DID that the Ecosystem DID of the TrustRegistry entry created in the VPR than owns the CredentialSchema entry in the VPR.

A Verifiable Trust Json Schema Credential MUST have a credentialSchema property that contains exactly the following:

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

Additionally, it MUST have a credentialSubject object with:

Example of a Verifiable Trust Json Schema Credential:

{
  "@context": [
      "https://www.w3.org/ns/credentials/v2"
  ],
  "id": "https://ecosystem/schemas-example-jsc.json",
  "type": ["VerifiableCredential", "JsonSchemaCredential"],
  "issuer": "did:example:ecosystem",
  "issuanceDate": "2024-01-01T19:23:24Z",
  "credentialSchema": {
    "id": "https://www.w3.org/ns/credentials/json-schema/v2.json",
    "type": "JsonSchema",
    "digestSRI": "sha384-S57yQDg1MTzF56Oi9DbSQ14u7jBy0RDdx0YbeV7shwhCS88G8SCXeFq82PafhCrW"
  },
  "credentialSubject": {
    "id": "vpr:verana:mainnet/cs/v1/js/12345678",
    "type": "JsonSchema",
    "jsonSchema": {
      "$ref": "vpr:verana:mainnet/cs/v1/js/12345678"
    },
    "digestSRI": "sha384-ABCSGyugst67rs67rdbugsy0RDdx0YbeV7shwhCS88G8SCXeFq82PafhCeZ" 
  }
}

§ [VT-ECOSYSTEM-DIDDOC] Ecosystem DID Document

For each CredentialSchema entry an Ecosystem has created in his Trust Registry in a VPR, the Ecosystem MUST self-issue the corresponding Verifiable Trust Json Schema Credential as specified in [VT-JSON-SCHEMA-CRED].

Additionally, in MUST present (as a linked-vp) the Verifiable Trust Json Schema Credential(s) in its DID Document, as well as the corresponding VPR entry for verification. To do so, it MUST define the following entries in its DID Document:

Example:

"service": [
    {
      "id": "did:example:ecosystem#vpr-schemas-example-jsc-vp",
      "type": "LinkedVerifiablePresentation",
      "serviceEndpoint": ["https://ecosystem/schemas-example-jsc-vp.json"]
    },
    {
      "id": "did:example:ecosystem#vpr-schemas-trust-registry-1234",
      "type": "VerifiablePublicRegistry",
      "version": "1.0",
      "serviceEndpoint": ["vpr:verana:mainnet"]
    }
    ...
  ]

§ [VT-CRED] Verifiable Trust Credential

A Verifiable Trust Credential MUST have a credentialSchema property:

As a matter of fact, a Verifiable Trust Credential MUST conform to the dereferenced json schema of the JsonSchemaCredential.

Example:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "id": "did:example:holder",
  "type": ["VerifiableCredential", "VerifiableTrustCredential", "ExampleCredential"],
  "issuer": "did:example:authorized-issuer",
  "credentialSubject": {
     "id": "did:example:holder",
    ...
  },
  ...
  "credentialSchema": {
    "id": "https://ecosystem/schemas-example-jsc.json",
    "type": "JsonSchemaCredential"
  }
}

§ [VT-LINKED-VP] Verifiable Trust Credential 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 -c-vp. Example:

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

§ [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:

An Ecosystem creates its Trust Registry in a VPR by creating a TrustRegistry entry tr. For this Trust Registry to qualify for being used for trust resolution in VSs and VUAs, it MUST provide, associated to the TrustRegistry entry tr, at least one CredentialSchema entry, with a respective json_schema attribute defined as follows in [ECS-SERVICE], [ECS-ORG], [ECS-PERSON], [ECS-UA].

WARNING

All ECS json schema are unstable and may change for v2 stable version of this spec

§ [ECS-SERVICE] Service Credential Json Schema

Used to identify Services.

Credential subject object of schema MUST contain the following attributes:

the resulting json_schema attribute will be the following Json Schema.

{
  "$id": "vpr:verana:mainnet/cs/v1/js/VPR_CREDENTIAL_SCHEMA_ID",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "ServiceCredential",
  "description": "ServiceCredential using JsonSchema",
  "type": "object",
  "properties": {
    "credentialSubject": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "format": "uri"
        },
        "name": {
          "type": "string",
          "minLength": 1,
          "maxLength": 512
        },
        "type": {
          "type": "string",
          "minLength": 1,
          "maxLength": 128
        },
        "description": {
          "type": "string",
          "minLength": 0,
          "maxLength": 4096
        },
        "logo": {
          "type": "string",
          "contentEncoding": "base64",
          "contentMediaType": "image/png"
        },
        "minimumAgeRequired": {
          "type": "number",
          "minimum": 0,
          "exclusiveMaximum": 150
        },
        "termsAndConditions": {
          "type": "string",
          "format": "uri",
          "maxLength": 2048
        },
        "termsAndConditionsHash": {
          "type": "string"
        },
        "privacyPolicy": {
          "type": "string",
          "format": "uri",
          "maxLength": 2048
        },
        "privacyPolicyHash": {
          "type": "string"
        }
      },
      "required": [
        "id",
        "name",
        "type",
        "description",
        "logo",
        "minimumAgeRequired",
        "termsAndConditions",
        "privacyPolicy"
      ]
    }
  }
}

§ [ECS-ORG] OrganizationCredential Json Schema

Used to identify Verifiable Services run by Organizations.

Credential subject object of schema MUST contain the following attributes:

the resulting json_schema attribute will be the following Json Schema.

{
  "$id": "vpr:verana:mainnet/v1/cs/js/VPR_CREDENTIAL_SCHEMA_ID",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "OrganizationCredential",
  "description": "OrganizationCredential using JsonSchema",
  "type": "object",
  "properties": {
    "credentialSubject": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "format": "uri"
        },
        "name": {
          "type": "string",
          "minLength": 0,
          "maxLength": 256
        },
        "logo": {
          "type": "string",
          "contentEncoding": "base64",
          "contentMediaType": "image/png"
        },
        "registryId": {
          "type": "string",
          "minLength": 0,
          "maxLength": 256
        },
        "registryUrl": {
          "type": "string",
          "minLength": 0,
          "maxLength": 256
        },
        "address": {
          "type": "string",
          "minLength": 0,
          "maxLength": 1024
        },
        "type": {
          "type": "string",
          "enum": ["PUBLIC", "PRIVATE", "FOUNDATION"]
        },
        "countryCode": {
          "type": "string",
          "minLength": 2,
          "maxLength": 2
        }
      },
      "required": [
        "id",
        "name",
        "logo",
        "registryId",
        "registryUrl",
        "address",
        "type",
        "countryCode"
      ]
    }
  }
}

§ [ECS-PERSON] Person Credential Json Schema

Used to identify Verifiable Services run by Persons.

Credential subject object of schema MUST contain the following attributes:

the resulting json_schema attribute will be the following Json Schema.

{
  "$id": "vpr:verana:mainnet/v1/cs/js/VPR_CREDENTIAL_SCHEMA_ID",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "PersonCredential",
  "description": "PersonCredential 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
        },
        "avatar": {
          "type": "string",
          "contentEncoding": "base64",
          "contentMediaType": "image/png"
        },
        "birthDate": {
          "type": "string",
          "format": "date"
        },
        "countryOfResidence": {
          "type": "string",
          "minLength": 2,
          "maxLength": 2
        }
      },
      "required": [
        "id",
        "lastName",
        "birthDate",
        "countryOfResidence"
      ]
    }
  }
}

§ [ECS-UA] User Agent Credential Json 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:mainnet/v1/cs/js/VPR_CREDENTIAL_SCHEMA_ID",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "UserAgentCredential",
  "description": "UserAgentCredential using JsonSchema",
  "type": "object",
  "properties": {
    "credentialSubject": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "format": "uri"
        },
        "name": {
          "type": "string",
          "minLength": 1,
          "maxLength": 512
        },
        "description": {
          "type": "string",
          "minLength": 0,
          "maxLength": 4096
        },
        "category": {
          "type": "string",
          "minLength": 1,
          "maxLength": 128
        },
        "logo": {
          "type": "string",
          "contentEncoding": "base64",
          "contentMediaType": "image/png"
        },
        "wallet": {
          "type": "boolean"
        },
        "termsAndConditions": {
          "type": "string",
          "format": "uri",
          "maxLength": 2048
        },
        "termsAndConditionsHash": {
          "type": "string"
        },
        "privacyPolicy": {
          "type": "string",
          "format": "uri",
          "maxLength": 2048
        },
        "privacyPolicyHash": {
          "type": "string"
        }
      },
      "required": [
        "id",
        "name",
        "description",
        "category",
        "logo",
        "wallet",
        "termsAndConditions",
        "privacyPolicy"
      ]
    }
  }
}

§ [VT-ECS-JSON-SCHEMA-CRED] Essential Schema Json Schema Credentials

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

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

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

  "service": [
    {
      "id": "did:example:service#vpr-ecs-person-c-vp",
      "type": "LinkedVerifiablePresentation",
      "serviceEndpoint": ["https://service/ecs-person-c-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 the ECSs they support, 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 they support:

Example:

  "service": [
    {
      "id": "did:example:ecosystem#vpr-ecs-service-jsc-vp",
      "type": "LinkedVerifiablePresentation",
      "serviceEndpoint": ["https://ecosystem/ecs-service-jsc-vp.json"]
    },
    {
      "id": "did:example:ecosystem#vpr-ecs-org-jsc-vp",
      "type": "LinkedVerifiablePresentation",
      "serviceEndpoint": ["https://ecosystem/ecs-org-jsc-vp.json"]
    },
    {
      "id": "did:example:ecosystem#vpr-ecs-person-jsc-vp",
      "type": "LinkedVerifiablePresentation",
      "serviceEndpoint": ["https://ecosystem/ecs-person-jsc-vp.json"]
    },
    {
      "id": "did:example:ecosystem#vpr-ecs-ua-jsc-vp",
      "type": "LinkedVerifiablePresentation",
      "serviceEndpoint": ["https://ecosystem/ecs-ua-jsc-vp.json"]
    },
    {
      "id": "did:example:ecosystem#vpr-ecs-trust-registry-789041745",
      "type": "VerifiablePublicRegistry",
      "version": "1.0",
      "serviceEndpoint": ["vpr:verana:mainnet"]
    }
    
    ...
  ]

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

NOTE

In other words, to be a VS, a service MUST identify itself directly by presenting an Organization or a Person Essential Credential, or the issuer of its Service Essential Credential MUST identify itself by presenting an Organization or a Person Essential Credential.

§ [VUA-REQ] Requirements for a User Agent to be a VUA

NOTE

It is RECOMMENDED to use anoncreds plus selective disclosure for [VT-ECS-UA-CRED] and presentations to prevent correlation.

§ [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] or [VT-ECS-PERSON-CRED] 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] 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] 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] 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] credential presented by the peer.

§ [VT-PERM-QUERIES] Verification of permission(s) in Verifiable Public Registries

For any credential issuance or credential verification, in addition to verifying the compliance of their peers (VSs and VUAs), entities MUST query the relevant Verifiable Public Registry (VPR) to ensure that the credential(s) are being issued or verified by authorized entities.

Depending on the permissions registered in the VPR(s), the issuer or verifier MAY be required to execute a transaction in the VPR, which MAY involve the payment of trust fees, prior to offering or requesting the presentation of a credential.

The receiving VS or VUA MUST deny the credential offer or presentation request if these preconditions are not met.

This section is non-normative and should be developed with examples and flow diagrams.

When a VS or a VUA receives a credential offer or a presentation request, it must use the appropriate VPR endpoints to verify the following:

The requested VS or VUA must reject the credential offer or presentation request if these conditions are not fulfilled.

Please refer to Permission Module in VPR specs for more information.

§ [VT-TRQP] Trust Registry Query Protocol

It is RECOMMENDED for implementations to support the TRQP. When TRQP stabilizes, they will likely become the default method for VPR queries.

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

Example:


{ 
  verifiablePublicRegistries: [ 
    { 
      "name": "vpr:verana:mainnet",
      "baseurls": [
        "https://user-agent-vpr-node-1/vpr/",
        "https://user-agent-vpr-node-2/vpr/",
      ]
      "version": "1"
      "production": true
    },
    { 
      "name": "vpr:verana:testnet",
      "baseurls": [
        "https://user-agent-vpr-node-testnet/vpr/"
      ]
      "version": "1"
      "production": false
    },
    { 
      "name": "vpr:verana:devnet",
      "baseurls": [
        "https://user-agent-vpr-node-devnet/vpr/"
      ]
      "version": "2"
      "production": false
    }
  ]
}

Example:


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

Everything below this point is outdated and should be ignored

§ Implementations

This section is non-normative.

Implementations are provided by the community, being the Verana Foundation and 2060.io the most active contributors at the moment.

§ Trust Resolution

§ Typescript Implementation

This section is non-normative.

§ VUAs Implementations

§ Hologram Messaging

This section is non-normative.

Hologram Messaging is a Verifiable Credential wallet and messaging app with true privacy preserving features. Unlike other messaging apps, Hologram is a self-custody app, which means user’s data is only stored on device, and exclusively under user’s control.

Hologram is the first ever-built VUA and is already available in the app stores, look for “Hologram Messaging” in apple store, google play or huawei’s app gallery. It has a user interface very similar to that well known apps like whatsapp, signal or telegram.

Based on the DIDComm open protocol, Hologram provides classic features such has peer-to-peer chat with verifiable credential exchange (to be able to verify who I am chatting to), as well as a Verifiable Chatbot browser to connect to any decentralized Hologram Chatbot VS. Anyone can create an Hologram Service, publish its DID, and invite users to connect by using Hologram (or any other compatible User Agent), request Verifiable Credential Presentations, issue credentials, perform calls and video calls, exchange content, read NFC chips, and more. Integration of p2p money transfers and payments are underway.

Because Hologram is using the DIDComm open protocol, anyone can create a new interoperable VUA so that Hologram users will natively be able to chat with users from others compatible VUAs.

§ VSs Implementations

§ Hologram Services

This section is non-normative.

Hologram Services can be of 2 kinds:

Creation of an Hologram Service is really straightforward, just have a look at 2060.io github repository for examples.

Popular Chatbot Services include:

Basic Out-of-band Services include:

§ User Agent Display of Trust Resolution

VUAs MUST show a representation of the trust resolution for any connection, with VSs or other VUAs.

§ Credential Wallets

§ Connection Invitation

§ Presentation Request

§ Internationalization

This section is non normative.

It is the responsibility of browsers and search engines to properly translate credential attributes, as credential schemas are always defined in a single language, that SHOULD be english.

✕
Table of Contents ✕
undefined