Raidiam
Book a working session

Evidence

How it works

What your platform reads at each step, where a request stops, and how long each answer lasts.

Back to how it works

What each step reads

  1. Presents

    The agent's entity configuration, published at its own identifier.

    The entity configuration this agent publishes Observed

    The signed bytes

    The Records Assistant, signed PS256, typ entity-statement+jwt. Payload fields, cut at the ellipses.

    "iss": "https://rp.directory.showcase.raidiam.io/…/70219aeb-…",
"sub": "https://rp.directory.showcase.raidiam.io/…/70219aeb-…",
"authority_hints": [
  "https://authority.directory.showcase.raidiam.io/…/845f7286-…",
  "https://authority.directory.showcase.raidiam.io/…/2ec610f4-…"
],
"trust_marks": [ { "trust_mark_type": "…/tarnbrook.records.reader" … },
  … four more, one of them from the second authority ],
"metadata": { "openid_relying_party": { … } },
"jwks": { "keys": [ { "kid": "mrk-097d8498…" … } ] },
"iat": 1789522439,
"exp": 1789526039
    • authority_hints The authorities to fetch next. The walk follows both.
    • trust_marks The marks the platform asks each issuer about.
    • metadata What the folded policy lands on.

    Read at 01:33 UTC on 16 September 2026. This copy expired an hour later. The link fetches the current one. Open the live entity configuration

  2. Resolves

    One subordinate statement per hop, each verified with the keys above it, ending on the anchor key your platform holds.

    When the walk has no next hop Observed

    The signed bytes

    Ask an authority about an identity it does not govern and the chain stops. Your platform issues nothing.

    GET …/authority/845f7286-…/fetch
    ?sub=…/openid_relying_party/00000000-0000-0000-0000-000000000000
HTTP 404
"error": "not_found",
"error_description": "unknown entity identifier"

    Read at 01:35 UTC on 16 September 2026. The link repeats it. Open the refusal itself

  3. Folds

    The policy on each statement, folded anchor first. Then each required mark and its status.

    The policy the authority publishes about this agent Observed

    The signed bytes

    The metadata_policy for openid_relying_party, from the Tarnbrook subordinate statement, cut at the ellipses.

    "authorization_details_types": { "value": [ "records.read", "records.annotate",
    "transfer.initiate", "transfer.status" ] },
"grant_types": { "value": [ "client_credentials", "authorization_code", … ] },
"token_endpoint_auth_method": { "value": "private_key_jwt" }
    • authorization_details_types The four this authority permits. Your platform issues within them or refuses.

    Read at 01:37 UTC on 16 September 2026. That copy was minted at 01:37:51 and expires at 01:42:51. Open the subordinate statement

    The status query, and what the authority signed back Observed

    The signed bytes

    The request is a form post of the mark itself. The answer is typ trust-mark-status-response+jwt.

    POST …/authority/845f7286-…/trust-mark-status
trust_mark=eyJhbGciOiJQUzI1NiIs…

HTTP 200  application/trust-mark-status-response+jwt
"iss": "https://authority.directory.showcase.raidiam.io/…/845f7286-…",
"status": "active",
"trust_mark": "eyJhbGciOiJQUzI1NiIs…",
"iat": 1789522650
    • status The answer for the tarnbrook.agent.member mark on this agent.

    Read at 01:37 UTC on 16 September 2026. The mark it asks about is one of those in the entity configuration under step 01. Open the row and its register entry

    When the query is asked the wrong way Observed

    The signed bytes

    A consumer posts the mark it holds. A query by subject and mark type is refused, so the endpoint answers only somebody who already holds the mark.

    POST …/trust-mark-status
sub=…/70219aeb-…&trust_mark_type=…/tarnbrook.agent.member
HTTP 400
"error": "invalid_request",
"error_description": "request missing required parameter 'trust_mark'"

    Read at 01:37 UTC on 16 September 2026. Open the row and its register entry

  4. Issues

    The requested types, against each ceiling in order.

    • Registered4
    • Attested4
    • Granted1

Where a request stops

Resolves

federation-client-resolver.ts

  • no_chain_to_pinned_anchorTold noEvery path fails before it reaches an anchor you pin
  • anchor_not_for_admissionTold noThe path ends on an anchor pinned for marks only
  • authority_unreachableCould not tellA fetch failed over the network and no path closed

Folds

federation-client-resolver.ts

  • policy_violationTold noThe agent's metadata breaks the folded policy
  • accreditation_missingTold noThe required mark is absent from the agent
  • accreditation_withdrawnTold noThe issuer reports it inactive, or dropped the agent or its role policy
  • accreditation_unconfirmedCould not tellStatus, list or statement unreadable, with no recent active answer held

Issues

containment.ts, grants.ts

  • human_step_requiredTold noThe type needs a person's approval here
  • set_containmentTold noA type outside a ceiling. The refusal names the outermost one
  • scope_not_registeredTold noA scope outside the resolved metadata

The resolver stops a path at its first refusal. The token endpoint refuses a human step first, then runs containment, then checks the scope.

How long each answer lasts

  • Resolved answer heldThe shortest of the setting, the statement lifetimes and the mark status window ≤ 60 s
  • Mark status cached 60 s
  • Access token lifetime 300 s
  • Unreadable status honouredIf only the status endpoint fails, a recent active answer still admits 300 s

A platform reads again when the answer it holds expires. Values for the API platform.

What each consumer pins

Each consumer pins an anchor as the pair of entity identifier and key, and states in advance how long it will honour a mark it verified earlier when the status endpoint fails to answer. That window is read from the estate declaration rather than typed into this page.

ConsumerPinsRequires the markHonours a verified mark forTreatment
The API platform The Tarnbrook anchor, and the Aldercross anchor for marks only The Tarnbrook member mark or the enforcement point mark 300 s Reference implementation
The workforce platform The Tarnbrook anchor, and the Aldercross anchor for marks only The Tarnbrook member mark 300 s Reference implementation
The records resource The Tarnbrook anchor It reads the token the platform issued 0 s Reference implementation
The transfers resource The Tarnbrook anchor It reads the token the platform issued 0 s Reference implementation
Larkspur's gateway The Aldercross anchor The scheme's accreditation mark 300 s Reference implementation stands in for a third party
The attester The Tarnbrook anchor The agent's member mark 0 s Reference implementation
The agent runtime The Tarnbrook anchor The resource mark on what it discovered 0 s Customer side
The platform edge The Tarnbrook anchor The Tarnbrook member mark 300 s Reference implementation
The Batch Reviewer The Tarnbrook anchor It reads the token the platform issued 0 s Reference implementation
The portfolios resource The Tarnbrook anchor It reads the token the platform issued 0 s Reference implementation

Business meaning

OpenID Federation (open standard) 1.0 supplies the signed chain, the trust marks and the metadata policy your platform folds.

Role rows on the governed record become the metadata policy in the authority's signed statement about the agent. That statement is what your platform folds to derive the client. Observed

Authority explanation

Ten terms
anchor
The root entity of a trust domain whose key a consumer pins from configuration.
authority
A Connect entity that publishes signed subordinate statements, marks and policy about the entities it governs.
trust domain
The set of entities that chain to one anchor.
entity configuration
The self signed statement an entity publishes at its own identifier.
subordinate statement
The statement a superior signs about a subordinate: keys, policy, marks.
trust mark
The signed projection of an active accreditation, with a status endpoint.
envelope
The set of authorization detail types and grant types an authority permits an agent to request. The registered ceiling.
resolve
Walk the chain from a leaf to a pinned anchor and fold the policy.
pin
The anchor key a consumer holds in configuration, written at deploy time, as the pair of anchor identifier and key.
recognition
The governed act by which an authority becomes a superior of an entity that already publishes its own configuration, minting nothing.

The status query is a form post of the mark itself, and the answer is signed by the issuing authority. A query by subject and mark type is refused. What the answer bounds on this tenant is set out on the lifecycle page. Observed

Every consumer in the table above is Raidiam reference code, deployed and operated by Raidiam for this showcase from one deployment manifest. It shows one resolver exercised by every consumer rather than independent implementations agreeing. Deployment evidence

A platform that supports automatic client registration under the specification has the shape this needs. What has been exercised here is the other path: a platform without it puts the walk in front of itself as a component that derives a client, which is what the reference platforms here do.

Technical evidence

The resolver every consumer here shares is one module, and its dependency list is part of the deployment manifest. The rows below are the claims this page carries.

Metadata policy on the subordinate statement is projected from role rows on the governed record. The rows set on the role appear as the policy operators in the authority's statement about the entity. Observed

Govern · Role rows as the source of published policy. Lives in: Raidiam Connect. The row on the evidence page.

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

Discover · Trust mark status from the issuing authority. Lives in: Raidiam Connect. The row on the evidence page.

Every service on this estate, including the hosts that stand in for a third party, is deployed and operated by Raidiam for this showcase from one deployment manifest. Deployment evidence

Keys · One operator for the whole estate. Lives in: reference implementation. The row on the evidence page.

Raw artefact

Every read below is an unauthenticated GET that the capability matrix declares for this page. The command shown is the whole request, and it carries an accept header only.

https://authority.directory.showcase.raidiam.io/authority/96f37fd5-1f2e-4d8e-adbf-de069b3ba978/fetch?sub=https://rp.directory.showcase.raidiam.io/openid_relying_party/9108cb50-119d-47a9-b90b-825377971753

the statement about the hosted scratch agent carries subset_of, one_of and value operators from the role rows Read on the wire 2026-09-09.

Fetch it yourself

$ curl -s "https://authority.directory.showcase.raidiam.io/authority/96f37fd5-1f2e-4d8e-adbf-de069b3ba978/fetch?sub=https://rp.directory.showcase.raidiam.io/openid_relying_party/9108cb50-119d-47a9-b90b-825377971753"

https://rp.directory.showcase.raidiam.io/openid_relying_party/9108cb50-119d-47a9-b90b-825377971753/.well-known/openid-federation

the configuration carries the live mark a consumer posts to the status endpoint Read on the wire 2026-09-09.

Fetch it yourself

$ curl -s "https://rp.directory.showcase.raidiam.io/openid_relying_party/9108cb50-119d-47a9-b90b-825377971753/.well-known/openid-federation"