TRQP Notes And Updates

2024-11-21 TRTF Meeting Notes.md

Priority #1 : Refining the Abstract Data Model of the TRQP

Based on feedback from various calls and discussions, the TRQP requires an abstract data model to progress the spec and provide consistent representations throughout the specification.

This was highlighted as a core area of improvement with the specification. Last week, the conversation left off with the following high level bullets:

• The abstract data model needs to express a simple and clear way to traverse trust networks ( inter-trust ecosystem resolution )
• It was discussed that context was important, with various mentions of tuples.
• Authorization data model was an area of request of focus.

Key Assumptions

• Trust Anchors are chosen out of band
• While all trust ecosystems have intra-trust frameworks for expression, it is possible to align most ecosystems on a inter-trust expression framework.

Proposal on Moving Forward

To improve the data model, we need to understand clearly two things:

1. What are the questions that need to be asked across trust registries?
2. What are the responses that need to be returned across registries?

The question Does Entity X have Authorization Y, in the context of Ecosystem Governance Framework Z? is only part of the requirements for a TR.

1. We also have support for a few other questions:
   1. https://trustoverip.github.io/tswg-trust-registry-protocol/#configuration-queries-cq-
      1. What is your authorizations?
      2. What is the EGF’s you operate under?
      3. What are your assurance levels?
   2. https://trustoverip.github.io/tswg-trust-registry-protocol/#metadata-queries-mq-
      1. What is your participating EGF's?
      2. What other registries do you recognize under what capacity?

Patterns To Learn From

To improve our understanding, I think we need two cases. The Simple, layer case, and the more complicated multi-layer case.

Simple Structure ( Case A )

Simple structure is a single trust registry with a shallow network. In this case, the Trust Registry provides an authorization to issuer to a basic credential, which the verifier looks up the authorization over the Trust Registry API endpoints via TRQP.

graph TD
  TrustRegistry -->|authorizes basic credential issuance| Issuer 
  Issuer -->|issues credential A| Holder 
  Holder <-->|requests credential A| Verifier 
  Verifier -.->|trusts| TrustRegistry 
  Verifier -.->|query issuer status| TrustRegistry 

Loading

In the single hop case, the verifier simply queries the trust registry and gets a response back.

sequenceDiagram 
  actor verifier
  participant TrustRegistry
  
  verifier -->> TrustRegistry : request
  TrustRegistry -->> verifier : response

Loading

Multi-Layer Structure ( Case B )

The Multi-Layer Structure involves a federation with leafs and a single anchor. The trust resolution process involves a verifier to hop N times to reach the anchor and finalize the trust decision. During this process, they will want to query the intermediate actors to determine if they can trust them. At each intermediate trust registry, the verifier will check recognized registries and finally the verifier will check the leaf structure to verifier the entry.

graph TD
  Anchor -->|gives authorization to namespace| Leaf1
  Anchor -->|gives sub-authorization to leaf| Leaf2
  Leaf2 -->|authorizes basic credential issuance| Issuer 
  Issuer -->|issues credential A| Holder 
  Holder <-->|requests credential A| Verifier 
  Verifier -.->|trusts as an anchor for A credential| Anchor 
  Verifier -.->|query issuer status| Leaf2 
  Leaf2 -.->|next hop on trust query| Anchor  

Loading

In the multi-hop case, the initial query then leads to n registries, to the final registry in the chain.

sequenceDiagram 
  autonumber
  actor verifier
  participant Leaf2
  participant Anchor
  
  verifier -->> Leaf2 : request entity auth and context for why Leaf2 is trustworthy
  Leaf2 -->> verifier : response entity auth and egf this is operating under.
  verifier -->> Anchor : request registry recognized
  Anchor -->> verifier : response registry recognized

Loading

2024-11-28 TRTF Meeting Notes.md

Building the common data model

Assumptions about Data Flow

In the case where the Trust Network is centralized, the central system just needs to respond via TRQP the state of the authorization.

When it is a multi-hop system, a verifier at each hop the following data MUST be present the following information to make the next hop:

1. The next hops location, which is prescribed as a DID based service endpoint
2. The authorization in question. This is required so the verifier knows which permissions/rights are they asking the Trust Registry to respond to.
3. The ecosystem of the hop that is relevant to the query. This MAY be different than the ecosystem listed on the next hop. For example, as a Ecosystem, I recognize and trust this TR managed by this entity.

They also must resolve the entity_id according to the above at the leaf of the newtork.

The Relationship between TRQP and other Trust Frameworks

Unlike other trust frameworks, such as OpenID Federation (OIDF) and EBSI Trust Chains, the TRQP is not a substitute, but a complement.

While most trust frameworks are focused on establishing inter-network trust chains, TRQP is focused exclusively on resolving a Trust Network Query outside of the network. It is meant for specifically actors that DO NOT talk the same trust chain but desire some level of interoperability across networks.

The way this is achieved is by abstracting the core mechanics to a unified and simple abstraction model, that answers the question : “Does Entity X have Authorization Y, in the context of Ecosystem Governance Framework Z?”. The TRQP provides a standard way to interact on READ with the Trust Network regardless of how the Trust Chain is formed on WRITE.

In cases where the Trust Network is distributed and decentralized, then each Trust Registry in the chain MUST support the TRQP. If one does not, the chain will fail.

In the case where the Trust Network is centralized, the central system just needs to respond via TRQP the state of the authorization.

When it is a multi-hop system, a verifier at each hop the following data MUST be present the following information to make the next hop:

1. The next hops location, which is prescribed as a DID based service endpoint
2. The authorization in question. This is required so the verifier knows which permissions/rights is he asking the Trust Registry to respond to.
3. The ecosystem of the hop that is relevant to the query.

They also must resolve the entity_id according to the above at the leaf of the newtork.

Single Hop Case

In the single hop case, the verifier simply queries the trust registry and gets a response back.

sequenceDiagram 
  actor verifier
  participant hop1
  
  verifier -->> TrustRegistry : initial query, get auth response of entity_id, auth, egf
  hop1 -->> verifier : authorization response

Loading

• Pre-Conditions
  1. An out of band trust decision is made against the Trust Registry that the verifier makes that suggests the trust registry is an authoritative source for the ecosystem. The verifier establishes trust. This MAY be established through the metadata resolution.
  2. The issuer is registered with the TrustRegistry.
  3. The Holder presents the credential to the Verifier over some credential exchange.
     1. In this exchange, the Trust Registry, Identifier of the Entity, Authorization, and Ecosystem Governance Framework are all expressed by the verifier for checking.
• Trust Resolution Process
  • The Verifier queries the Trust Registry. The trust Registry will respond with a respond of the current status of the entry.

Multi-Hop Case

In the multi-hop case, the initial query then leads to n registries, to the final registry in the chain.

sequenceDiagram 
  actor verifier
  participant TrustRegistry1
  participant TrustRegistry2
  
  verifier -->> TrustRegistry1 : initial query to TR auth, entity_id, egf
  TrustRegistry1 -->> verifier : TrustRegistry2 location, entity, authorization, egf
  verifier -->> TrustRegistry2 : entity, authorization, egf
  TrustRegistry2 -->> verifier : authorization response

Loading

In this case, the TrustRegistry must forward to the next registry that their involvement with the an ecosystem that can answer the authorization question.

TrustRegistry1 is the only registry that knows the verifier’s issuer DID. TrustRegistry2 only has the TrustRegistry1 registry as a recognized registry.

Together, by forming a chain of trust networks, we get to the point we form a Ecosystem of Ecosystems pattern.

AuthorizationDataModel.md

Authorization Data Model

The Authorization Data Model in the context of the Trust Registry Query Protocol (TRQP) defines the framework for expressing, querying, and interpreting claims about entities and their authorizations within a Ecosystem Governane Framework. This model is scoped specifically to claims about recognized roles or actions under an Ecosystem Governance Framework (EGF) and does not extend to general-purpose resource authorization mechanisms.

Abstract Representation

A request to a Trust Registry is abstractly represented as a triple:

• Subject: The entity for which authorization information is being queried or asserted (e.g., a DID or other globally unique identifier).
• Predicate: The relationship being queried or asserted about the entity (e.g., "is authorized to perform").
• Object: The activity, role, or status associated with the entity under the scope of the authorization (e.g., "issue verifiable credentials").

This abstraction aligns with common semantic representations and ensures that authorization queries and responses are consistently interpretable across trust registries.

Contextual Information

Request and response information about an authorization MAY depend on a context C. The exact definition and mechanism for expressing C will be specified in later sections. This allows for flexibility in handling authorizations where additional environmental or situational factors are relevant.

Assumptions and Scope of This Document

We assume the following assumptions in this specification:

• Discovery has already been made out of bound over the authorization string reuquired for query.
• Trust establishment with the TR has been made already out of bound.
• In the context of below, we are soley focused on expressing the authorization grant in the question : Is entity X authorized to do Y under EGF Z? We assume questions such as "should I trust this ecosystem" and "what are your authorizations" are out of bound for this article.

Authorization States

The Authorization Data Model considers the following cases:

Entity Registered in the Trust Registry

The entity states considered are the following :

• Authorized: The entity is authorized to perform activity X under EGF Z.
• Not Authorized: The entity is not authorized to perform activity X under EGF Z.
• Revoked: The entity had permission, but then was revoked to perform activity X under EGF Z.
• Undisclosed Authorization Status: The entity is registered, but the Trust Registry does not disclose the authorization status for activity X, often due to requestor permissions.
• Registered Without Specific Authorization Details: The entity is registered, but no specific authorization details are associated with activity X.

Entity Not Registered in the Trust Registry

• No Knowledge: The registry explicitly states it has no information about the entity.
• Undisclosed Recognition Status: The registry does not disclose whether it recognizes the entity, neither confirming nor denying any authorization, effectively revoking the query.

Authorization States

The following represents corresponding state codes for each state:

• Object Activity State : Represent the current state of the claim. They should be always shared alongside the actual objects.

  • active : this claim is valid and working
  • inactive : this claim is not valid.

• Authorization States

  • authorized : used when an authorization is authorized.
  • revoked : used when you explicitly want to mention that an authorization was terminated.
  • unauthorized : used in cases where an authorization is not given.

• Recognition States

  • recognized : the registry recognizes the entity but makes no positions on it's authorizations.
  • undeclared : the registry will not confirm or deny the recognition of the entity.
  • not recognized : the registry confirms they explictly do not recognize the registry either because they did not see the entity.
  • rejected : the registry has rejected the recognition status of the entity.
  • revoked : the registry used to recognize the entity, but no longer does

Authorization Data Model Requirements

• Globally Unique Identifiers: All authorization identifiers MUST be globally unique to prevent namespace collisions.
• Global Resolution (Optional): Authorization identifiers MAY be globally resolvable to additional metadata or resources.
• EGF Bound: All authorizations MUST be bound to an Ecosystem Governance Framework (EGF).

Authorization Type Data Model

An Authorization Type encapsulates the metadata and constraints of a specific authorization. The data model is defined as follows:

Field	Type	Description
id	String	A globally unique identifier for the authorization type.
ecosystem_controller	String (DID)	Identifier of the ecosystem governance controller responsible for the authorization.
grantors	Array	Identifiers of entities that can issue authorizations of this type.
name	String	A human-readable name for the authorization type.
description	String	A detailed description of the authorization type.
maximum_level_of_assurance	Integer	The maximum level of assurance (LOA) permitted under this authorization type.
status	Enum	Status of the authorization type (e.g., "active", "deprecated", "revoked").
creation_date	DateTime	The timestamp when this authorization type was created.
last_updated	DateTime	The timestamp of the most recent update to this authorization type.
egf_reference	String (URL)	A reference or link to the Ecosystem Governance Framework associated with this authorization type.
superceded	String(DID)	The id of the superceding authorization
superseded	String(DID)	The id of the superseding authorization

Sample JSON Representation

{
  "id": "auth-type-12345",
  "ecosystem_controller": "did:example:ecosystem1",
  "grantors": [
    "did:example:grantor1",
    "did:example:grantor2"
  ],
  "name": "Credential Issuer Authorization",
  "description": "Authorization for entities to issue credentials within the Example Ecosystem.",
  "maximum_level_of_assurance": 3,
  "status": "active",
  "creation_date": "2024-12-01T12:00:00Z",
  "last_updated": "2024-12-04T08:00:00Z",
  "egf_reference": "https://example.com/egf"
}

Notes on usage

The maximum_level_of_assurance field establishes the binding between this Authorization Type and the allowable level of assurance (LOA) for activities. LOA definitions, constraints, and mappings will be described in a dedicated section of the specification. This model ensures compatibility across trust registries by standardizing how authorizations are expressed and queried, providing interoperability in SSI ecosystems

sample_tr.md

Sample Trust Registry JSON File

Sample Trust Registry

The intent of this document is to describe the most mimimal version of a Trust Registry.

{
  "metadata": {
    "identifier": "did:web:sample:trustregistry",
    "name": "Trust Registry",
    "version": "0.0.1",
    "primaryEGFURI": "did:web:sample.com:primary",
    "description": "A registry of organizations that have agreed to accept the as a source of trust for digital identity verification and attestation.",
    "language": "en"
  },
  "organizations": [
    {
      "name": "Org 1",
      "type": "organization",
      "did": "did:web:sample.com",
      "status": {
        "status": "active",
        "detail": "Active Organizations"
      }
    }
  ],
  "ecosystems": [
    {
      "metadata": {
        "name": "Sample Trust Registry",
        "type": "ecosystem",
        "namespaces": [
          "foundation.sample.certified.EmployeeID.verify",
          "foundation.sample.certified.EmployeeID.issue"
        ],
        "description": "Sample Registry",
        "did": "did:web:sample.foundation",
        "contronller": "did:web:sample.com", 
        "egfURI": "did:web:sample.com:governance",
        "primary_trust_registry": "did:web:sample.com:trustregistry",
        "registries": [
          {
            "name": "Sample Trust Registry",
            "identifier": "did:web:sample.com",
            "description": "Sample",
            "primaryEGFURI": "did:web:sample.com:primary",
            "peerType": "peer"
          }
        ],
        "status": {
          "status": "active",
          "detail": "Active ecosystem"
        }
      },
      "entries": [
        {
          "did": "did:web:sample.com",
          "validFrom": "2024-09-10T12:00:00Z",
          "validTo": "2025-09-10T12:00:00Z",
          "authorizations": ["did:web:sample.com:authorization:loa1"],
          "status": {
            "status": "active"
          }
        }
      ],
      "assurance_levels": {
        "loa1": {
          "name": "Level of Assurance 1",
          "description": "Level of Assurance 1 (LOA1) is the lowest level of assurance."
        },
        "loa2": {
          "name": "Level of Assurance 2",
          "description": "Level of Assurance 2 (LOA2) is a medium level of assurance"
        }
      },
      "authorization_types": {
        "did:web:sample.com:authorization:loa1": {
          "name": "Authorization Type 1",
          "description": "Authorization Type 1 is a type of authorization that is used to grant access to a resource or service."
        },
        "did:web:sample.com:authorization:loa2": {
          "name": "Authorization Type 2",
          "description": "Authorization Type 2 is a type of authorization that is used to grant access to a resource or service."
        }
      },
      "vid_methods": [
        {
          "identifier": "vid1",
          "maxiumum_level_of_assurance": "loa1"
        }
      ]
    }
    }
  ]
}

is the thing you received the thing you authorized?

Mention burden to do followups on discovery after the initial questions.
Make sure the limits of the TRQP are clear.

Document why namespaces.

put it in the spec about clarifying assumptions around traversal.