`verified_claims`
Claims plus verification metadata, not merely profile attributes.
OPENID IDENTITY ASSURANCE
OpenID Connect for Identity Assurance 1.0
Standardizes how a Relying Party requests and receives verified identity information together with metadata describing how, when, under which framework and with what evidence verification occurred. references the Final specification with Errata Set 1 (07/2026).
SOURCEAuthoritative / document
CAPTUREDevice / SDK
VERIFYDocument + biometric
ASSUREPolicy + risk
DECIDEClaims / status
EVIDENCEAudit / trace
MODEL
Verified identity result
Authoritative source + document + biometrics + policy → Identity Assurance → verified claims → RP.
01SOURCEAuthoritative/evidence
02DOCUMENTeID / passport
03BIOMETRICHolder / modality
04POLICYrequested assurance
05VERIFYprocess metadata
06CLAIMSverified_claims
07OIDCprotocol delivery
08RPdecision
BOUNDARY
Implementation, alignment and certification
Using the concepts/schema is not the same as certification.
Verification metadata
trust framework · method · time · evidence / source context.
Relying Party
Consumes verified identity under requested policy/scope.
Certification boundary
Mobile-ID SSO OP certification is distinct from Identity Assurance certification.
OPENID IDENTITY ASSURANCE
Verified Claims carry verification context, not only attributes
References OpenID Connect for Identity Assurance 1.0 and the Schema Definition incorporating Errata Set 1 (July 2026).
verified_claims structure
verification.trust_frameworkTrust framework used for the verification.ASSURANCE
verification.assurance_levelAssurance information where the framework/schema uses it.ASSURANCE
verification.timeVerification time semantics defined by the schema.TIME
verification.verification_processReference to the verification process.TRACE
verification.evidence[]Evidence and associated check/assurance details.EVIDENCE
claimsThe identity claims that have been verified.CLAIMS
CheckID mapping discipline
- Subject — verified entity context.
- Process — an individual verification process.
- Document/biometric result — inputs to the assurance/evidence model.
- Evidence/transaction reference — traceability, not automatically a one-to-one OpenID field.
Mapping status: DIRECT · DERIVED · CONCEPTUAL · REQUIRES_IMPLEMENTATION.
CHECKID ↔ OPENID IDA
Field-level mapping
Documents the relationship instead of making a broad “OpenID aligned” statement.
| CheckID concept | OpenID IDA concept | Mapping | Status |
|---|---|---|---|
| Subject | End-user / subject context | CONCEPTUAL | Serialization to be confirmed |
| Process | verification process | CONCEPTUAL / DERIVED | CheckID process reference exists |
| Document verification | document evidence / checks | DERIVED | Evidence model dependent |
| Verification time | verification.time | DIRECT when contract field exists | Validate schema |
| Verified attributes | claims | DIRECT / DERIVED | Response mapping |
| Assurance result | assurance_level / trust framework | REQUIRES_IMPLEMENTATION | No inference |
Technical basisSOURCE-BACKED
SourceOpenID Foundation
StandardOpenID Connect for Identity Assurance 1.0 + Schema Definition
VersionErrata Set 1, July 2026
ApplicabilityIdentity assurance exchange model
EvidenceOfficial OpenID specifications + CheckID mapping register