1. Specification
Identity is the layer every other service depends on. Whoever operates the identity provider decides who can sign in, what they can see and when access stops, and holds the record of everything each person did. The evidence shows that in most UK public bodies that position is occupied by a single overseas vendor’s directory, bundled with the productivity suite (key finding 1).
A sovereign identity layer separates three things that are bundled today:
- Authentication. Proving who someone is, passwordless by default, with the credential held on the person’s device rather than in a vendor’s cloud.
- Federation. Letting an organisation trust identities issued elsewhere (another department, a university, a contractor) without copying its directory.
- Authorisation and audit. Deciding what an identity may do, and keeping the record under the public body’s control, exportable in an open format.
Each must meet the general criteria that apply to every layer. The sovereignty tests that matter most here are customer-held keys for the signing and token keys (G3), operation by an operator the buyer chooses (G4), and exit: a directory and its audit log must leave in an open format (G2).
2. Layer profile
Criteria specific to identity and access, in addition to the general profile. A supplier claims each line and a buyer tests it.
| Id | Criterion | Standard |
|---|---|---|
| IA-1 | Applications sign users in through an open protocol, so the identity provider can be replaced without changing the applications. | OpenID Connect Core 1.0 over OAuth 2.0 |
| IA-2 | Federation with existing public-sector and academic federations uses the protocol those federations run. | SAML 2.0; the UK Access Management Federation’s technical specification |
| IA-3 | Passwordless sign-in with the credential held on the user’s device; phishing-resistant by construction. | FIDO2 / W3C WebAuthn, passkeys |
| IA-4 | The identity provider can broker to other providers, so no organisation depends on one. | OpenID Connect and SAML brokering; discovery via OpenID Connect Discovery |
| IA-5 | Accounts and groups are provisioned and removed through an open interface, not a vendor console, so joiners and leavers do not depend on one product. | SCIM 2.0 or an LDAP interface |
| IA-6 | The user sees and controls which attributes are released to which service. | Consent screens and attribute release policy; selective disclosure |
| IA-7 | Signing keys and token-encryption keys are generated and held under the buyer’s control. | Keys in a hardware security module or key service the buyer controls (general criterion G3) |
| IA-8 | Sign-in and administrative events are exportable in an open, documented format to a security operations service the buyer chooses. | Structured event export; OpenTelemetry or syslog |
| IA-9 | Ready for verifiable credentials, so the layer can align with the EU Digital Identity Wallet and partner schemes. | W3C Verifiable Credentials, OpenID for Verifiable Credentials |
Already adopted in UK government
The Cabinet Office’s Open Standards Board has not adopted a profile for identity or access (Open standards for government). Adoption here is de facto, through the public services in section 4: GOV.UK One Login (OpenID Connect), NHS CIS2 (OpenID Connect and OAuth 2.0) and the UK Access Management Federation (SAML 2.0). A supplier that meets IA-1 to IA-3 can federate with all three today.
3. Open-source solutions that meet the profile
A solution is listed only against the lines it demonstrably meets, with a source. A line it does not meet, or that has not been checked, is left blank. Suppliers and maintainers can submit evidence through the contribution route.
Keycloak
| Line | Met | Evidence |
|---|---|---|
| G5 licence | Yes | Apache License 2.0; a Cloud Native Computing Foundation project since April 2023, so changes are governed by a foundation, not one company (CNCF, 2023). |
| G4 | Yes | Self-hosted on any infrastructure; the project ships container images and an operator for Kubernetes (Keycloak, 2026). |
| IA-1 | Yes | Certified OpenID Connect provider (OpenID Foundation certified implementations). |
| IA-2 | Yes | SAML 2.0 identity provider and service provider (Keycloak server administration guide). |
| IA-3 | Yes | WebAuthn and passkey authentication (Keycloak server administration guide). |
| IA-4 | Yes | Identity brokering to external OpenID Connect and SAML providers, and user federation to LDAP and Kerberos (Keycloak server administration guide). |
| IA-5 | LDAP federation is built in; SCIM is provided by community extensions and is not assessed here. | |
| IA-6 | Yes | Per-client consent screens and scoped attribute release (Keycloak server administration guide). |
| IA-7 | Keys are generated per realm and can be rotated; holding them in a buyer-controlled HSM depends on the deployment and is not assessed here. | |
| IA-8 | Yes | Event listener interface with admin and login events; export to external systems through listeners (Keycloak server administration guide). |
| IA-9 | Under development in the project (OpenID for Verifiable Credential Issuance is an experimental feature); not assessed. |
Candidates awaiting assessment
Listed so that contributors can pick them up; nothing is claimed until a line is evidenced.
- Ory (Kratos, Hydra, Keto): Apache License 2.0 as stated by the project.
- authentik: MIT licence as stated by the project.
- ZITADEL: licence as stated by the project.
4. Public services implementing the standard
These are services, not software you can install. They show that the UK already operates the standards above at national scale. They still have to meet the general criteria, and where they do not, that is a finding for the evidence side.
| Service | Operator | Standard | Source |
|---|---|---|---|
| GOV.UK One Login | Government Digital Service | OpenID Connect (IA-1) | GOV.UK One Login technical documentation |
| NHS Care Identity Service 2 (CIS2) | NHS England | OpenID Connect and OAuth 2.0 (IA-1); smartcard and passkey-style authenticators (IA-3) | NHS England, CIS2 authentication |
| UK Access Management Federation | Jisc | SAML 2.0 federation (IA-2) | UK federation technical specification |
5. Skills and horizon
Horizon 1 of the roadmap is “identity first”: agree a shared open identity architecture building on the three services above, and require IA-1 to IA-3 in every renewal that falls in the window.
The skills the layer needs are federation operators, identity engineers who can run a provider under IA-7 and IA-8, and security staff who can consume IA-8 events. Universities already run the largest federation in the country through Jisc; the skills section proposes that experience as the training ground.