Assurance input
Verification results, provenance, evidence quality, holder binding and configured signals.
Identity assurance is not just a score: the decision must be tied to method, source, scope, policy and traceable evidence.
Verification → provenance → policy → decision → evidence
Verification results, provenance, evidence quality, holder binding and configured signals.
The relying organisation defines assurance requirements; CheckID provides policy/decision capability only where corresponding implementation evidence exists.
Decisions require reason/context/version where the real contract supports them; conceptual fields are not presented as API fields.
Service output is modelled as transaction + service + method + source + result + evidence references.
OpenID IDA is a reference for verified claims and verification metadata; a mapping is called IMPLEMENTED only with Tier-1 field evidence.
Evidence supports dispute/audit/investigation, while retention and integrity mechanisms follow the actual source/contract.
Do not invent fields.
| Concept | Meaning | Status |
|---|---|---|
| Service transaction | Service transaction identifier | Implementation where an actual ID field exists |
| Verification method | Method used | Implementation/reference according to contract |
| Source/provenance | Data/evidence provenance | Requires actual source |
| Result | Verification result | Contract-exact |
| Policy/version | Decision context | Only where implemented |
| Evidence references | Evidence references | Called a real field only when source-backed |
A reference does not by itself mean CheckID conforms to or is certified against the document.
Request/receive verified identity information with assurance metadata
Verified claims and verification metadata schema reference