Markdown document

Gate register: showcase tenant verification

8 claims on this site rest on this artefact.

Read from the capability matrix as this page was served. Each claim below opens on the evidence page beside every other claim it makes.

01 What it proves The claims that rest on this file.

02 Resolved The artefact read as fields.

03 Signed Not carried by this artefact.

04 Raw and source The bytes, and where to fetch them.

Delegated accreditation as a Connect control govern.delegated-accreditation Observed
Publication driven by governed state govern.publication-follows-lifecycle Observed
Role rows as the source of published policy govern.policy-from-roles Observed
One organisation under two authorities discover.two-domains Observed
Trust mark status from the issuing authority discover.mark-status-live Observed
Accreditation withdrawal reaching the mark and status endpoints revoke.accreditation-status-follows Not observed on this tenant
Authority signing keys held in a key management service keys.authority-signer-kms Deployment evidence
The vouched key set of a recognition statement keys.recognition-vouches-own-key-only Not observed on this tenant

Where it lives: docs/verification/tenant-showcase-2026-09.md
Read on: 2026-09-09

Every claim, and what supports it Book a working session

The document as this site holds it, rendered from its markdown source.

Gate register: showcase tenant verification

Started 9 September 2026 by the lead, with a superuser web session the operator supplied. Environment: the Raidiam showcase directory, https://web.directory.showcase.raidiam.io. Every write below was made on objects created in this session and named SHOWCASE-SCRATCH; nothing that existed before was changed. Requests were sequential, at most one per second.

Steps are numbered as in design document 02 section 7. Step 0 is the headless write added by the review. Additional facts from the reviews are lettered.

Register

Id	Fact	Method	Answer	Verdict	When	Changes
9a	A federation entity can be created through the API	`POST /references/federations` with body `{Name, OrganizationName, HomepageUri, Status}` (the shape of the existing records)	`201`, `ReferenceID ec54688a-3e67-414d-84e6-9372e736e4c2`, all five federation endpoints returned; read back on `/references/federations?page=0&size=500` as Active	YES	2026-09-09 04:18 UTC	02 section 7 step 9 and 02 section 8 question 6: the engine can create federation entities; no by hand act. 06 section 10 step 1.
3	Role metadata rows: claim allow list, operators, `attest_jwt_client_auth` as a value, `oauth_resource` as an entity type	Eight `POST .../authorisationdomainroles/{role}/metadata` on role `scratch.member` in domain `showcase-scratch`, then a read back	Seven rows accepted and read back: `client_registration_types value`, `token_endpoint_auth_method one_of [private_key_jwt, attest_jwt_client_auth]`, `token_endpoint_auth_method value attest_jwt_client_auth`, `authorization_details_types value`, `authorization_details_types subset_of`, `grant_types value` (three grants including device code), `backchannel_token_delivery_mode value poll`. The eighth, `EntityType oauth_resource`, was refused: `Invalid request body: instance value ("oauth_resource") not found in enum (possible values: ["openid_provider","openid_relying_party","oauth_authorization_server", ...])`	YES for the relying party rows, `one_of`, `subset_of` and the attested method; NO for `oauth_resource` rows	2026-09-09 04:27 UTC	02 section 1.2 role table stands. 02 section 1.1: the `tarnbrook.resource` role carries no rows, confirmed. The journey 4 gate on `attest_jwt_client_auth` passes at the row level; whether a consumer honours it is a resolver test.
9b	An organisation can be created through the API with the OpenAPI required fields	`POST /organisations` with `OrganisationId, OrganisationName, LegalEntityName, CountryOfRegistration, CompanyRegister, RegistrationNumber, AddressLine1, City, Postcode, Country, Status`	`201`; `GET /organisations/SHOWCASE-SCRATCH-ORG` returns the record under `OrgDetails`	YES	2026-09-09 04:23 UTC	06 section 10: the engine creates organisations. `CompanyRegister` accepts free text, so "Showcase register" (review C9) works.
9c	An authority can be created under an organisation through the API, and its federation membership follows from the domain mapping	`POST /organisations/SHOWCASE-SCRATCH-ORG/authority-configuration` with `{AuthorityName, AuthorityCode, AuthorityUri, AuthorityCountry, Status}`; then `POST /references/authorityauthorisationdomains` with `{Status, AuthorityID, AuthorisationDomainID}`; then two unauthenticated GETs	`201` with `AuthorityId 96f37fd5-1f2e-4d8e-adbf-de069b3ba978` (the API set `AuthorityName` to the organisation name, ignoring the body's name); mapping `201`; within three seconds the authority's entity configuration answered `200`, signed with the tenant authority key `mrk-1bc80926…`, with `authority_hints` naming only the scratch federation entity, and the scratch federation entity's `/list` named the authority	YES. The whole estate root is API creatable and an authority's superiors are exactly the federations of the domains mapped to it	2026-09-09 04:30 UTC	02 section 7 step 9 closed as yes; 02 section 8 question 6 falls away; 06 section 10 step 1 is an engine step; 13 question 2 loses the by hand act. The authority name is the organisation name, so the world's authority names must be organisation names.
12	`AdditionalSoftwareMetadata` is accepted with the UI flag off	`POST .../softwarestatements` with the field as free text, then as a JSON string	Free text: `400 Invalid JSON provided for additional software metadata`. JSON string `{"scratch_probe":"step12"}`: `201`, read back verbatim	YES: the field is a JSON string validated as JSON; the UI flag hides it, the API takes it	2026-09-09 04:36 UTC	03 section 1 and 04 section 1.5: the provenance attribute bag may be recorded on the statement as JSON
9d	An organisation can hold domain claims and role claims under two authorities	`POST .../authoritydomainclaims` and `POST .../authorityclaims` for `SHOWCASE-SCRATCH-ORG` under the scratch authority (domain `showcase-scratch`, role `scratch.member`) and under the second scratch authority (domain `showcase-scratch-2`, role `scratch2.accredited`)	All four `201`; the organisation's claim list shows both roles with two different `AuthorityId` values	YES at the organisation level; the wire half of step 5 (marks from both domains on one hosted configuration) is read next	2026-09-09 04:40 UTC	02 section 7 step 5 first half; 02 section 1.2 organisations table stands; review C2's organisation per key class remains possible
C	The earlier estate's delegated accreditation refusal was a client side check	Read the earlier demonstrator's catalogue deploy source, `provision.ts` lines 288 to 300	The catalogue looked up the organisation's held claims and refused locally with "does not hold it, so it cannot grant it onward"; Connect was never asked	Confirmed: the beat as filmed for the earlier customer was not Connect's refusal. Review B3 and F8 stand; the API form is probed as fact D	2026-09-09	04 section 2.1, 05 section 3.3, 11 beat a-e must use the API form only
D	Delegated accreditation is a Connect control: a statement claim referencing a claim the organisation does not hold is refused by Connect	Three `POST .../softwarestatements/{ss}/authorityclaims` on the self managed scratch statement: (1) a held organisation claim id, (2) a fabricated id, (3) another organisation's claim id for a role the first organisation also holds under the same authority	(1) `201`; (2) `404 Resource of type 'Organisation Authority Claim' with ID '0000…0001' for Organisation with ID 'SHOWCASE-SCRATCH-ORG' not found`; (3) `404` with the same message naming org 2's claim id and org 1; the statement's claim list stayed at one	YES. Connect refuses with a 4xx that names the referential rule and scopes it to the organisation. The film beat can show Connect's own answer	2026-09-09 04:44 UTC	Review B3 and F8 closed: use the API form; 04 section 2.1 keeps only the API form; 05 section 3.3 and 11 beat a-e say "Connect answers 404 naming the organisation"; capability row `govern.delegated-accreditation` stays Observed
5	A federation managed entity configuration carries marks from two domains under two authorities, and hints both	Unauthenticated GET of the hosted scratch statement's entity configuration after claims under both authorities	`200`, signed `mrk-097d8498…`, `authority_hints` names both scratch authorities, two trust marks (`showcase-scratch/scratch.member` and `showcase-scratch-2/scratch2.accredited`); each authority's `fetch?sub=` answers with its own policy and vouches `mrk-097d8498…`; `/resolve` from the second anchor answers `200` with a four hop chain	YES. One organisation under two authorities, one hosted identity with two generated superiors, exactly as 02 section 3.4 needs	2026-09-09 04:47 UTC	02 section 7 step 5 closed; 02 section 3.4 stands; the hero's two chains need no by hand publication
B	`/list?entity_type=` classification of a self managed software statement	Both scratch authorities' `/list` with and without `entity_type`	`openid_relying_party` returns the hosted and the self managed statements; `openid_provider` returns nothing	The filter classifies software statements correctly here. The ANCHOR entity that appeared under `openid_provider` on the shared authority is therefore most likely registered as an authorisation server, not a statement	2026-09-09 04:47 UTC	Review B7 softened: the filter is usable for statements; the explorer still classifies by published metadata for safety
E	Connect's resolver validates policy operator combinations	`/resolve` for the hosted statement from the first anchor while the role carried `value` and `subset_of` rows on `authorization_details_types` whose value was not a subset, and `value` with `one_of` on `token_endpoint_auth_method`	`400 invalid_metadata: unresolvable metadata policy encountered`; after the conflicting `value` rows were removed the resolve is re read (row 3b)	A proper 400, not a 500. The role rows must respect the specification's combination rules; the converge engine must validate them before writing	2026-09-09 04:50 UTC	06 section 10: add a policy combination check to `validateEstate`; 02 section 1.2: the `tarnbrook.auth.*` roles must not combine `value` and `one_of` on one claim
F	The resolve response on this tenant carries no `trust_marks` member	`/resolve` for the hosted statement from the second anchor: `trust_marks` absent, while the entity configuration carries two marks	Consumers must read marks from the entity configuration and verify them, never from the resolve response	2026-09-09 04:47 UTC	02 section 3.1 rule 4 stands and is now a verified requirement
G	The vouched key set for a self managed statement whose organisation holds no key	`fetch?sub=https://agents.showcase.raidiam.io/scratch/agent` from the scratch authority	`jwks` contains exactly one key, `mrk-097d8498…`, the tenant's hosted entity key	The 19 August defect reproduced on a fresh organisation: the directory vouches its own key for an entity it does not host and that holds no key of its own	2026-09-09 04:47 UTC	02 section 4.2 and 14: the product ticket stands; the converge test `recognition-vouches-own-key-only` will be red
6	`trust-mark-status` is POST with form `trust_mark=<jwt>` and answers a signed status	`POST {authority}/trust-mark-status` with the live mark for the self managed scratch statement; then with `sub` and `trust_mark_type` instead	The mark form: `200`, a JWS with `typ trust-mark-status-response+jwt`, signed `mrk-1bc80926…`, `status: active`, `iss` the authority, the mark echoed. The parameter form: `400 request missing required parameter 'trust_mark'`	YES for the live query. The withdrawn case is read in step 10	2026-09-09 04:52 UTC	02 section 3.1 rule 5 stands: consumers POST the mark they hold. The mark carries `iat` and no `exp` (read), so the status query is the only bound
3b	The cause of the `invalid_metadata` refusal in E, and whether `one_of` on an absent parameter breaks a resolve	Rows removed one at a time with a 70 s wait and a `/resolve` after each: the two `value` rows that conflicted with `subset_of` and `one_of`; then the `one_of` row; then the `client_registration_types value "automatic"` row (a string, where the leaf asserts an array); then `one_of` re added	`400` persisted until the string valued `client_registration_types` row was removed, then `200` with a four hop chain; `one_of` re added on `token_endpoint_auth_method`, which the hosted leaf does not assert: still `200`, and the resolved metadata carries no `token_endpoint_auth_method`; `subset_of` on an absent `authorization_details_types` leaves it absent; `value` rows on `grant_types` and `backchannel_token_delivery_mode` land	A row's value shape must match the parameter's shape (`Values` for an array parameter). `one_of` and `subset_of` never set a value; on an absent parameter they leave it absent and the resolve succeeds	2026-09-09 05:05 UTC	Review F9 confirmed: the hosted hero needs `value` rows for `token_endpoint_auth_method` and `authorization_details_types`. 06 section 10: `validateEstate` checks value shape against the claim name. 02 section 3.1: the shared resolver treats `one_of` on an absent parameter as absent, not as a violation, matching Connect
13	Audit attribution for writes made with the web session	`GET /audit?resourceType=softwareStatementAuthorityRoleClaim&page=7&size=50` (pages are oldest first)	Every claim write of this session carries `PerformedBy: the signed in operator`; `OrganisationId` absent in the row	The session user is the audit subject. A client's writes carry its assertion subject (measured on the earlier tenant); step 0 confirms on this one	2026-09-09 05:00 UTC	02 section 6 audit paragraph stands; D4 attribution depends on step 0
10	Mint cadence and what a claim withdrawal reaches	The self managed statement's only claim set Inactive by `PUT` (full record, `Status: Inactive`), then `fetch?sub=`, `trust-mark` and `/list` polled every 3 s for 106 s	`/list` dropped the entity at the first poll (4 s); `fetch?sub=` kept answering `200` with an empty `openid_relying_party` policy and re minted at 61 s (`iat` 1788929041 to 1788929102); `trust-mark` kept answering `200` with the SAME mark (`iat` unchanged) for the whole window	Cadence about 61 s. A claim withdrawal removes the entity from the list and empties the policy on the next mint, and leaves the statement itself served	2026-09-09 05:03 UTC	02 section 6 rows "identity withdrawn" and "accreditation withdrawn" change: the list and the policy follow; the served statement does not
I	The trust mark endpoint and the status endpoint follow a claim withdrawal	After the self managed claim went Inactive: `trust-mark` GET and `trust-mark-status` POST for the old mark at 106 s and again at 6 minutes. Then on the hosted statement: its `scratch2.accredited` claim set Inactive, the entity configuration, the second authority's `/list`, `trust-mark` and `trust-mark-status` read after 65 s	Self managed: `trust-mark` `200` with the same mark, status `active` at 6 minutes. Hosted: the mark DROPPED from the generated entity configuration and the entity left the second authority's `/list` within 65 s, while the second authority's `trust-mark` endpoint still answered `200` and `trust-mark-status` for the withdrawn mark still answered `active`	NO. The generated configuration and the list follow the claim; the mark issuing endpoint and the status endpoint do not, at least within six minutes. Marks carry no `exp`, so a self hosted leaf that republishes its marks from the authority keeps a withdrawn accreditation, and a consumer's status query confirms it	2026-09-09 05:12 UTC	Product ticket T3 (below). 02 section 3.1 rule 5 and section 6 "accreditation withdrawn": the status query is not a bound on this tenant today; until T3 lands, consumers treat a mark as valid only while the subject is on the issuing authority's `/list` and the subordinate statement carries the role's policy, and the lifecycle page says so. Journey 6's accreditation beat shows the list and the configuration, not the status endpoint
J	A software statement can be set Inactive by `PUT`	`PUT .../softwarestatements/{ss}` with the full GET record and `Status: Inactive`; then with the create shaped body and `Status: Inactive`	Both `400 Invalid request body: instance failed to match all required schemas (matched only 1 out of 2)`; the record stayed Active	Not settled. The PUT schema is a two way `oneOf` the two bodies did not satisfy. The known withdrawal path is the soft `DELETE`, which is permanent	2026-09-09 05:13 UTC	04 section 1.15 and 6.2 keep the soft delete as the withdrawal act; the UI's PUT body is read from the directory UI source in W05 follow up
0	A headless write on showcase attributed to a purpose built subject	Pending: needs a client that authenticates (see A)		OPEN
A	The earlier headless client (`35942319`, org `edfb10ca`) fails client authentication although its record is Active, its two active certificates match the local ones by `x5t#S256`, the private key matches the certificate, and the server requests a client certificate in the TLS handshake	`tls_client_auth` at `matls-auth…/token` with the leaf, and with the leaf plus issuing CA: `401 invalid_client`. The skill's jwt bearer assertion script: `401 invalid_client`	Not the certificates. The OAuth client registration behind the statement is the suspect. Decisive test: a freshly created client under the scratch organisation	OPEN	2026-09-09	Decision 3 (repair the AAF client) may become "create the operations client" if a new client authenticates

Objects created in this session

Order	Object	Id	Final state
1	Federation entity `SHOWCASE-SCRATCH federation`	`ec54688a-3e67-414d-84e6-9372e736e4c2`	Active (no Inactive path known yet)
2	Authorisation domain `showcase-scratch` (FederationID = the scratch federation)	`7c265223-cb32-44cd-aec4-eeaba7930ed7`	Active
3	Role `scratch.member` in `showcase-scratch`, RoleType Federation	`7e57f81e-03c0-4366-82e3-228537ce0c60`	Active, seven metadata rows
4	Organisation `SHOWCASE-SCRATCH verification org`	`SHOWCASE-SCRATCH-ORG`	Active
5	Authority under `SHOWCASE-SCRATCH-ORG`	`96f37fd5-1f2e-4d8e-adbf-de069b3ba978`	Active
6	Authority to domain mapping (scratch authority, `showcase-scratch`)	`d8376adc-e0bc-43b0-af0b-517b4e6e3846`	Active
7	Software statement `SHOWCASE-SCRATCH operator client` (federation disabled, `tls_client_auth`) in org 1	`031095e8-b3e8-4499-b559-734b8659f362`	Active, no certificates yet (the certificate script is blocked for the lead; the operator runs it)
8	Software statement `SHOWCASE-SCRATCH self managed agent`, ClientId `https://agents.showcase.raidiam.io/scratch/agent`	`99ed14cf-526c-4c5d-b95d-9859842040e4`	Active, one statement claim `scratch.member` (`09f87111-ac79-47a6-b5a5-8619925bdc73`)
9	Domain claim org 1 under authority 1	`b9dba37b-37a2-439c-9128-19479ea3f6d7`	Active
10	Org claim org 1 `scratch.member` under authority 1	`dc1a584f-fb0d-40b0-a9a8-d474449157ab`	Active
11	Federation entity `SHOWCASE-SCRATCH federation 2`	`2a0d5e07-22de-4367-87bb-3025b63754d4`	Active
12	Organisation `SHOWCASE-SCRATCH-ORG-2`	`SHOWCASE-SCRATCH-ORG-2`	Active
13	Domain `showcase-scratch-2` (FederationID = federation 2)	`f7557933-2f26-4681-9cc7-caabefb14d86`	Active
14	Authority under org 2	`5bb31966-3818-4454-808d-3d94f9989af7`	Active
15	Mapping domain 2 to authority 2	`45928c42-8b35-451a-aa19-d07162678e62`	Active
16	Role `scratch2.accredited` in domain 2	`5616531f-88a1-46d3-9eb8-ea58d0df4a86`	Active, no rows
17	Domain claim org 2 under authority 2	`47613423-e8c1-4c2f-954c-329a894c37c1`	Active
18	Org claim org 2 `scratch2.accredited`	`eab90283-24af-40c5-8780-1e35209a8cf4`	Active
19	Domain claim org 1 under authority 2	`99621793-a325-4c2c-954c-f1b5b8648824`	Active
20	Org claim org 1 `scratch2.accredited`	`1a313ddd-edd3-4f77-ab93-b4ff6bfae1d4`	Active
21	Software statement `SHOWCASE-SCRATCH hosted agent` (federation managed) in org 1	`9108cb50-119d-47a9-b90b-825377971753`	Active
22	Statement claim on the hosted statement, `scratch.member` under authority 1	`c67517df-2d45-4b90-a7f4-3a27bca08bcf`	Active
23	Statement claim on the hosted statement, `scratch2.accredited` under authority 2	`3cbe05e6-d12b-4eb2-8234-de5db58d6d25`	Active
24	Statement claim 09f87111 on the self managed statement		Inactive (withdrawn by the verification)
25	Statement claim 3cbe05e6 on the hosted statement (`scratch2.accredited`)		Inactive (withdrawn by the verification)

Product tickets to file, from this session

Id	Title	Observed	Expected
T1	Subordinate statements about self managed and issuer registered entities vouch the tenant's hosted entity signing key	`fetch?sub=https://agents.showcase.raidiam.io/scratch/agent` from the scratch authority vouches exactly one key, `mrk-097d8498…`, for an organisation that holds no key (row G); design document 14 locates the unconditional append	The `jwks` of a statement about a self managed subject holds only the owning organisation's active signing keys; empty rather than a key the subject does not hold
T2	Authority to authority recognition	An authority's `authority_hints` are its federation memberships only; a statement naming another authority's URL vouches the organisation keyset (design document 02 section 4)	A statement under organisation O naming authority B's URL with a claim under authority A makes A a superior of B, vouching B's signing key
T3	The trust mark and trust mark status endpoints do not follow a claim withdrawal	Row I: six minutes after a software authority claim was set Inactive, `trust-mark` still issued the mark and `trust-mark-status` answered `active`, while the generated entity configuration and `/list` had already dropped it	Within the mint cadence, `trust-mark` answers 404 for a subject with no active claim of that type and `trust-mark-status` answers a not active status for a mark whose claim is Inactive
T4	A subordinate statement is served for an entity that is no longer listed	Row 10: after the only claim went Inactive the entity left `/list` within seconds while `fetch?sub=` kept answering `200` with an empty policy (the earlier tenant's recorded defect)	`fetch?sub=` answers 404 for a subject the authority no longer lists, so a chain walk fails at that hop rather than resolving with an empty policy

Other facts checked this session, outside the tenant

Fact	Method	Answer	Consequence
ElevenLabs quota (decision 9)	`GET https://api.elevenlabs.io/v1/user/subscription` with the key in `~/.claude/secrets/elevenlabs-api-key.env`	`401`	The stored key no longer authenticates. the operator supplies a working key with the top up before W33 (voicing).
Railway access (W07)	`railway whoami` and `railway list` with the CLI at `~/.nvm/versions/node/v18.17.1/bin/railway` (4.36.1)	Logged in as the operator; projects anchor, the earlier project, ciba, bnt	Project `agent-trust-showcase` created and linked from the code repository, id `ba509b06-48e3-4381-afc7-1981ebcd5f70`, environment `production`, workspace the operator's workspace.
The showcase DNS zone (W07)	`dig NS showcase.raidiam.io` and the AWS organisation repository	`showcase.raidiam.io` is not a delegated zone; `directory.showcase.raidiam.io` and `demo.directory.showcase.raidiam.io` are delegated to the directory showcase account; the precedent for a new zone is a child zone in the account's `dns.tf` plus an NS record in the `raidiam.io` zone file	Branch `feat/agents-showcase-dns-zone` in `tf-raidiam-aws-organisation` holds the child zone file, uncommitted; the operator commits, pushes and opens the PR, then the delegation PR.
AWS profiles for the showcase account	`~/.aws/config`	`raidiam-showcase-admin` and `raidiam-showcase-ro` exist	The deploy tooling writes Route 53 records with `raidiam-showcase-admin` once the zone exists.

Fetch it yourself: docs/verification/tenant-showcase-2026-09.md