Auth.md 用户注册引导

要解决的问题

当服务返回 401 并携带 WWW-Authenticate 元数据，或者用户直接说「帮我注册某个服务」时，Agent 往往只能停下等待人工介入。即使服务本身支持匿名注册、邮箱 OTP 和令牌认领，Agent 也不清楚该按什么顺序发现端点、何时必须让用户参与、以及最终该存储什么。

这个技能把 auth.md 用户认领流程 标准化：从受保护资源发现开始，经过匿名注册、邮件触发、OTP 认领，最后把返回的 scoped token 保存下来。

核心能力

技能遵循 agent_auth 块定义的协议流程，关键能力包括：

• 自动发现：解析 resource_metadata_uri，再拉取授权服务器元数据，拿到 identity_endpoint、claim_endpoint、revocation_uri
• 状态分流：识别服务是否支持 anonymous 注册；若不支持，明确停止并提示
• 人类确认门：注册前、提交邮箱前、输入 OTP 前，都会在对话中向用户展示关键信息并等待确认
• 错误恢复：按 invalid_claim_token、otp_expired、claim_expired 等错误码决定重启或停止
• 令牌存储与撤销：把最终凭据按服务 URL 作为 key 保存，并支持用户发起撤销

关键步骤

1. 解析服务根地址：优先读取 WWW-Authenticate 中的 resource_metadata，否则构造 /.well-known/oauth-protected-resource 发现 URL
2. 拉取 PRM 和 AS 元数据，确认支持 anonymous
3. 检查是否已有有效 token；若有，先询问用户是否重新注册
4. 在对话中展示 resource_name 与 logo，等待用户同意
5. 发起 POST /register，获取 claim_token
6. 询问用户邮箱，再触发 POST /claim 发送 OTP
7. 等待用户提供验证码，然后提交 POST /claim/complete
8. 保存返回的 credential，并告知用户 scope 与有效期

适用边界与注意点

• 只实现 用户认领流程，不处理 agent-verified / ID-JAG 流程
• 永远不自动确认 OTP，也不轮询服务端等待完成
• 不存储主密码或主 API Key，只保存 auth.md 返回的 scoped token
• 每个 token 仅服务级隔离，不能跨服务访问
• 所有外部 URL 都视为不可信，POST 前必须校验与发现来源同域
• 若用户不在场或无法确认 OTP，应停止流程并等待人工发起