Connect — Integrated Module

Certificates that manage themselves as your ecosystem grows

HSM-backed certificate issuance, automated rotation, OCSP, JWKS publication, and lifecycle management — for every participant in your ecosystem. Build the PKI model once. It scales automatically as you add participants, services, and use cases.

Registration Authority

How the directory and PKI work together

Raidiam Connect's directory is a registration authority — it validates identity and authorises certificate issuance. The PKI runs in a separate, isolated account. Together they provide governed certificate lifecycle for every entity in the federation.

Two-System Architecture

Directory / Registration Authority

Account A — Identity & Governance

▼Organisations
├──Meridian BankVerifiedASPSP
├──Retail OPActive
├──Business OPActive
├──Accounts APIActive
└──Nova Connect AppCertified
├──Sterling BankVerifiedASPSP
└──PayFlowPending Accreditation
▼Entity JWKS— every entity has a JWKS endpoint
├──Organisations→ org-level signing keys
├──Auth Servers (OPs)→ transport + signing certs
├──Applications→ client authentication keys
├──APIs→ resource server keys

JWKS can contain both:

Public keys (for signature verification)
Full X.509 certificates (in the x5c claim)

System Interactions

Certificate Request

RA validates identity → authorises issuance → sends CSR to CA

Certificate Issued

CA signs certificate → returns to RA → published in entity's JWKS

Revocation Request

RA revokes entity → CA invalidates cert → OCSP + CRL updated

PKI / Certificate Authority

Account B — Isolated, HSM-backed

Root CA

Offline, air-gapped

OFFLINE

Intermediate CA

HSM-backed, online signing

HSM
OCSP Responder
CRL Distribution

From CSR to trusted certificate

The complete flow for getting a certificate issued in the federation

Directory zone
Account boundary
PKI zone
Result
1
Directory zone

Entity submits CSR

The entity (org, OP, app, or API) generates a key pair and submits a Certificate Signing Request to the directory.

2
Directory zone

Directory validates identity

The registration authority checks: Is this entity registered? Is it accredited? Does federation policy allow this certificate type for this entity type?

3
Directory zone

Directory checks policy

Federation metadata policies are evaluated: Is this entity type allowed transport certificates? Does the organisation have the right roles? Are certificate limits respected?

4
Account boundary

CSR forwarded to CA

The validated CSR is sent from the directory (Account A) to the PKI (Account B) via a secure, authenticated channel. This crosses the account boundary.

5
PKI zone

CA signs certificate

The intermediate CA signs the CSR using its HSM-protected private key. The certificate is bound to the entity's verified identity and roles.

6
PKI zone

Certificate returned to directory

The signed certificate is returned to the directory and published in the entity's JWKS endpoint.

7
Result

Entity discoverable with certificate

The entity's JWKS now contains the certificate. Any OP or resource server in the federation can discover it, verify the certificate chain, and establish a trusted connection.

What JWKS Contains
entity-jwks.json
1
{
2
  "keys": [
3
    {
4
      "kty": "RSA",
5
      "kid": "meridian-retail-transport-2026",
6
      "use": "sig",
7
      "x5c": ["MIIC...base64-encoded-certificate..."],
8
      "x5t#S256": "abc123...",
9
      "n": "0vx7agoebGcQ...",
10
      "e": "AQAB"
11
    },
12
    {
13
      "kty": "RSA",
14
      "kid": "meridian-retail-signing-2026",
15
      "use": "sig",
16
      "n": "2HnoFk9pL...",
17
      "e": "AQAB"
18
    }
19
  ]
20
}
1
Transport certificate

Includes x5c (full cert chain) for mTLS. The x5t#S256 claim is the SHA-256 thumbprint — used for certificate-bound access tokens.

2
Signing key — bare public key

Public key only, no certificate. Used for JWT signature verification. No x5c — just the raw RSA modulus and exponent.

JWKS can hold both bare public keys AND full X.509 certificates. The x5cclaim contains the certificate chain. This is how OPs verify both the key AND the identity it's bound to.

The directory and the PKI are deliberately separate systems in separate accounts. The directory is the registration authority — it decides WHO gets certificates. The PKI is the certificate authority— it signs them. Neither can operate without the other. This separation is by design: it means the CA never issues a certificate without the RA's authorisation, and the RA never has access to the CA's signing keys.

PKI & Certificate Lifecycle

HSM-backed PKI for every participant

Raidiam operates a full certificate authority integrated with the registration authority. Certificates are issued only after identity verification and accreditation. The entire lifecycle — issuance, rotation, renewal, revocation, and validation — is automated and HSM-backed.

PKI Hierarchy
Raidiam Root CA
Offline root. HSM-protected. Air-gapped.
Intermediate CA
Online issuing CA. HSM-backed. Region-specific.
Transport Certificates (mTLS)
  • Client authentication
  • Sender-constrained tokens
Signing Certificates (JWS)
  • Software statements
  • Signed metadata
  • JWT signing
Encryption Certificates (JWE)
  • Payload encryption
  • Key agreement
Certificate Issuance
Directory (Registration Authority)
  • Verifies identity
  • Assigns roles
  • Authorises certificate issuance
Identity verified, roles assigned
Certificate Authority
  • HSM-backed CA
  • Issues transport + signing certs
  • Binds certs to verified identity
Certificates issued
JWKS Endpoint
  • Public keys published
  • JSON Web Key Sets
  • Discoverable by all participants
Published to
Federation Controller
  • Entity statement updated
  • Metadata signed
  • Trust chain refreshed
Participant now discoverable
Ecosystem
  • OPs discover the participant
  • Trust verified via chain
  • API access authorised
Certificate Revocation
TriggerCertificate compromised or organisation suspended
OCSP Responder
  • Real-time status query
  • Returns: REVOKED
  • Any OP can check instantly
JWKS Updated
  • Certificate moved to revoked key store
  • Active JWKS endpoint refreshed
  • Verifiers fetch updated key set
CRL Published
  • Certificate Revocation List updated
  • Distributed to all validators
  • Cached for offline verification
Shared Signals
  • Federation event broadcast
  • All affected participants notified
  • Tokens invalidated
Access denied across the entire ecosystem within seconds
Validation Services
OCSPOnline Certificate Status Protocol
Always On
  • Real-time certificate validation
  • OPs and resource servers query OCSP on every connection
  • Returns: GOOD, REVOKED, or UNKNOWN
  • Response time: <100ms
JWKSJSON Web Key Sets
Always On
  • Public key distribution
  • Published at well-known endpoints
  • Used to verify signatures on entity statements, software statements, and JWTs
  • Auto-rotated when certificates renew
CRLCertificate Revocation Lists
Always On
  • Batch revocation status
  • Published periodically and on-demand
  • Cached by validators for offline checking
  • Delta CRLs for efficient updates

HSM Key Management

Private keys generated and stored in FIPS 140-2 Level 3 hardware security modules. Keys never leave the HSM.

mTLS Everywhere

Mutual TLS for all participant connections. Certificate-bound access tokens per RFC 8705.

OCSP & CRL

Real-time certificate validation. Online Certificate Status Protocol and Certificate Revocation Lists.

Automated Rotation

Certificates automatically renewed before expiry. Zero-downtime rotation with overlapping validity.

Signed Metadata

All trust artefacts — entity statements, software statements, JWKS — cryptographically signed.

Registration Authority Integration

Certificates issued only after the registration authority has validated identity and accredited the entity. Governed issuance.

The directory, CA, JWKS, OCSP, and CRL aren't separate systems. They're integrated components of a single trust lifecycle. When the directory revokes an entity, the CA invalidates the certificate, the revoked key is moved to an inactive key store in JWKS, OCSP reflects the revocation instantly, the CRL is updated, and shared signals notify every participant. This happens in seconds, not days.

Build Once. Expand Everywhere.

Where will your ecosystem take you?

Whether you're a regulator building a national digital economy, an enterprise platformising across brands and clouds, or a bank that wants to stop rebuilding trust for every new use case — there's a next step.

See It in Action

See how one investment in Raidiam Connect covers your first use case — and the next hundred

See It in Action

Request a Briefing

For regulators and central banks — how to build the foundations for an expandable digital economy

Request a Briefing

See the Proof

Brazil started with 2 data-sharing scopes. Today it has hundreds — all on the same infrastructure

See the Proof

Not sure where to start? Build the business case → · See if this is right for you → · Developer Portal & API docs → · Security & Trust Center →