@decidio /验证
独立的，零依赖的决定授权收据验证器。 验证密封收据的签名、内容绑定和链单 离线-没有Decidio依赖． 你只能用供应商的软件来验证的记录并不是真正拥有的；这就是为什么“客户拥有记录”这句话是真的，而不是夸夸其谈。
# A receipt from Decidio's hosted service: no flag needed - the trust anchor is built in.
npx @decidio/verify receipt.json
npx @decidio/verify r1.json r2.json r3.json # each + the chain order (one issuer end to end)
# Any other issuer (a self-hosted Decidio): pin its DID yourself - take it from that host's
# <api>/api/did, never from the receipt. An explicit --issuer always wins over the built-in anchor.
npx @decidio/verify --issuer did:key:z6Mk… receipt.json
# A structural check only is a named choice, and its verdict carries the UNPINNED warning:
npx @decidio/verify --allow-unpinned receipt.json
每次运行首先打印其信任锚 -判决被钉在发行人身上，以及在哪里
来自(--issuer，或者 built in: Decidio hosted service, decidio-api.onrender.com）. 这个
内置列表(KNOWN_ISSUERS（导出）包含一个条目：托管服务的颁发者，
did:key:z6MkmLGeR5NjJ87a1yU5ygqju49CtnUrt38esqM54Y9tXnKq，出版于
https://decidio-api.onrender.com/api/did． 没有 --issuer，即指定任何其他开票人的收据
拒绝了（出口2）的补救办法：收据自己的 issuer Field是一种主张，而不是信任的锚，
所以验证者永远不会锁定它。这个列表是故意的 不 包括验证工具包
已发布的示例发行者——它的私钥是公开的，因此信任它可以验证伪造。
VALID是什么意思（在编写退出代码之前先阅读）
验证回答两个独立的问题，其中只有一个是免费的：
- 该文件内部是否一致且未被修改？ 回答与
--allow-unpinned. - 是由您期望的一方签发的吗？ 由信任主播回答-内置的决定
发行人，或者你用的那个
--issuer.
由……签字的收据 自发的关键 内部是一致的，所以是未固定的支票
报告 VALID 并退出 0 ——没错，因为没人问 谁 签署了它。这是
为什么命令行从来不会脱机运行，除非你说 --allow-unpinned一份完全伪造的外部审查
这样的收据和出口密码表明可以。一个
锻造pair甚至报告一个完整的链：一个链证明链接成立，而不是起源。所以
decidio-verify receipts/*.json && promote 只促进由信托锚发出的收据
打印运行;错误的签名者退出非零，将问题命名为颁发者，而不是将责任归咎于
内容。
import { verifyReceipt, verifyChain } from "@decidio/verify";
const r = verifyReceipt(vc); // { valid, issuer, contentBound, recordId, reason? }
它检查什么（脱机，仅使用收据中的公共DID）
- 内容绑定 ——re-derives
sha256((prevHash||"") + recordCanonical)确认它等于带符号的contentHash，因此签名提交到实际内容（防篡改）。 - 签名 -验证W3C数据完整性证明(
DataIntegrityProof, cryptosuiteeddsa-jcs-2022， Ed25519 viadid:key)超过整个收据：签名输入为SHA-256(JCS(proof options))紧随其后的是SHA-256(JCS(receipt without proof)),每 数据完整性EdDSA加密套件v1.0 §3.3。 验证只需要SHA-256， Ed25519， base58和RFC 8785 -没有JSON-LD，没有上下文 抓取，没有DID解析，没有网络。 在2026-08-04之前密封的收据在名称下带有预标准的Decidio格式eddsa-2022;这些文件会被拒绝，并有明确的理由，不会被报告为被篡改。 - 链 （
verifyChain) -每张收据prevHash链接到先验contentHash，并且每个收据都独立验证。
签名+内容+链验证 离线． 撤销/状态是一个单独的、网络绑定的检查——收据是篡改证据，而不是活动检查。
一个政策检查，证明与印章(verifyCheckEntry）
一份代理收据的密封记录清楚地写明了保单的名称 决定 请求
（authority.decidingPolicies：每一个阻止它的政策，或者每一个把它发给一个人的政策，
否则——每一项通过的政策——只有第一个)，并承诺 每一个 检查它的策略
只有一个根(authority.checkCommitment、算法 decidio.check-merkle.v1)两者皆非
哪些政策，多少政策。Decidio将他们可能看到的每张支票——事实、一份盐和一份
证明——任何人都可以根据收据离线确认：
import { verifyCheckEntry } from "@decidio/verify";
const r = verifyCheckEntry(vc, { entry, salt, proof }, "did:key:z6Mk…"); // { valid, policyId, result, reason? }
它首先验证收据（当您通过发行者时固定），然后折叠条目的叶子
SHA-256(salt ‖ JCS(entry)) -通过其证明的五个兄弟哈希，每个节点
SHA-256(0x01 ‖ min ‖ max)，并将结果与密封的根进行比较。32个叶子是
条目和记录的键填充，排序，所以证明的长度和位置没有说明如何
检查了许多政策。有效条目证明了一个策略对该请求的结论
没有其他的。在Decidio承诺其支票之前密封的收据没有根和
是这样报道的。
整张支票，证明是完整的(verifyCheckComplete）
条目证明它在承诺中；它不能证明没有其他条目被遗漏。为此, 决定手 工作空间的管理 -谁可以看到每一个政策，所以是显示每一个条目- 记录的 完整性的关键：该记录的填充键，而不是其他记录的填充键。有了它, 完整的列表将重建密封根目录：
import { verifyCheckComplete } from "@decidio/verify";
// `check` is the admin's answer from GET /api/records/:id/check: { entries, completenessKey, … }
const r = verifyCheckComplete(vc, check, "did:key:z6Mk…"); // { valid, count, policyIds, reason? }
它验证收据，计算每个条目的叶子，加上32−k的pad
HMAC-SHA256(completenessKey, JCS([i])) 对于I = 0,1，…，对32个叶子进行排序并重建树。
只有当根是密封的根时，它才有效：条目被遗漏、添加、给出两次或更改；
或者一个错的键，根键就会移动。键告诉它的持有者有多少个策略检查了请求，
这就是为什么迪迪奥只把它交给行政部门。一个只有 verifyCheckEntry
与之前完全一样检查相同的收据条目：对它来说，一个pad只是一个兄弟散列。
verifyCheckEntry 和 verifyCheckComplete 只存在于这个TypeScript包中；Python验证器
还没有。
奇偶校验
Python验证器进入 decidio[verify] （python -m decidio.verify）. 两个验证器都接受 相同 真正的Decidio密封-在跨语言一致性套件中得到验证。零依赖 node:crypto (TS) / cryptography (Python)。