Assurance, Assessment, and Certification

Review status: This foundation page requires specialist review before public approval. Its claims must remain within the scope stated here.

Assurance is confidence supported by evidence. Certification is one possible formal outcome within a defined scheme. Neither term should be used as a general marketing synonym for security, interoperability, or legal compliance.

Controlled vocabulary

Statement	Meaning	Evidence required
Designed to support	Architecture includes controls relevant to an objective	Approved design, scope, assumptions, and limitations
Implemented	The capability exists in the stated build or deployment	Release evidence, configuration scope, and tests
Available	The capability is offered for the stated users, region, and conditions	Product approval and published availability statement
Configured for a profile	A named deployment uses a defined policy baseline	Profile version, configuration, tests, and approval
Interoperability tested	An implementation was tested against named peers or test vectors	Versions, profiles, results, limitations, and date
Conformance tested	Behavior was evaluated against specified normative requirements	Test suite, version, result, exclusions, and assessor
Independently assessed	A separate qualified party reviewed a defined scope	Report or attestation, assessor, scope, period, and limitations
Certified	A recognized certification body issued a valid certificate	Scheme, certificate, holder, scope, version, validity, and surveillance conditions
Registered or notified	An authority or scheme entered a service into an official register	Register entry, service, role, jurisdiction, and status
Legally recognized	Law or an authority grants a specific legal status	Current legal source and official evidence
Supports compliance	A capability can contribute controls or evidence	Control mapping plus institutional responsibilities

These statements are not interchangeable.

Assurance layers

Architecture assurance

Evaluates whether the design includes suitable trust boundaries, role separation, data minimisation, cryptographic controls, recovery, observability, and failure behavior.

Implementation assurance

Evaluates whether code, configuration, schemas, policies, keys, and dependencies implement the approved design.

Operational assurance

Evaluates whether the production service is patched, monitored, recoverable, access-controlled, tested, and operated according to policy.

Ecosystem assurance

Evaluates issuers, verifiers, wallet providers, proofing services, custodians, processors, and relying parties as a complete trust relationship.

Independent and regulatory assurance

May include penetration testing, privacy or security assessment, conformity assessment, certification, regulator registration, audit, trust mark, or legally defined status.

A strong result in one layer does not automatically establish the others.

Scope statement

Every public assurance claim should identify:

• product and component;
• deployment or environment;
• feature and trust role;
• standard, framework, regulation, or scheme;
• exact profile and version;
• assessor or certifier;
• assessment period and evidence date;
• exclusions and dependencies;
• validity, surveillance, and expiry;
• public evidence location or controlled access process.

“UbID is certified” is insufficient when the certificate covers only one component, environment, control family, or period.

Recommended evidence package

Depending on the claim, evidence may include:

• architecture and data-flow diagrams;
• threat model and privacy assessment;
• cryptographic inventory and key-lifecycle documentation;
• software bill of materials and dependency review;
• source, build, release, and deployment provenance;
• positive and negative protocol tests;
• accessibility, usability, and biometric performance review;
• penetration test and remediation evidence;
• backup, recovery, business-continuity, and incident exercises;
• access review and segregation-of-duties evidence;
• processor and transfer assessments;
• policy-version and historical-decision evidence;
• independent report, certificate, register entry, or authority decision.

Sensitive findings and operational details remain controlled even when a public summary is appropriate.

Interoperability is not certification

Successful exchange with one wallet, issuer, verifier, or agent demonstrates a tested combination. It does not prove support for every optional feature, every version, every external implementation, or every trust policy.

Public interoperability claims should name:

• protocol and version;
• profile and optional features;
• implementation versions;
• positive and negative test scope;
• date;
• known limitations;
• whether the result was self-tested or independently witnessed.

Security review is not legal approval

A penetration test, code review, cryptographic assessment, or privacy impact assessment can improve assurance. It does not grant a regulated identity status, approve a legal basis, or certify a relying party's business decision.

Trust marks and public language

Before displaying a logo, badge, certification, or regulated-status claim, confirm:

1. the service and legal entity named by the evidence;
2. the covered product, environment, region, and role;
3. the current validity and surveillance status;
4. the exact wording allowed by the scheme;
5. whether partner or customer use is included;
6. whether material changes require reassessment;
7. that the public link points to current evidence.

Expired, suspended, superseded, or scope-limited evidence must not be presented as a current platform-wide claim.

Reassessment triggers

Reassessment may be required after:

• material architecture or trust-boundary change;
• new credential format, algorithm, key provider, or recovery model;
• addition of biometric processing or automated decisions;
• new jurisdiction, sector, processor, or transfer route;
• major dependency or infrastructure change;
• security incident or significant vulnerability;
• revised standard, law, regulator guidance, or certification scheme;
• change in legal entity, product scope, or service role.

See Content and Capability Status and References and Source Standards.