§ Verifiable Public Registry v2 Specification

Specification Status: Preview

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

Editors:

Fabrice Rochette (The Verana Foundation, 2060.io)

Contributors:

Ariel Gentile

Mathieu Gauthron

Pratik Kumar

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. The concept of Verifiable Trust is specified in the Verifiable Trust spec.

This specification deals with the Verifiable Public Registry (VPR), a decentralized registry of registries, part of the Verifiable Trust concept.

§ About this Document

In order to fully understand the concepts developed in this document, you should have some basic knowledge of DID, DIDComm, VS, trust registry, ledger-based applications, and more generally, all terms present in the Terminology section.

NOTE

Before exploring this spec, it is highly recommended to first read the Verifiable Trust Spec.

§ Introduction

§ What is a Trust Registry?

This section is non-normative.

A trust registry is an approved list of recognized ecosystem participants, such as trust registry operators, credential issuers and verifiers that are authorized to onboard ecosystem participants, and or issue/verify certain credentials in an ecosystem.

A trust registry typically expose APIs that are consumed by services that would like to query its database, and take decisions based on the returned result:

§ What is a Verifiable Public Registry?

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

Additionally, a VPR provides a DID directory, a simple repository of service identifiers (DIDs).

Any account registered in the VPR can add a DID to the DID directory.

This directory is intended to be crawled by indexers, which resolve the listed DIDs, identify associated verifiable services, and index them.

Indexers may expose this data through APIs for querying the indexed services or use it to build a search engine for querying the database of indexed verifiable services.

§ 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

account:
A verifiable public registry account.
applicant:
A account that starts a validation process.
controller:
An account which is the controller of a specific resource in an VPR.
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.
credential schema permission:
A permission, linked to a credential schema, that represent, in a given ecosystem, a grant for being issuer, verifier, issuer grantor, or verifier grantor of a 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].
decentralized web nodes:
Decentralized web nodes, see DIF spec
denom:
Native token of a VPR, example: VNA.
DID Directory:
A repository of DIDs in a VPR.

ecosystem: a network of interacting entities, both technical and human, that work together to establish and maintain digital trust. It encompasses applications, credentials, governance frameworks, and the underlying technical infrastructure, all designed to facilitate trustworthy interactions.

ecosystem governance framework:
The governance framework (GF) of an ecosystem].
ecosystem governance authority:
The governance authority (GA) of an ecosystem.
entity:
An account controller.
estimated transaction fees:
Estimated fees required, in denom, that is passed when execute a transaction in an VPR. Usually, a estimated transaction fees are always slightly greater than transaction fees, to make sure the execution of the transaction will not be aborted for an out-of-gas situation. Unused gas is refunded to account.
governance framework:
The governance framework (GF) of a VPR.
governance authority:
The governance authority (GA) of a VPR.
grantor:
A role an entity is granted by an ecosystem for operating its trust registry.
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 is granted by an ecosystem or an issuer grantor for issuing credentials of a given credential schema to holders.
issuer grantor:
A trust registry operator role an entity is granted by an ecosystem for a given credential schema for adding or revoking issuers.
json schema
a Json Schema, as specified in https://json-schema.org/specification.
keeper:
A storage map(key, value) in the ledger of an VPR.
linked-vp:
A presentation of a verifiable credential as specified in LINKED-VP.
participant:
An entity that is recognized by one or several ecosystem(s) in a VPR.
query:
A read-only action that perform some reading in an VPR and returns value.
subject:
A thing about which claims are made. Example subjects include human beings, animals, things, and organization, a DID
transaction:
An action that modifies the ledger of an VPR and which execution requires transaction fees.
transaction fees:
Fees required, in denom, to execute a transaction in an VPR.
trust deposit:
A financial deposit that is used as a trust guarantee. For a given controller, its trust deposit is increased when running validation process (either as an applicant or as a validator), or when registering DID in the DID directory.
trust fee:
Fees paid by a participant that are distributed to other participants.
network fee:
Fees paid by a participant that are distributed to network validators and trust deposit holders.
trust unit:
Price, in denom, of one unit of trust.
trust registry
An approved list of issuers and verifiers that are authorized to issue/verify certain credentials in an ecosystem.
URI
An Universal Resource Identifier, as specified in rfc3986.
valid permission:
For a given country code, a credential schema permission of a given type, which (country attribute is null or equals to the given country code), and effective_from timestamp is lower than current timestamp, and (effective_until timestamp is null or greater than current timestamp), and revoked is null and terminated is null and slashed is null.
validation process:
A process run by applicants that want to, for a specific credential schema, be a issuer, be a verifier, or simply hold a verifiable credential linked to the credential schema.
validator:
A role an entity performs by participating in validation processes with applicants in order to register them as issuer, or verifier of a credential schema, or to deliver a verifiable credential to them.
verifiable public registry:
a public, normally decentralized, ledger-based 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,… and a tokenized business model for charging/rewarding participants.
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. See VT Spec.
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. See VT Spec.
Verifiable Trust Specification:
see VT Spec.
verifier:
A role an entity is granted by an ecosystem or a verifier grantor for verifying credentials of a given credential schema.
verifier grantor:
A trust registry operator role an entity is granted by an ecosystem for a given credential schema for adding or revoking verifiers.
verifiable credential:
A verifiable credential as defined in [VC-DATA-MODEL].

§ Naming Conventions

§ In this spec

§ In Implementations

§ Features of a Verifiable Public Registry (VPR)

§ Trust Registry Management

This section is non-normative.

In an VPR, any account can create (and become the controller of) a TrustRegistry entry that represents a trust registry of an ecosystem. Each TrustRegistry entry 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 and Permissions

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

To participate in an ecosystem and assume a role associated with a specific credential schema, an entity must have an account in the VPR and complete a validation process to obtain the required permission.

The validation process involves two parties:

Running a validation process typically involves the payment of trust fees. Trust fee amount to be paid by the applicant is defined in the permission of the validator involved in the validation process:

uml diagram
NOTE

If an issuer chooses to charge trust fees to a credential holder using the tokenized payment system of the VPR, a validation process must take place and the holder (applicant) MUST have an account to complete the transaction.

Alternatively, the issuer may opt not to use the VPR validation process for holder verification. In such cases, validation occurs outside the VPR, and the issuer is free to use external payment methods (e.g., credit card) to collect fees from the holder candidate.

§ DID Directory Management

This section is non-normative.

The DID directory is a public database of services that can be used by crawlers to index the metadata associated with verifiable services.

Search engines can iterate over the DID directory and index VSs by resolving the service identifier (at the moment a DID, that could be extended in the future), verify if service is a verifiable service, and in such a case extracting their verifiable metadata, such as linked-vp presented credentials.

The DID directory is particularly important for verifiable user agents, such as social browsers, CDN enabled browsers… However, it can also be leveraged by traditional, form-based search engines, which may return simple links for accessing VSs.

Any participant can register a DID in the DID directory by executing a transaction involving network fees and requiring trust deposit.

uml diagram

§ Business models

§ Trust Deposit

This section is non-normative.

In a VPR, each account is associated with a trust deposit.

This trust deposit is automatically funded through transactions involving trust operations, such as:

The trust deposit is fundamental to the “Proof-of-Trust” (PoT) mechanism of the Verifiable Trust Specification, and it operates as follows:

This system ensures that participation in the trust ecosystem is backed by economic accountability, reinforcing the integrity, governability and verifiability of the VPR.

§ Object creation

This section is non-normative.

Creating the following objects requires both a contribution to the trust deposit and the payment of applicable network fees:

The following operations only require payment of network fees (no trust deposit is involved):

§ Validation process trust fees

This section is non-normative.

We’ve explained in the Credential Schemas and Permissions section above what is a validation process.

The table below summarizes the possible combinations of applicants and validators:

Payee → Payer ↓ Ecosystem Issuer Grantor Verifier Grantor Issuer Verifier Holder
Issuer Grantor renewable subscription (1)
Verifier Grantor renewable subscription (2)
Issuer renewable subscription (3) renewable subscription (1)
Verifier renewable subscription (4) renewable subscription (2)
Holder renewable subscription

Validation process is started by the applicant.

Example of a candidate issuer (applicant) that would like to be granted an ISSUER permission for a credential schema of an ecosystem, by a validator that has a ISSUER_GRANTOR permission:

uml diagram

The total fees paid by the applicant consists of:

Example, using 20% for trust_deposit_rate:

uml diagram

Upon completion of the validation process, escrowed trust fees are distributed to the validator as follows:

uml diagram

§ “Pay-Per” trust fees

This section is non-normative.

Pay-per-issuance and pay-per-verification trust fees are defined at the permission level for each role within the ecosystem.

uml diagram

Entities acting as issuers or verifiers for a given credential schema may be required to pay trust fees based on the schema’s configuration and permission tree.

If trust fee payment is required, the entity must execute a transaction in the VPR to pay the appropriate trust fees before issuing or verifying a credential.

Key Points for “Pay-Per” Business Models

Fee Distribution Model

Trust fees are consistently distributed across participants:

NOTE

Wallet User Agents and User Agents that implement the VT spec must verify that the ISSUER or VERIFIER has fulfilled the required trust fee payment.
If not, they must reject the issuance or verification request.

Note: The User Agent and Wallet User Agent may refer to the same implementation.

Distribution example for the issuance by ISSUER #C of a credential, using the permission tree above, 20% for trust_deposit_rate, 10% for wallet_user_agent_reward_rate and user_agent_reward_rate.

uml diagram

Distribution example for the verification by VERIFIER #E of a credential issued by ISSUER #C, using the permission tree above, 20% for trust_deposit_rate, 10% for wallet_user_agent_reward_rate and user_agent_reward_rate.

uml diagram

§ Governance of a VPR

This section is non-normative.

A governance framework must define the governance rules that apply to a VPR.

A designated governance authority is responsible for enforcing these rules and, when necessary, applying financial sanctions to participants who violate the rules.

NOTE

Ecosystem Governance Frameworks (EGFs) operate independently from the VPR governance framework.

While the VPR governance framework defines the global rules for operating the Verifiable Public Registry (e.g., trust deposits, fee distribution, slashing conditions), each ecosystem must define its own EGF to govern roles, permissions, credential policies, and compliance within its specific domain.

This separation ensures that ecosystems remain autonomous and can tailor governance to their unique needs, without being constrained by the global rules of the VPR.

§ Data model

For simplicity, the data model is presented using an object-relational structure. However, this representation may not be optimal for all implementation scenarios.

Implementors are responsible for adapting the data model to suit their chosen architecture.
For example, a key-value store may be more appropriate for a ledger-based implementation than a relational model.

uml diagram

§ TrustRegistry

TrustRegistry:

§ GovernanceFrameworkVersion

GovernanceFrameworkVersion:

§ GovernanceFrameworkDocument

GovernanceFrameworkDocument

§ CredentialSchema

CredentialSchema:

General Info:

§ Permission

Permission:

§ PermissionSession

PermissionSession:

§ DIDDirectory

DidDirectory:

§ TrustDeposit

TrustDeposit:

§ GlobalVariables

GlobalVariables:

Trust Unit:

Credential Schema:

Validation:

Trust Registry:

DID Directory:

Trust Deposit:

§ Module Requirements

All VPR modules MUST, at least, provide:

Note about Query REST API:

Examples:

Get a TrustRegistry

"trust_registry": {
  {
    "active_version": 0,
    "aka": "string",
    "controller": "string",
    "created": "2025-01-14T19:40:37.967Z",
    "deposit": "string",
    "did": "string",
    "id": "string",
    "language": "string",
    "modified": "2025-01-14T19:40:37.967Z",
    "versions": [
      {
        "active_since": "2025-01-14T19:40:37.967Z",
        "created": "2025-01-14T19:40:37.967Z",
        "id": "string",
        "tr_id": "string",
        "version": 0,
        "documents": [
          {
            "created": "2025-01-14T19:40:37.967Z",
            "gfv_id": "string",
            "digest_sri": "string",
            "id": "string",
            "language": "string",
            "url": "string"
          }
        ]
      }
    ]  
  }
"trustRegistries": [ {
  {
    "active_version": 0,
    "aka": "string",
    "controller": "string",
    "created": "2025-01-14T19:40:37.967Z",
    "deposit": "string",
    "did": "string",
    "id": "string",
    "language": "string",
    "modified": "2025-01-14T19:40:37.967Z",
    "versions": [
      {
        "active_since": "2025-01-14T19:40:37.967Z",
        "created": "2025-01-14T19:40:37.967Z",
        "id": "string",
        "tr_id": "string",
        "version": 0,
        "documents": [
          {
            "created": "2025-01-14T19:40:37.967Z",
            "gfv_id": "string",
            "digest_sri": "string",
            "id": "string",
            "language": "string",
            "url": "string"
          }
        ]
      }
    ]  
  }, {
    "active_version": 0,
    "aka": "string",
    "controller": "string",
    "created": "2025-01-14T19:40:37.967Z",
    "deposit": "string",
    "did": "string",
    "id": "string",
    "language": "string",
    "modified": "2025-01-14T19:40:37.967Z",
    "versions": [
      {
        "active_since": "2025-01-14T19:40:37.967Z",
        "created": "2025-01-14T19:40:37.967Z",
        "id": "string",
        "tr_id": "string",
        "version": 0,
        "documents": [
          {
            "created": "2025-01-14T19:40:37.967Z",
            "gfv_id": "string",
            "digest_sri": "string",
            "id": "string",
            "language": "string",
            "url": "string"
          }
        ],
      }
    ]  
  }
]
WARNING

For Msg methods, all precondition checks MUST be verified first for accepting the Msg, and MUST be verified again upon method execution

A VPR implementation MUST implement all the following requirements.

NOTE

The relative REST path is the path suffix. Implementer can set any prefix, like https://example/verana/tr/v1/get.

Module Method Name Relative REST API path Type Requirements
Trust Registry Create a Trust Registry Msg [MOD-TR-MSG-1]
Add Governance Framework Document Msg [MOD-TR-MSG-2]
Increase Active Version Msg [MOD-TR-MSG-3]
Update Trust Registry Msg [MOD-TR-MSG-4]
Archive Trust Registry Msg [MOD-TR-MSG-5]
Update TR Module Parameters Msg [MOD-TR-MSG-6]
Get Trust Registry /tr/v1/get Query [MOD-TR-QRY-1]
List Trust Registries /tr/v1/list Query [MOD-TR-QRY-2]
List TR Module Parameters /tr/v1/params Query [MOD-TR-QRY-3]
Credential Schema Create a Credential Schema Msg [MOD-CS-MSG-1]
Update a Credential Schema Msg [MOD-CS-MSG-2]
Archive Credential Schema Msg [MOD-CS-MSG-3]
Update CS Module Parameters Msg [MOD-CS-MSG-4]
List Credential Schemas /cs/v1/list Query [MOD-CS-QRY-1]
Get a Credential Schema /cs/v1/get Query [MOD-CS-QRY-2]
Render Json Schema /cs/v1/js Query [MOD-CS-QRY-3]
List CS Module Parameters /cs/v1/params Query [MOD-TR-QRY-3]
Permission Start Permission VP Msg [MOD-PERM-MSG-1]
Renew a Permission VP Msg [MOD-PERM-MSG-2]
Set Permission VP to Validated Msg [MOD-PERM-MSG-3]
Request Permission VP Termination Msg [MOD-PERM-MSG-4]
Confirm Permission VP Termination Msg [MOD-PERM-MSG-5]
Cancel Permission VP Last Request Msg [MOD-PERM-MSG-6]
Create Root Permission Msg [MOD-PERM-MSG-7]
Extend Permission Msg [MOD-PERM-MSG-8]
Revoke Permission Msg [MOD-PERM-MSG-9]
Create or update Permission Session Msg [MOD-PERM-MSG-10]
Update Permission Module Parameters Msg [MOD-PERM-MSG-11]
Slash Permission Trust Deposit Msg [MOD-PERM-MSG-12]
Repay Permission Slashed Trust Deposit Msg [MOD-PERM-MSG-13]
Create Permission Msg [MOD-PERM-MSG-14]
List Permissions /perm/v1/list Query [MOD-PERM-QRY-1]
Get a Permission /prem/v1/get Query [MOD-PERM-QRY-2]
Find Permissions With DID /perm/v1/find_with_did Query [MOD-PERM-QRY-3]
Find Beneficiaries /perm/v1/beneficiaries Query [MOD-PERM-QRY-4]
Get Permission Session /perm/v1/get_session Query [MOD-PERM-QRY-5]
List Permission Module Parameters Query [MOD-PERM-QRY-6]
List Permission Sessions Query [MOD-PERM-QRY-7]
DID Directory Add a DID Msg [MOD-DD-MSG-1]
Renew a DID Msg [MOD-DD-MSG-2]
Remove a DID Msg [MOD-DD-MSG-3]
Touch a DID Msg [MOD-DD-MSG-4]
Update TD Module Parameters Msg [MOD-DD-MSG-5]
List DIDs /dd/v1/list Query [MOD-DD-QRY-1]
Get a DID /dd/v1/get Query [MOD-DD-QRY-2]
List DD Module Parameters /dd/v1/params Query [MOD-DD-QRY-3]
Trust Deposit Adjust Trust Deposit Msg [MOD-TD-MSG-1]
Reclaim Trust Deposit Yield Msg [MOD-TD-MSG-2]
Reclaim Trust Deposit Msg [MOD-TD-MSG-3]
Update TD Module Parameters Msg [MOD-TD-MSG-4]
Slash Trust Deposit Msg [MOD-TD-MSG-5]
Repay Slashed Trust Deposit Msg [MOD-TD-MSG-6]
Burn Ecosystem Slashed Trust Deposit Msg [MOD-TD-MSG-7]
Get Trust Deposit /td/v1/get Query [MOD-TD-QRY-1]
List TD Module Parameters /td/v1/params Query [MOD-TD-QRY-2]
NOTE

Any method failure in the precondition/basic checks SHOULD lead to a CLI ERROR / HTTP BAD REQUEST error with a human readable message giving a clue of the reason why method failed.

§ Trust Registry Module

§ [MOD-TR-MSG-1] Create New Trust Registry

Any account CAN execute this method.

§ [MOD-TR-MSG-1-1] Create New Trust Registry parameters

An account that would like to create a trust registry MUST call this method by specifying:

Provided document must be of the same language that the primary language of the trust registry.

§ [MOD-TR-MSG-1-2] Create New Trust Registry precondition checks

If any of these precondition checks fail, method MUST abort.

§ [MOD-TR-MSG-1-2-1] Create New Trust Registry basic checks
NOTE

It is not a problem if several trust registries are created with the same ecosystem DID. Identifier of a TrustRegistry is its id, and the Verifiable Trust Spec includes the id of the TrustRegistry in the DID Document. DID unique constraint is then not needed.

§ [MOD-TR-MSG-1-2-2] Create New Trust Registry fee checks

Applicant MUST have an available balance in its account, to cover the following:

NOTE

TrustRegistry trust deposit is not reclaimable.

§ [MOD-TR-MSG-1-3] Create New Trust Registry execution

If all precondition checks passed, method is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

§ [MOD-TR-MSG-2] Add Governance Framework Document

Any account CAN execute this method.

§ [MOD-TR-MSG-2-1] Add Governance Framework Document parameters

An account that would like to add a governance framework document MUST call this method by specifying:

If for a given language, a document already exists, the execution of this transaction would replace the corresponding entry. Else, a new entry is created.

§ [MOD-TR-MSG-2-2] Add Governance Framework Document precondition checks

If any of these precondition checks fail, method MUST abort.

§ [MOD-TR-MSG-2-2-1] Add Governance Framework Document basic checks
§ [MOD-TR-MSG-2-2-2] Add Governance Framework Document fee checks

Account MUST have the required estimated transaction fees in its account.

§ [MOD-TR-MSG-2-3] Add Governance Framework Document execution

If all precondition checks passed, method is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

load GovernanceFrameworkVersion entry gfv for the requested version, or create a new GovernanceFrameworkVersion gfv if required:

§ [MOD-TR-MSG-3] Increase Active Governance Framework Version

Any account CAN execute this method.

§ [MOD-TR-MSG-3-1] Increase Active Governance Framework Version parameters

An account that would like to add a governance framework document MUST call this method by specifying:

§ [MOD-TR-MSG-3-2] Increase Active Governance Framework Version precondition checks

If any of these precondition checks fail, method MUST abort.

§ [MOD-TR-MSG-3-2-1] Increase Active Governance Framework Version basic checks
§ [MOD-TR-MSG-3-2-2] Increase Active Governance Framework Version fee checks

Account MUST have the required estimated transaction fees in its account.

§ [MOD-TR-MSG-3-3] Increase Active Governance Framework Version execution

If all precondition checks passed, method is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

§ [MOD-TR-MSG-4] Update Trust Registry

Any account CAN execute this method.

§ [MOD-TR-MSG-4-1] Update Trust Registry parameters

An account that would like to update a trust registry MUST call this method by specifying:

§ [MOD-TR-MSG-4-2] Update Trust Registry precondition checks

If any of these precondition checks fail, method MUST abort.

§ [MOD-TR-MSG-4-2-1] Update Trust Registry basic checks
§ [MOD-TR-MSG-4-2-2] Update Trust Registry fee checks

Applicant MUST have an available balance in its account, to cover the required transaction fees.

§ [MOD-TR-MSG-4-3] Update Trust Registry execution

If all precondition checks passed, method is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

§ [MOD-TR-MSG-5] Archive Trust Registry

Any account CAN execute this method.

§ [MOD-TR-MSG-5-1] Archive Trust Registry parameters

An account that would like to archive or unarchive a trust registry MUST call this method by specifying:

§ [MOD-TR-MSG-5-2] Archive Trust Registry precondition checks

If any of these precondition checks fail, method MUST abort.

§ [MOD-TR-MSG-5-2-1] Archive Trust Registry basic checks
§ [MOD-TR-MSG-5-2-2] Archive Trust Registry fee checks

Account MUST have an available balance in its account to cover the required transaction fees.

§ [MOD-TR-MSG-5-3] Archive Trust Registry execution

If all precondition checks passed, method is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

§ [MOD-TR-MSG-6] Update Module Parameters

Update Module Parameters.

Can only be executed through a governance proposal.

§ [MOD-TR-MSG-6-1] Update Module Parameters parameters
§ [MOD-TR-MSG-6-2] Update Module Parameters precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-TR-MSG-6-2-1] Update Module Parameters basic checks
§ [MOD-TR-MSG-6-2-2] Update Module Parameters fee checks

provided transaction fees MUST be sufficient for execution

§ [MOD-TR-MSG-6-3] Update Module Parameters execution

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

for each parameter param <key, value> in parameters:

§ [MOD-TR-QRY-1] Get Trust Registry

Anyone CAN execute this method.

§ [MOD-TR-QRY-1-1] Get Trust Registry parameters
§ [MOD-TR-QRY-1-2] Get Trust Registry checks
§ [MOD-TR-QRY-1-3] Get Trust Registry execution

return found TrustRegistry entry (if any), as well as all its nested GovernanceFrameworkVersion and GovernanceFrameworkDocument entries. If latest_gf_only is true, return only nested GovernanceFrameworkVersion and GovernanceFrameworkDocument entries for the active version.

§ [MOD-TR-QRY-2] List Trust Registries

This method is used to query the DID Directory keeper. Returned result MUST be ordered by TrustRegistry.modified asc.

§ [MOD-TR-QRY-2-1] List Trust Registries query parameters

The following parameters are optional:

§ [MOD-TR-QRY-2-2] List Trust Registries query checks

If any of these checks fail, query MUST fail.

§ [MOD-TR-QRY-2-3] List Trust Registries execution of the query

If all precondition checks passed, query is executed and result (may be empty) returned. If modified_after is specified, order by modified_after desc.

§ [MOD-TR-QRY-3] List Module Parameters

Anyone CAN run this query.

§ [MOD-TR-QRY-3-2] List Module Parameters parameters
§ [MOD-TR-QRY-3-2] List Module Parameters query checks
§ [MOD-TR-QRY-3-3] List Module Parameters execution of the query

Return the list of the existing parameters and their values.

§ [MOD-TR-QRY-3-4] List Module Parameters API result example
{
  "params": {
    "key1": "value1",
    "key2": "value2",
    ...
    ...
  }
}

§ Credential Schema Module

§ [MOD-CS-MSG-1] Create New Credential Schema

Any account CAN execute this method.

§ [MOD-CS-MSG-1-1] Create New Credential Schema parameters

An account that would like to create a credential schema MUST call this method by specifying:

§ [MOD-CS-MSG-1-2] Create New Credential Schema precondition checks

If any of these precondition checks fail, method MUST abort.

§ [MOD-CS-MSG-1-2-1] Create New Credential Schema basic checks
§ [MOD-CS-MSG-1-2-2] Create New Credential Schema fee checks

Applicant MUST have an available balance in its account, to cover the following fees:

NOTE

Credential Schema trust deposit is not reclaimable.

§ [MOD-CS-MSG-1-3] Create New Credential Schema execution

If all precondition checks passed, method is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

NOTE

If needed, depending on configuration mode, Trust Registry controller MAY need to create a ECOSYSTEM Permission so that validation processes can be run.

§ [MOD-CS-MSG-2] Update Credential Schema

Any account CAN execute this method.

§ [MOD-CS-MSG-2-1] Update Credential Schema parameters

An account that would like to update a credential schema MUST call this method by specifying:

other attributes are immutables and cannot be updated.

§ [MOD-CS-MSG-2-2] Update Credential Schema precondition checks

If any of these precondition checks fail, method MUST abort.

§ [MOD-CS-MSG-2-2-1] Update Credential Schema basic checks
§ [MOD-CS-MSG-2-2-2] Update Credential Schema fee checks

Account MUST have an available balance in its account to cover the required transaction fees.

§ [MOD-CS-MSG-2-3] Update Credential Schema execution

If all precondition checks passed, method is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

§ [MOD-CS-MSG-3] Archive Credential Schema

Any account CAN execute this method.

§ [MOD-CS-MSG-3-1] Archive Credential Schema parameters

An account that would like to archive or unarchive a credential schema MUST call this method by specifying:

§ [MOD-CS-MSG-3-2] Archive Credential Schema precondition checks

If any of these precondition checks fail, method MUST abort.

§ [MOD-CS-MSG-3-2-1] Archive Credential Schema basic checks
§ [MOD-CS-MSG-3-2-2] Archive Credential Schema fee checks

Account MUST have an available balance in its account to cover the required transaction fees.

§ [MOD-CS-MSG-3-3] Archive Credential Schema execution

If all precondition checks passed, method is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

§ [MOD-CS-MSG-4] Update Module Parameters

Update Module Parameters.

Can only be executed through a governance proposal.

§ [MOD-CS-MSG-4-1] Update Module Parameters parameters
§ [MOD-CS-MSG-4-2] Update Module Parameters precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-CS-MSG-4-2-1] Update Module Parameters basic checks
§ [MOD-CS-MSG-4-2-2] Update Module Parameters fee checks

provided transaction fees MUST be sufficient for execution

§ [MOD-CS-MSG-4-3] Update Module Parameters execution

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

for each parameter param <key, value> in parameters:

§ [MOD-CS-QRY-1] List Credential Schemas

Anyone CAN execute this method. Returned result MUST be ordered by CredentialSchema.created asc.

§ [MOD-CS-QRY-1-1] List Credential Schemas parameters
§ [MOD-CS-QRY-1-2] List Credential Schemas checks
§ [MOD-CS-QRY-1-3] List Credential Schemas execution

return a list of found entry, or an empty list if nothing found. Results MUST be ordered by modified ASC.

§ [MOD-CS-QRY-2] Get Credential Schema

Anyone CAN execute this method.

§ [MOD-CS-QRY-2-1] Get Credential Schema parameters
§ [MOD-CS-QRY-2-2] Get Credential Schema checks
§ [MOD-CS-QRY-2-3] Get Credential Schema execution

return found entry (if any).

§ [MOD-CS-QRY-3] Render Json Schema

Anyone CAN execute this method.

§ [MOD-CS-QRY-3-1] Render Json Schema parameters
§ [MOD-CS-QRY-3-2] Render Json Schema checks
§ [MOD-CS-QRY-3-3] Render Json Schema execution

Render found entry (if any). In case value is returned by a REST API, content type MUST be set to “application/schema+json”.

§ [MOD-CS-QRY-4] List Module Parameters

Anyone CAN run this query.

§ [MOD-CS-QRY-4-2] List Module Parameters parameters
§ [MOD-CS-QRY-4-2] List Module Parameters query checks
§ [MOD-CS-QRY-4-3] List Module Parameters execution of the query

Return the list of the existing parameters and their values.

§ [MOD-CS-QRY-4-4] List Module Parameters API result example
{
  "params": {
    "key1": "value1",
    "key2": "value2",
    ...
    ...
  }
}

§ Permission Module

§ Permission Module Overview

This section is non-normative.

Permission are linked to a Credential Schema and representable as a tree.

uml diagram

The ECOSYSTEM type permissions are created by the Credential Schema owner. All other permissions are created by running a Validation Process.

A Validation Process (VP) is a process which involves an applicant (which is the controller of validation entry stored in a validation keeper), a validator permission, and optional fees plus transaction fees.

Validation is used by applicants that want to:

In all cases, the process is very similar. Example execution of a validation process:

  1. Applicant starts a validation process by running the [start new validation] transaction. Validation process may be subject to paying validation fees, as defined by validator.
  2. Validation process usually requires that applicant connects to a validation VS identified by its DID, and execute a some validation steps, required for the validation process to conclude.
  3. If applicant qualifies, validator updates the validation entry by running the [set to validated] transaction, and applicant is granted new permissions, and/or gets issued a credential.

Validation is valid for a specific period, for example 365 days, as configured in the credential schema for credential schema related validations, or set by trust registry for user-agent validation.

NOTE

In some cases, even if the validation is valid for a period of time, the resulting created permission or issued credential might have a shorter expiration timestamp because the validated attribute(s) might expire before validation expiration: in this case, the applicant must provide updated information to the validator before attribute expiration, in order to get issued an updated new permission and/or an updated credential.

If validation is set to expire, applicant that wishes to extend the expiration timestamp must renew its validation.

At any time, applicant can cancel the validation process.

Some special unexpected situation may arise and must be mitigated. Examples:

§ [MOD-PERM-MSG-1] Start Permission VP

Any account CAN execute this method.

§ [MOD-PERM-MSG-1-1] Start Permission VP parameters

An Applicant that would like to start a permission validation process MUST execute this method by specifying:

Available compatible perms can be found by using [MOD-PERM-QRY-1] and presented in a front-end so applicant can choose its validator.

§ [MOD-PERM-MSG-1-2] Start Permission VP precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-PERM-MSG-1-2-1] Start Permission VP basic checks

if a mandatory parameter is not present, transaction MUST abort.

NOTE

A holder MAY directly connect to the DID VS of an issuer in order to get issued a credential. It’s up to the issuer to decide if running the validation process (for charging fees) is REQUIRED or not.

§ [MOD-PERM-MSG-1-2-2] Start Permission VP permission checks

At the end, if a valid permission validator_perm is not found, transaction MUST abort.

§ [MOD-PERM-MSG-1-2-3] Start Permission VP fee checks

Load Permission entry validator_perm of the selected validator.

Applicant MUST have an available balance in its account, to cover the following fees:

§ [MOD-PERM-MSG-1-3] Start Permission VP execution

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

§ Connecting to the VS of the Validator

This section is non-normative, and provided for understanding only.

This action must be initiated by the applicant.

During a validation process, if the associated validator_perm includes a specific did, the applicant should establish a secure connection with the validator’s VS (Verifiable Service) using a secure communication protocol such as DIDComm or DWN.

Upon connecting to the VS, the applicant should be required by the validator to complete one or more of the following tasks:

  1. Prove control over the controller account that initiated the validation process (e.g., via blind signature or cryptographic challenge).
  2. Provide requested information, such as filling out forms, submitting documents, or other forms of disclosure as required by the validation VS.
  3. If the requested permission includes a VS DID, the applicant should prove control over the corresponding DID to the validator’s VS.

Once the validator determines that the process is complete, they may terminate the validation process and create the permission accordingly. This permission configuration usually include:

The validator may compile a summary file of the validation process, documenting exchanged data, proofs, and decisions, and share it with the applicant via the VS connection or another secure channel.

For audit or governance purposes, the validator should register a digest (e.g., hash or SRI) of this summary in applicant_perm.vp_summary_digest_sri.

§ [MOD-PERM-MSG-2] Renew Permission VP

This section is non-normative.

§ [MOD-PERM-MSG-2-1] Renew Permission VP parameters

An account controller of a permission entry that would like to renew a validation process for this permission MUST execute this method by specifying:

§ [MOD-PERM-MSG-2-2] Renew Permission VP precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-PERM-MSG-2-2-1] Renew Permission VP basic checks

if a mandatory parameter is not present, transaction MUST abort.

§ [MOD-PERM-MSG-2-2-2] Renew Permission VP permission checks
§ [MOD-PERM-MSG-2-2-3] Renew Permission VP fee checks

Applicant MUST have an available balance in its account, to cover the following fees:

§ [MOD-PERM-MSG-2-3] Renew Permission VP execution

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

§ [MOD-PERM-MSG-3] Set Permission VP to Validated

Any account CAN execute this method.

§ [MOD-PERM-MSG-3-1] Set Permission VP to Validated parameters

An account that would like to set a validation entry to VALIDATED MUST execute this method by specifying:

§ [MOD-PERM-MSG-3-2] Set Permission VP to Validated precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-PERM-MSG-3-2-1] Set Permission VP to Validated basic checks

if a mandatory parameter is not present, transaction MUST abort.

Calculation of vp_exp, the validation process expiration timestamp, required to verify provided effective_until:

Now, let’s verify effective_until:

§ [MOD-PERM-MSG-3-2-2] Set Permission VP to Validated validator perms

This section is non-normative.

If validator_perm is not a valid permission (expired, revoked, slashed…) then applicant should start a new validation process.

§ [MOD-PERM-MSG-3-2-3] Set Permission VP to Validated fee checks

Validator MUST have the required estimated transaction fees in its account, else transaction MUST abort.

§ [MOD-PERM-MSG-3-3] Set Permission VP to Validated execution

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

Calculate vp_exp:

Change value of provided effective_until if needed, and abort if needed:

Update Permission applicant_perm:

Fees and Trust Deposits:

§ [MOD-PERM-MSG-4] Request Permission VP Termination

This section is non-normative.

At any time, applicant may request termination of the validation process current action.

Requesting termination of the validation process set permission entry to the TERMINATION_REQUESTED state so that corresponding permissions can be terminated. Then, the applicant or the validator (if type is not HOLDER) or the validator (if type is HOLDER) MUST confirm termination transaction for the validation entry to be set to TERMINATED and trust deposits to be freed.

§ [MOD-PERM-MSG-4-1] Request Permission VP Termination parameters

An account that would like to set a Permission entry to TERMINATION_REQUESTED MUST execute this method by specifying:

§ [MOD-PERM-MSG-4-2] Request Permission VP Termination precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-PERM-MSG-4-2-1] Request Permission VP Termination basic checks

if a mandatory parameter is not present, transaction MUST abort.

If validation process already expired, either party can terminate the validation process to reclaim the deposit. Else, only the grantee can terminate the vp.

§ [MOD-PERM-MSG-4-2-2] Request Permission VP Termination fee checks

Applicant MUST have the required estimated transaction fees in its account, else transaction MUST abort.

§ [MOD-PERM-MSG-4-3] Request Permission VP Termination execution

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

Define vars:

Update perm:

Update deposits if state is TERMINATED:

If applicant_perm.vp_state has been set to TERMINATED:

NOTE

if applicant_perm.type is HOLDER, then validator SHOULD revoke the corresponding credential and then call the confirm validation method to free the trust deposits.

§ [MOD-PERM-MSG-5] Confirm Permission VP Termination

This method is called by a validator to confirm the termination of a vp when permission type is HOLDER, usually after revoking (or not) the verifiable credential of the holder. It can be although called by the grantee after a timeout, defined in GlobalVariables.validation_term_requested_timeout_days.

§ [MOD-PERM-MSG-5-1] Confirm Permission VP Termination parameters

An account that would like to set confirm validation entry termination MUST execute this method by specifying:

§ [MOD-PERM-MSG-5-2] Confirm Permission VP Termination precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-PERM-MSG-5-2-1] Confirm Permission VP Termination basic checks

if a mandatory parameter is not present, transaction MUST abort.

§ [MOD-PERM-MSG-5-2-2] Confirm Permission VP Termination permission checks

Timeout not reached: only validator can call the method:

if applicant_perm.term_requested + GlobalVariables.validation_term_requested_timeout_days is after or equal to current timestamp:

Timeout reached: either the validator or the applicant can call the method:

if applicant_perm.term_requested + GlobalVariables.validation_term_requested_timeout_days is before now:

Else MUST abort.

NOTE

For HOLDER type validation, if validation has not expired, only the validator can terminate the validation, unless GlobalVariables.validation_term_requested_timeout_days have passed since termination request and validator did not answered.

§ [MOD-PERM-MSG-5-2-3] Confirm Permission VP Termination fee checks

Account executing the method MUST have the required estimated transaction fees.

§ [MOD-PERM-MSG-5-3] Confirm Permission VP Termination execution

If all precondition checks passed, transaction is executed.

Define vars:

Update:

If account executing the method is the validator:

NOTE

If account executing the method is the grantee (timeout), validator is punished and its trust deposit is not freed.

§ [MOD-PERM-MSG-6] Cancel Permission VP Last Request

At any time, applicant of a permission validation process may request cancellation of the process, provided state is PENDING. Upon method execution, the pending validation is cancelled and paid trust fees are refunded. If vp_exp is not null, vp_state is set back to VALIDATED, else vp_state is set to TERMINATED.

§ [MOD-PERM-MSG-6-1] Cancel Permission VP Last Request parameters

An account that would like to set cancel a validation entry MUST execute this method by specifying:

§ [MOD-PERM-MSG-6-2] Cancel Permission VP Last Request precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-PERM-MSG-6-2-1] Cancel Permission VP Last Request basic checks

if a mandatory parameter is not present, transaction MUST abort.

§ [MOD-PERM-MSG-6-2-2] Cancel Permission VP Last Request fee checks

Account executing the method MUST have the required estimated transaction fees in its account, else transaction MUST abort.

§ [MOD-PERM-MSG-6-3] Cancel Permission VP Last Request execution

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

§ [MOD-PERM-MSG-7] Create Root Permission

This method is used by controllers of Trust Registries. When they create a Credential Schema, they need to create (a) permission(s) of type ECOSYSTEM so that other participants can run validation processes.

§ [MOD-PERM-MSG-7-1] Create Root Permission parameters

An account that would like to create a Permission entry MUST call this method by specifying:

§ [MOD-PERM-MSG-7-2] Create Root Permission precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-PERM-MSG-7-2-1] Create Root Permission basic checks

if a mandatory parameter is not present, transaction MUST abort.

§ [MOD-PERM-MSG-7-2-2] Create Root Permission permission checks

To execute this method, account MUST match at least one these rules, else transaction MUST abort.

NOTE

HOLDER permission are used so that it is possible to identify grantee account for paying rewards.

§ [MOD-PERM-MSG-7-2-3] Create Root Permission fee checks

Account MUST have the required estimated transaction fees available.

§ [MOD-PERM-MSG-7-3] Create Root Permission execution

If all precondition checks passed, method is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

A new entry Permission perm MUST be created:

§ [MOD-PERM-MSG-8] Extend Permission

This method can only be called by a validator.

§ [MOD-PERM-MSG-8-1] Extend Permission parameters

An account that would like to extend the effective_until timestamp of a permission MUST call this method by specifying:

§ [MOD-PERM-MSG-8-2] Extend Permission precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-PERM-MSG-8-2-1] Extend Permission basic checks

if a mandatory parameter is not present, transaction MUST abort.

§ [MOD-PERM-MSG-8-2-2] Extend Permission validator perms
§ [MOD-PERM-MSG-8-2-3] Extend Permission fee checks

Validator MUST have the required estimated transaction fees in its account, else transaction MUST abort.

§ [MOD-PERM-MSG-8-3] Extend Permission execution

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

§ [MOD-PERM-MSG-9] Revoke Permission

This method can only be called by a validator.

§ [MOD-PERM-MSG-9-1] Revoke Permission parameters

An account that would like to extend the effective_until timestamp of a permission MUST call this method by specifying:

§ [MOD-PERM-MSG-9-2] Revoke Permission precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-PERM-MSG-9-2-1] Revoke Permission basic checks

if a mandatory parameter is not present, transaction MUST abort.

§ [MOD-PERM-MSG-9-2-2] Revoke Permission validator perms
§ [MOD-PERM-MSG-9-2-3] Revoke Permission fee checks

Validator MUST have the required estimated transaction fees in its account, else transaction MUST abort.

§ [MOD-PERM-MSG-9-3] Revoke Permission execution

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

§ [MOD-PERM-MSG-10] Create or Update Permission Session

Any credential exchange that requires issuer or verifier to pay fees implies the creation of a PermissionSession.

If the peer wants to issue a credential, the agent, the Verifiable User Agent or Verifiable Service that receive the request MUST send to peer:

If the peer wants to verify a credential, agent must send to peer:

payer MUST create a Permission Session using the above information, then, agent MUST check session has been created and is valid before accepting the action (receive and store issued credential, or accept a presentation request).

uml diagram

See VT spec.

§ [MOD-PERM-MSG-10-1] Create or Update Permission Session parameters

An account that would like to create or update a PermissionSession entry MUST send a Msg by specifying:

§ [MOD-PERM-MSG-10-2] Create or Update Permission Session precondition checks

If any of these precondition checks fail, transaction MUST abort.

if issuer_perm_id is null AND verifier_perm_id is null, MUST abort.

if issuer_perm_id is no null:

if verifier_perm_id is no null:

agent:

wallet_agent:

WARNING

we might want to check that credential schema of agent and wallet_agent perms is an ECS of type UserAgent. At the moment there is no way of doing it. We consider User Agent will not report a permission that is not controlled by its owner.

§ [MOD-PERM-MSG-10-3] Create or Update Permission Session fee checks

Account MUST have sufficient available balance for:

To calculate the required beneficiary fees, use “Find Beneficiaries” query method below to get the set of beneficiary permission found_perm_set. Now that we have the set with all ancestors, we can calculate the required fees:

Total required trust_fees to be paid by account executing the method, including Trust Deposit: (beneficiary_fees + percent fees for agents) * trust deposit percent * trust unit price:

trust_fees = beneficiary_fees * (1 + (GlobalVariables.user_agent_reward_rate + GlobalVariables.wallet_user_agent_reward_rate)) * (1 + GlobalVariables.trust_deposit_rate) * GlobalVariables.trust_unit_price

See Pay per trust fees above.

§ [MOD-PERM-MSG-10-4] Create or Update Permission Session execution

If all precondition checks passed, method is executed.

If new, create entry PermissionSession session:

Else update:

WARNING

session.authz[] can contain null issuer_perm_id OR verifier_perm_id

§ [MOD-PERM-MSG-11] Update Permission Module Parameters

Update Permission Module Parameters.

Can only be executed through a governance proposal.

§ [MOD-PERM-MSG-11-1] Update Permission Module Parameters parameters
§ [MOD-PERM-MSG-11-2] Update Permission Module Parameters precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-PERM-MSG-11-2-1] Update Permission Module Parameters basic checks
§ [MOD-PERM-MSG-11-2-2] Update Permission Module Parameters fee checks

provided transaction fees MUST be sufficient for execution

§ [MOD-PERM-MSG-11-3] Update Permission Module Parameters execution

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

for each parameter param <key, value> in parameters:

§ [MOD-PERM-MSG-12] Slash Permission Trust Deposit

This method can only be called by either:

§ [MOD-PERM-MSG-12-1] Slash Permission Trust Deposit parameters

An account that would like to slash a permission trust deposit MUST call this method by specifying:

§ [MOD-PERM-MSG-12-2] Slash Permission Trust Deposit precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-PERM-MSG-12-2-1] Slash Permission Trust Deposit basic checks

if a mandatory parameter is not present, transaction MUST abort.

§ [MOD-PERM-MSG-12-2-2] Slash Permission Trust Deposit validator perms

Either Option #1, #2 or #3 MUST be true else abort.

Option #1: executed by validator

if applicant_perm.validator_perm_id is defined:

Option #2: executed by ecosystem controller

Option #3: network governance authority

Account executing the method MUST be the network governance authority (voted proposal).

§ [MOD-PERM-MSG-12-2-3] Slash Permission Trust Deposit fee checks

Account executing the method MUST have the required estimated transaction fees in its account, else transaction MUST abort.

§ [MOD-PERM-MSG-12-3] Slash Permission Trust Deposit execution

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

use MOD-TD-MSG-7 to burn the slashed amount from the trust deposit of applicant_perm.grantee.

§ [MOD-PERM-MSG-13] Repay Permission Slashed Trust Deposit

This method can only be called by anyone that want to repay the deposit of a slashed perm. This won’t make the perm re-usable: it will be needed for the grantee to request a new permission, as slashed permissions cannot be revived (same happen for revoked, etc…).

Nevertheless, to get a new permission for a given ecosystem, it is needed, using this method, to repay the deposit of a slashed permission first.

§ [MOD-PERM-MSG-13-1] Repay Permission Slashed Trust Deposit parameters

An account that would like to repay a permission trust deposit MUST call this method by specifying:

§ [MOD-PERM-MSG-13-2] Repay Permission Slashed Trust Deposit precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-PERM-MSG-13-2-1] Repay Permission Slashed Trust Deposit basic checks

if a mandatory parameter is not present, transaction MUST abort.

§ [MOD-PERM-MSG-13-2-2] Repay Permission Slashed Trust Deposit validator perms

Any account can execute this method.

§ [MOD-PERM-MSG-13-2-3] Repay Permission Slashed Trust Deposit fee checks

Account executing the method MUST have the required estimated transaction fees in its account, plus applicant_perm.slashed_deposit, else transaction MUST abort.

§ [MOD-PERM-MSG-13-3] Repay Permission Slashed Trust Deposit execution

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

use Adjust Trust Deposit to transfer amount to trust deposit of applicant_perm.grantee.

§ [MOD-PERM-MSG-14] Create Permission

This simple permission creation method can be used to self-create an ISSUER (resp. VERIFIER) permission if issuance mode (resp. verification mode) is set to OPEN for a given schema. As permissions are the anchor of ecosystem trust deposit operations, it is required if Ecosystem decided to charge the issuance (or the verification) of the credentials.

§ [MOD-PERM-MSG-14-1] Create Permission parameters

An account that would like to create a Permission entry MUST call this method by specifying:

§ [MOD-PERM-MSG-14-2] Create Permission precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-PERM-MSG-14-2-1] Create Permission basic checks

if a mandatory parameter is not present, transaction MUST abort.

§ [MOD-PERM-MSG-14-2-2] Create Permission permission checks

To execute this method, account MUST match at least one these rules, else transaction MUST abort.

§ [MOD-PERM-MSG-14-2-3] Create Permission fee checks

Account MUST have the required estimated transaction fees available.

§ [MOD-PERM-MSG-14-3] Create Permission execution

If all precondition checks passed, method is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

A new entry Permission perm MUST be created:

§ [MOD-PERM-QRY-1] List Permissions

Anyone CAN execute this method.

§ [MOD-PERM-QRY-1-1] List Permissions parameters
§ [MOD-PERM-QRY-1-2] List Permissions checks
§ [MOD-PERM-QRY-1-3] List Permissions execution

return a list of found entries, or an empty list if nothing found. Ordered by last modified asc.

§ [MOD-PERM-QRY-2] Get Permission

Anyone CAN execute this method.

§ [MOD-PERM-QRY-2-1] Get Permission parameters
§ [MOD-PERM-QRY-2-2] Get Permission checks
§ [MOD-PERM-QRY-2-3] Get Permission execution

return found entry (if any).

§ [MOD-PERM-QRY-3] Find Permissions With DID

Usually, Verifiable Trust verification flow will work as in the example below. To simplify, we suppose VUAa is both a User Agent and a Verifiable Credential Wallet.

§ [MOD-PERM-QRY-3-1] Find Permission With DID parameters
§ [MOD-PERM-QRY-3-2] Find Permission With DID checks
§ [MOD-PERM-QRY-3-3] Find Permission With DID execution

This method should use an index per cs.id and insert any new entry hash(perm.did;perm.type) when perm.effective_from and perm.did are not null (updated when perm is modified). Index example:

SchemaId => hash(did;type) => Perm id list => (load perms one by one and filter other query attributes such as country, effective_from, effective_until, revoked, terminated)

Using example index, calculate hash(did;type) to get the list of matching permissions perms[].

return found_perms.

§ [MOD-PERM-QRY-4] Find Beneficiaries

Anyone can execute this method.

To calculate the fees required for paying the beneficiaries, it is needed to recurse all involved perms until the root of the permission tree (which is the trust registry perm), starting from the 2 branches issuer_perm and verifier_perm. As both branches may have common ancestors, we can create a Set (unordered collection with no duplicates), and recurse over the 2 branches, adding found perms. If verifier_perm is null, issuer_perm is never added to the set. If verifier_perm is NOT null, issuer_perm is added to the set if it exists but verifier_perm is not added to the set.

NOTE

If a Credential Schema is configured with permission management mode set to OPEN for either issuance or verification, it is necessary to check whether the associated ECOSYSTEM permission requires issuance or verification fees. This check MUST be performed by calling this method and passing the id of the ECOSYSTEM permission. In this case, the only beneficiary of the fees is the ECOSYSTEM permission itself.

Example 1: verifier_perm: is not set: it’s a credential offer, schema configured to have Issuer Grantors.

uml diagram

Example 2: verifier_perm: is not set: it’s a credential offer. Schema configured to NOT have Issuer Grantors.

uml diagram

Example 3: verifier_perm is set, it’s a presentation request. Schema configured to have Verifier and Issuer Grantors.

uml diagram
§ [MOD-PERM-QRY-4-1] Find Beneficiaries parameters
§ [MOD-PERM-QRY-4-2] Find Beneficiaries checks
§ [MOD-PERM-QRY-4-3] Find Beneficiaries execution

Let’s build the set. Revoked and terminated permissions will not be added to the set. Expired permissions, if not revoked/terminated, will be considered.

if issuer_perm is not null:

Additionally, if verifier_perm is not null:

return found_perms.

NOTE

This works even is schema is open to any issuer or open to any verifier.

§ [MOD-PERM-QRY-5] Get PermissionSession

§ [MOD-PERM-QRY-5-1] Get PermissionSession parameters
§ [MOD-PERM-QRY-5-2] Get PermissionSession checks
§ [MOD-PERM-QRY-5-3] Get PermissionSession execution

return PermissionSession entry if found, else return not found.

§ [MOD-PERM-QRY-6] List Permission Module Parameters
§ [MOD-PERM-QRY-6-2] List Permission Module Parameters parameters
§ [MOD-PERM-QRY-6-2] List Permission Module Parameters query checks
§ [MOD-PERM-QRY-6-3] List Permission Module Parameters execution of the query

Return the list of the existing parameters and their values.

§ [MOD-PERM-QRY-6-4] List Permission Module Parameters API result example
{
  "params": {
    "key1": "value1",
    "key2": "value2",
    ...
    ...
  }
}

§ [MOD-PERM-QRY-7] List Permission Sessions

Anyone CAN execute this method.

§ [MOD-PERM-QRY-7-1] List Permission Sessions parameters
§ [MOD-PERM-QRY-7-2] List Permission Sessions checks
§ [MOD-PERM-QRY-7-3] List Permission Sessions execution

return a list of found entries, or an empty list if nothing found, ordered by last modified asc.

§ Validation Examples

§ Getting a Credential from an Authorized Issuer

This section is non-normative.

Example of an Applicant that would like to get issued a credential (HOLDER):

uml diagram
§ Add a DID to the List of Granted Issuers of a Credential Schema

This section is non-normative.

uml diagram

§ DID Directory Module

The DID Directory is a keystore of DIDs.

§ DID Directory Module Overview

This section is non-normative.

Registering a DID in the DID Directory makes the DID, its associated credentials, and related services (such as VSs) publicly discoverable by crawlers and indexers.

⚠️ Registration is optional and not required for Trust Resolution.
However, it may be useful for certain use cases, for example, a Social Browser may rely on the DID Directory to crawl and index all DIDs that reference Social Channel VSs, enabling users to search and discover them directly through the app.

The DID Directory is open to anyone, meaning:

This implies that a DID could be registered by someone who is not its legitimate controller, an inherent limitation of the model.
That said, the deterrent is economic: why would anyone pay registration fees for a DID they do not control?

To protect the intent of the actual DID controller, registration alone does not trigger indexing.
Indexers must respect optional crawler directives included in the DID Document (e.g., index, noindex), ensuring that control over indexation remains with the DID controller, regardless of who registered the DID in the directory.

NOTE

Note that it is possible to register any DID from any method.

NOTE

It is not needed to register DIDs that are already present in Trust Registries, Permissions,… as services linked to these DIDs are indexed like if they were registered in the DID Directory.

§ [MOD-DD-MSG-1] Add a DID

Add a DID to the DID Directory, with expiration timestamp set to current timestamp + years years.

Any account CAN run this method.

§ [MOD-DD-MSG-1-1] Add a DID transaction parameters
§ [MOD-DD-MSG-1-2] Add a DID precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-DD-MSG-1-2-1] Add a DID basic checks
§ [MOD-DD-MSG-1-2-2] Add a DID fee checks

Applicant MUST have an available balance (not blocked by trust deposit nor staked) in its account, to cover the following fees:

§ [MOD-DD-MSG-1-3] Add a DID execution

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

§ [MOD-DD-MSG-2] Renew a DID

Renew a DID, by adding years years to current expiration timestamp.

This method MUST be run by controller of the DID entry.

§ [MOD-DD-MSG-2-1] Renew a DID transaction parameters
§ [MOD-DD-MSG-2-2] Renew a DID precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-DD-MSG-2-2-1] Renew a DID basic checks

if any of the following conditions is not satisfied, transaction MUST abort.

§ [MOD-DD-MSG-2-2-2] Renew a DID fee checks

Applicant MUST have an available balance (not blocked by trust deposit nor staked) in its account, to cover the following fees:

§ [MOD-DD-MSG-2-3] Renew a DID execution of the transaction

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

§ [MOD-DD-MSG-3] Remove a DID

Remove a DID and unlock the corresponding trust deposit.

§ [MOD-DD-MSG-3-1] Remove a DID transaction parameters
§ [MOD-DD-MSG-3-2] Remove a DID precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-DD-MSG-3-2-1] Remove a DID basic checks

if any of the following conditions is not satisfied, transaction MUST abort.

§ [MOD-DD-MSG-3-2-2] Remove a DID fee checks

Account running the transaction MUST have the required estimated transaction fees in its account, else transaction MUST abort.

§ [MOD-DD-MSG-3-3] Remove a DID execution of the transaction

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

§ [MOD-DD-MSG-4] Touch a DID

This method is used to update the modified of a given entry so that crawlers will know DID should be immediately reindexed.

§ [MOD-DD-MSG-4-1] touch a DID transaction parameters
§ [MOD-DD-MSG-4-2] Touch a DID precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-DD-MSG-4-2-1] Touch a DID basic checks
§ [MOD-DD-MSG-4-2-2] Touch a DID fee checks

Account running the transaction MUST have the required estimated transaction fees in its account, else transaction MUST abort.

§ [MOD-DD-MSG-4-3] Touch a DID execution of the transaction

If all precondition checks passed, transaction is executed.

Transaction execution MUST perform the following tasks, and rollback if any error occurs.

§ [MOD-DD-MSG-5] Update Module Parameters

Update Module Parameters.

Can only be executed through a governance proposal.

§ [MOD-DD-MSG-5-1] Update Module Parameters parameters
§ [MOD-DD-MSG-5-2] Update Module Parameters precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-DD-MSG-5-2-1] Update Module Parameters basic checks
§ [MOD-DD-MSG-5-2-2] Update Module Parameters fee checks

provided transaction fees MUST be sufficient for execution

§ [MOD-DD-MSG-5-3] Update Module Parameters execution

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

for each parameter param <key, value> in parameters:

§ [MOD-DD-QRY-1] List DIDs

This method is used to query the DID Directory keeper. Returned data MUST be ordered by modified asc.

§ [MOD-DD-QRY-1-1] List DIDs query parameters

The following parameters are optional:

§ [MOD-DD-QRY-1-2] List DIDs query checks

If any of these checks fail, query MUST fail.

§ [MOD-DD-QRY-1-3] List DIDs execution of the query

If all precondition checks passed, query is executed and result (may be empty) returned.

§ [MOD-DD-QRY-2] Get a DID

This method is used to read a DID from the DID Directory keeper. As this method does not modify data, it does not require a transaction.

§ [MOD-DD-QRY-2-1] Get a DID query parameters
§ [MOD-DD-QRY-2-2] Get a DID query checks

did MUST conform to the DID Syntax, as specified [DID-CORE].

§ [MOD-DD-QRY-2-3] Get a DID execution of the query

If DID is found, return the corresponding entry, else empty result is returned.

§ [MOD-DD-QRY-3] List Module Parameters

Anyone CAN run this query.

§ [MOD-DD-QRY-3-2] List Module Parameters parameters
§ [MOD-DD-QRY-3-2] List Module Parameters query checks
§ [MOD-DD-QRY-3-3] List Module Parameters execution of the query

Return the list of the existing parameters and their values.

§ [MOD-DD-QRY-3-4] List Module Parameters API result example
{
  "params": {
    "key1": "value1",
    "key2": "value2",
    ...
    ...
  }
}

§ Trust deposit module

§ Trust deposit module overview

This section is non-normative.

Concept: the trust deposit is used to lock trust value as a stake. To process application messages that perform state changes, several modules methods are requiring a trust deposit to be sent, from the executing account, to the trust deposit module.

We will use a similar method than the one described here to manage trust deposit and yield calculation and easy way.

Example:

In our example, we suppose a VPR is just starting and no trust transaction have taken place yet. For this reason:

Operation #1:

an account account1 wants to create a transaction that requires:

First, the Trust Deposit: execution of the method will perform the following (we consider this account had no TrustDeposit entry yet):

Second, fee distribution: let’s suppose 70% of transaction fees are distributed to validators, and 30% of transaction fees are distributed to trust deposit holders. For this specific transaction:

Now, account1 can (optionally) reclaim the difference between the GlobalVariables.trust_deposit_share_value * tt.share minus tt.denom, which represents the trust (yield) gains.

Operation #2:

Another account account2 wants to create a transaction that requires:

First, Trust Deposit:

Second, fee distribution: let’s suppose 70% of transaction fees are distributed to validators, and 30% of transaction fees are distributed to trust deposit holders. For this specific transaction:

After the 2 operations:

§ [MOD-TD-MSG-1] Adjust Trust Deposit

This method is used to increase or decrease the trust deposit of a specific account.

Only the modules that require trust deposit manipulation CAN call this method. If trust deposit has been slashed and not repaid, method execution MUST abort.

§ [MOD-TD-MSG-1-1] Adjust Trust Deposit method parameters
§ [MOD-TD-MSG-1-2] Adjust Trust Deposit precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-TD-MSG-1-2-1] Adjust Trust Deposit basic checks

Value checks:

§ [MOD-TD-MSG-1-2-2] Adjust Trust Deposit fee checks

Account running the transaction MUST have the required estimated transaction fees in its account plus needed_deposit, else transaction MUST abort.

§ [MOD-TD-MSG-1-3] Adjust Trust Deposit execution of the method

If all precondition checks passed, method is executed in a transaction.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

The last case, augend < 0, is to free trust deposit (ej when terminating a permission).

§ [MOD-TD-MSG-2] Reclaim Trust Deposit Yield

This method is used to reclaim yield. If trust deposit has been slashed and not repaid, method execution MUST abort.

Any account MAY call this method.

For a given TrustDeposit entry td, claimable yield is calculated like this:

claimable_yield = td.share * GlobalVariables.trust_deposit_share_value - td.deposit.

If claimable_yield is positive, they can be claimed.

§ [MOD-TD-MSG-2-1] Reclaim Trust Deposit Yield method parameters

N/A

§ [MOD-TD-MSG-2-2] Reclaim Trust Deposit Yield precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-TD-MSG-2-2-1] Reclaim Trust Deposit Yield basic checks
§ [MOD-TD-MSG-2-2-2] Reclaim Trust Deposit Yield fee checks

Account running the transaction MUST have the required estimated transaction fees in its account, else transaction MUST abort.

§ [MOD-TD-MSG-2-3] Reclaim Trust Deposit Yield Value execution of the method

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

For the TrustDeposit entry td linked to account:

NOTE

Maybe here the claimed yield should go to the deposit. TBD.

§ [MOD-TD-MSG-3] Reclaim Trust Deposit

This method is used to reclaim claimable trust deposit value, td.claimable. If trust deposit has been slashed and not repaid, method execution MUST abort.

Any account MAY call this method.

In order to discourage user from using this method:

§ [MOD-TD-MSG-3-1] Reclaim Trust Deposit method parameters
§ [MOD-TD-MSG-3-2] Reclaim Trust Deposit precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-TD-MSG-3-2-1] Reclaim Trust Deposit basic checks

if any of these conditions is not satisfied, transaction MUST abort.

§ [MOD-TD-MSG-3-2-2] Reclaim Trust Deposit fee checks

Account running the transaction MUST have the required estimated transaction fees in its account, else transaction MUST abort.

§ [MOD-TD-MSG-3-3] Reclaim Trust Deposit execution of the method

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

For the TrustDeposit entry td linked to account:

§ [MOD-TD-MSG-4] Update Module Parameters

Update Module Parameters.

Can only be executed through a governance proposal.

§ [MOD-TD-MSG-4-1] Update Module Parameters parameters
§ [MOD-TD-MSG-4-2] Update Module Parameters precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-TD-MSG-4-2-1] Update Module Parameters basic checks
§ [MOD-TD-MSG-4-2-2] Update Module Parameters fee checks

provided transaction fees MUST be sufficient for execution

§ [MOD-TD-MSG-4-3] Update Module Parameters execution

If all precondition checks passed, transaction is executed.

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

for each parameter param <key, value> in parameters:

§ [MOD-TD-MSG-5] Slash Trust Deposit

This method is used by the network governance authority to globally slash an account trust deposit.

This method can only be called by a governance proposal. A globally slashed account MUST repay the slashed deposit in order to continue to use the services provided by the VPR. When and account is slashed, and while slashed deposit has not been repaid, all account linked permissions MUST be considered non trustable.

This method is for network governance authority slash. For ecosystem slash, see Slash Permission Trust Deposit.

§ [MOD-TD-MSG-5-1] Slash Trust Deposit method parameters
§ [MOD-TD-MSG-5-2] Slash Trust Deposit precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-TD-MSG-5-2-1] Slash Trust Deposit basic checks

if any of these conditions is not satisfied, transaction MUST abort.

§ [MOD-TD-MSG-5-2-2] Slash Trust Deposit fee checks

Account running the transaction MUST have the required estimated transaction fees in its account, else transaction MUST abort.

§ [MOD-TD-MSG-5-3] Slash Trust Deposit execution of the method

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

For the TrustDeposit entry td linked to account:

§ [MOD-TD-MSG-6] Repay Slashed Trust Deposit

Repay a slashed trust deposit. Can be executed by any account.

§ [MOD-TD-MSG-6-1] Repay Slashed Trust Deposit method parameters
§ [MOD-TD-MSG-6-2] Repay Slashed Trust Deposit precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-TD-MSG-6-2-1] Repay Slashed Trust Deposit basic checks

if any of these conditions is not satisfied, transaction MUST abort.

§ [MOD-TD-MSG-6-2-2] Repay Slashed Trust Deposit fee checks

Account running the transaction MUST have the required estimated transaction fees in its account plus amount, else transaction MUST abort.

§ [MOD-TD-MSG-6-3] Repay Slashed Trust Deposit execution of the method

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

For the TrustDeposit entry td linked to account:

§ [MOD-TD-MSG-7] Burn Ecosystem Slashed Trust Deposit

Burn the portion of the trust deposit of a given account. This method can only be called by the permission module when performing an ecosystem-related slash.

WARNING

Make sure to properly protect access to the execution of this method else it may lead to very destructive actions.

§ [MOD-TD-MSG-7-1] Burn Ecosystem Slashed Trust Deposit method parameters
WARNING

Alternative approach: For security and consistency, implementers MAY choose to reference the ID of the slashed permission, load it and use its defined slashed_deposit value as the slashing amount. The decision between this method and specifying the amount directly is left to implementers.

§ [MOD-TD-MSG-7-2] Burn Ecosystem Slashed Trust Deposit precondition checks

If any of these precondition checks fail, transaction MUST abort.

§ [MOD-TD-MSG-7-2-1] Burn Ecosystem Slashed Trust Deposit basic checks

if any of these conditions is not satisfied, transaction MUST abort.

§ [MOD-TD-MSG-7-2-2] Burn Ecosystem Slashed Trust Deposit fee checks

Account running the transaction MUST have the required estimated transaction fees in its account else transaction MUST abort.

§ [MOD-TD-MSG-7-3] Burn Ecosystem Slashed Trust Deposit execution of the method

Method execution MUST perform the following tasks in a transaction, and rollback if any error occurs.

For the TrustDeposit entry td linked to account:

§ [MOD-TD-QRY-1] Get Trust Deposit

Any account CAN run this query. As this method does not modify data, it does not require a transaction.

§ [MOD-TD-QRY-1-1] Get Trust Deposit query parameters
§ [MOD-TD-QRY-1-2] Get Trust Deposit query checks

If any of these checks fail, query MUST fail.

§ [MOD-TD-QRY-1-3] Get Trust Deposit execution of the query

If found, returns trust deposit, else return not found.

§ [MOD-TD-QRY-2] List Module Parameters

Anyone CAN run this query.

§ [MOD-TD-QRY-2-2] List Module Parameters parameters
§ [MOD-TD-QRY-2-2] List Module Parameters query checks
§ [MOD-TD-QRY-2-3] List Module Parameters execution of the query

Return the list of the existing parameters and their values.

§ [MOD-TD-QRY-2-4] List Module Parameters API result example
{
  "params": {
    "key1": "value1",
    "key2": "value2",
    ...
    ...
  }
}

§ ToIP Trust Registry QueryProtocol version 2.0

This section is non-normative.

Implementations must provide support for ToIP Trust Registry QueryProtocol version 2.0. This will be developed when TRQP spec stabilizes.

§ Initial Data Requirements

§ [GLO] Global Variables

Global variables CAN only be changed by the governance authority through proposals.

Default values MUST be set at VPR initialization (genesis). Below you’ll find some possible values. These values will have to be defined in the governance framework.

Trust Unit:

Credential Schema:

Validation:

Trust Registry:

DID Directory:

Trust Deposit:

§ References

§ Normative References

DID-CORE
Decentralized Identifiers (DIDs) v1.0. Manu Sporny; Amy Guy; Markus Sabadello; Drummond Reed; 2022-07-19. Status: REC.
RFC3986
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter; 2005-01. Status: Internet Standard.
VC-DATA-MODEL
Verifiable Credentials Data Model v1.1. Manu Sporny; Grant Noble; Dave Longley; Daniel Burnett; Brent Zundel; Kyle Den Hartog; 2022-03-03. Status: REC.

Table of Contents
undefined