A platform meeting the agent for the first time admits it by resolving the authority.

The agent asserts no types of its own.

The platform reads from the agent through authority_hints in the order the agent lists them, then verifies from the anchor key it holds in configuration back to the agent. It walks both chains and admits through the one it pins for admission.

OpenID Federation (open standard) gives every entity a signed configuration about itself, and gives a superior a signed statement about each entity beneath it. The API platform performs the walk itself, with the resolver every consumer on this estate shares, and the pin is the pair of anchor identifier and key.

Each anchor's statement about its authority carries no policy, so the folded client is the Tarnbrook statement's policy, every parameter of it: the four detail types, the grant types, the backchannel delivery mode, the registration type and private_key_jwt. The value operator sets each of them.

The five reads

Each read is an unauthenticated GET. The chain figure links nine documents; three of them are the first three reads below. The fourth read is linked from the bound figure, and the fifth is linked here.

Who is asking. The agent's own configuration. Look for client_name Records Assistant, two authority_hints with Aldercross first, and five trust marks: four from the Tarnbrook domain and one from the Aldercross scheme.

Who vouches for it. The Tarnbrook authority's statement about the agent. Look for metadata_policy, and the four detail types it sets.

What a second domain says. The Aldercross authority's statement about the same agent. Look for two detail types where the first domain sets four.

What the resource bounds. The transfers resource's own page. Look for Limits, per transaction, GBP 1000.00.

Whether the platform admits. The platform's health answer. Look for admitting true and both anchor pins loaded. Read on 29 September 2026.

Its authority lists it directly, so no superior is involved.

A failed hop drops only its own chain, so the name the platform answers with depends on what survives the walk. The figure shows the checks this agent meets. The resolver can also answer accreditation_issuer_not_accepted, accreditation_unconfirmed when a status endpoint cannot be read and no recent active answer is held, and authority_unreachable when a document cannot be fetched at all.

A consumer holding an accreditation mark asks the issuing authority for its current status and receives a signed answer. The query is a form post of the mark itself. Observed

The platform holds the client it built until the shortest of three windows ends: its resolution cache, the earliest expiry on the chain, and its mark status cache. Then it resolves again.

A refusal names the first ceiling a request falls outside. apps/reference-op/src/grants.ts builds the ceilings and apps/reference-op/src/containment.ts compares them. The registered ceiling is the client the chain produced. The attested ceiling is narrowed by an attestation where a copy presents one, which use case 4 teaches; with none, grants.ts copies the registered types into it. The granted ceiling is the types the agent requests. For a task that moves value, a person approves it: the approval form offers the amount the agent asked for, and the person sets the value the token carries.