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.