CheckID
CustomersPartners
VIEN
Contact
Home/CheckID Platform/Identity Assurance
PLATFORM · CHECKID

Identity Assurance

Bind source, document, subject, biometrics, risk and evidence into an auditable result.

Talk to an expertDeveloper quick start
CAPABILITYInput → Processing → Output
CONTROLPolicy · risk · standard
EVIDENCEResult · trace · scope
VERIFIED IDENTITY RESULT

JWT · verified_claims · trust framework

The source API contains claim_sources/JWT and verified_claims. distinguishes source implementation from current OpenID standard alignment and certification status.

Source contractSections 3.4, 3.6 and Appendix A · final_result / claim_sources
Authoritative / verified source context
↓
Document + process evidence
↓
Verification / assurance context
↓
Signed verified identity result
JWT PAYLOAD — CONCEPTUAL REDACTIONSOURCE SHAPE 
{
  "iss": "https://id.mobile-id.vn",
  "sub": "<SUBJECT_ID>",
  "verified_claims": {
    "verification": {
      "trust_framework": "<TRUST_FRAMEWORK>"
    },
    "claims": {
      "name": "<VERIFIED_NAME>",
      "dob": "<VERIFIED_DOB>"
    }
  }
}
Certification boundaryUse of OpenID Identity Assurance concepts/profile in the source does not imply OpenID Identity Assurance certification.
TECHNICAL CONTENT

Identity Assurance: expressing confidence through source, method and evidence

Source → Scope → Implementation → Evidence → Limitation

Assurance is not a badge

Assurance is a contextual statement about confidence in identity information, based on proofing methods, sources, policy, evidence and limitations. does not assign IAL/AAL/LoA labels without an approved mapping.

Inputs

Assurance can combine document/eID results, authoritative-source results, biometric verification/PAD and policy context when those components are used by the deployment. Provenance is retained for each input.

Profile

An assurance profile records Objective, Sources, Methods, Controls, Evidence, Standards, Certificates and Limitations. The same verified attribute can carry different assurance when obtained through a different source/method.

Result

A relying party should understand which attributes were verified, by which method/source, at what time and under what context. A certificate for one module is not used to infer assurance for every transaction.

OpenID mapping

OpenID Connect for Identity Assurance standardizes how RPs request and receive identity information with verification metadata. Concrete trust frameworks and legal/commercial rules remain deployment concerns; CheckID mappings are classified DIRECT, DERIVED, CONCEPTUAL or REQUIRES_IMPLEMENTATION.

Re-proofing

Assurance lifetime depends on source, policy and use case. does not invent re-proofing intervals; step-up or reverification intervals must come from policy evidence.

Official technical references