验证编排中哪一部分应由你的应用负责?

先在免费沙盒中跑通流程,再准备生产接入。

统计选择在本站复用,可随时关闭;账号关联另行同意。

验证编排中哪一部分应由你的应用负责?

一个小型 B2B 团队在接入托管身份引导时发现,同一个处理器里混杂了三件事:提供商给出的结论、这条消息的送达方式,以及业务是否应允许该用户执行操作。回调一返回 Approved,处理器就在同一步里授予了卖家权限。本文提出一张小型决策表来拆分这三项职责,并用已测试的合成 fixture 加以对照。你需要判断的是:由你的应用负责业务权限这一边界,是否足够契合你的引导任务,值得尝试沙箱集成。

curl https://gridzen.ai/console/api/quickstart/trial \
  -H 'Content-Type: application/json' \
  -d '{"task": "identity_onboarding", "scenario": "success"}'

接入指南

问题:一个状态,三个问题

Approved 这样的状态只回答了关于提供商证据的一个狭义问题。它不能说明消息是否真实、是否属于当前 tenant 和 subject、是否仍在截止期限内,更不能说明你的规则此刻是否允许该操作。根据 Bring Your Own Provider 指南,客户保留自己与提供商的关系,并授权一个明确界定的集成范围;GridZen 通过已批准的适配器和路由来规范化证据。当前 alpha 版本不接受在浏览器或请求体中传入任意提供商密钥。拥有公开 API 或可用账户,并不能证明你有权出售由此产生的数据。

拟议的决策表

这张表是拟议的应用设计,而非已实现的行为。 提供商证据:由提供商负责,依据你自己的账户和合同。你需要核对产品、国家、事件和允许的标识符是否与你记录的范围一致。 送达:由编排层负责。在 GridZen 的生产路由中,这包括验证签名通知、重新获取权威决定、处理截止期限以及事件去重。 业务权限:由你的应用负责。它需要明确的策略、策略版本、与 tenant 和 subject 的绑定,以及基于当前证据做出的决定。 由此得出的规则是:任何一行都不能自行升级为下一行。Approved 不是无条件的许可,端到端的真实客户操作仍未经验证。

假设场景与预期 fixture 输出

假设某团队在引导卖家,并在本地用 SQLite 运行可下载的 fixture。所有标识符都必须以 fixture- 开头。 创建:调用返回 mode synthetic_fixture、state simulated、session fixture-session,以及一个位于 example.invalid 的 hosted_link;同时返回 link_executable false 和 next send_real_provider_link_only_after_authorization。 事件 fixture-approved 且 policy 为 true:会话返回 status approved、deadline 60、permission_granted true、grant_count 1、live_permission_changed false、policy_version 1、allow_action true。 重放同一事件:输出完全相同,grant_count 仍为 1。 随后收到 Declined 更正:status 变为 declined,permission_granted 变为 false;grant_count 作为历史记录仍为 1。 在另一个超过截止期限仍处于待处理的会话中,以 now 61 调用 recover,返回 status expired、permission_granted false、grant_count 0、next review_or_authorized_provider_refresh、provider_polled false。 这些权限字段只是本地 fixture 记录,并非真实的业务许可。

由你的应用保留的失败处理

fixture 会返回明确的错误,而不是猜测。针对未知会话的事件返回 BINDING_MISMATCH;读取未知会话返回 SESSION_NOT_FOUND。source 不是 fixture_callback,或 mode 不是 synthetic_fixture 时,抛出 PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED。fixture 只接受合成回调,从不验证真实签名。 decide 和 revise_policy 调用要求明确的整数策略版本和明确的布尔值。版本过期时抛出 STALE_POLICY_VERSION;在截止期限内没有当前已批准的证据就做决定,则抛出 CURRENT_EVIDENCE_AND_EXPLICIT_APPROVAL_REQUIRED。 handoff 调用返回 verified false 和 next_action read_current_evidence_and_policy_before_explicit_decision。recover 只在本地让会话过期,不会轮询提供商;从提供商刷新是你已授权路由的职责。

已实现与未实现的内容

fixture 中已实现:SQLite 持久化、tenant 与 subject 绑定、事件去重、通过 Declined 撤销、本地过期,以及带版本的策略检查。 GridZen 真实托管身份试用中已有证据的部分:真实会话创建、签名通知、权威读取和过期。该试用面向符合条件、并单独接受 Didit 附加条款的美国和英国企业;每个已验证企业域名限 2 次请求,共享终身上限 10 次,仅限已确认的免费模块,不向客户收费。 尚未验证:新近获批的真实用户,以及任何客户业务操作。另请注意,匿名的三场景 HTTP 试用与可下载的四分支示例是不同的产物。 在任何真实使用之前,指南要求先批准数据保留、删除、访问日志、策略归属和运营恢复方案。

验收清单

- 记录提供商产品、国家、事件、允许的标识符、账户所有者、凭据处理方式和下游证据范围。 - 确认允许代表客户进行服务端处理。 - 运行 fixture,核对上述输出,包括重复事件时 grant_count 为 1 以及 provider_polled 为 false。 - 测试失败路径:输入缺失、上游错误、未知 ID 和过期策略。 - 检查追踪日志中是否泄露原始标识符。 - 将业务权限保留在你自己的规则中,采用明确且带版本的决定。 - 判断保存的沙箱请求是否契合你的任务;只有在此之后,再考虑真实试用。

运行已检查的模拟示例

下载并解压 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 辅助写作,并经过独立审稿。

另行体验三种沙盒结果 创建账号,继续项目接入

下载不等于运行成功;本地示例与在线沙盒分别测试。

接入你的应用

运行三种模拟结果 · 需要接入帮助

连接免费沙盒账号

号码基础有效性不证明持有权或送达,不提供短信验证码。业务放行由你的系统判断。