Traditional identity systems stop at organisational boundaries. Here is what crosses them.

Standard identity tools were built for single organisations. Cross-institutional trust at scale requires a different foundation — the choice of Swiss healthcare.

Discuss this architecture for your organisation — no commitment

Four structural limitations of standard identity tools

OAuth (Open Authorization) and Public Key Infrastructure (PKI) are excellent tools — within a single organization's boundary. These are not failures. They are architectural constraints that become visible when trust needs to span organizations.

Token trust

OAuth / PKI constraint

OAuth tokens are trusted within the boundaries of their issuer. Across organisations, this boundary breaks — the receiving organisation has no way to verify the issuing organisation's authority.

DKMS / Stargate solution

DKMS establishes cryptographic identity that is self-certifying — every organisation's identity is verifiable by any other organisation without dependency on a shared certificate authority.

Access granularity

OAuth / PKI constraint

OAuth scopes are coarse — designed for application-level permissions. Resource-graph consent across organisational boundaries requires a different model.

DKMS / Stargate solution

Stargate's policy engine (Open Policy Agent, OPA) enables programmable, granular access control that operates across organisational trust boundaries.

Auditability

OAuth / PKI constraint

OAuth logs are organisational. Cross-organisational audit trails — who accessed what, when, authorised by whom — require cryptographic chaining that OAuth was not designed to provide.

DKMS / Stargate solution

KERI (Key Event Receipt Infrastructure) provides tamper-evident audit trails. Every identity event is cryptographically linked and independently verifiable, creating cross-organisational auditability.

Trust architecture

OAuth / PKI constraint

OAuth assumes a central authority — an identity provider everyone trusts. Distributed institutional trust between sovereign organisations cannot depend on a single authority.

DKMS / Stargate solution

DKMS enables sovereign identity management — every organisation controls its own cryptographic roots. Trust is established bilaterally, not delegated to a central coordinator.

OAuth for local tokens, DKMS for scalable institutional trust

KERI identity infrastructure architecture diagram showing key event log, witnesses, watchers, and cross-organizational trust establishment
KERI identity infrastructure — self-certifying identifiers, key event receipts, and bilateral trust without central authority

This is an evolution, not a replacement. OAuth (Open Authorization) is the right tool for local authentication within the boundaries of a single organisation. DKMS (Decentralized Key Management System) is the right tool for institutional trust at scale — across sovereign organisations without a shared identity provider. Stargate combines both, deploying each where it is the right tool.

Aligned with Switzerland's national eID programme

Swiyu is Switzerland's national electronic identity programme, currently under development. It is built on the same Self-Sovereign Identity (SSI) and decentralised trust model that underpins Stargate and SEAL. This is not a coincidence — the same architectural principles that solve institutional trust at scale are now being adopted at the national level.

Vereign has been involved in the Swiyu consultation process from its earliest stages. Georg Greve served on the Swiyu Technical Advisory Council, contributing practical experience from production-scale DKMS deployment in Swiss healthcare. This direct involvement ensures that Vereign's architecture remains aligned with Switzerland's evolving regulatory and identity infrastructure.

For organizations deploying Stargate today, Swiyu alignment means their trust infrastructure is future-proof with respect to Swiss regulatory direction. The architectural decisions are compatible — organizations are not building for today's requirements alone, but for the trust environment Switzerland is building towards.

Stargate delivers this architecture

Stargate is the production implementation of the DKMS-based trust architecture described above. It combines OAuth for local authentication with KERI-anchored DKMS for cross-organizational trust, a programmable OPA-based policy engine, semantic interoperability via Overlays Capture Architecture (OCA), and verifiable communication via SEAL.

SEAL, the verifiable communication component of Stargate, is already processing over 800,000 verified messages per month across Swiss healthcare. Full Stargate deployment is rolling out throughout 2026, chosen by Swiss healthcare as the future trust fabric.

Explore Stargate

Consent enforcement is what DKMS is for

EHDS Article 71(8) creates a structural constraint that no central authority can satisfy: when a person opts out of secondary use, that withdrawal must propagate across every institution that holds or derives data from the original. No CA can co-sign the opt-out; no identity provider can cascade the revocation. The constraint is architecturally incompatible with centralized identity.

DKMS satisfies five invariants EHDS Article 71 requires: person-scoped identifiers that survive re-enrollment; verifiable, timestamped opt-out records anchored in the Key Event Log; reversibility without re-identification; cross-controller propagation without bilateral agreements between every institution pair; and unlinkability between the consent record and the data it covers.

After data has been disclosed — shared across a hospital network, a research consortium, or a payer chain — a subsequent opt-out must still reach every downstream controller. DKMS key event logs propagate the revocation cryptographically: each controller's KEL is append-only and witnessed, so a revocation appended at the person's edge becomes verifiable at every institution that holds a derived record.

Read the consent architecture thesis

Proven in Swiss healthcare — chosen for national-scale deployment

HIN — Health Info Net — is Switzerland's health information network, connecting hospitals, GP practices, and specialist providers across cantonal boundaries. SEAL, the verifiable communication component built on this trust architecture, already processes 800,000+ verified messages per month. Full Stargate deployment with structured data exchange is rolling out throughout 2026.

HIN — Health Info Net

800,000+

verified messages per month

850+

gateways across Swiss healthcare

30,000+

GP offices and healthcare institutions

Trust Architecture — frequently asked questions

What is DKMS?
DKMS (Decentralised Key Management) is the category of identity infrastructure where cryptographic trust is rooted at the organisational edge, not in a central certificate authority. Every organisation controls its own key material and its own append-only Key Event Log (KEL). Vereign co-founded the DKMS Alliance to formalise DKMS as a category alongside PKI and OAuth.
How is DKMS different from PKI?
PKI anchors trust in central Certificate Authorities — one CA compromise affects every subject that CA signed. DKMS anchors trust in each organisation's own Key Event Log: a failure is scoped to one controller, key rotation is native and atomic via pre-rotation commitments, and cross-jurisdiction trust does not require CA-to-CA recognition treaties. DKMS is PKI at the edge, without the single point of failure.
Does DKMS replace OAuth?
No. OAuth is correct for local token flows inside a single organisation and should continue to be used there. DKMS solves a problem OAuth was never designed for: establishing verifiable trust between organisations without a shared intermediary. The two are complementary — OAuth for local tokens, DKMS for scalable institutional trust.
Is DKMS post-quantum ready?
Yes. DKMS treats key rotation as a first-class operation. When post-quantum algorithms are required, migration becomes a routine key rotation on the existing Key Event Log rather than a big-bang reissuance of certificates. KERI's pre-rotation property means the next key can be any algorithm the controller commits to — including post-quantum schemes — without breaking existing trust relationships.
Who maintains DKMS?
DKMS is an open specification. The DKMS Alliance — co-founded by Vereign — coordinates the specification. The reference implementation of KERI (the protocol underlying DKMS) is maintained as open source by the broader KERI community. Vereign's Stargate and SEAL are AGPLv3+ implementations of the DKMS layer deployed in production across Swiss healthcare.
Does DKMS require a blockchain?
No. DKMS uses hash-linked Key Event Logs (KELs) for append-only integrity, but there is no consensus layer, no token, and no distributed ledger. The architectural decision to avoid blockchain is deliberate — regulated infrastructure requires deterministic verification, not probabilistic finality.

Book an architecture review — map this to your trust boundaries.

This architecture is deployed in Swiss healthcare at national scale. Whether you are evaluating alternatives to centralized identity or planning cross-organizational data exchange, we will map it to your environment in a 30-minute call.

Book an architecture review
Swiss Data Protection GDPR Compliant Open Source AGPLv3+ Swiss Hosting
See how the architecture works step by step