信任服务域
范围
本域定位
当前版本的信任服务域（Trust Services Domain, TSD）规定 ACT 协议中关键业务事件的统一存证、引用与验证规则，为授权、商业交互、支付执行和履约相关事实提供可追溯、可校验、可复核的信任基础。
本域范围
本域覆盖以下内容：
- 存证事件类型及其标识规则；
- 存证事件的标准载荷结构与最小必填要素；
- 存证事件的提交、签名、锚定引用和状态表示规则；
- 存证结果的查询、验证与争议处理所需的基础校验规则；
- 跨域事件引用关系及其一致性要求；
- 本域规定以 ACT Trust Chain 作为链上锚定基础设施，用于承载关键业务事件的摘要锚点，并支持跨机构场景下的不可篡改校验。
本域不规范以下内容：
- 具体底层账本、区块链、时间戳服务、数据库或第三方存证基础设施的内部实现；
- 各参与方内部审计平台、法务处理系统和业务运营系统实现。
可信存证价值说明
本域采用“链下完整记录 + 链上摘要锚定”的双层存证架构：链下保留完整业务事件明文与签名材料，链上仅写入防篡改摘要锚点，以同时满足业务可核验性、隐私保护与跨机构信任需求。
这一设计的核心目标，不是将原始业务数据集中交由第三方保存，而是在各方尽量自主保管原始数据的前提下，建立一套最小必要且可被共同验证的信任基础。当争议、审计或合规核查发生时，相关参与方再按照需求出示本方保留的原始记录，并与链上已预先锚定的摘要进行一致性比对，从而证明记录在事后未被篡改。
由于链上仅保存轻量化摘要而不保存全量业务明文，本域能够在控制存储成本、减少敏感信息外溢风险的同时，保留跨机构验证所需的关键证明能力。同时，链上锚点由多方共识维护，不依赖任何单一平台或单一参与方的日志背书，因此相较于单点日志系统更具中立性与公信力。基于这一机制，可信存证不仅服务于历史留痕，更是后续签名核验、因果链追溯和争议处理得以成立的共同基础。
本域组件列表与关系
组件总览
信任服务域由五个协议组件构成，它们共同完成从关键业务事件定义、链下存证记录生成、链上摘要锚定，到事后核验与争议处理支持的完整链路。
各组件的功能定位如下。
- TSD-ATT-EVT：存证事件类型定义。 负责定义 ACT 业务全链路中可以纳入可信存证的关键事件类型及其标准语义，作为本域后续存证处理的统一入口。
- TSD-ATT-OFF：链下存证记录。 负责规范参与方在本地生成、保存和管理完整存证记录的要求，使关键业务事件能够形成可追溯、可核验的一手证据载体。
- TSD-ATT-OCA：链上存证锚点。 负责规范从链下存证记录中提取最小必要摘要信息并写入 ACT Trust Chain 的要求，以形成不可篡改的链上时间锚点和跨机构验证依据。
- TSD-ATT-SVF：签名核验流程。 负责规范在争议处理、审计或合规核查场景下，对链下记录、签名材料和链上锚点执行一致性核验的标准步骤。
- TSD-ATT-DSP：争议处理流程。 负责规范各参与方基于链下存证记录、链上锚点及核验结论开展举证、核验和处理的流程框架。
核心对象与标识
为保持本域内部处理以及与其他域之间引用关系的一致性，信任服务域使用一组标准核心对象和标识来描述可信存证链路中的关键信息。本域核心对象及其作用可概括如下。
| 对象或标识 | 含义 | 主要产生位置 | 主要使用位置 |
|---|---|---|---|
| 存证事件 | 对 ACT 全链路关键业务节点的标准化事件表达，用于明确“什么事情可被存证”以及该事件的统一语义 | TSD-ATT-EVT | TSD-ATT-OFF、TSD-ATT-OCA，以及其他域在引用存证事件标识时的相关处理环节 |
| 存证记录唯一标识 | 用于唯一标识一条链下存证记录，并作为链下记录与链上锚点之间稳定绑定的主键 | TSD-ATT-OFF | TSD-ATT-OCA、TSD-ATT-SVF、TSD-ATT-DSP |
| 链下存证记录 | 由参与方按统一要求生成并本地保存的完整事件记录，通常承载事件内容、参与方信息、摘要值及签名材料，是争议处理时的一手证据对象 | TSD-ATT-OFF | TSD-ATT-OCA、TSD-ATT-SVF、TSD-ATT-DSP |
| 链上存证锚点 | 从链下存证记录提取的轻量化摘要凭证，用于在 ACT Trust Chain 上形成不可篡改的锚定记录 | TSD-ATT-OCA | TSD-ATT-SVF、TSD-ATT-DSP，以及跨机构核验场景 |
| 核验结论 | 对链下记录、签名材料和链上锚点执行一致性校验后形成的标准结果，用于判断记录是否完整、真实且未被篡改 | TSD-ATT-SVF | TSD-ATT-DSP，以及审计、合规核查等后续处理环节 |
| 争议处理请求 | 争议方围绕特定交易链路发起的举证或处理请求，通常关联具体业务事件、交易标识及争议说明 | TSD-ATT-DSP | TSD-ATT-DSP 及相关仲裁、核验处理环节 |
依赖与跨域引用
TSD-ATT-EVT 是本域的逻辑起点，用于定义哪些关键业务节点可以被纳入可信存证以及这些事件的统一语义。
TSD-ATT-OFF 依据 TSD-ATT-EVT 所定义的事件类型生成链下存证记录，并形成后续链上锚定和事后核验所依赖的主体证据对象。
TSD-ATT-OCA 进一步引用链下存证记录中的核心摘要信息，完成链上锚定，从而为链下记录提供跨机构可验证的防篡改依据。
TSD-ATT-SVF 同时依赖链下存证记录和链上存证锚点执行一致性校验，以形成标准化核验结论。
TSD-ATT-DSP 则以链下记录、链上锚点及核验结论为重要依据，组织争议场景下的举证、核验和处理流程。
上述关系共同构成“事件定义—链下留痕—链上锚定—事后核验—争议处理”的闭环链路。
信任服务域统一维护存证事件类型注册表；委托授权域、商业交互域和支付服务域仅在相关组件中引用事件标识符，不在各自域内重复定义事件结构或存证治理规则。
在跨域串联上，本域主要通过 intent_id、delegation_id、商户侧订单交易号、支付交易流水号和存证记录唯一标识等对象，建立从授权、交易确认、支付执行到争议处理的全链路证据关联关系。
TSD-ATT-EVT：存证事件类型定义
概述
TSD-ATT-EVT（Attestation Event） 用于定义 ACT 可信存证体系中的标准存证事件类型，统一委托授权域、商业交互域和支付服务域在关键业务节点上的事件标识与基础语义。
本组件在体系中承担全局事件类型注册表的作用，凡纳入可信存证范围的关键事件，应在本组件中统一登记和引用。
本组件仅定义可被存证的关键事件类型，不定义各业务域内部的临时状态、实现步骤或厂商私有中间事件。后续如新增需统一存证的关键业务节点，应继续沿用本组件的命名方式和注册方式扩展事件类型。
当前协议仅规定标准存证事件类型及其基础触发语义，不规定各事件的完整 event_body 结构、字段级校验规则、签名封装方式或链上锚定格式。
参与方及前置条件
TSD-ATT-EVT 的参与方包括委托授权域、商业交互域和支付服务域中产生关键业务事件的相关参与方，以及负责维护存证事件类型注册信息的管理方。
进入本组件前，应满足以下前置条件。
- 相关业务域应已明确本域可纳入可信存证范围的关键业务节点及其完成条件。
- 相关参与方应能够提供稳定的业务关联标识，以支持链下记录、链上锚点和争议处理过程中的跨域串联。
- 前述关联标识宜至少包括
intent_id，并可根据具体场景进一步包括delegation_id及各业务域交易标识。
基本要求
本组件中的标准事件类型命名空间采用 act:<domain>:<event> 形式，其中 domain 表示事件所属业务域，event 表示该域内的具体关键业务事件。
标准事件类型应具备稳定、可枚举、可跨域引用的特性，不应因单一实现差异改变其基础语义。同一业务事件可由不同参与方分别进行存证，但相关参与方在引用时应使用同一标准事件标识，并保持一致的触发语义理解。
存证事件的上报宜在业务事件完成后异步进行，不宜占用业务主流程路径，也不宜影响在线交易处理时延。
标准事件类型
当前版本纳入 TSD-ATT-EVT 的标准事件类型如下。
| 事件类型标识 | 所属域 | 触发时机 |
|---|---|---|
act:delegation:intent-created | ADD | 用户意图完成确认并形成可用于后续授权处理的意图结果时触发 |
act:delegation:delegation-issued | ADD | 意图授权凭证签发完成并进入 Active 状态时触发 |
act:delegation:delegation-suspended | ADD | 意图授权凭证被挂起时触发 |
act:delegation:delegation-resumed | ADD | 意图授权凭证由 Suspended 状态恢复为 Active 状态时触发 |
act:delegation:delegation-revoked | ADD | 意图授权凭证被吊销时触发 |
act:delegation:delegation-expired | ADD | 意图授权凭证到期失效时触发 |
act:commerce:decision-logged | CID | 买方智能体完成候选比较或决策留痕时触发 |
act:commerce:cart-confirmed | CID | 购物车确认完成并进入可发起支付的交易确认状态时触发 |
act:payment:transaction-completed | PSD | 支付交易完成并形成支付结果时触发 |
act:commerce:fulfillment-completed | CID | 商户侧订单履约完成时触发 |
上述事件构成当前版本可信存证的标准事件集合，覆盖授权形成与状态变化、商业确认、履约完成和支付完成等关键节点。
TSD-ATT-OFF：链下存证记录
概述
TSD-ATT-OFF（Offline Attestation Record）用于规定 ACT 可信存证体系中链下存证记录的标准结构、生成方式、保存要求与跨域串联规则，是各参与方对关键业务事件进行本地可信留痕的基础组件。
本组件承载需被证明的业务事件明文、参与方身份、链路关联标识、负载哈希与数字签名等内容，用于在不将业务明文上链的前提下，为后续链上锚定、签名核验和争议处理提供可验证的原始依据。
参与方及前置条件
TSD-ATT-OFF 的参与方包括在委托授权域、商业交互域和支付服务域中产生关键业务事件并承担存证责任的相关参与方，以及可受托提供记录保存或查询服务的存证服务提供方。
进入本组件前，应满足以下前置条件。
- 相关业务事件应已达到 TSD-ATT-EVT 中对应标准事件类型的触发条件，且事件发起方或记录生成方应能够取得稳定的业务关联标识，至少包括
intent_id，并可按场景进一步包括delegation_id、商户侧订单交易号和支付交易流水号。 - 记录生成方在创建链下存证记录前，还应具备可用的签名私钥、可解析的身份标识、公认的时间表示方式，以及符合要求的本地安全存储能力或受托存储安排。
基本要求
链下存证记录应以结构化数据模型生成，并应能够被后续的负载哈希计算、数字签名、链上锚定和核验流程稳定解析，因此记录一经生成不得进行无版本号的结构性变更。
链下存证记录应坚持“业务先完成、存证后异步上报”的原则，业务事件实际发生时间与存证记录创建时间应分别记录，以明确业务完成时点与存证落盘时点之间的差异。
链下存证记录应支持跨域串联、隐私保护、防篡改和可追责四项能力，即能够还原链路、避免敏感明文外泄、通过哈希和签名发现事后修改，并明确由谁对记录真实性负责。
链下存证记录结构
链下存证记录由六个部分构成：基础元数据、全链路串联与溯源标识、隐私与防推断要素、参与方列表、事件载荷 event_body、数字签名；实现方可在不破坏兼容性的前提下增加扩展字段。
除扩展字段外，各部分中的核心字段应具有稳定语义，并应与 TSD-ATT-EVT、TSD-ATT-OCA、TSD-ATT-SVF 的相关字段保持一致命名或一一映射关系，以避免链下、链上和核验阶段出现字段歧义。
基础元数据
基础元数据用于标识“这条记录是什么、属于哪个版本、业务何时发生、记录何时生成”，是每条记录的唯一身份证明，确保存证记录可被精确定位和跨版本解析。
| 字段语义 | 存在性 | 说明 |
|---|---|---|
| 存证记录唯一标识 | 必备 | 由记录生成方在创建时赋值，一经生成不应更改 |
| 事件类型标识 | 必备 | 应为 TSD-ATT-EVT 中已注册的枚举值 |
| 业务事件时间 | 必备 | 业务事件实际发生时间（非存证记录创建时间），由发起方在事件完成时记录 |
| 存证记录创建时间 | 必备 | 存证记录创建时间，可晚于业务事件时间，体现异步上报 |
| 存证记录结构版本号 | 必备 | 供未来版本兼容处理 |
记录生成方应分别记录业务事件时间和存证记录创建时间，不得以单一时间字段同时表达两者含义。业务事件时间和存证记录创建时间均宜采用 ISO 8601 UTC 格式表达，以便后续链上锚定、核验和争议处理保持一致。
全链路串联与溯源标识
全链路串联与溯源标识用于记录“这件事属于哪条业务链路”，将分散在不同参与方、不同时间点产生的孤立存证记录串联为一条完整的端到端因果证据链，确保争议时能够还原完整交易全貌。
| 字段语义 | 存在性 | 说明 |
|---|---|---|
| 意图标识 | 必备 | 全局业务流程主键，同一业务流程所有存证记录应携带相同意图标识 |
| 委托标识 | 条件必备 | 委托支付场景中应携带 |
| 商户侧订单交易号 | 条件必备 | 购物车确认之后的事件应携带 |
| 支付交易流水号 | 条件必备 | 支付执行之后的事件应携带，与 PSP 返回值一致 |
| 上游存证记录引用 | 可选 | 指向上游关联事件的存证记录唯一标识；当存在明确上游事件时宜携带，可用于构建端到端因果证据链 |
意图标识（intent_id）应作为跨 ADD、CID、PSD、TSD 的全局主串联键使用，其他标识符则作为不同业务阶段的辅助串联键。
当当前事件与上游关键事件之间具有明确因果关系时，记录生成方宜填写上游存证记录引用，以支持 TSD-ATT-SVF 在必要时执行递归式上游链路核验。
隐私与防推断要素
隐私与防推断要素用于解决“如何在不暴露明文的前提下保证记录不可篡改”，并通过引入随机盐值使每条记录的摘要值唯一且不可预测，以降低通过已知业务数据反推存证内容的风险。
| 字段语义 | 存在性 | 说明 |
|---|---|---|
| 随机盐值 | 必备 | 每条存证记录宜包含一个独立的高熵随机盐值，原始长度不低于 128 位，使用密码学安全随机数生成器生成。 |
| 负载哈希值 | 必备 | 对事件载荷与参与方列表按规范化方式处理后，并结合随机盐值计算得到的密码学摘要值；宜以 Base64url 编码保存。 |
| 哈希算法标识 | 必备 | 当前版本可支持 SHA-256 或 SM3；如后续版本支持其他算法，应通过该字段显式声明。 |
负载哈希计算步骤如下。
- 将事件载荷与参与方列表字段按 RFC 8785 JSON 规范化方案（JCS）处理为规范字节序列。
- 将规范字节序列与随机盐值原始字节拼接，拼接顺序为“规范字节序列 ∥ 盐值字节”。
- 对拼接结果执行 SHA-256 或 SM3 计算。
- 将计算结果以 Base64url 编码存储为负载哈希值。
记录生成方应确保每条链下存证记录使用独立随机盐值，不应在多条记录间复用同一盐值。
当事件载荷内容完全相同但随机盐值不同，重新计算出的负载哈希值也应不同，这一特性是本组件防推断设计的一部分。
参与方列表
参与方列表记录本次业务事件中涉及的各方主体身份，明确“谁参与了这件事、以什么角色参与”，以便争议发生时责任归属清晰可查。
| 字段语义 | 存在性 | 说明 |
|---|---|---|
| 参与方标识 | 必备 | 谁存证了这次事件 |
| 参与方角色 | 必备 | 以什么身份存证了这次事件；枚举值可包括：付款方智能体、收款方智能体、商户、支付服务方、委托人智能体、存证服务提供方 |
| 被代理方标识 | 可选 | 当该参与方是代理其他实体行事（例如平台型智能体代表某位具体用户完成操作）时，记录被代理方的标识 |
每条存证记录的参与方列表应包含至少一个角色，以确保每条记录都有明确的责任发起方可被追溯。角色枚举可包括付款方智能体、收款方智能体、商户、支付服务方、委托人智能体、存证服务提供方等受协议识别的参与角色。
当存在多方联合存证时，参与方列表可包含多个参与方条目，但其角色含义应保持清晰且不可重复歧义。
参与方标识应能够与本体系身份机制或外部受信身份机制对应解析，从而支撑后续签名公钥获取和责任归属判断。
事件载荷
事件载荷（event_body ）承载“这件事具体发生了什么”，是链下存证记录中保存当前业务节点关键明文与业务要素的核心部分，也是争议处理时核对交易细节的直接依据。
事件载荷的字段集合由事件类型决定，本组件仅定义该部分在链下存证记录中的位置、存在性与隐私约束，不在本节穷举不同事件类型的全部专属字段。
| 字段语义 | 存在性 | 说明 |
|---|---|---|
| 事件载荷 | 必备 | 承载当前关键业务事件的业务明文与必要业务要素，其字段由事件类型动态决定 |
| 预留扩展字段 | 可选 | 用于承载不影响核心可验证性的补充信息；不宜包含高敏感个人信息或原始支付账号等敏感数据 |
事件载荷不应包含以下敏感信息：委托人完整身份信息，如真实姓名、证件号、联系方式等个人身份信息，以及原始支付账号，如银行卡号、支付账户号等。
事件载荷可包含金额、货币、商品快照摘要、时间戳等非敏感业务要素；对于因隐私要求无法明文记录的字段，宜以对应字段的哈希摘要替代，并在字段语义命名中以“摘要”或“哈希”后缀加以标识。
数字签名
数字签名用于回答“谁对这条记录的真实性负责”，通过密码学签名将参与方身份与记录内容绑定，确保任何事后篡改均可被发现，并为链下存证记录提供不可抵赖的证据基础。
| 字段语义 | 存在性 | 说明 |
|---|---|---|
| 签名方标识 | 必备 | 格式同参与方标识 |
| 签名算法标识 | 必备 | 须为本协议支持的签名算法枚举值 |
| 签名值 | 必备 | Base64url 编码 |
| 签名覆盖范围说明 | 必备 | 覆盖：事件载荷、参与方列表、随机盐值、存证记录唯一标识、业务事件时间五个字段 |
每条存证记录应至少包含一个由存证记录发起方生成的签名，其他参与方可附加联合签名以增强证据效力。
签名方公钥宜从其身份标识对应的身份文档或受信注册信息中获取，以支撑后续 TSD-ATT-SVF 的验签流程。
负载哈希计算要求
为避免不同实现因 JSON 序列化差异而产生不一致摘要，记录生成方在计算负载哈希和执行数字签名时，应对相关对象使用 RFC 8785 JCS 进行规范化处理。
负载哈希的最小输入集合应包括 event_body 与参与方列表，且应与本条记录所携带的独立随机盐共同参与运算，以保证链下记录与链上锚点之间的唯一绑定关系和防重放特性。
同一条记录在不变更业务内容、参与方列表和盐值的前提下，重复计算负载哈希应得到完全一致的结果，否则视为实现不符合本组件要求。
存储与保留要求
链下存证记录可由各参与方自主存储，也可委托存证服务提供方代为存储，但无论由谁保存，记录内容的真实性责任仍由记录发起方或签名方承担，存证服务提供方不因代存而取得修改原始记录的权限。
链下存证记录宜按适用法律法规、争议处理周期和业务风险暴露期设置保留期限，且在保留期内应保证记录可检索、可导出、可校验，并具备防删除、防覆盖和备份恢复能力。
当协议版本升级时，已生成记录的结构和可验证内容不应被回写变更，解析方应依据记录中的结构版本号选择相应的解析逻辑，以保证历史证据长期有效。
TSD-ATT-OCA：链上存证锚点
概述
TSD-ATT-OCA（On-Chain Attestation Anchor）用于规定 ACT 可信存证体系中链上存证锚点的标准结构、提交要求与链上写入规则，是链下存证记录进入 ACT Trust Chain 的标准承接组件。链上存证锚点是基于链下存证记录提取的轻量化元数据凭证，链上不存放全量业务明文，而是承载最小必要索引、摘要哈希和签名相关信息，以在多方共识账本上提供不可篡改的跨机构可验证证明。
链上存证锚点通过负载哈希与对应链下存证记录唯一绑定，任何对链下原文的单方面修改，都会导致重新计算的哈希值与链上锚点不一致，从而无法通过后续核验。
参与方及前置条件
TSD-ATT-OCA 的参与方包括负责生成并提交链上锚点的各域参与方、可受托代为提交锚点的存证服务提供方，以及负责承载锚点写入与查询能力的 ACT Trust Chain 节点运营机构。
进入本组件前，应满足以下前置条件。
- 相关业务事件应已在 TSD-ATT-EVT 中完成标准事件类型判定，且其对应链下存证记录应已依 TSD-ATT-OFF 要求生成完成，并具备存证记录唯一标识、事件类型标识、业务事件时间、意图标识及负载哈希值等基础字段。
- 若由存证服务提供方代为提交链上锚点，存证服务提供方仅承担代提交或代查询职责，不因代办写入而取得对链下原始记录内容的修改权或真实性背书权。
基本要求
链上存证锚点应遵循“链下保存完整明文、链上保存最小必要摘要”的设计原则，以在保护商业隐私和控制链上存储成本的同时，保证跨机构可验证性。
链上锚点应能够与对应链下存证记录建立稳定的一一映射关系，其中存证记录唯一标识用于记录级绑定，负载哈希值用于内容级绑定，二者共同支撑后续的链上链下一致性核验。
链上锚点宜在业务事件完成并生成链下存证记录后异步提交，不应阻塞原有业务主流程，也不宜影响在线交易处理时延。
链上锚点应作为可信证明索引而非完整证据本体，发生争议或审计时，仍应以链下存证记录作为原始证据来源，再结合链上锚点完成完整性和不可篡改性验证。
存证锚点结构
链上存证锚点采用两层数据模型，即基础字段层与扩展字段层，其中基础字段层为所有锚点应具备的核心要素，扩展字段层用于适配特定部署场景的附加属性。
锚点宜采用 JWS Compact Serialization 形式封装后写入 ACT Trust Chain，封装后的头部应包含签名算法标识与签名密钥引用标识，载荷部分则承载本组件定义的锚点字段。
头部要求
JWS 头部应至少包含签名算法标识与签名密钥引用标识，以支持链上锚点来源身份识别和后续验签处理。
头部字段的具体命名和编码方式可由实现层在兼容 JWS Compact Serialization 的前提下确定，但不应影响锚点载荷的稳定解析和跨机构互认。
载荷字段
JWT 载荷包含以下字段。
| 字段语义 | 存在性 | 说明 |
|---|---|---|
| 存证记录唯一标识 | 必备 | 与链下存证记录的唯一标识严格一致，实现两者的唯一绑定 |
| 协议版本号 | 必备 | 存证记录结构版本号 |
| 事件类型标识 | 必备 | 应为 TSD-ATT-EVT 中已注册的枚举值 |
| 业务事件时间 | 必备 | 与链下存证记录的业务事件时间一致，宜采用 ISO 8601 UTC 表达 |
| JWT 签发时间 | 必备 | 本锚点提交至链上的时间 |
| 意图标识 | 必备 | 全局业务流程追踪标识 |
| 委托标识 | 条件必备 | 委托支付场景中应携带 |
| 商户侧订单交易号 | 条件必备 | 购物车确认之后的事件应携带 |
| 支付交易流水号 | 条件必备 | 支付类事件应携带 |
| 提交方身份标识 | 必备 | 提交本锚点的参与方身份标识 |
| 负载哈希值 | 必备 | 与链下存证记录中负载哈希值完全一致，宜采用 Base64url 编码，是两者唯一绑定的密码学依据 |
| 哈希算法标识 | 必备 | 当前版本可支持 SHA-256 或 SM3，并应与链下记录中的哈希算法声明保持一致 |
| 隐私通道标识 | 必备 | ACT Trust Chain 的隐私通道标识，用于多方数据隔离 |
| 预留扩展字段 | 可选 | 用于适配特定场景的附加属性，不宜包含业务明文或个人身份信息 |
结构映射要求
链上锚点中的存证记录唯一标识、协议版本号、事件类型标识、业务事件时间、意图标识、委托标识、订单交易号、支付交易流水号和负载哈希值，应与对应链下存证记录中的相关字段保持一致或可一一映射。
提交方身份标识用于标识“是谁将该锚点提交到链上”，而不当然等同于链下存证记录中的全部参与方集合，因此在发生争议时仍应回溯链下记录中的参与方列表和数字签名信息进行完整核验。
扩展字段的引入不应破坏基础字段层的稳定语义，也不应导致不同机构对同一锚点的核心可验证内容产生不同解释。
技术要求
ACT Trust Chain 节点运营机构宜提供标准链上锚点写入接口，用于接受以 JWS Compact Serialization 形式封装的锚点提交请求，并返回可用于后续查询和核验的链上受理结果。
相同存证记录唯一标识的锚点请求应视为幂等操作，节点应拒绝重复提交，并在响应中返回已存在锚点的区块高度或等效链上定位信息，以防止同一事件被重复锚定。
链上数据结构不宜存放业务明文、敏感个人信息或原始支付账号等高敏感要素，宜仅包含脱敏哈希、匿名化索引及不包含敏感内容的扩展位，以延续本体系“链下明文、链上摘要”的隐私保护原则。
当链下记录的哈希算法、版本号或关联标识发生协议级扩展时，链上锚点实现应保持对既有版本的兼容解析能力，不应因新版本上线而破坏历史锚点的可验证性。
链上锚点一经写入，不应被覆盖式修改；如后续因业务补充需要新增关联信息，宜通过新增链上记录或扩展字段的兼容方式实现，而不应回写既有核心锚点内容。
TSD-ATT-SVF：签名核验流程
概述
TSD-ATT-SVF（Signature Verification Flow）用于规定 ACT 可信存证体系中对已存证事件记录进行事后密码学核验的标准步骤，供各参与方在争议处理、合规审计和跨机构核验场景中统一调用。
本组件用于验证链下存证记录的完整性、签名有效性以及链上链下一致性，从而判断某条存证记录是否可被认定为未经篡改且可归责的可信证据。
参与方及前置条件
TSD-ATT-SVF 的参与方包括发起核验的业务参与方、负责提供链下存证记录的记录持有方、提供代存或代查服务的存证服务提供方，以及提供链上锚点查询能力的 ACT Trust Chain 节点运营机构。
进入本组件前，应满足以下前置条件。
- 核验发起方应能够取得待核验的链下存证记录全文，或至少取得其存证记录唯一标识并通过本地存储或存证服务提供方查询接口获取对应完整记录。
- 核验发起方还应能够获取签名方身份标识对应的当前有效公钥或历史有效公钥，并具备查询链上锚点的能力，否则无法完成完整核验闭环。
基本要求
签名核验应遵循“先链下、后链上，先摘要、后验签，先当前记录、后上游链路”的顺序化核验思路，以避免在基础一致性未确认的情况下直接进入更高成本或更复杂的后续核验步骤。
核验过程中重新计算负载哈希时，应使用与 TSD-ATT-OFF 一致的规范化规则，即对事件载荷与参与方列表按 RFC 8785 JCS 进行规范化处理后，再按既定算法重新计算摘要值。
任一步骤若已得到足以否定记录可信性的明确失败结论，核验流程可终止并返回对应错误码，而不必继续执行后续步骤。
若仅因外部依赖不可用而无法完成核验，例如链上查询超时或当前有效公钥无法获取，则应返回“暂不可得结论”或“公钥不可用”类结果，而不应将其误判为记录已被篡改。
核验步骤
第一步：取回链下存证记录
核验发起方应根据存证记录唯一标识从链下存储中取回完整存证记录；若记录由存证服务提供方 代存，则应通过存证服务提供方查询接口获取。
取回的链下存证记录应至少包含基础元数据、全链路串联与溯源标识、参与方列表、事件载荷、负载哈希值和数字签名等核验所需核心内容，否则不满足进入后续核验流程的条件。
第二步：获取签名方公钥
核验发起方应解析数字签名数组中每个签名元素对应的签名方身份标识，并据此获取其用于验签的公钥材料。
对于 DID 格式的身份标识，公钥宜从该身份标识对应的 DID 文档中获取；对于在 ACT Trust Chain 信任注册表中登记的机构标识，公钥宜从信任注册表中查询获取。
核验方宜进一步验证所获取公钥在业务事件时间点上的有效性，包括是否已轮换、是否失效以及是否仍处于可用于历史签名核验的有效时间范围内。
若无法获取签名方当前有效公钥或可用于历史核验的有效公钥，则应终止密码学验签并返回 PUBLIC_KEY_UNAVAILABLE。
第三步：重新计算并比对负载哈希
核验方应对链下存证记录中的事件载荷与参与方列表按 RFC 8785 JCS 规范化后，结合记录中保存的随机盐值，按照 TSD-ATT-OFF 规定的算法重新计算负载哈希。
重新计算得到的负载哈希值应与链下存证记录中存储的负载哈希值逐字节一致；若不一致，则说明本地记录内容或其结构化要素可能已发生变更。
当本地重新计算结果与记录内保存的摘要不一致时，核验流程应终止并返回 PAYLOAD_HASH_MISMATCH。
第四步：密码学验签
核验方应使用第二步获取的对应公钥，对数字签名数组中的每个签名元素逐一执行密码学验签。
验签时应确保签名覆盖范围与 TSD-ATT-OFF 中声明的覆盖对象一致，至少包括事件载荷、参与方列表、随机盐值、存证记录唯一标识和业务事件时间。
任一签名元素验证失败时，应返回 SIGNATURE_INVALID，并宜附带失败签名对应的签名方身份标识，以便后续定位责任主体或排查实现差异。
若记录包含多个签名，验证方可根据业务规则决定是否要求全部签名都成功验证，但至少应保证被认定为有效的签名集合满足本场景的最低可信要求。
第五步：链上锚点核验
核验方应向 ACT Trust Chain 查询该存证记录唯一标识对应的链上锚点，并确认该锚点已存在。
若锚点存在，核验方还应比对链上锚点中的负载哈希值与第三步本地重新计算得到的负载哈希值是否完全一致。
链上查询宜设置超时时间为 30 秒，超时后宜重试最多 3 次；若最终仍超时，则应返回 ANCHOR_QUERY_TIMEOUT，而不应将其判定为 VERIFIED 或 CHAIN_HASH_MISMATCH。
若锚点存在但链上链下哈希值不一致，则应返回 CHAIN_HASH_MISMATCH；若链上不存在对应锚点，则应返回 ANCHOR_NOT_FOUND。
第六步：上游因果链递归核验
若当前链下存证记录中存在上游存证记录引用字段，核验方可对其指向的上游关联存证记录递归执行第一步至第五步，以逐级构建完整的端到端因果证据链。
该步骤为可选步骤，但在跨域争议处理中具有较高价值，因为它能够把单点事件核验扩展为链路级事实还原，从而支持对授权、确认、支付、履约等关键节点进行整体一致性审查。
第七步：返回核验结论
在完成前述步骤后，核验方应返回标准化核验结论，以保证不同机构和不同实现之间对核验结果的理解一致。
核验结论不应由自由文本随意定义，而应优先使用本组件规定的标准枚举值，以支撑后续争议处理、审计留痕和系统间自动化对接。
核验结论
| 核验结论 | 含义 |
|---|---|
VERIFIED | 签名有效，链上链下一致，记录完整未篡改。 |
PAYLOAD_HASH_MISMATCH | 本地重新计算的摘要与存证记录中存储的摘要不一致，本地记录可能已被篡改。 |
SIGNATURE_INVALID | 签名验证失败，宜附带失败的签名方身份标识。 |
CHAIN_HASH_MISMATCH | 链上锚点存在，但链上摘要与本地重新计算结果不一致，链上或链下可能存在篡改。 |
ANCHOR_NOT_FOUND | 链上不存在对应锚点，存证可能未成功上链。 |
ANCHOR_QUERY_TIMEOUT | 链上查询超时，当前无法形成最终核验结论。 |
PUBLIC_KEY_UNAVAILABLE | 无法获取签名方当前有效公钥或用于历史核验的有效公钥，可能存在密钥轮换或解析失败情况。 |
当核验结果为 VERIFIED 时，仅表示该记录在密码学层面和链上链下一致性层面通过核验，并不当然等同于相关业务行为在合同、监管或争议裁决意义上已经被最终确认无争议。
当核验结果为非 VERIFIED 时，后续处理方宜结合失败类型分别采取补充举证、重新查询、要求补交记录或进入争议处理流程等措施，而不宜将所有失败结果作同一处理。
技术要求
核验实现应与 TSD-ATT-OFF 和 TSD-ATT-OCA 保持一致的数据处理规则，特别是在 JCS 规范化、哈希算法选择、Base64url 编码和字段映射方面，不应因实现差异导致同一记录在不同机构处产生不同核验结论。
对于采用 JWS Compact Serialization 封装的链上锚点，实现方在解析和验签时应正确处理头部、载荷和签名三部分的分离与校验，并确保算法声明与实际验签算法一致，以降低算法替换或解析歧义带来的风险。
核验系统宜保留过程性审计日志，包括核验时间、核验发起方、所使用公钥来源、链上查询结果和最终核验结论，以便在后续争议处理中还原核验过程。
当签名方发生密钥轮换时，核验实现应依据业务事件时间与密钥有效时间段进行比对，在业务事件时间落入旧密钥有效期内时继续允许使用旧密钥完成历史签名核验，以保证历史证据长期可验证。
TSD-ATT-DSP：争议处理流程
概述
TSD-ATT-DSP（Dispute Resolution）用于规定 ACT 协议交易中发生争议时的处理流程框架，明确各参与方如何基于链下存证记录和链上锚点开展举证、核验与处置。
本组件是可信存证体系的重要应用出口，存证机制的实际价值主要通过争议处理场景得以兑现。
本组件仅定义流程框架和基本要求；最终仲裁的决策权归属，例如平台仲裁、行业仲裁委员会或司法机构，由各参与方在入网协议或相关法律安排中另行约定，不属于本协议规范范围。
参与方及前置条件
TSD-ATT-DSP 的参与方包括争议申请方、被申请方或其他相关交易参与方、负责受理并组织核验的处理方或仲裁方、提供链下存证记录代存或代查服务的存证服务提供方，以及提供链上锚点查询能力的 ACT Trust Chain 节点运营机构。
进入本组件前，应满足以下前置条件。
- 争议事项宜已经具备可用于定位业务链路的关联标识，例如意图标识、委托标识、商户侧订单交易号或支付交易流水号中的一种或多种，以支持相关存证记录的检索与串联。
- 相关参与方应能够提供本方留存的完整链下存证记录，或能够依据存证记录唯一标识通过本地存储或存证服务提供方查询接口取回对应记录。
- 处理方还应具备查询 ACT Trust Chain 链上锚点的能力，并能够获取签名方身份标识对应的有效公钥材料，以完成链上链下一致性核验和签名有效性核验。
- 如无法取得必要的链下记录、链上锚点或签名核验所需公钥材料，则本组件可进入受理和举证阶段，但可能无法完成完整的标准化核验闭环。
基本流程
争议处理宜按“争议申请—各方举证—存证核验—形成处置结论”的顺序进行，以保证处理路径清晰、责任边界明确和核验依据统一。
争议方应提交争议类型、用于定位业务链路的关联标识及争议描述；相关参与方应在规定时限内提交本方链下存证记录；处理方应对争议链路上的存证记录执行 TSD-ATT-SVF 核验，并将核验结论作为处置的重要依据。
仲裁方或处理方在综合各方举证材料与核验结论后作出处置决定；若某参与方未能在规定时限内提供存证记录，或其存证记录核验结论为非 VERIFIED，处理方可将此作为对该方不利的推定依据之一。
| 流程阶段 | 主要要求 |
|---|---|
| 争议申请 | 争议方提交争议类型、用于定位业务链路的关联标识及争议描述 |
| 各方举证 | 各相关参与方在规定时限内提交本方链下存证记录 |
| 存证核验 | 处理方对争议链路上的存证记录执行 TSD-ATT-SVF 核验，核验结论作为重要依据 |
| 处置结论 | 处理方综合举证材料与核验结论作出处置决定 |
处理要求
争议处理应坚持“以原始记录为基础、以密码学核验为准绳、以链上锚点为防篡改依据”的基本原则，避免仅依赖单方口头说明、平台日志截图或不可核验的二次整理材料形成结论。
在处理过程中，链下存证记录是原始证据来源，链上锚点用于证明其摘要已被事先锚定且不可事后篡改，签名核验流程则用于确认记录完整性、签名有效性与链上链下一致性。
详细的争议分类、举证时限、补证机制、证据优先级和最终裁决规则可在后续协议版本或配套治理文件中进一步完善，本章保持轻量级流程设计即可。