[评估] 通知绑定方案的 KMS 部分(owner 验证/bindingCode/存储)— 见 aastar-sdk#193

[jhfnetboy]

请评估:通知联系方式绑定方案中 KMS 的部分

跨仓库绑定方案见 **AAStarCommunity/aastar-sdk#193 作为信任锚 + 存储 + 验证)。请评估第 3 节"@kms"那几问能否落地:

• owner 授权验证用 owner key 签名 vs passkey ceremony?
• KMS 签发 + 校验一次性 bindingCode 可行?
• "KMS 只存不代发" → bindingCode 的发送 + 用户 /bind 的接收谁来做?
• 存储 schema(account → verified telegram/email)+ getContact API 形状?

在 AAStarCommunity/aastar-sdk#193 下回复你们的可落地评估即可。关联:带外确认绑定落 KMS(本组织 Validator#124)。

[jhfnetboy]

关联 YetAnotherAA#382:tier 提额(modifyTierLimitsWithGuardians)+ 初始 setTierLimits 都是严格 onlyOwner(msg.sender==owner,非 entryPoint)→ 不能走 UserOp,必须 owner key 直发 eth tx。账户 owner 是 TEE 持有的 secp256k1 key。请确认 KMS 是否暴露「以账户 owner 身份签 + 广播任意 eth tx」端点(setTierLimits/addGuardian/提额共用)。详见 YetAnotherAA#382。

[jhfnetboy]

✅ Phase 1 KMS 侧完成并已部署（v0.27.0，2026-06-26）

通知联系方式绑定的 KMS Phase 1（Telegram） 已实现、过 codex+opus 多轮 review、合并并部署到 dev 板（kms.aastar.io，v0.27.0 strict/dev，已验证 live）。host-only，TA 0.8.0/proto 0.7.0 不变、未重刷。

已上线端点（全 x-api-key + 限流；POST 64KB 上限）

端点	鉴权	入参 → 出参
POST /contact/begin-binding	owner ceremony	{account, channel:"telegram", WebAuthn} → {bindingCode, expiresAt}
POST /contact/claim-binding	bot api-key	{bindingCode, telegramChatId, telegramUsername?} → {verifyToken, expiresAt}
POST /contact/confirm-binding	owner ceremony	{account, bindingCode, verifyToken, WebAuthn} → {status:"verified"}
GET /contact/{account}	api-key（DVT）	→ {contacts:[{channel, contactRef, status, verifiedAt}]}
POST /contact/unbind	owner ceremony	{account, channel, WebAuthn} → {status}

WebAuthn 字段 = 标准 ceremony assertion（{ChallengeId, Credential}，与现有 KMS API 同形）。confirm 必须 owner ceremony（bot 知道 verifyToken，故 confirm 不能只 api-key）+ DB 校验 account 归属。

设计 + 跟踪的 Phase-1 follow-up

见 docs/design/contact-binding-kms.md：信任模型（§2，被攻陷 bot 限于通知层）、follow-up（api-key scoping / ceremony 绑 {account,channel} commitment / bot-key-class / email 待 begin_email_binding / contact_ref at-rest 加密 pre-GA）、Phase 2（passkey-PRF 加密的可携带绑定 blob，跨 KMS social-recovery 导入）。

PR #130（DB 层）/ #131（verifyConfirmAssertion）/ #132（端点）/ #133（review 修复）/ #134（release v0.27.0）全合并。本 issue 留开跟踪 Phase 2 + 上述 follow-up。

[jhfnetboy]

owner-tx 路径补充(YetAnotherAA#382):查到 KMS /Sign 已能签 EIP-155 Transaction(owner key,WebAuthn-gated)→ 提额/setTierLimits 的 owner-call 用这个即可,KMS 无需新增端点。请确认 dev 板 v0.27.0 的 /Sign Transaction 路径可用 + strict 板下传 options.payload(tx signing digest)的用法。

[jhfnetboy]

📌 跟踪两个待 KMS 的 follow-up（来自 SDK/YAA 集成，2026-06-26）

1. email 联系方式绑定 → 需 KMS begin_email_binding（移至 Phase 2）

   • 现状：contact 端点 telegram 已 live（v0.27.1）；email 在 begin/claim/confirm DB 路径上不完整（begin_email_binding 未实现，confirm 永远失败=安全但半成品），端点对 email 显式报错不静默。
   • 待办：实现 begin_email_binding（begin 时设 contact_ref=email + verify_token，无 claim 步）+ 开放 email 端点。SDK（aastar-sdk#203）email 封装也等这个。归 Phase 2（telegram 跑通后）。

2. #382 提额（raise tier limit）的 owner-tx 端点 → 待 KMS 确认

   • 背景：setTierLimits/setWeightConfig/addGuardian/modifyTierLimitsWithGuardians 是严格 onlyOwner（msg.sender==owner），不能走 4337 UserOp / EntryPoint / account.execute（会变 msg.sender → revert NotOwner），必须是 owner key 直发的 tx（详见 aastar-sdk#202 / #382 注释纠正）。
   • 对 KMS/TEE 托管账户：owner 是 TEE 内 secp256k1 key，所以这类 onlyOwner 调用需 KMS 签 + 广播 owner tx。
   • 待 KMS 确认：是否/如何暴露「owner 直发 tx 签名（+广播）」给提额这类 onlyOwner 操作（现有 Sign/SignHash 出签名，但广播 + nonce 管理 + 直发语义需确认）。SDK 的提额助手等这个确认。

两者均非 v0.27.x 阻塞，记此跟踪。Refs aastar-sdk#202/#203、#382。

[jhfnetboy]

↳ follow-up #2（提额 owner-tx）KMS 确认结果（回复在 YetAnotherAA#382）

查 KMS 代码后确认：

• 签名路径已存在：POST /Sign 的 transaction → TEE 用 owner secp256k1 签以太坊 tx（owner WebAuthn ceremony 门控）。提额 setTierLimits 直接复用 → 无新增 KMS 签名工作。
• 纠正：KMS 只签不广播（无 RPC）；客户端(SDK/YAA)广播。"KMS 直发" 不准确。KMS 也不发初始 tier 配置——是 SDK/YAA 编 tx→KMS 签→客户端广播（无 KMS 内部 tier 流程）。
• 唯一可能的 KMS 小工作：当前 /Sign 是 legacy tx（gasPrice），不支持 EIP-1559。若 owner tx 必须 type-2 → 需补。否则零工作。
• 待 YAA 确认：legacy 可用？owner == KMS 派生 EOA？确认后 #3b UI 可动手。

球回到 YAA/SDK（确认 legacy + owner-EOA）。Refs YetAnotherAA#382。