Subject verification, eID and authoritative services within confirmed scope.
Citizen/employee → authoritative identity → assurance → service decision → evidence/audit
A government journey identifies the citizen, digital/assisted channel, authoritative identity evidence, holder binding, service purpose and evidence. CheckID does not become the source of truth when data originates from a competent authority.
Authentication/federation and attribute sharing are different layers. An OIDC/federation assertion does not by itself establish the underlying proofing unless assurance metadata/trust framework is defined.
Counter/kiosk/assisted flows need operator/device boundaries, accessibility and exception handling for users unable to complete a remote biometric/eID flow. Public documentation does not assume a fallback that agency policy has not defined.
Cross-agency use requires purpose, legal authority, attribute provenance, relying-party trust and audit. “Connected government database” is not used as a generic claim.
Data residency, on-prem/private cloud, HA/DR and sovereign operations are deployment/contract questions; Current documentation provides a requirement matrix but does not invent topology or SLA values.
A government-grade decision should identify actor, source, method, result, assurance context, time and evidence correlation where the implementation supports them. NIST SP 800-63-4 is a reference, not a conformance claim.
The government reference architecture separates authoritative sources, identity proofing, authentication/federation, service purpose, assisted access and evidence; it does not assume a country-specific architecture without a government source.
Evidence may come from eID/documents, authoritative sources and biometrics; source authority and holder binding answer different questions.
Authentication/session assertions are not attribute sharing; purpose, RP, consent/authorization and scope remain separate.
Kiosk/counter journeys require operator/device boundaries, exception handling and accessibility; compatibility is not inferred without testing.
Cross-agency exchange requires provenance, purpose limitation and responsibility; CheckID does not become the authoritative source merely by orchestrating.
On-prem/private/data-residency statements are public only when deployment sources support them; a requirement is not the same as an implemented deployment.
Service transactions, source/method, results, authorization context and evidence correlate using actual identifiers.
Service consumption is separated from national authority and policy responsibilities.
| Journey | CheckID services | Boundary |
|---|---|---|
| Citizen identification | e-Identification + authoritative attributes | Determine subject from permitted authority/source |
| Identity verification | e-Verification + proofing + holder binding | Support public services with appropriate assurance |
| Citizen authentication | e-Authentication/federation where supported | Separate from service authorisation |
| Assisted service | eID/document/biometric + operator context | Support counter/kiosk under policy |
| Inter-agency | Federation/assertion/attribute sharing where implemented | Purpose + data minimisation + audit |
| Evidence | Identity Assurance & Evidence | Trace source, method, result and limitation |
