BLUEPRINT

第 7 章 Open Questions（未决议题）

本章列出在当前协议层暂不决定、留待实现侧 spec、后续协议版本或独立 ADR 解决的开放问题。每条议题都对应 design.md 第 10 节的相同条目，可在后续任务 8 完成 open-questions.md 归档时进一步细化。

这些议题不是 FayID 协议的缺陷，而是有意保留的扩展点。它们的共同特征是：在协议层过早决定会限制实现自由度，或会因生态演进而需要调整。

1. 具体哈希 / 签名 / KDF 算法

议题：协议层仅给出候选（Ed25519 / HKDF-SHA256 / BIP-39），最终选型留待实现 spec 决定。

影响范围：跨实现互操作性、密码学审计

解决方向：在实现 spec 中固定算法，并伴随版本化（如 fayid/dyn/v1、fayid/gmc/v1 中的 v1 后缀）。未来升级算法时通过新版本号实现共存。

2. Dynamic Code 时间窗长度

议题：协议层仅要求 Dynamic Code 存在 expiresAt，具体长度（分钟级 / 小时级）由实现策略决定。

影响范围：用户体验、隐私强度、轮换频率

解决方向：实现侧根据场景定制。高安全场景使用短窗口（如 5 分钟），常规场景可放宽到小时级。

3. Verification Code 校验失败的限速阈值

议题：VERIFICATION_RATE_LIMITED 的窗口宽度、失败次数阈值、退避策略均为实现侧决策。

影响范围：抗暴力破解、用户体验

解决方向：参考行业标准（如指数退避），由实现 spec 给出默认值。

4. Authorization Grant 默认 TTL 与续期模型

议题：协议层只要求 expiresAt 显式存在；续期 / 滑动过期 / 短 TTL + 刷新令牌等具体模型留待实现 spec。

影响范围：用户体验、安全性、与传统鉴权来源的互操作

解决方向：实现 spec 中可能引入 RefreshGrant 类型；亦可针对不同 legacySourceKind 应用差异化 TTL。

5. Human ID 撤销语义

议题：当前协议层 Human ID 不进入 REVOKED 状态。Mnemonic 泄露后的"补救"路径（如 Human ID 重发、信誉迁移）超出本规范范围。

影响范围：灾难恢复、信誉连续性

解决方向：可能演化为：

  • 在更高层引入"信誉迁移"机制（旧 opaqueRef → 新 opaqueRef 的链上声明）
  • 或在协议 v2 中引入有限制的 Human ID 撤销 + 接班机制

6. resourceRef 命名空间规范

议题：本规范仅给出 <scheme>://<authority>/<path> 形式建议，正式语法可能演化为独立 spec 或对接现有 URI 标准。

影响范围：跨实现互操作

解决方向：可能形成独立的"FayID Resource Identifier"规范，或直接采用 RFC 3986 URI 标准。

7. 跨 FayID System 实例的互操作性

议题：当存在多个 FayID System 部署（不同运营方）时，Human ID / iFay ID / Organization ID 的全球唯一性需要全局命名空间或前缀分区机制。

影响范围：多运营方生态、跨链互操作

解决方向：可能演化为 FayID v2 的核心议题。候选方案包括：

  • 命名空间前缀（如 hid_us_xxx vs hid_eu_xxx）
  • DNSSec 风格的根命名权威
  • 链上注册表

8. GMC opaqueRef 的密钥滚动

议题：gmc_namespace_secret 的轮换会破坏长期信誉关联——同一 Human ID 在新旧密钥下派生的 opaqueRef 不同。

影响范围：信誉连续性、密钥安全

解决方向：

  • 设计新旧 namespace_secret 共存窗口
  • 或通过链上"opaqueRef 迁移声明"建立新旧引用的等价关系
  • 此议题需要独立 ADR

9. Property P9 的执行机制

议题：协议层规定"Human ID 不出站不入日志"的行为；实现侧的强制机制（类型系统标签、序列化 redact、CI 静态扫描）由实现 spec 选择。

影响范围：实现质量、安全审计

解决方向：

  • 类型系统层面：使用 newtype / branded type 区分 Human ID 与其他实体
  • 序列化层面：默认 redact，显式开关白名单
  • CI 层面：静态扫描出站载荷与日志路径

10. 传统鉴权来源的可信度分级

议题：所有传统凭据是否平权地兑换 Authorization Grant？是否对 SMART_CONTRACT 与 PASSWORD 应用不同 TTL 上限？

影响范围：安全策略、风险控制

解决方向：

  • 引入 legacySourceKind 到 TTL 上限的映射
  • 对低可信来源（如简单 PASSWORD）应用更短 TTL
  • 对高可信来源（如 SMART_CONTRACT）放宽限制

归档与跟踪

上述 10 条议题将在后续任务 8 中归档至 .kiro/specs/fayid-identity-system/open-questions.md，每条标注：

  • owner：议题主理人
  • 影响范围：受影响的子系统
  • 解决里程碑：v1 / v2 / 实现 spec / ADR

本章作为蓝图的"未决议题"索引，仅复述议题概要；详细的归档与跟踪请查阅后续生成的 open-questions.md。