> Accepted in August 2026: MintID’s four assurance grades are its own contract, anchored on the eIDAS levels and squared with ISO/IEC 29115, with recency reported as a separate freshness band. The options, the comparison, and why the hybrid was chosen. index — 12 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/mcp](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) * [context](#context) * [the two options](#options) * [decision: the hybrid](#decision) * [consequences](#consequences) 10. [record · packagingrecord/02](/en/sdk/packaging) 11. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 12. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · record/01 # Decision record — the assurance vocabulary Accepted in August 2026: MintID’s four assurance grades are its own contract, anchored on the eIDAS levels and squared with ISO/IEC 29115, with recency reported as a separate freshness band. The options, the comparison, and why the hybrid was chosen. ## Context _Status: **Accepted** (August 2026) · first recorded in July 2026 as an open decision · depends on the specification’s assurance-grade and issuer-conduct rules_ Issuers turn authenticated identity checks into one assurance grade, A1 to A4. Something must say, normatively, _which evidence suffices for which grade_. Two issuers grading the same evidence differently — or one grading A3 on evidence the ecosystem would call basic — would undermine exactly the trust the grades exist to carry. The choice shapes conformance testing, issuer onboarding and how regulators read a MintID grade. It does not touch chain state or consensus, which is why it could stay open while the provider-neutral KYC interface was being built. ## The two options ### Option A — a bespoke MintID vocabulary MintID defines its own evidence requirements: for each grade, the required check types, evidence classes and review cadence, versioned with the protocol. * **Pros:** full control over the semantics; an exact fit for four grades; no dependence on an external body’s revision cycle; conformance tests derived directly from our own text. * **Cons:** the authoring and maintenance burden is ours; every provider and issuer maps onto _our_ vocabulary without ecosystem tooling; regulators and partner institutions must be taught what a MintID grade means; audit defensibility rests on our own documentation alone. ### Option B — adopt an external framework wholesale A1–A4 are defined purely as mappings onto an established framework — candidates included OpenID Connect for Identity Assurance, the eIDAS levels (low, substantial, high) and NIST SP 800-63 (IAL1–3). * **Pros:** regulator and institutional legibility for free; providers already describe their checks in these vocabularies; external audit can lean on established criteria; less text to maintain. * **Cons:** none of these frameworks has four levels, so any mapping onto A1–A4 is partial; revisions happen outside our control; each framework carries a jurisdictional flavour; and some assumptions — such as verifier-side attribute visibility — do not fit a credential presented in zero knowledge. A: bespoke B: external framework Fit to four grades exact partial (three-level frameworks) Regulator and partner legibility must be built largely inherited Provider-mapping effort higher (our vocabulary) lower (their native vocabulary) Revision control ours an external body’s Jurisdiction neutrality yes flavoured by the chosen framework Maintenance burden authoring tracking plus glue A hybrid — MintID’s own four-grade contract, anchored on external levels — was recorded at the time as a variant of A. It is where the decision landed. ## Decision: the hybrid MintID keeps its own four-grade contract — grades are decided by the issuer from enumerated, authenticated checks, within the grades the council allows it — and **anchors the grades on the eIDAS assurance levels, squared with ISO/IEC 29115**. The grade meanings are unchanged; the external columns are mappings, not redefinitions. Grade eIDAS ISO/IEC 29115 NIST SP 800-63 AML posture A1 low LoA2 IAL1 customer due diligence A2 substantial LoA3 IAL2 due diligence with biometric liveness (ETSI TS 119 461 baseline proofing) A3 substantial + enhanced due diligence LoA3⁺ IAL2 + EDD screening: sanctions, PEP, adverse media A4 high LoA4 IAL3 qualified identity proofing (ETSI extended proofing, a notified eID at high, the EU Digital Identity Wallet) **Freshness is a second dimension, not a grade.** The issuer holds a freshness band — F4 under 30 days, F3 under 90, F2 under 180, F1 under 365 — published as a band and never as a date, so that it cannot become a linkable timestamp. **Why.** eIDAS is what Europe’s regulators, the EU Digital Identity Wallet and qualified trust-service proofing use first, and the EU AML Regulation points to it; ISO/IEC 29115 supplies the four-level backbone; and every framework reviewed tiers identity proofing by _strength_, while none attaches a validity period to a level — which is why validity moved out of the grade. The first issuer implementation informed the choice, and the provider-neutral KYC interface did not change. ## Consequences The issuer-side KYC policy that applies the grades — requirements per type of operator (person or organisation), evidence reuse within the AML envelope, overdue re-verification handled as suspension rather than revocation, and consent withdrawal revoking everything it backed — is implemented behind the provider-neutral interface and awaits counsel sign-off. Until then, the first issuer works with a simulated KYC provider only. For verifiers nothing changes on the wire: a presentation still proves _grade ≥ G_ and, separately, _freshness ≥ F_ — never a level or a date. [previous← reason codes](/en/sdk/reason-codes)[nextrecord · packaging →](/en/sdk/packaging) --- Source: https://mintid.net/en/sdk/kyc-trust-model · Decision record — the assurance vocabulary — MintID verifier SDK docs