Raidiam
Book a working session

Evidence

How Connect is deployed

The two capability rows behind this page, the artefacts that support them, and the read you can run yourself.

Back to the claim

Who operates what

This showcase

Raidiam operates all 16 services, from one deployment manifest

Reference implementation 12

  • site
  • attester
  • platform-workforce
  • platform-api
  • records
  • transfers
  • portfolios
  • platform-edge
  • quillon
  • larkspur
  • aldercross-officer
  • signals

Customer side 4

  • catalogue
  • agent
  • commercial-uk
  • private-ch

Your deployment

Raidiam runs

  • The Connect tenant

You run

  • The platforms
  • The agents and resources
  • The catalogue

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. In your deployment those roles separate. You run the catalogue, the platforms, the resources and the agents. Raidiam runs the tenant. Deployment evidence

Where the signing key is

What you can read

The authority's signed statement, its header

alg
PS256
kid
mrk-1bc80926203a499793dbdc707a663700
typ
entity-statement+jwt

Read on the wire on 29 September 2026. The statement it came from

  • Every signed statement names its key identifier in its header.

What the operator states Deployment evidence

A key management service

In the account Raidiam operates

  • The anchor signers
  • The authority signers
  • The hosted entity signing key
  • The private half stays in the key service.

The anchor signers and the authority signers on this tenant are keys in a key management service, in the account Raidiam operates. Every signed statement names its key identifier in its header. A key management boundary you operate for the authority signer is a deployment choice for Connect, and this tenant is configured the other way. Deployment evidence

The rows and their artefacts

Each row below links the artefact that supports it, read on the wire on the date printed beside it. The security and keys page carries the full keys table.

The anchor signers and the authority signers on this tenant are AWS KMS keys in the account Raidiam operates. Every signed statement names its KMS key identifier in the header, which is what can be read from outside. That the private half stays in the key service is a statement the operator of the deployment makes, which is why this row is deployment evidence. Deployment evidence

Keys · Authority signing keys held in a key management service. 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.

Read the artefact yourself

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/.well-known/openid-federation

the header names a KMS key identifier Read on the wire 2026-09-09.

Fetch it yourself

$ curl -s "https://authority.directory.showcase.raidiam.io/authority/96f37fd5-1f2e-4d8e-adbf-de069b3ba978/.well-known/openid-federation"