> An open architecture decision record: should the evidence vocabulary behind assurance grades A1–A4 be a bespoke MintID verdict contract, or a mapping onto an external assurance standard? Both options, the comparison, and the evidence that will settle it. 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. [adr-0001 · kyc trust modeladr/0001](/en/sdk/adr-0001-kyc-trust-model) * [context](#context) * [the two options](#options) * [decision: open](#decision) * [consequences](#consequences) 10. [adr-0002 · packagingadr/0002](/en/sdk/adr-0002-packaging) 11. [adr-0003 · multi-languageadr/0003](/en/sdk/adr-0003-multilanguage) 12. [bip-0001 · contract freezebip/0001](/en/sdk/bip-0001-verifier-service-contract) SDK docs · adr/0001 # ADR-0001 — KYC trust model An open architecture decision record: should the evidence vocabulary behind assurance grades A1–A4 be a bespoke MintID verdict contract, or a mapping onto an external assurance standard? Both options, the comparison, and the evidence that will settle it. ## Context _Status: **Open** · recorded 2026-07-19 · card MINT-162 · spec refs R5, R28, §4, §14.3_ `AssessAssurance` turns a KYC provider's enumerated, authenticated checks into one assurance grade, A1–A4. Something must define, normatively, _which evidence suffices for which grade_ — the vocabulary the `KycPolicy` is written in. Two authorities grading the same evidence differently, or one grading A3 on evidence the ecosystem would call basic, undermines exactly the trust the grades exist to carry. The decision shapes conformance testing, authority onboarding, and how regulators read a MintID grade — but it does not touch chain state or consensus, which is why it can stay open while the provider abstraction ships. ## The two options ### Option A — a bespoke MintID verdict contract MintID defines its own evidence-requirements vocabulary: for each grade, a normative list of required check types, evidence classes, freshness bounds and review cadence, versioned in the protocol repository — referenced on-chain, if ever, only as an identifier, never as content. * **Pros:** full sovereignty over semantics; the vocabulary exactly fits A1–A4 and the §4 validity and review cadences; no dependency on an external body's revision cycle; conformance tests derive directly from our own text. * **Cons:** we carry the authoring and maintenance burden; every provider and authority maps onto _our_ vocabulary with no ecosystem tooling; regulators and partner institutions must be taught what a MintID grade means; audit defensibility rests entirely on our own documentation. ### Option B — adopt an external assurance standard as the vocabulary A1–A4 are defined as mappings onto an established framework — candidates include OpenID Connect for Identity Assurance (the natural fit for an OpenID4VCI/VP stack), eIDAS levels (low / substantial / high), and NIST SP 800-63 IAL1–3. For example: "A2 = evidence satisfying IAL2 under trust framework X", with the standard's own evidence taxonomy used in `KycPolicy`. * **Pros:** regulator and institutional legibility for free; commercial KYC providers already describe their checks in these vocabularies, easing driver mappings; external audit can lean on established criteria; less normative text to maintain. * **Cons:** none of the frameworks has four levels — any mapping onto A1–A4 is partial and needs bespoke glue anyway; standard drift imports revision risk we don't control; frameworks are jurisdiction-flavoured (eIDAS = EU, 800-63 = US) and choosing one is a positioning act; and there is a risk of inheriting requirements that don't fit a privacy-preserving, zero-knowledge-presented credential — such as assumptions about verifier-side attribute visibility. A: bespoke B: external standard Fit to A1–A4 as specified exact partial (3-level frameworks vs 4 grades) Regulator / partner legibility must be built largely inherited Provider-mapping effort per driver higher (our vocabulary) lower (their native vocabulary) Revision control ours external body's Jurisdiction neutrality yes flavoured by chosen framework Conformance-test derivation from our text from standard + our glue Maintenance burden authoring tracking + glue A hybrid — a bespoke contract that _cites_ external levels as informative anchors — is a plausible landing zone; it is recorded as a variant of A, not a third option, to keep the decision binary on _what is normative_. ## Decision: open — deliberately No recommendation is recorded. Evidence that would settle it: * **Regulatory input** — which framework (if any) the first target jurisdictions expect a KYC authority to attest against. * **First authority onboarding** — what vocabulary the first real KYC authority's compliance function and its providers already operate in; the cost of each option measured on a real case instead of estimated. * **Conformance-suite experience** — whether contract tests written against grade semantics can stay framework-agnostic or keep forcing one option's shape. The decision closes on a dedicated card once the regulatory input or the first onboarding exists — and closing it must also confirm that the chosen mapping implies no unfreeze of the §4 grade definitions. ## Consequences while open Everything both options require is already binding: grades are issuer-decided, bounded by council-allowed tiers (R5), derived from enumerated authenticated checks, with the grade decision recorded in the issuer's private case file. The provider abstraction implements the interface without hardcoding either vocabulary —`KycPolicy` stays opaque to the driver. What stays blocked until closure: the normative per-grade evidence-requirements text, authority-facing grading guidance, and any conformance test that asserts _which_ evidence yields _which_ grade. [previous← reason codes](/en/sdk/reason-codes)[nextadr-0002 · packaging →](/en/sdk/adr-0002-packaging) --- Source: https://mintid.net/en/sdk/adr-0001-kyc-trust-model · ADR-0001 — KYC trust model — MintID verifier SDK docs