Chrome 155默认支持数字凭证签发：企业会员证与员工证能直接接入吗

Chrome开发者团队在2026年10月23日发布说明：从Chrome 155开始，Digital Credentials API的“签发”能力默认启用，开发者无需再依赖此前的试验令牌或功能开关。这让符合条件的签发机构网站可以通过浏览器与用户手机上的钱包应用衔接，把数字身份类凭证加入钱包。它不是“任何网站点一下就能发电子证件”的通用功能；企业要先分清自己的业务是否真的需要签发可验证凭证。

签发、持有和核验是三件不同的事

在数字凭证场景中，签发方负责确认资格并生成凭证，用户通过钱包持有，核验方在需要时请求证明。Chrome这次介绍的是“签发”衔接：网站提出签发请求，浏览器交给操作系统，再由用户选择支持的钱包。它不意味着浏览器替企业审核身份，也不意味着普通的会员二维码自动变成可验证凭证。本站此前讨论可验证凭证威胁模型，同样强调展示证书图片与在线核验系统的边界。

企业在什么情况下值得关注

有持续资格管理需求的会员组织、校园、活动主办方或专业培训机构，可能需要让用户保存并出示凭证。方案设计时，应先问：资格由谁确认，失效后如何撤销，核验方只需看到什么信息，用户如何同意分享？如果企业只是希望客户扫码进入服务页，现有网站与小程序协同可能更简单、维护更低。不能为追赶新技术而额外收集不必要的身份资料。

兼容与隐私测试不能省

Chrome官方说明，签发流程依赖受支持的钱包应用和设备环境，并介绍了同设备与跨设备两种流程。跨设备过程可由电脑显示二维码、用户在Android手机上完成；因此企业不能假定所有手机和浏览器都能走同一路径。上线前应准备传统入口，测试用户拒绝、钱包缺失、网络中断以及签发后撤销等情况。后台管理权限也应按账号分工清单控制。

1. 确认真实业务是否需要跨机构核验，而非仅需展示一张卡片。
2. 列出签发方、钱包、核验方各自的数据与责任。
3. 用受支持设备做原型验证，并保留兼容性提示。
4. 在正式上线前明确用户同意、撤销和异常处理方式。

对一般企业官网来说，这项能力目前更像面向特定身份业务的基础接口。先把项目流程与数据边界画清楚，再决定是否接入，通常比直接照搬演示代码更稳妥。

资料依据：Chrome数字凭证签发功能公告；W3C Digital Credentials API草案。