身份的集成点不是客户端小组件。ARC 在运行时边界把凭据解析为调用者上下文，再在构造 session 数据视图与应用策略时使用该上下文。
建议顺序
- 阅读 调用者上下文，弄清
CallerInfo含什么、什么会失败关闭。 - 阅读 Session 数据 与 session 视图，弄清调用者能收到哪些路径。
- 通过 session 的
/user存放持久 per-user 数据（仅在运行时为你的 blocklet scope 启用时再使用/space）。 - 把授权留在 provider 与运行时策略中。AUP 或 Web Device 只负责呈现与路径绑定。
- 需要协议或 SDK 本身时，先看 ARC 中的 DID Connect 了解运行时接缝，再外链到 DID Connect 上游材料获取协议细节。
在 ARC 里 “集成” 指什么
| 层 | 你的工作 | 运行时的工作 |
|---|---|---|
| 凭据 | 不要在 UI 消息里发明替代鉴权头 | 把 cookie / Bearer / access key 解析为 CallerInfo |
| Session 视图 | 把 UI 与逻辑绑定到 /user、/tmp 与已声明挂载 | 仅为已解析调用者构建 SessionUserAFS |
| Membership | 不要信任客户端自选的 instance 角色 | 仅在服务端提供 instance 上下文时叠加 membership |
| 存储 | 经受支持的 AFS 路径挂载或使用 DID Space | 强制角色前缀、隔离与写入门控 |
实用规则
- 优先使用 session 路径，而不是在应用代码里重建
spaces/<did>/blocklets/...。 - 优先使用服务端解析的调用者字段，而不是「看起来像 DID」的表单字段。
- UI 验收优先本地运行 blocklet；离线数据检查使用隔离的
arc space --root-path（检查本地空间）。 - 不要把历史 DID Connect 管理 UI 包装成新工作的 ARC 稳定扩展面。
本页不覆盖
端到端 passkey 引导界面、OAuth provider 配置、远程多租户开通，以及 membership 管理 API，需要各自版本化的合同与示例。本节止于当前源码已实现的已验证交接。