CIO 视角 · 用 VC/DID 让健康数据
"证明可信"而不必"交出数据"

2026-07-13 · 傅棱 / 首席算法 · 约 13 分钟阅读

一、CIO 桌上真实的两难

把摄像头对准任何一位健康险 CIO,过去 24 个月里他必然听过两句话交替出现:

• "承保精度不够,能不能多接一些用户健康数据。"(来自精算 / 产品)
• "数据存不下、跨境不能走、审计过不去。"(来自法务 / 安全 / 合规)

传统 IT 架构下这两条几乎不可调和。要么牺牲精度,要么承担合规风险。VC(Verifiable Credentials)+ DID(Decentralized Identifier)提供了第三条路:让保险公司"验证凭证",而不是"接收数据"。

二、VC/DID 到底是什么(3 分钟版本)

DID 是一个由用户自己控制、格式化的身份标识符,例如 did:vita:0x7f...ab。用户可以为它绑定任意公钥,只要保住私钥,任何第三方都可以验证"这个 DID 说的话是它本人说的"。

VC 是一份由某个签发者(Issuer)针对某个持有者(Holder)签发的、结构化的可验证声明,例如"该 DID 在过去 12 个月保持了 VITA 健康分 A 级"。这份声明本身带有签发者的数字签名,任何验证者(Verifier)可以离线校验,不用回连签发者。

关键在于:VC 只暴露"声明"本身,不暴露底层原始数据。用户可以把"我保持了 A 级"给到保险公司,而不需要把心率、步数、睡眠明细全部交过去。

三、保险场景里的 3 层落地

Layer 1 · Issuer(签发方):VITA 作为持牌数据处理者,基于用户授权采集原始行为数据,按精算标准计算健康分,并对聚合后的评级(A/B/C/D)签发 VC。签名密钥托管在 HSM,支持轮换,不落到应用层。

Layer 2 · Holder(用户端):用户在移动 App 端持有 DID + VC。App 内的钱包不做加密货币,只做凭证存储与选择性披露。这一点非常重要:CIO 团队向法务解释时要强调"钱包 ≠ 加密资产钱包"。

Layer 3 · Verifier(保险公司):保险公司的核保 / 定价系统集成一个轻量的 Verifier SDK,离线校验用户提交的 VC 签名与有效期,直接把评级作为承保因子。原始行为数据一次都不需要落到保险公司的数据仓库。

四、集成路径(给到实施团队的最短路径)

1. 选型:VC 标准优先选 W3C VC Data Model 2.0;DID 方法在境内推荐 did:key 或联盟链方案,不建议使用需要公链 gas 的方法。
2. 密钥:Issuer 签名密钥入 HSM(阿里云 KMS 支持 EdDSA)。用户私钥使用系统级安全芯片(iOS Secure Enclave / Android StrongBox),不落地。
3. 凭证有效期:健康类 VC 建议 90 天,过期后强制重新采样与重签。
4. 撤销机制:提供 Status List 2021 格式的撤销位图,VC 校验时并行查询;掉线兜底为"证书失效"。
5. 审计:签发、撤销、验证事件全部落到不可篡改的审计日志(蚂蚁链或等价方案),满足监管调阅。
6. 降级:所有集成点都要有"传统 API 调用"的降级路径,保证 VC 网关故障时业务不停。

五、合规边界

需要在项目立项时就写清楚的四条边界:

• VC 不是金融凭证,不承载法币价值,不可转让,不做二级交易。
• DID 不是加密货币钱包,不涉及任何链上资产。
• 凭证不能面向未成年人签发。
• 面向境内用户的 DID 方法不使用公链;跨境场景另做独立评估。

六、给 CIO 的评估清单

1. 核心系统是否能容纳"凭证验证"这个新调用类型(而不是传统数据查询)?
2. HSM / KMS 是否已支持 EdDSA?没有的话准备升级窗口。
3. 数据仓库能不能明确排除掉"原始行为数据"进入 T+1 数仓?
4. 核保规则引擎能不能把 VC 评级直接映射为承保因子权重?
5. 安全团队认不认可"用户私钥不在服务端"的信任模型?
6. 合规团队能不能签"不接触原始数据"的架构承诺书?

6 个问题里 4 个以上是"可以",VC/DID 就是你团队接下来 12 个月里 ROI 最高的技术投入之一。

本文技术描述基于 W3C VC/DID 相关标准与 VITA 内部研发实践,不构成对具体产品的采购建议。VITA 不面向个人发行任何代币或加密资产。