Trust Check element

A Trust Check element is a per-leg TRQP query declaration on an Agent Surface. Trust Check elements on an Access Point run on the caller leg (Access Point → Managed Agent); Trust Check elements on a Target run on the target leg (Managed Agent → Target). The Trust Check stage executes all configured elements in parallel and writes the results into input.trust_check_results for OPA evaluation.

For conceptual background, see Trust registries. For the OPA fields these results populate, see OPA policy input reference.

Fields

Validation constraints

• The element identifier field (id) must be non-blank and at most 64 Unicode code points. Control characters and bidi-override characters are rejected.
• Authority ID must be non-blank.
• Name, when present, must be at most 64 Unicode code points and must not contain control or bidi-override characters.
• Each leg (Access Point or Target) may contain at most 10 Trust Check elements.
• Element identifiers (id) must be unique within a leg. Duplicate identifiers on the same leg are rejected on save.

Query parameters

Template syntax

All four query fields accept {{ }} templates resolved against the input.* JSON the gateway builds for the same request. Templates follow the OPA input namespace, so a value from the policy input is available using the same path you would use in a Rego rule.

{{ input.agent.provider_did }}         → resolved DID of the agent's department/provider
{{ input.agent.did }}                  → effective caller DID
{{ input.source_auth.claims.sub }}     → JWT subject claim (jwt_bearer auth only)
{{ input.http.path }}                  → request path

A || fallback operator is supported for fields that may be absent:

{{ input.extension_identity.did || input.agent.did }}

The right-hand side is used only when the left-hand side is missing or null. A non-scalar value (array, object) or a malformed template short-circuits with TEMPLATE_RESOLUTION_FAILED; it does not fall through to the right-hand side.

When a template fails to resolve, the element produces ok = false with error.code = TEMPLATE_RESOLUTION_FAILED and no TRQP network call is made.

Result fields

Each element in input.trust_check_results.caller and input.trust_check_results.target has this shape:

{
  "id": "tc-caller-1",
  "trust_registry_id": "tr-main",
  "query_type": "recognition",
  "ok": true,
  "error": null,
  "name": "Verify caller department",
  "authority_id": "did:web:authority.example.com",
  "entity_id": "did:web:caller.example.com",
  "action": "is",
  "resource": "ownedAgent",
  "query_resolved": true
}

Error codes

Rego patterns

Address a result by id rather than array index:

# Allow only when the named element passed
allow if {
  some r in input.trust_check_results.caller
  r.id == "tc-caller-1"
  r.ok == true
}

Deny on any stage failure:

deny if {
  some r in input.trust_check_results.caller
  r.error != null
}

Branch on a registry-level problem report code:

deny if {
  some r in input.trust_check_results.caller
  r.error.code == "TRUST_REGISTRY_PROBLEM_REPORT"
  r.error.message == "AGENT_NOT_RECOGNIZED"
}

Related

• Access Point reference: Trust Check on the caller leg.
• Target reference: Trust Check on the target leg.
• OPA policy input reference: How Trust Check results appear as input.trust_check_results in Rego.
• Trust registries: Conceptual background on TRQP queries and trust registry connections.