Evidence: Same software
One release. A governed identity in each environment.
A vendor's product runs in our estate and in theirs. Is that one identity or two?
- 3Claims on this page
- 6Artefacts behind them
- 3Reads you can run here
One release, two governed identities
Your own infrastructure
Tarnbrook Financial Group operates it
- Declared artefact digest
- sha256:9c1f…9887
- Listed by
- The Tarnbrook authority
- Policy on its envelope
- value
- It asks for
- records.read transfer.status review.submit
- Envelope
- records.read records.annotate review.submit
The publisher's platform
Quillon Software operates it
- Declared artefact digest
- sha256:9c1f…9887
- Listed by
- Quillon's root
- Policy on its envelope
- subset_of
- It asks for
- records.read transfer.status transfer.initiate
- Envelope
- records.read transfer.status
Both agents name one signed release record.
Each agent, in full
Their superior, their policy operator and their envelope differ.
Quillon signs that record for Balance Monitor 2.4.0, and both entity configurations name it by its digest. The record declares an artefact digest, a software bill of materials and the tools the release offers. The digests are declared rather than computed: no artefact is served at the address the record names on this estate. Read on the wire on 29 September 2026, both configurations carry the same record_digest and the same artefact. The two instances are served by different programs on this estate, and they run different tasks, so the record is what they share.
Your own infrastructure
Callum Reid stands an instance up from the Tarnbrook catalogue. The Tarnbrook authority lists that agent directly, and the agent signs with private_key_jwt on a key Tarnbrook holds. It asks for records.read, transfer.status and review.submit. Two value rows replace that ask: tarnbrook.records.reader gives it records.read and records.annotate, and tarnbrook.review.caller gives it review.submit, which lets this agent ask the Batch Reviewer to review a batch. So transfer.status is dropped and records.annotate is added. The token carries no assurance claim, because the platform admits an identity rather than an instance.
The publisher's platform
Yusuf Demir operates a second instance at Quillon, as a service. Quillon's own root lists that agent, and the Tarnbrook authority recognises that root, so the only chain from Quillon's agent to the Tarnbrook anchor passes through the recognition hop. The agent signs with private_key_jwt on a key Quillon holds, and its token carries no assurance claim either. It holds neither Tarnbrook role the other agent holds.
Where each policy sits
Your own infrastructure
- The agent
- Listed directly
On the statement about the agent
value- records.read
- records.annotate
- review.submit
- Tarnbrook authority
- Tarnbrook anchor
The publisher's platform
- The agent
- Quillon's root
On the recognition hop
subset_of- records.read
- transfer.status
- Tarnbrook authority
- Tarnbrook anchor
Quillon's agent asks for
- records.read
- transfer.status
- transfer.initiate
The ceiling on the hop subset_of
- records.read
- transfer.status
The resolved envelope
- records.read
- transfer.status
- transfer.initiate Dropped
The ceiling sits on the authority's statement about Quillon's root, so it covers every agent under it.
How each policy folds a claim
A value row replaces what the leaf asks for, so it can add a type as well as drop one. A subset_of row keeps only what the leaf asks for and the row allows, so it can only drop.
Quillon's agent asks for records.read, transfer.status and transfer.initiate. The row on tarnbrook.external.reader allows records.read and transfer.status. Resolved at the Tarnbrook anchor on 29 September 2026, the envelope is those two, and transfer.initiate is gone. The chain has five statements, one more than the Tarnbrook agent's four, and the extra one is the hop.
One record for every agent from the publisher
Quillon Software The publisher
- Publishes its root
- Holds the root key
- Signs the release record
- Lists its own agent
Tarnbrook Financial Group The operator
- Recognises the root
- Sets the hop's ceiling
- Grants the role to Quillon
A new agent under Quillon's root
Same record, same ceiling.
One recognition record and one ceiling cover every agent that root lists.
Every step, with the record it writes
Quillon Software, the publisher. It publishes an entity configuration at its own address, so an operator reads the root there. It generates the root key and supplies the public half; the private half stays with Quillon. It signs one release record for Balance Monitor 2.4.0. It lists its own agent under that root, so the operator's authority never lists it, and it sets private_key_jwt as that agent's method.
Tarnbrook Financial Group, the operator. It recognises the publisher's root with one recognition record at the Tarnbrook authority. It sets the ceiling on that hop as a subset_of row on tarnbrook.external.reader, bounding it to records.read and transfer.status. It grants that role to Quillon's organisation. It does nothing further for a new agent under that root, because every such agent reaches the anchor through the same record. The instance Tarnbrook stands up itself it lists directly, with value rows of its own.
What this page proves
Each claim, its label and the artefacts behind it.
Delegated accreditation as a Connect control
ObservedConnect refuses a statement claim that references a claim the organisation does not hold, with a 404 that names the referential rule and scopes it to the organisation.
- Lifecycle stage
- Govern
- Lives in
- Raidiam Connect
- Checked by
- Test verification:D
- Artefacts cited
- 2
-
docs/verification/tenant-showcase-2026-09.md#row-d
Read on the wire 2026-09-09. three claim writes on the self managed scratch statement: one held claim accepted, a fabricated id and another organisation's claim id both refused
-
Read on the wire 2026-09-09. the API the write goes through
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://www.raidiam.com/developers/docs/apis/connect-openapi/create-organisation-software-statement-authority-claim
the API the write goes through Read on the wire 2026-09-09.
Fetch it yourself
$ curl -s "https://www.raidiam.com/developers/docs/apis/connect-openapi/create-organisation-software-statement-authority-claim"
Role rows as the source of published policy
ObservedMetadata policy on the subordinate statement is projected from role rows on the governed record.
The rest of the statement
The rows set on the role appear as the policy operators in the authority's statement about the entity.
- Lifecycle stage
- Govern
- Lives in
- Raidiam Connect
- Checked by
- Test verification:3b
- Artefacts cited
- 2
-
authority.directory.showcase.raidiam.io/authority/96f37fd5-1f2e-4d8e-adbf-de069b3ba978/fetch
Read on the wire 2026-09-09. the statement about the hosted scratch agent carries subset_of, one_of and value operators from the role rows
-
docs/verification/tenant-showcase-2026-09.md#row-3b
Read on the wire 2026-09-09. a row's value shape must match the parameter's shape; one_of and subset_of leave an absent parameter absent
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"
The vouched key set of a recognition statement
Not observed on this tenantThe design requires that the statement about a recognised root vouches only the keys that root publishes. On this tenant the statement about a self managed entity whose organisation holds no key vouches one key, the tenant's hosted entity signing key, which the subject does not hold. In the entity generated model the subject holds its own private key and Connect does not receive it. The key this statement vouches is the tenant's hosted entity signing key, which Connect adds by product behaviour rather than from anything the subject supplied.
- Lifecycle stage
- Keys
- Lives in
- Raidiam Connect
- Checked by
- Test E11
- Artefacts cited
- 3
-
authority.directory.showcase.raidiam.io/authority/96f37fd5-1f2e-4d8e-adbf-de069b3ba978/fetch
Read on the wire 2026-09-09. one vouched key for an organisation that holds none
-
docs/verification/tenant-showcase-2026-09.md#row-g
Read on the wire 2026-09-09.
-
docs/ledger.yaml#T1
the product change record
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://agents.showcase.raidiam.io/scratch/agent
one vouched key for an organisation that holds none 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://agents.showcase.raidiam.io/scratch/agent"
The working
What the figures above leave to words.
What it means for the business
One release can run in more than one environment, and the operator changes with the environment. Each instance runs as an agent with a governed identity of its own. Provenance travels with the software. Your authority decides what each agent may ask for, directly or at the hop that admits the publisher.
Where the authority comes from
Recognition is the governed act by which the Tarnbrook authority becomes a superior of an entity that already publishes its own configuration. Quillon generated its root's key and supplied the public half. The Tarnbrook authority recognised that root with one recognition record.
The rows on the role are what the authority publishes as policy, so the ceiling on a recognition hop is a governance record rather than a setting inside a platform. Observed
Connect refuses a statement claim that references a claim the organisation does not hold, and names the referential rule. On this tenant that was read on a scratch statement: a claim the organisation held was accepted, and a fabricated claim and another organisation's claim were both refused. The same rule would refuse Quillon a role it holds no grant of. That attempt was not made on Quillon's record. Observed
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 design requires that the statement about a recognised root vouches only the keys that root publishes. On this tenant the statement about a self managed entity whose organisation holds no key vouches one key, the tenant's hosted entity signing key, which the subject does not hold. Read on 29 September 2026, both of the authority's statements on this page also carry that tenant key. Not observed on this tenant
Other runtimes
This estate runs Balance Monitor 2.4.0 in two places, both self managed. It runs no instance of it on a workload domain or on a workstation. The Batch Reviewer and the Analyst Companion run there, and the runtime use case covers what each of those tokens carries.
Check it against the running estate
Every surface this use case touches, and the host that answers for it.
Which supplier's software runs in both your estate and theirs, and who operates each copy?
Ninety minutes, on the shape of your estate: which systems resolve first, which anchor each pins, and which key each party holds.
Book a working sessionExplore further