提供方交接除了状态还应携带什么？

问题：没有上下文的状态

假设你的处理程序收到一个回调，其中只有状态 Approved 和会话 ID。如果仅凭这些就采取行动，可能出现三种失败。第一，绑定到其他租户或用户的回调可能解锁错误的账户。第二，迟到的回调可能复活产品早已放弃的会话。第三，一次批准可能授予策略此后已经关闭的操作。你面临的决定是：交接记录必须包含哪些内容，每项检查由谁负责。fixture 回答了其中一部分，其余部分由你的应用回答。

拟议的交接契约（应用设计，并非 GridZen 已实现）

我们建议每条交接记录包含以下内容： 1. 绑定：session、tenant 和 subject，在创建会话时固定。 2. 期限：一个绝对过期时间，过期后任何状态都不能授予权限。 3. 调用方策略：policy_version 和 allow_action 标志，二者均由你的应用掌控。 4. 证据状态：规范化后的状态，以及是否已授予权限、共授予了多少次。 5. 下一步：明确的指令，绝不是隐含的权限。 这是一项设计建议。GridZen 的 Bring Your Own Provider 指南说明，当前 alpha 版本不接受在浏览器或请求体中提交任意提供方密钥。指南还说明，每个提供方产品都需要各自经批准的适配器和范围审查，线上路由是否可用需要另行确认。

fixture 实际实现的内容

Identity 类把每个会话存入 SQLite，列包括：id、tenant、subject、status、deadline、granted、grants、policy_version 和 allow_action。 create 方法会拒绝任何不以 fixture- 开头的标识符，也会拒绝 1 到 3600 秒范围之外的 timeout。 event 方法的行为如下： - 只接受 mode 为 synthetic_fixture 且 source 为 fixture_callback 的事件。其他输入会抛出 PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED，因为这里不存在真实的签名验证。 - 当 tenant 或 subject 与存储值不一致时，抛出 BINDING_MISMATCH。 - 忽略重复的事件 ID。 - 当 now 达到或超过 deadline 时，将会话标记为过期。 - 把无法识别的状态映射为 unknown。 - 只有在状态为 Approved、policy 为 True 且 allow_action 开启时才授予权限。 handoff 方法返回当前记录，其中 verified 为 false，next_action 为 read_current_evidence_and_policy_before_explicit_decision。decide 方法要求 policy_version 匹配、明确批准、状态为 approved 且在期限内，并且 allow_action 开启。若 policy_version 不匹配，则抛出 STALE_POLICY_VERSION。

假设场景与预期输出

一个假设的交易平台为卖家办理入驻。以下步骤使用 fixture 的默认值。 1. 创建会话。预期输出包含 session fixture-session、位于 example.invalid 下的 hosted_link、link_executable false，以及 next 为 send_real_provider_link_only_after_authorization。 2. 发送事件 fixture-approved，policy 为 True。预期输出为 status approved、deadline 60、permission_granted true、grant_count 1、live_permission_changed false、policy_version 1、allow_action true。 3. 重放同一事件。输出完全相同，grant_count 仍为 1。 4. 随后发送状态为 Declined 的事件。输出显示 status declined、permission_granted false。grant_count 仍为 1，因为它记录的是历史。 5. 在一个没有收到任何回调的新会话中，以 now 61 调用 recover。输出显示 status expired、permission_granted false、grant_count 0、next 为 review_or_authorized_provider_refresh、provider_polled false。 6. 错误处理如下：对未知会话发送事件返回 BINDING_MISMATCH；读取未知会话返回 SESSION_NOT_FOUND。

由调用方负责的失败处理

fixture 只负责给出失败的名称，每种失败意味着什么由你的应用决定。 - BINDING_MISMATCH：视为安全事件，不要重试。 - STALE_POLICY_VERSION：重新读取策略，然后重试决策。 - 已过期：转入人工审核，或创建一个新的已授权会话。 - 状态为 unknown：暂缓处理，等待审核。 recover 方法只在本地使会话过期，从不轮询提供方。从真实提供方刷新证据是另一项需要授权的独立集成。 fixture 中的授权只是本地记录，不是真实的业务权限，live_permission_changed 始终为 false。在真实的托管身份试用中，GridZen 会验证签名通知并重新获取权威决策。但从新批准的用户到客户执行业务操作的完整端到端流程，目前仍未得到验证。

验收清单

从 fixture 转向沙箱申请之前，请逐项确认： - 每条交接记录在创建时保存 session、tenant、subject 和 deadline。 - tenant 或 subject 不匹配时予以拒绝并记录日志，不重试。 - 重复事件不会增加 grant_count。 - 期限之后到达的回调不能授予任何权限。 - 批准之后的 Declined 事件会撤销 permission_granted。 - 策略变更会重置授权，过期的 policy_version 会被拒绝。 - 没有任何代码路径把 verified false 当作权限。 - 任何线上使用之前，保留、删除、访问日志和策略归属均已获批。 如果你的任务需要已确认路由之外的提供方或国家，不要假定已获支持，请先申请范围审查。

运行已检查的模拟示例

下载并解压 https://gridzen.ai/downloads/verification-delivery.zip，进入 verification_delivery，用 Python 3.10+ 运行。此本地示例不联网；独立身份实验请使用新的数据库。

python3 delivery.py identity --db /tmp/gridzen-article-fixture.sqlite

来源与范围

https://gridzen.ai/guides/bring-your-own-provider/ https://gridzen.ai/guides/current-capabilities/ 依据已检查的来源快照与本地模拟；建议的业务规则属于设计建议，不代表已证明的生产行为。内容使用 AI 辅助写作，并经过独立审稿。