§ Trust Registry Query Protocol (TRQP) Specification

• Specification Version: 2.0
• Document Status: Public Review 01

Participate:

GitHub repo

File an issue

Start a discussion

• Editors: Darrell O’Donnell, Andor Kesselman, Drummond Reed, Antti Kettunen,
• Contributors: Alex Tweeddale, Christine Martin, Dave Poltorak, Eric Drury, Fabrice Rochette, Jacques Latour, Jesse Carter, Jeff Braswell, Jon Bauer, Makki Elfatih, Marcus Ubani, Markus Sabadello, Scott Perry, Sankarshan Mukhopadhyay, Subhasis, Tim Bouma

§ Introduction

This section is informative.

The ToIP Trust Registry Query Protocol (TRQP) is a lightweight, read-only protocol for making fast, efficient queries for authoritative data from trust registries, also known as trust lists. To use an analogy, TRQP is to trust registries what DNS is to name servers.

The same way DNS name servers serve name domains, TRQP trust registries serve trust domains, also known as digital trust ecosystems. Four primary actors participate in the flow of verifiable data (including verifiable credentials) within the ecosystem: 1) data producers (issuers), 2) data subjects (holders), 3) data consumers (verifiers or relying parties), and 4) governing bodies (authorities).

Authorities determine the policies governing which actors can perform what actions on what data within the ecosystem. These policies are typically published in a human-readable form called a governance framework, also known as a trust framework. To make these policies accessible to software agents, they are published in a machine-readable form known as authority statements. Authority statements can be published in a file, issued to individual actors as verifiable credentials, or published in a trust registry.

Digitally-verifiable authority statements can be expressed using various standards, including X.509 certificate hierarchies, OpenID Federations, EBSI Trust Chains, or TRAIN trust lists. Although these standards can work well for intra-ecosystem authority verification, they are not optimized for inter-ecosystem authority verification.

The purpose of TRQP is to bridge this gap by provide a standard protocol for querying authority statements from any TRQP-compliant trust registry. It specifies a standard data model, query vocabulary, and transport protocol binding that can be implemented by any ecosystem regardless of its internal trust architecture.

TRQP focuses on three query types:

1. Authorization Queries: “Has Entity X been granted Authorization Y under Ecosystem Governance Framework Z?”
2. Recognition Queries: “Is Ecosystem A recognized as an authority for Governance Framework B by Ecosystem C?”
3. Delegation Queries: “Has Ecosystem A been delegated authority for Governance Framework D by Ecosystem C?”
4. Description (Metadata) Queries: “What DID methods does Ecosystem A support?”

§ Conventions and Definitions

§ Keywords

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in IETF RFC 2119.

§ Augmented Backus-Naur Form (ABNF)

The syntax definitions in this specifications use Augmented Backus-Naur Form (ABNF) as defined in IETF RFC 5234.

§ Definitions

authority statement

An assertion by an authority about another entity. Types of authority statements include authorization, recognition, delegation, and description (metadata).

authorization statement

An authority statement in which an authority grants an authorization to an entity over which it has authority.

delegation statement

An authority statement in which an authority delegates a specific scope of authority to another entity.

description statement

An authority statement in which an authority asserts metadata describing an entity.

digital trust ecosystem

A digital ecosystem in which participants are one or more interoperating trust communities. Governance of various roles within this ecosystem is typically managed by a governing body using a governance framework. Many digital trust ecosystems maintain one or more trust registries.

ecosystem

See digital trust ecosystem.

ecosystem governing authority

The entity responsible for governance of a digital trust ecosystem and for publishing its authority statements. An ecosystem governing authority may take any legal form or may not be a formal legal entity at all.

ecosystem ID

The globally unique identifier of a digital trust ecosystem.

ecosystem governance framework

A governance framework for a digital trust ecosystem. This may incorporate other types of frameworks such as credential governance frameworks.

entity ID

The unique identifier of an entity within a digital trust ecosystem.

inter-ecosystem

An adjective describing relationships and data exchanges between participants in two or more separate ecosystems operating under separate governance frameworks.

intra-ecosystem

An adjective describing relationships and data exchanges between participants operating within the same ecosystem and the same governance framework.

recognition statement

An authority statement in which one authority recognizes the authority of another authority as a peer. Note that this recognition relationship may be unilateral or bilateral and is non-exclusive.

TRQP binding

A technical specification defining how to implement the TRQP Core protocol over a specific transport protocol.

TRQP bridge

A system that connects a TRQP endpoint to a system of record. The bridge transforms a TRQP query into the query format supported by the system of record and performs the reverse mapping for the response.

TRQP Core

The foundational specification that defines core data models, query vocabulary, and other requirements for the Trust Registry Query Protocol.

TRQP consumer

A network device (client or server) that send TRQP queries to a TRQP endpoint.

TRQP endpoint

The network service endpoint for trust registry that speaks TRQP.

trust registry

A repository that serves as a source for authority statements or other governed information describing one or more trust communities. A trust registry is typically authorized by an ecosystem governance framework.

trust registry operator

The legal entity responsible for operating a trust registry. A trust registry may be operated directly by an [ref:ecosystem governing authority]], or operation may be delegated to an independent trust registry operator.

system of record

An authoritative source for the authority statements available from a [ref:trust registry]].

§ Scope

This section is informative.

Figure 1 illustrates the four primary components involved with TRQP architecture.

Figure 1: The primary components involved in TRQP architecture.

The scope of this specification is limited to the TRQP protocol operating between TRQP consumers and TRQP endpoints representing addressable TRQP trust registries. The following are out-of-scope:

• Systems of record. This specification casts no requirements on how the system of record is designed or deployed. Also, because TRQP is read-only, this specification does not address create, update, or delete operations for the system of record.
• TRQP bridges. If the system of record is not a native TRQP trust registry, a TRQP bridge is needed to transform a TRQP query into the query format supported by the system of record. Seperate specifications may be published for popular TRQP bridges, however they are out-of-scope for this specification.

§ High-Level Architecture

This section is informative.

In TRQP architecture, there are two primary roles involved with a TRQP-compliant trust registry:

1. The ecosystem governing authority role (section 4.1).
2. The trust registry operator role (section 4.2).

Both roles may be played by the same entity or by separate entities. Figure 2 is a diagram of the case where the ecosystem governing authority is also the trust registry operator.

Figure 2: Case #1, where an ecosystem governing authority operates its own trust registry

Figure 3 is a diagram of the case where the roles are played by different entities, i.e., the ecosystem governing authority delegates operation of the trust registry to an independent trust registry operator.

Figure 3: Case #2, where a trust registry is operated by an independent trust registry operator

§ Ecosystem Governing Authority

The ecosystem governing authority is the entity responsible for governance of the ecosystem and for publishing its authority statements. It may take any legal form or may not be a formal legal entity at all. The only requirement is that the ecosystem governing authority be recognized by the stakeholders in the ecosystem for the purposes of its governance.

From a TRQP architecture standpoint, the ecosystem governing authority is responsible for:

• Publishing the ecosystem governance framework.
• Controlling the ecosystem ID.
• Publishing the ecosystem’s authority statements to one or more trust registries.

If the ecosystem governing authority chooses to operate its own trust registr(ies), it is also responsible for the functions in section 4.2. If not, the ecosystem governing authority is responsible for delegating these responsibilities to a trust registry operator and communicating that delegation pathway to any potential TRQP consumers. This should include publishing a delegation statement to the trust registry (section 6.4).

§ Trust Registry Operator

As described above, the role of a trust registry operator can be performed directly by an ecosystem governing authority or may be delegated to an independent trust registry operator who specializes in this function. In the latter case, from a ToIP governance architecture perspective, the trust registry operator is serving as an administering authority.

In all cases, the trust registry operator is responsible for:

• Controlling the trust registry ID.
• Hosting the trust registry’s TRQP endpoints.
• Managing the infrastructure to read and write to the registry.
• Security, privacy, scalability, operating integrity, and availability of the trust registry.

If a trust registry operator is serving in an administering authority role, it is also responsible for:

• Its own cryptographic key management.
• Publishing its own authority statements (as shown in figure 3), including:
  • Delegation statements asserting its delegated-by relationship to each ecosystem governing authority the trust registry serves (section 6.3).
  • Description statements asserting authoritative metadata about the trust registry (section 6.4).

§ Ecosystem Governance Framework

Just as an ecosystem governing authority may take any form, so may the policies governing the ecosystem. For the purposes of this specification, the collection of these policies (whether human-readable and/or machine-readable) is called the ecosystem governance framework.

To facilitate trust decisions by its stakeholders—or by any other relying party—the ecosystem governing authority is responsible for publishing the ecosystem governance framework. Although they are not normative requirements of this specification, the following recommendations apply:

1. The ecosystem governance framework should be published using a verifiable identifier so its authenticity can be verified.
2. The ecosystem governance framework ID should be discoverable via the ecosystem ID (section 5.1).
3. The ecosystem governance framework should follow the recommendations of the ToIP Governance Architecture Specification and ToIP Governance Metamodel Specification.

§ Identifiers

This section is normative.

Interoperability of TRQP across decentralized digital trust ecosystems depends on globally unique identifiers in the same way interoperability of the Internet depends on IP addresses and DNS names.

The following requirements apply to all identifiers defining in this section:

1. The identifier MUST be represented as a single string conforming to IETF RFC 3986 [normative reference].
2. It is RECOMMENDED to use a verifiable identifier such as a W3C Decentralized Identifier (DID), a KERI autonomic identifier (AID), or an HTTPS URL so their authenticity can be verified by any relying party.

For additional assurance, it is RECOMMENDED to use multi-anchoring of identifiers as defined by the IETF High Assurance DIDs using DNS specification [normative reference] or the work of the ToIP High Assurance Verifiable Identifiers Task Force [informative reference].

§ Ecosystem IDs

1. A TRQP-compliant digital trust ecosystem as a logical governance entity MUST have a globally unique identifier (the “ecosystem ID”).
2. The domain name records, cryptographic keys, or other controls for the ecosystem ID MUST be controlled by the ecosystem governing authority.
3. The ecosystem ID MUST:
   • Be used as an authority ID in TRQP authority statements for which the ecosystem governing authority is the authority.
   • Enable discoverability of the Ecosystem Governance Framework.
   • Enable discoverability of the authorized trust registries serving that ecosystem.

§ Trust Registry IDs

1. A trust registry MUST have a globally unique identifier (the “trust registry ID”).
2. The domain name records, cryptographic keys, or other controls for the trust registry ID MUST be controlled by one of the following:
   1. The ecosystem governing authority, or
   2. An independent trust registry operator delegated by the ecosystem governing authority.
3. The trust registry ID MUST be used as an authority ID in TRQP authority statements for which the trust registry operator is the authority.
4. The trust regsitry ID MUST enable discoverability of the TRQP endpoints.

§ Authority IDs

1. An authority ID MUST be the identifier of the controlling party for an authority statement.
2. An authority ID MAY be either an ecosystem ID or a trust registry ID.
3. All TRQP-compliant authority statements MUST be asserted by an authority ID.

§ Entity IDs

1. An entity ID MUST be the identifier of the entity that is the target of the authority statement.
2. For a recognition statement (section 6.3) or a delegation statement (section 6.4), the entity ID MUST be an authority ID.
3. For an authorization statement about a governed party (section 6.2), the entity ID MUST be unique in the scope of the ecosystem. It is NOT REQUIRED for the entity ID to be globally unique.

§ Authority Statements

This section is normative.

Authority statements are the machine-readable data stored in trust registries to communicate authoritative information about authorizations, delegations, recognitions, and descriptions (metadata).

§ Standard Structure

To enable interoperability of authority statements across ecosystems, TRQP authority statements are structured in three standard parts as shown in Figure 3:

Figure 4: The standard three-part structure of TRQP authority statements

These three strings are simple yet flexible enough to express all types of authority statements. This standard structure should also enable TRQP bridges to perform deterministic transformations regardless of the structure of the data in an underlying system of record.

§ Query Vocabulary

§ TRQP Bindings

This section is normative

TRQP Bindings are technical specifications that define how to implement the TRQP Core protocol over a specific transport protocol. Currently, only the RESTful binding is available.

To be a compatible binding, the following requirements must be met:

• All compliant TRQP Bindings MUST support the required interfaces described in the Required Interfaces (Section 9) section.
• A compliant TRQP Binding MUST adhere to the TRQP Core requirements.
• A compliant TRQP Binding MUST support versioning using Semantic Versioning 2.0.

§ Error Handling

§ Error Response Considerations

this section is normative

§ Query Error Handling Guidelines

this section is informative

This document outlines general guidelines for handling errors in responses to queries within the Trust Registry Query Protocol. The approach described here is abstracted from any specific transport or protocol (such as HTTP) to offer guidance applicable across various implementations.

§ Error Codes

This section is normative

Status Codes

TRQP uses a structured range of status codes to indicate the outcome of a query. These codes are grouped to provide clarity and support future extensibility without breaking compatibility:

• 0–99: Success Codes — The operation completed successfully.
• 100–199: General Errors — Unspecified or system-level errors.
• 200–299: Resource Errors — Issues related to resource availability or access.
• 300–399: Authentication Errors — Issues related to authenticating the querier.
• 400–499: Validation Errors — Problems validating query inputs.

§ Queries

This section defines the query types available under the TRQP Binding. Each query type is processed against a TRQP‐compliant trust registry endpoint and MUST adhere to the TRQP Core and TRQP Binding requirements. The following query types are defined:

1. Description (Metadata) Query
2. Authorization Query
3. Ecosystem Recognition Query
4. Delegation Query

§ Metadata (Description) Query

The metadata query supports descriptive information about an ecosystem or a registry. If no ecosystem is provided, it’s default behavior is to provide information about the registry itself. It is expected for the TRQP Profile to define the payloads in more detail.

§ Request Parameters Table

Example Request:

{ "ecosystem_id": "ecosystem A" }

§ Response

Response model is left to the TRQP Profile and TRQP:Binding to define. The RESTful binding allows an arbitrary JSON response.

§ Metadata Query Errors

§ Authorization Query

In an authorization statement, an authority grants an authorization to an entity under its authority. In the ToIP governance model, this entity is called a governed party. This query serves the authorization statements of the ecosystem.

§ Request Parameters Table

Example Request:

{
  "ecosystem_id": "ecosystem A",
  "authorization_id": "credential-A-issuer",
  "entity_id": "random-id-1234",
  "time": "2025-04-01T00:00:00Z"
}

§ Response

The Status Table below describes possible statuses.

The response MUST have one of the following statuses:

Additional details, such as validity information or supporting proof references, MAY be included in the response as per the binding and profile requirements.

§ Authorization Query Errors

§ Ecosystem Recognition Query

In a recognition statement, one ecosystem governing authority recognizes another ecosystem governing authority as a peer. The following query shares the recognition status.

§ Request Parameters Table

Example Request:

{
  "authority_id": "ecosystem A",
  "entity_id": "ecosystem B",
  "scope": "financial-services",
  "time": "2025-04-01T00:00:00Z"
}

§ Response

MUST serve be one of the following statuses in the response:

Optional Fields: Additional supporting details such as proof references or log entries MAY be included.

The system MUST return a clear yes/no answer regarding ecosystem recognition and MAY provide further explanatory details as specified in the TRQP Binding.

§ Ecosystem Recognition Query Errors

§ Delegation Query

§ Request Parameters Table

Example Request:

{
  "delegator_id": "authority-123",
  "delegatee_id": "entity-456",
  "scope": "limited-access",
  "time": "2025-04-01T00:00:00Z"
}

§ Response

• Delegation Status: MUST be one of the following:

Additional details or supporting information regarding the delegation MAY be included per the binding.

§ Delegation Query Errors

§ Trust Registry Query Protocol RESTful Binding

this section is normative

RESTful TRQP Bindings specification that implements the core specification.

The following OpenAPI Document describes the RESTful endpoints that are required for the TRQP RESTful binding.

• The /metadata endpoint is aligned to the MetadataQuery.
• The /registries/{ecosystem_id}/recognition maps to the RecognitionQuery.
• The /entities/{entity_id}/authorization maps to the AuthorizationQuery.

§ HTTP Error Code Mapping

This section is normative

The following mapping of error codes to HTTP Status is provided for http-based implementations:

Additional Information:

• Error Codes and further detail are represented using Problem Details described in rfc7807.
• Authorization and Recognition Queries both take timestamps as a required parameter to resolve.
• Time parameters are in the form RFC3339 and MUST be sent in UTC time.
• If jws field in response is provided, verifiers are recommended to use that to verify the response payload controller.

Security considerations are left to the implementation profile to describe. Identifier requirements are left to the implementation profile to describe. Resolution paths are left to the implementation profile to describe.

§ Swagger

openapi: 3.0.1
info:
  title: TRQP Restful Binding
  version: 1.0.0
  description: |
    This specification defines a RESTful TRQP Binding.
    It includes endpoints for retrieving Trust Registry metadata,
    authorization data, verifying entity authorization status,
    and checking ecosystem recognition.
servers:
  - url: https://example-trust-registry.com
    description: Production server (example)

tags:
  - name: trqp
    description: TRQP Compliant Queries

paths:
  /metadata:
    get:
      summary: Retrieve Trust Registry Metadata
      tags:
        - trqp
      description: |
        Returns Trust Registry Metadata as a JSON object.
      operationId: getTrustRegistryMetadata
      parameters:
        - name: egf_id
          in: query
          required: false
          description: An optional identifier specifying which ecosystem's metadata should be retrieved.
          schema:
            type: string
      responses:
        "200":
          description: Successfully retrieved Trust Registry Metadata.
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/TrustRegistryMetadata"
        "404":
          description: Metadata not found.
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/ProblemDetails"
        "401":
          description: Unauthorized request.
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/ProblemDetails"

  /registries/{entity_id}/recognition:
    get:
      summary: Check Ecosystem Recognition
      tags:
        - trqp
      description: Verifies if the ecosystem governing authority identified by `entity_id` is recognized by the ecosystem governing authority identified by `authority_id`
      operationId: checkEcosystemRecognition
      parameters:
        - name: entity_id
          in: path
          required: true
          description: Unique identifier of the ecosystem governing authority being recognized.
          schema:
            type: string
        - name: authority_id
          in: query
          required: true
          description: Unique identifier of the ecosystem governing authority asserting recognition. Defaults to the ecosystem governing authority of the trust registry (but only if the trust registry serves only a single ecosystem governing authority).
          schema:
            type: string
        - name: time
          in: query
          required: false
          description: RFC3339 timestamp indicating when recognition is checked. Defaults to "now" on system being queried.
          schema:
            type: string
            format: date-time
      responses:
        "200":
          description: Ecosystem recognition successfully verified.
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/RecognitionResponse"
        "401":
          description: Unauthorized request.
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/ProblemDetails"
        "404":
          description: Ecosystem not recognized or not found.
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/ProblemDetails"

  /entities/{entity_id}/authorization:
    get:
      summary: Check Entity Authorization Status
      tags:
        - trqp
      description: |
        Determines if the specified entity (`entity_id`) is authorized under the given authorization identifier (`authorization_id`)
        within the specified governance framework (`egf_id`). Optionally, returns a list of authorizations if `all` is true.
      operationId: checkAuthorizationStatus
      parameters:
        - name: entity_id
          in: path
          required: true
          description: Unique identifier of the entity.
          schema:
            type: string
        - name: authorization_id
          in: query
          required: true
          description: Authorization identifier to evaluate.
          schema:
            type: string
        - name: authority_id
          in: query
          required: true
          description: Unique identifier of the ecosystem governing authority granting authorization.
          schema:
            type: string
        - name: time
          in: query
          required: false
          description: |
            ISO8601/RFC3339 timestamp for authorization status evaluation.
            Defaults to the current time if omitted.
          schema:
            type: string
            format: date-time
      responses:
        "200":
          description: Authorization status successfully retrieved.
          content:
            application/json:
              schema:
                oneOf:
                  - $ref: "#/components/schemas/AuthorizationResponse"
                  - type: array
                    items:
                      $ref: "#/components/schemas/AuthorizationResponse"
        "404":
          description: Entity not found.
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/ProblemDetails"
        "401":
          description: Unauthorized request.
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/ProblemDetails"

components:
  schemas:
    ProblemDetails:
      type: object
      description: |
        A Problem Details object as defined in [RFC 7807](https://datatracker.ietf.org/doc/html/rfc7807).
      properties:
        type:
          type: string
          format: uri
          description: A URI reference that identifies the problem type.
        title:
          type: string
          description: A short, human-readable summary of the problem.
        status:
          type: integer
          description: The HTTP status code (e.g., 404 for "Not Found").
        detail:
          type: string
          description: A human-readable explanation specific to this occurrence of the problem.
        instance:
          type: string
          format: uri
          description: A URI reference that identifies the specific occurrence of the problem.
      additionalProperties: true

    TrustRegistryMetadata:
      type: object
      properties:
        id:
          type: string
          description: Unique identifier of the Trust Registry.
        default_egf_id:
          type: string
          description: Default EGF, identified by DID, that will be used if none is supplied in various queries.
          #TODO: review thinking on defaultEGF_DID
        description:
          type: string
          maxLength: 4096
          description: A description of the Trust Registry.
        name:
          type: string
          description: Human-readable name of the Trust Registry.
        controllers:
          type: array
          description: List of unique identifiers representing the controllers of the Trust Registry.
          items:
            type: string
          minItems: 1
      required:
        - id
        - description
        - name
        - controllers

    AuthorizationResponse:
      type: object
      properties:
        egf_id:
          type: string
          description: EGF DID this authorization response relates to.
        recognized:
          type: boolean
          description: Indicates whether the entity is recognized by the Trust Registry.
        authorized:
          type: boolean
          description: Specifies whether the entity is authorized under the provided authorization ID.
        message:
          type: string
          description: Additional context or information regarding the authorization status.
        evaluated_at:
          type: string
          format: date-time
          description: Timestamp when the authorization status was evaluated.
        response_time:
          type: string
          format: date-time
          description: Timestamp when the response was generated.
        expiry_time:
          type: string
          format: date-time
          description: Timestamp when the authorization status expires (if applicable).
        jws:
          type: string
          description: Signed response object as specified in [RFC 7515](https://datatracker.ietf.org/doc/html/rfc7515) from the controller of the Trust Registry.
      required:
        - recognized
        - authorized
        - message
        - evaluated_at
        - response_time

    RecognitionResponse:
      type: object
      properties:
        recognized:
          type: boolean
          description: Indicates whether the ecosystem ID is recognized by the Trust Registry.
        message:
          type: string
          description: Additional information regarding the recognition status.
        egf_id:
          type: string
          description: EGF DID this recognition applies to.
        evaluated_at:
          type: string
          format: date-time
          description: Timestamp when the recognition status was evaluated.
        response_time:
          type: string
          format: date-time
          description: Timestamp when the response was generated.
        expiry_time:
          type: string
          format: date-time
          description: Timestamp when the recognition status expires (if applicable).
        jws:
          type: string
          description: Signed response object as specified in [RFC 7515](https://datatracker.ietf.org/doc/html/rfc7515) from the controller of the Trust Registry.
      required:
        - recognized
        - message
        - evaluated_at
        - response_time

§ Security Considerations

All implementers (“bindings TRQP Binding” and “bridges TRQP Bridge”) of TRQP SHOULD take the following threats into account and implement appropriate controls:

• Trust Anchor Hijacking: Use strong cryptography and rotate keys regularly.
• Trust Registry Bugs: Conduct code reviews, vulnerability scans, and robust QA.
• Trust Anchor Spoofing: Verify responses using known cryptographic anchors or certificate chains.
• Domain Hijacking: Protect DNS entries; if DNS-based discovery is used, consider DNSSEC or other verification.
• Replay Attacks: Use timestamps, nonces, and short-lived tokens.
• Data Integrity: Sign or hash data at rest, use TLS or equivalent in transit.
• Denial of Service (DoS): Rate-limit queries, monitor usage, scale infrastructure appropriately.
• Insufficient Data Validation: Enforce strict schema checks and reject malformed data with clear error messages.
• Trust Anchor Compromise: Implement multi-tier trust anchors, and have a plan to revoke or replace compromised keys quickly.
• Logging and Auditing: Log all access, changes, and suspicious activities; adopt real-time monitoring.
• Protocol Downgrade Attacks: Default to the latest secure version, disallow fallback to insecure versions.
• Privacy Concerns: Encrypt sensitive or personally identifiable information, and comply with relevant data protection laws.
• Timing Attacks: Where feasible, adopt constant-time operations for cryptographic and authorization checks.

§ Privacy Considerations

Implementers must design the system so that the handling of authorizations and identity information minimizes the risk of exposing sensitive details. In addition to data minimization and regulatory compliance, pay special attention to the following:

• Careful Handling of Authorizations & Identities:
  • Ensure that authorization tokens and identity data (such as DIDs) do not leak more information than necessary.
  • Avoid exposing internal structures or hierarchies that could be exploited by correlating queries or monitoring network traffic.
• Correlation Risk Mitigation:
  • Recognize that even though only ecosystem DIDs are transmitted in recognition queries, combining this data with network-level information (such as IP addresses) can lead to correlation attacks.
  • Consider implementing techniques such as query obfuscation, randomized response timings, or other privacy-preserving measures to reduce the risk of linking requests back to a particular requester.

§ Implementation Considerations

Implementing the TRQP for the Ayra Trust Network requires a dual focus: establishing secure bridging mechanisms between heterogeneous trust frameworks and ensuring that trust registries accurately represent the ecosystem model. Key aspects include:

• Bridging Across Ecosystems:
  • Adapter Development: As the TRQP is designed to bridge various intra-trust frameworks (such as Open ID Federation, X509 Chains, or TRAIN), implementers should develop adapters tailored to their ecosystem. These adapters translate local trust assertions into the common TRQP language.
  • Interoperability Focus: The bridge should speak the “lowest common denominator” across frameworks. This means abstracting complex internal authorization models into a standardized format that can be reliably queried by external verifiers.
  • Flexible Query Handling: Ensure your bridging solution can handle both Recognition and Authorization Queries seamlessly. For example, when verifying whether an entity is authorized under a particular Ecosystem Governance Framework (EGF), the adapter must translate internal rules into a compliant TRQP response.
• Trust Registries & Ecosystem Representation:
  • Trust Registry as the Ecosystem State Holder: A Trust Registry is not the ecosystem itself but a capability within the ecosystem that serves as the authoritative source for its authorization state. It must be capable of answering queriesthat reflect the current state of authority in the ecosystem.
  • Ecosystem Model Mapping:
    • Trust registries should maintain a clear mapping of internal ecosystem authorizations to the standardized TRQP model. This means maintaining up-to-date relationships between entities, their roles, and the associated authorizations.
    • Represent the ecosystem model in a way that abstracts the underlying complexity—ensuring that verifiers only need to interact with a uniform interface regardless of the diversity of the underlying trust frameworks.
  • Bridging Governance & Registries:
    • The registry should integrate with the broader ecosystem governance framework, adhering to the TRQP’s requirements for identifier creation (using compliant DID methods) and service endpoint specifications.
    • Document how the registry bubbles up the state of authorizations, including how updates and revocations are handled to maintain an accurate and timely reflection of the ecosystem’s trust landscape.