### TRQP Metadata Query Example Request Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/models.md An example JSON payload for initiating a Metadata (Description) Query, demonstrating the optional 'ecosystem_id' parameter to specify a target ecosystem. ```JSON { "ecosystem_id": "ecosystem A" } ``` -------------------------------- ### Install Node.js Project Dependencies Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/EditingTheSpec.md Installs all necessary Node.js package dependencies defined in the project's `package.json` file from the root of the repository. ```bash npm install ``` -------------------------------- ### Install Spec-Up Local Dependency Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/EditingTheSpec.md Installs the `spec-up` tool as a local dependency within the project, which is required for rendering the specification. ```bash npm install spec-up ``` -------------------------------- ### Render Specification with Live Updates Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/EditingTheSpec.md Starts a local server to render the specification document with live updates, automatically refreshing `docs/index.html` as source files are edited. This command should be run from the root of the repository. ```bash npm run edit ``` -------------------------------- ### Example Delegation Query Request Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/models.md Provides a sample JSON payload for a delegation query. This example illustrates the structure and typical values for `delegator_id`, `delegatee_id`, `scope`, and `time` in a delegation request. ```json { "delegator_id": "authority-123", "delegatee_id": "entity-456", "scope": "limited-access", "time": "2025-04-01T00:00:00Z" } ``` -------------------------------- ### Example Trust Registry Authorization Query Request JSON Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/models.md An example JSON payload demonstrating a typical authorization query request. This snippet illustrates the structure and expected values for the required parameters and the optional 'time' parameter. ```json { "ecosystem_id": "ecosystem A", "authorization_id": "credential-A-issuer", "entity_id": "random-id-1234", "time": "2025-04-01T00:00:00Z" } ``` -------------------------------- ### Example Ecosystem Recognition Query Request Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/models.md Illustrates a sample JSON payload for an ecosystem recognition query. This example demonstrates the structure and typical values for `authority_id`, `entity_id`, `scope`, and `time` when making a request. ```json { "authority_id": "ecosystem A", "entity_id": "ecosystem B", "scope": "financial-services", "time": "2025-04-01T00:00:00Z" } ``` -------------------------------- ### TRQP Metadata Query Request Parameters Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/models.md Details the parameters available for the Metadata (Description) Query, specifying the type, requirement status, a brief description, and an example value for each parameter. ```APIDOC Parameter: ecosystem_id Type: string Required: Optional Description: Identifier for scoping the metadata request to a specific ecosystem. Example: "ecosystem A" ``` -------------------------------- ### Trust Registry Authorization Query Request Parameters Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/models.md Defines the parameters required for an authorization query to the Trust Registry, including their types, requirements, descriptions, and examples. These parameters are used to specify the ecosystem, authorization type, entity, and an optional timestamp for evaluation. ```APIDOC AuthorizationQueryRequest: ecosystem_id: string (Required) - An ecosystem identifier as defined in the TRQP Binding. Example: "ecosystem A" authorization_id: string (Required) - MUST match one of the defined authorization types in the TRQP Binding. Example: "credential-A-issuer" entity_id: string (Required) - Identifies the entity for which the authorization is being queried. Example: "random-id-1234" time: string (Optional) - A timestamp in RFC3339 UTC format indicating when to evaluate the query. The system MUST clearly indicate whether the subject holds the specified authorization at the evaluated time. If no `time` is provided, `time` SHOULD be evaluated as the time the request was received by the registry. Example: "2025-04-01T00:00:00Z" ``` -------------------------------- ### Run Spec-Up in Live Edit Mode Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/README.md This command initiates Spec-Up in a live editing environment. It automatically re-renders the specification whenever changes are saved, providing an immediate preview for local development and review. ```Shell npm run edit ``` -------------------------------- ### TRQP API Usage Guidelines Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/bindings/restful/spec.md Outlines important considerations and requirements for interacting with the Trust Registry Query Protocol (TRQP) RESTful API. This includes details on timestamp formats, error representation, and response verification mechanisms. ```APIDOC TRQP API Usage Guidelines: - Error Codes and further detail are represented using Problem Details (rfc7807). - Authorization and Recognition Queries require timestamps as parameters. - Time parameters must be in RFC3339 format and sent in UTC time. - If 'jws' field is provided in response, verifiers should use it to verify the response payload controller. ``` -------------------------------- ### Generate Specification File Once Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/EditingTheSpec.md Generates the specification file (`docs/index.html`) a single time without live updates. Useful for a quick render check before committing changes. ```bash npm run render ``` -------------------------------- ### Ecosystem Recognition Query Request Parameters Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/models.md Defines the parameters required for an ecosystem recognition query. These parameters include identifiers for the requesting authority and the entity being evaluated, an optional scope to narrow the query, and an optional timestamp for historical evaluation. ```APIDOC Parameter | Type | Required? | Description | Example --------------|--------|-----------|---------------------------------------------------------------------------------------------------------|------------------------ authority_id | string | Yes | The identifier for the requesting ecosystem as defined in the TRQP Binding. | "ecosystem A" entity_id | string | Optional | Another ecosystem identifier against which recognition is being evaluated. | "ecosystem B" scope | string | Optional | A filter or context to narrow the recognition query; specific structure defined by individual profiles. | "financial-services" time | string | Optional | A timestamp in RFC3339 UTC format indicating when to evaluate the recognition query. | "2025-04-01T00:00:00Z" ``` -------------------------------- ### Ecosystem Recognition Query Response Statuses Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/models.md Describes the possible recognition statuses returned by the system for an ecosystem recognition query. These statuses indicate whether a recognition relationship is confirmed ('recognized') or denied ('not-recognized'). ```APIDOC Code | Recognition Status | Description ------|--------------------|-------------------------------------------- RS-1 | recognized | The recognition relationship is confirmed. RS-2 | not-recognized | The recognition relationship is denied. ``` -------------------------------- ### Delegation Query Request Parameters Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/models.md Defines the parameters for a delegation query. This includes identifiers for the delegating authority and the entity receiving the delegation, an optional scope for the delegation, and an optional timestamp for evaluation. ```APIDOC Parameter | Type | Required? | Description | Example --------------|--------|-----------|---------------------------------------------------------------|------------------------ delegator_id | string | Yes | The identifier for the authority delegating its authority. | "authority-123" delegatee_id | string | Yes | The identifier for the entity or authority receiving the delegated authority. | "entity-456" scope | string | Optional | The scope within which the delegation applies. | "limited-access" time | string | Optional | A timestamp in RFC3339 UTC format indicating when to evaluate the delegation. | "2025-04-01T00:00:00Z" ``` -------------------------------- ### TRQP RESTful Endpoints Overview Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/bindings/restful/spec.md Describes the primary RESTful endpoints required for the Trust Registry Query Protocol (TRQP) binding, mapping each to its corresponding core TRQP query type. This section outlines the functional purpose of each endpoint. ```APIDOC TRQP RESTful Endpoints: - /metadata: Aligned to MetadataQuery. - /registries/{ecosystem_id}/recognition: Maps to RecognitionQuery. - /entities/{entity_id}/authorization: Maps to AuthorizationQuery. ``` -------------------------------- ### TRQP Metadata Query Specific Error Codes Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/models.md Lists specific error codes and their descriptions relevant to the Metadata (Description) Query, indicating conditions such as a non-existent ecosystem identifier or incorrectly formatted request parameters. ```APIDOC Error Code: TRQP-201 When: The provided ecosystem identifier does not exist. Description: Indicates that the ecosystem identifier specified was not found. Error Code: TRQP-400 When: parameters are missing or incorrectly formatted. Description: Indicates that the request lacks required parameters or contains invalid data. ``` -------------------------------- ### Ecosystem Recognition Query Error Codes Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/models.md Lists common error codes and their descriptions for ecosystem recognition queries. These errors detail issues such as unrecognized authority or entity IDs, unknown scopes, or malformed request parameters. ```APIDOC Status Code | Error Name | When | Description -------------|-------------------------------|-------------------------------------------------------------|-------------------------------------------------------------------------- TRQP-201 | Authority ID Not Found | The requesting authority identifier is not recognized. | Indicates that the authority id is not registered. TRQP-200 | Entity ID Not Found | The entity id is unknown or unrecognized. | Indicates that the entity id does not exist. TRQP-200 | Scope Not Found | The specified scope does not match any known context. | Indicates that the target ecosystem or scope is not found. TRQP-400 | Malformed Recognition Request | Request parameters are incomplete or incorrectly formatted. | Indicates that essential elements of the recognition query are missing or invalid. ``` -------------------------------- ### TRQP Generic Metadata Assertion String Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/vocabularies.md Specifies the 'metadata' string used in TRQP description queries to retrieve generic metadata. When used as an assertion, this string instructs the trust registry to return all available metadata for the specified entity ID, as asserted by the authority ID. ```txt desc-string = "metadata" ``` -------------------------------- ### OpenAPI 3.0 Specification for TRQP Restful Binding Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/bindings/restful/spec.md Defines the RESTful API for the Trust Registry Query Protocol (TRQP), including endpoints for retrieving metadata, checking entity authorization, and verifying ecosystem recognition. This specification outlines the available paths, parameters, and expected responses for interacting with a TRQP-compliant Trust Registry. ```yaml 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: ``` -------------------------------- ### Delegation Query Response Statuses Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/models.md Outlines the possible delegation statuses returned by the system for a delegation query. These statuses indicate whether a delegation relationship is confirmed ('delegated'), denied ('not-delegated'), or has been revoked ('revoked'). ```APIDOC Code | Delegation Status | Description ------|-------------------|------------------------------------------- DS-1 | delegated | The delegation relationship is confirmed. DS-2 | not-delegated | The is no delegation relationship DS-3 | revoked | The delegation relationship was revoked ``` -------------------------------- ### Trust Registry Authorization Query Response Statuses Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/models.md Describes the possible authorization statuses returned by the Trust Registry in response to a query. Each status code indicates the outcome of the authorization check, such as authorized, not authorized, revoked, or issues with the subject. ```APIDOC AuthorizationQueryResponseStatus: AS-1: authorized - The entity holds the requested authorization. AS-2: not-authorized - The entity does not hold the requested authorization. AS-3: revoked - The authorization was previously granted but has been revoked. AS-4: unknown-subject - The entity is not recognized or does not exist. AS-5: error - An error occurred while evaluating the authorization query. ``` -------------------------------- ### Trust Registry Authorization Query Error Codes Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/models.md Lists specific error codes and their descriptions that can be returned by the Trust Registry for authorization queries. These errors indicate issues like unrecognized identifiers, invalid authorization types, or malformed parameters. ```APIDOC AuthorizationQueryError: TRQP-201: The specified ecosystem identifier is not recognized. - Indicates that the ecosystem identifier does not exist. TRQP-200: The provided authorization type does not match known types. - Indicates that the authorization type specified is invalid. TRQP-200: The provided authorization type is not available. - Indicates that the authorization type specified is not found. TRQP-200: The provided entity identifier does not exist in records. - Indicates that the entity ID is unknown. TRQP-400: The time parameter is invalid or incorrectly formatted. - Indicates that the requested time does not conform to the expected RFC3339 format. ``` -------------------------------- ### Define ProblemDetails API Schema (RFC 7807) Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/bindings/restful/spec.md Defines the Problem Details object as specified in RFC 7807, providing a standardized format for conveying error information via HTTP APIs. It includes fields for type, title, status, detail, and instance. ```APIDOC 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 ``` -------------------------------- ### TRQP Global Error Status Codes Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/models.md Defines the structured range of status codes used by TRQP to indicate query outcomes, grouped by type (Success, General, Resource, Authentication, Validation) with specific codes and messages for common errors. ```APIDOC Status Codes: 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. Specific Codes: TRQP-0: message: success details: query completed successfully TRQP-100: message: error details: error TRQP-200: message: notfound details: not found TRQP-201: message: ecosystem_notfound details: ecosystem not found TRQP-300: message: unauthorized details: authorization error TRQP-400: message: invalidrequest details: invalid request ``` -------------------------------- ### Delegation Query API Error Codes Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/models.md Documents common error codes and their descriptions for the Delegation Query API, including scenarios where delegator or delegatee identifiers are not recognized, or request parameters are malformed. These errors indicate issues with the input provided to the delegation query. ```APIDOC | Status Code | When | Description | |-------------|----------------------------------------------------------|------------------------------------------------------------------------------------------------| | TBD | The specified delegator identifier is not recognized. | Indicates that the delegator ID does not exist. | | TBD | The specified delegatee identifier is not recognized. | Indicates that the delegatee ID does not exist. | | TBD | Request parameters are missing or incorrectly formatted. | Indicates that essential elements of the delegation query are missing or contain invalid data. | ``` -------------------------------- ### TRQP HTTP Error Code Mapping Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/bindings/restful/spec.md Provides a normative mapping of Trust Registry Query Protocol (TRQP) specific return codes to standard HTTP status codes and their corresponding reasons. This mapping is essential for consistent error handling in HTTP-based TRQP implementations. Error details are further described using RFC7807 Problem Details. ```APIDOC | Return Code | Return Message | HTTP Status | HTTP Reason | |-------------|----------------|-------------|-----------------------| | TRQP-0 | success | 200 | OK | | TRQP-100 | error | 500 | Internal Server Error | | TRQP-200 | notfound | 404 | Not Found | | TRQP-300 | unauthorized | 401 | Not Authorized | | TRQP-400 | invalidrequest | 400 | Invalid request | ``` -------------------------------- ### TRQP Description Statement ABNF Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/vocabularies.md Defines the Augmented Backus-Naur Form (ABNF) for description assertions in the Trust Registry Query Protocol (TRQP). This specification mandates that a description assertion must be a URI reference, as defined in RFC 3986, identifying the metadata associated with an entity. ```txt desc-assertion = description description = URI-reference ; as defined in RFC 3986 ``` -------------------------------- ### TRQP Enumerated Delegation Assertion Strings Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/vocabularies.md Specifies the standard enumerated strings, 'delegates' and 'delegated-by', used within TRQP delegation assertions. These strings are crucial for expressing control relationships between ecosystem governing authorities, with 'delegates' indicating a delegation of authority and 'delegated-by' representing the inverse relationship. ```txt deleg-string = "delegates" / "delegated-by" ``` -------------------------------- ### Define Authorization Assertions for General Verifiable Data Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/vocabularies.md This section specifies the enumerated strings for authorization assertions related to other forms of verifiable data (non-credential) and their usage. It defines 'publish' for data publishing and 'consume' for data consumption, along with recommendations for defining the 'scope' based on the data type URI. ```txt auth-string = "publish" / "consume" ``` ```APIDOC - The `publish` string SHOULD be used for an entity authorized to act in the role of publishing and digitally signing verifiable data that is not in a digital credential format. - The `consume` string SHOULD be used for an entity authorized to act in the role of requesting, verifying, and using digitally signing verifiable data that is not in a digital credential format. - The `scope` of a verifiable data authorization assertion SHOULD define the type of verifiable data an entity is authorized to issue or verify. It is RECOMMENDED to: 1. Use the same URI string that uniquely defines the verifiable data type as defined in the appropriate specification or type definition. 2. Publish that URI string in the ecosystem governance framework and any associated type catalogues. ``` -------------------------------- ### Define RecognitionResponse API Schema Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/bindings/restful/spec.md Defines the schema for a recognition response, indicating whether an ecosystem ID is recognized by the Trust Registry, including a message, the relevant EGF DID, and timestamps for evaluation and response generation. ```APIDOC 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 ``` -------------------------------- ### Define Authorization Assertions for Digital Credentials Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/vocabularies.md This section specifies the enumerated strings for authorization assertions related to verifiable digital credentials and their usage. It defines 'issue' for credential issuance and 'verify' for credential verification, along with recommendations for defining the 'scope' based on the credential type URI. ```txt auth-string = "issue" / "verify" ``` ```APIDOC - The `issue` string SHOULD be used for an entity authorized to act in the role of issuing a digital credential as defined in the specification for the relevant digital credential format. - The `verify` string SHOULD be used for an entity authorized to act in the role of verifying a digital credential as defined in the specification for the relevant digital credential format. - The `scope` of an digital credential authorization assertion SHOULD define the type of digital credential the entity is authorized to issue or verify. It is RECOMMENDED to: 1. Use the same URI string that uniquely defines the credential type as defined in the appropriate credential specification or type definition. 2. Publish that URI string in the ecosystem governance framework and any associated type catalogues. ``` -------------------------------- ### ABNF for Trust Registry Protocol Authorization Assertions Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/vocabularies.md This ABNF defines the structure of authorization assertions used in the Trust Registry Protocol. An assertion consists of an 'authorization' segment and a 'scope' URI reference, both conforming to RFC 3986. ```txt auth-assertion = authorization “/” scope authorization = segment ; as defined in RFC 3986 scope = URI-reference ; as defined in RFC 3986 ``` -------------------------------- ### API Endpoint Responses and Error Definitions Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/bindings/restful/spec.md Defines common API responses, including successful outcomes that return AuthorizationResponse objects or arrays, and standard HTTP error responses (404 Not Found, 401 Unauthorized) that reference the ProblemDetails schema for detailed error information. ```APIDOC - $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" ``` -------------------------------- ### Define AuthorizationResponse API Schema Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/bindings/restful/spec.md Defines the schema for an authorization response, detailing whether an entity is recognized and authorized, along with an associated EGF DID, message, evaluation timestamps, and an optional JWS signed object. ```APIDOC 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 ``` -------------------------------- ### Define TrustRegistryMetadata API Schema Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/bindings/restful/spec.md Defines the schema for Trust Registry metadata, encompassing essential properties such as its unique identifier, default EGF ID, a descriptive text, human-readable name, and a list of controlling entities. ```APIDOC 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 ``` -------------------------------- ### TRQP Delegation Statement ABNF Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/vocabularies.md Defines the Augmented Backus-Naur Form (ABNF) for delegation assertions in the Trust Registry Query Protocol (TRQP). This specification details the required structure for a delegation statement, comprising a delegation component and a scope component, both conforming to RFC 3986 definitions. ```txt deleg-assertion = delegation "/" scope delegation = segment ; as defined in RFC 3986 scope = URI-reference ; as defined in RFC 3986 ``` -------------------------------- ### ABNF for Trust Registry Protocol Recognition Statements Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/vocabularies.md This ABNF defines the assertion string for recognition statements in the Trust Registry Protocol. A recognition statement asserts that one governing authority 'recognizes' another as a peer, and notably, does not include a scope. ```txt recog-string = "recognizes" ``` -------------------------------- ### Define Trust Registry Protocol Authority and Entity ID Characteristics Source: https://github.com/trustoverip/tswg-trust-registry-protocol/blob/main/specification/v1/core/vocabularies.md This section specifies the required characteristics for Authority IDs and Entity IDs within the Trust Over IP Trust Registry Protocol. Authority IDs must be globally unique and verifiable, while Entity IDs must be unique within an ecosystem and can be globally unique for correlation or locally unique for privacy. Both must conform to RFC 3986. ```APIDOC Authority ID: - MUST be a globally unique identifier for the authority making the statement. - MUST be represented as a single string conforming to IETF RFC 3986. - Should be a cryptographically verifiable identifier (e.g., DID or AID) or an HTTPS URL, so that verifiers can resolve and verify public keys, TRQP service endpoints, and other metadata describing the authority. - It is recommended to use multi-anchoring of the verifiable identifier for additional assurance (for example, using High Assurance DIDs using DNS or equivalent). Entity ID: - MUST be unique within the ecosystem. - If correlation across ecosystems is desirable (for example, to establish the reputation of a credential issuer), then it is recommended to be globally unique. - If correlation across ecosystems is not desirable (for example, for individual privacy), then it is recommended to be a locally unique identifier. - MUST be represented as a single string conforming to IETF RFC 3986. - Should be a cryptographically verifiable identifier (e.g., DID or AID) or an HTTPS URL, so that verifiers can resolve public keys, service endpoints, and other metadata describing the entity. ``` === COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.