从身份骨架到钱包接口
可验证凭证（VC）与 DID 是什么？链上身份的骨架 讲过可验证凭证（VC）与 DID 这套链下身份的骨架：发证方签名、持证方保管、验证方离线验证。骨架立起来之后，工程上还差一问：凭证住在钱包里，应用该怎么跟钱包说话？编号 169 的草案回答了这个问题，为钱包（规范里称凭证提供者）定义一组 wallet_creds_ 前缀的 JSON-RPC 方法。写作时它是 Draft（草案），frontmatter 声明依赖编号 25 的会话协议。
store 与 verify：存进去、验给你看
wallet_creds_store 让应用把一张凭证交给钱包保管，凭证不合规或构造错误时返回错误码：400 参数无效、500 处理或内部错误、501 加密原语无效。wallet_creds_verify 由应用调用、钱包执行：对单张凭证的 proof 段做验证，钱包本地验还是远程验由钱包自己决定，应用只是异步等一个成功或错误码。原文有一条强硬的纪律：无法返回恰当错误码的钱包，必须不允许应用调用这个方法，否则行为未定义。
issue 的方向反转
五个方法里最容易被误读的是 wallet_creds_issue：它的调用方向是反的——由钱包调用应用。钱包把一个按凭证清单规范构造的 credential_application 对象发过去，换回一张已签发的凭证。应用还可以收到一份 preferred_proofs 偏好表：数组有序，从最偏到最不偏好，每项说明要 jwt（外部证明）还是 ldp（内嵌证明）以及具体证明类型；钱包若都不支持，可在规范允许的组合里自选兜底。理解这个方向，就理解了发证方往往就是应用方的场景：你在网站上点「申请这张凭证」，钱包反向发起签发请求。
present：按需出示与持有者绑定
wallet_creds_present 用表示交换（Presentation Exchange）数据模型做查询：应用提交 presentation_definition，里面可以声明凭证格式约束，也可以声明选择性披露（只交部分字段）与持有者绑定要求。一旦要求持有者绑定，domain 与 challenge 两个参数就从可选变必填——作用与登录消息里的域名和随机数同源，防止这张出示被搬到别的网站复用。成功时钱包返回一个 Verifiable Presentation 对象，把所选凭证打包成 JSON。
metadata：先摸清能力
wallet_creds_metadata 让连接双方报告各自支持的凭证类型、签名格式与加密原语，应用据此决定后面调什么、不调什么。这与 网站记忆和钱包实况对不上？CAIP-312 给会话权限装了一个查询接口 那种「先查询实况再动手」的思路一致：能力不对齐时提前失败，好过调用到一半报未定义行为。
五个方法的方向表
按调用方向归类最好记：store、verify、present 三个方法方向相同，应用发起、钱包响应；issue 反转，钱包向应用要一张签好的凭证；metadata 双向通用。方向决定了安全审查的落点：应用能主动发起的三个方法里，钱包是被请求方，弹窗与限权在钱包侧；issue 发生时钱包是发起方，用户看到的「发证」动作其实是钱包在替你跑腿。把五个方法画成箭头图，比逐字读规范更快建立正确预期，也更容易发现某个钱包实现把方向做反的怪癖。
证明格式与档案声明
规范把可用的证明类型列成清单：外部证明走 JWT 路线，签名装在凭证结构之外；内嵌证明走 LDP 路线，签名嵌进凭证 JSON-LD 内部。wallet_creds_issue 的 preferred_proofs 偏好表就是在这个清单上排优先级，wallet_creds_metadata 报告的能力也以这份清单为坐标系。档案（Profile）一词在原文里出现得很密：能存什么类型的凭证、支持哪些签名格式，都归「受支持的可验证凭证档案」这一声明管。对开发者的含义是，报错 501 加密原语无效不是网络问题，而是双方对清单的理解没对齐，回头补 metadata 交换比重试调用有用。这也解释了为什么 一份 JSON 说清「哪条链、哪些方法、哪几个账户」：CAIP-217 授权作用域语法 的作用域语法在凭证场景同样吃香：清单先谈妥，方法调用才不会各说各话。
用户视角的边界
对用户而言，这族方法对应的钱包弹窗有三类：「保存这张凭证」「为这个网站生成出示」「接受这张凭证签发」。三类动作都不产生链上交易，因此也不会出现在区块浏览器记录里，核验它们要回到协议层日志而不是链上数据。选择性披露意味着你签字的内容可能只是凭证的一部分，弹窗展示哪些字段、隐藏哪些字段，是评估一个钱包诚实度的直观窗口。本文为协议机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。