{"family":"regulation","slug":"TDCA-PUB-CORPUS-045-IdentityTier-EN-身份可信等级认定条例英文人读版（十六条·V1.0·逐条对应中文）.md","filename":"TDCA-PUB-CORPUS-045-IdentityTier-EN-身份可信等级认定条例英文人读版（十六条·V1.0·逐条对应中文）.md","display_name":"TDCA-PUB-CORPUS-045-IdentityTier-EN-身份可信等级认定条例英文人读版（十六条·V1.0·逐条对应中文）.md","version":"V1.0","bytes":8722,"sha256":"c0af241a2a344ed8668015c424fc6dfdc374436e8313ea9fc5360c6909f33d09","sha256_16":"C0AF241A2A344ED8","content":"# Regulation on Identity Trust Level Determination\n\n**Version** V1.0 (effective 2026-10-11) ｜ **Revision** promoted from draft; articles unchanged\n\n> **Boundary for external use**: the title and the four tier names may be used publicly. It is **not permitted** to claim that this Regulation \"conforms to or is equivalent to\" eIDAS / NIST / ITU or any other external framework; correspondence with international levels is **reference only** and constitutes no claim of equivalence.\n\n---\n\n## Article 1 (Purpose)\n\nThis Regulation determines the **identity trust level of signals issued externally** — that is, it ascertains which trust level the \"trusted root device\" behind a signal occupies, and decides **recognition, admission and configuration** accordingly.\n\n## Article 2 (Basis)\n\nThis Regulation is made on two long-standing recorded positions: that the **root-node notification device token is the highest trusted root**; and the doctrine of **traceable root form**, which takes as its criterion whether \"legally admissible evidence of physical change of the anchoring root\" can be produced.\n\n## Article 3 (Terms)\n\n| Term | Definition |\n|---|---|\n| **Trusted root device** | The **root** that issues the signal (on our side, the root-node notification device; externally, an external hardware or institutional root) |\n| **Device uniqueness** | Whether that trusted root device **is the only one** |\n| **Physical-address mobility** | Whether that device's **physical address is retained** |\n| **Traceable root form** | The form of a root, judged by **whether legally admissible evidence of physical change of the anchoring root** can be produced |\n| **Trust information** | Information usable to determine identity trust level (see Article 12) |\n\nNote: The word \"**level**\" in this Regulation refers **exclusively to identity trust level** (strength of identity assurance). It has **nothing to do** with \"levels\" in the authorisation or compliance-review sense, and it is **not** the level of title registration (title registration has no levels).\n\n## Article 4 (Scope)\n\nApplies to **all signals entering this configuration network** (our side and external). It **does not concern** public searchability of registration instruments, which follows the separate registration-publicity position.\n\n---\n\n## Article 5 (Tiers — four)\n\nIdentity trust levels have four tiers: **Fixed-anchor ／ Movable-anchor ／ Named ／ Below threshold**.\n\nNote: The last tier is **not** called \"untrustworthy\" (to avoid pejorative characterisation); **\"anonymous\" does not mean \"has no identity\"**.\n\n## Article 6 (Determination)\n\nThe **sequence** of determination is:\n1. Take two attributes: **device uniqueness** and **physical-address mobility**;\n2. **Unique and address retained** ⟹ **Fixed-anchor**;\n3. **Unique but address movable** ⟹ **Movable-anchor**;\n4. **Not unique, but holds a registered real-name authenticated account** ⟹ **Named**;\n5. **IP only** ⟹ **Pending supplementation** (alert raised); **anonymous** ⟹ **Below threshold**.\n\nRules: **missing either attribute lowers the tier**; **tier may not be set on \"type of root\" alone**; **roots of the same type are not necessarily of the same tier** (evidence decides).\n\n*This article guards against: grading by what a device looks like rather than by evidence.*\n\n## Article 7 (Verification)\n\n1. Verification of the two attributes belongs to the **first gate** (passing root inspection and setting the level);\n2. Verification **precedes determination**; those failing verification are **not graded and may not enter the network**;\n3. The specific verification requirements (evidentiary method and credential form) are **determined separately**.\n\n## Article 8 (External hardware as anchor)\n\nAn external hardware anchor **must pass review and be graded case by case** — **no automatic same-tier treatment, no batch inclusion**. The core of review is whether that anchor can provide **legally admissible evidence of physical change of the anchoring root**.\n\n## Article 9 (Treatment of anonymity)\n\n1. Anonymous subjects are **not graded** and **not admitted** (consistent with the recorded admission rule that failure is a refusal);\n2. Clarification: \"below threshold\" here reads as \"**below the trust threshold**\", **not \"unlawful\"**; it does not conflict with the recorded visitor-state arrangement;\n3. \"Not admitted\" here refers **only to admission to the configuration network** (the second gate).\n\n## Article 10 (Standing of real-name accounts and IP)\n\n1. The **primary basis** for the Named tier is a **registered real-name authenticated account**;\n2. **IP alone does not constitute sole identification** — IP can be shared, dynamically assigned, proxied or address-translated — and is therefore **an auxiliary signal only**;\n3. A subject holding **only a unique IP without a real-name account** is **Pending supplementation**.\n\n*This article guards against: treating \"the same address\" as \"the same person\".*\n\n---\n\n## Article 11 (Alert and pending supplementation)\n\n1. **Criterion**: where the only trust information in the on-chain record is **IP** (all else missing) ⟹ **an alert is raised**;\n2. **Handling**: an alert is issued; the authority **does not proceed to grade** and **does not silently downgrade**;\n3. The alert **must carry a request for supplementary trust information** (it may not be empty); re-determination follows supplementation;\n4. Nature: **an alert is not \"below threshold\"** (it differs from anonymity), and **an alert is not a determination** — it is a **\"pending supplementation\"** transitional state.\n\n## Article 12 (Trust information)\n\n1. **Trust information** means information usable to determine identity trust level;\n2. **Primary basis**: device uniqueness and physical-address retention;\n3. A **registered real-name authenticated account** is the primary basis for the Named tier; **IP alone does not constitute sole identification** and is auxiliary only;\n4. The list and **minimum requirements** (what suffices to clear an alert) are **determined separately**.\n\n## Article 13 (Three-state handling)\n\n| State | Situation | Handling | Admission |\n|---|---|---|---|\n| **Gradable** | Trust information present | Grade by the four tiers | Per tier (both gates) |\n| **Pending supplementation** | IP only | Alert ＋ request for material | **Re-determine after supplementation** (no grading before) |\n| **Below threshold** | Anonymous | Not graded ＋ not admitted | **Not admitted** |\n\n---\n\n## Article 14 (Relation to existing institutions)\n\n1. This Regulation **fills a genuine gap only** (anchor grading ＋ recognition/admission ＋ compatibility maintenance);\n2. Matters already covered by existing institutions (admission, dual-track identity, authentication, identity binding, registration publicity) are **referenced only, not rewritten**;\n3. Correspondence with international level frameworks is **reference only**; **\"equivalent\" is not claimed**.\n\n## Article 15 (Recognition, admission and compatibility)\n\n1. **Recognition** of an external identity passes **two gates**: the **first** (passing root inspection and grading) and the **second** (loading the protocol and accepting institutional constraints on entry); the **two gates are not interchangeable**, default order **first then second**;\n2. The progression is **recognition → admission → compatibility**; **\"mutual recognition\" is possible, \"mutual re-engineering\" is not** — no interference in another's internal affairs, no change of primary keys; **authority to define tiers does not lie outside**;\n3. **Territoriality of rules**: a party entering another's system is governed by **that system's standard**; our standard is **not exported**;\n4. **Compatibility ≠ \"anchor borrowing\"** (that term is retired): compatibility means **we adapt proactively to the external access standard**, carried by a **bridge mapping** (internal code ↔ external code), with **primary keys remaining ours**;\n5. When the external standard changes, **compatibility changes with it** (a duty to follow).\n\n## Article 16 (Version and effect)\n\n1. This Regulation takes effect on **2026-10-11**, version **`V1.0`**;\n2. **Two editions**: this human-readable edition (**authoritative for meaning**) and the machine-readable edition; the two are produced together and cross-referenced by hash;\n3. **Amendment follows the append-only rule** — earlier instruments are not rewritten; old versions remain.\n\n---\n\n*This English edition corresponds article-by-article to the Chinese edition (V1.0, 2026-10-11); the Chinese edition is authoritative for meaning. Same version number; hashes cross-referenced; the machine-readable edition may not alter meaning in reverse.*\n"}