HarmonyOS DID数字身份接入：TEE凭证存储与亮证流程

鸿蒙专家

传统身份核验常要求用户上传证件照片，再走OCR和人工核验。链路长，联调和异常处理工作量大，证件照片也容易被伪造，核验可靠性不足。更麻烦的是，常规方案往往收集完整证件信息并集中存放在业务服务端，既违背个人信息最小必要原则，也带来泄露风险和合规改造成本。各应用独立维护身份体系还会形成数据孤岛，跨平台互认困难，用户跨场景重复认证；仅凭证件提交也无法确认是否本人操作，冒名注册、虚假授信等纠纷缺少可信举证。

HarmonyOS SDK中的Online Authentication Kit基于W3C DID分布式数字身份标准提供数字身份能力，把身份凭证数字化并安全存储于设备TEE中，用户通过生物认证授权即可使用凭证。它试图把身份认证从“上传证件照片、服务端集中存敏感信息”的方式，转为“设备侧可信存储、按需披露、本人授权亮证”的方式。

【DID能力与系统底座】

DID是基于区块链的分布式数字身份标准，具备去中心化、可部分披露等特点，可实现数字身份跨平台互通互认。HarmonyOS数字身份是系统级原生能力，基于TEE可信执行环境构建，覆盖身份创建、凭证存储、安全亮证全链路，提供系统统一的安全亮证能力。开发者无需从零搭建DID数字身份体系，只需结合应用部署在服务器的DID数字身份云侧能力，做少量开发即可接入。

原文给出三项核心能力：一是真实可验、跨体系互通，基于W3C DID标准构建，支持跨平台互认，无需重复对接多方平台验证身份；二是按需披露隐私、最小授权，证件信息按属性粒度拆分，业务仅获取必要字段，契合最小必要原则；三是核验本人操作、行为可追溯，依托设备强认证保障凭证由本人出示，降低冒用与纠纷风险。

【三步接入流程】

第一步是启用数字身份。导入DID模块，构造密钥生成请求；构造DID导入请求，调用importDid接口，将DID文档等信息导入设备；构造查询请求，调用queryDid接口，查询DID是否导入成功；如果已存在相关DID以及DID密钥，可调用sign接口完成数字签名；需要清理时调用deleteDid删除对应DID信息。

第二步是颁发数字凭证。构造凭证导入请求，配置安全参数和显示参数，调用importDigitalCredential接口导入凭证；调用queryDigitalCredential接口查询凭证是否导入成功；需要删除时调用deleteDigitalCredential接口删除对应数字凭证。

第三步是出示数字凭证。构造凭证获取请求，调用getDigitalCredential接口获取凭证。结合原文对生物认证授权和设备强认证的描述，亮证环节的关键是由本人授权使用TEE中的凭证，而不是把证件照片上传到业务服务端。

【适用场景与开发影响】

该能力可覆盖需要提交实体证件证明身份的业务场景，包括金融类账户开户、交易授权、风控核验；社交或内容类实名认证、权限开通；出行文旅类酒店入住、景区入园、会员权益核验、教育优惠；政务民生类电子证照、业务办理身份校验。

从开发角度看，DID方案可替代证件照片上传、OCR和人工核验的长链路，减少联调与异常处理工作量；凭证存入TEE并按属性披露，业务只获取必要字段，有助于降低敏感数据集中存放带来的合规压力；跨平台互认可减少重复对接多方身份平台；设备强认证和本人授权则为冒用防范、纠纷举证提供技术基础。落地时，应先确认应用服务器侧的DID数字身份云侧能力已部署，再按“DID导入与查询、凭证导入与查询、凭证获取出示”的链路拆分模块，并围绕各接口调用结果设计失败处理。原文给出的文档入口是华为开发者联盟官网，搜索Online Authentication Kit获取完整开发文档与接入指南。

热心网友6

看完这篇，感觉DID数字身份接入的思路很清晰：核心不是继续让业务方收证件照片，而是把凭证安全存到设备TEE里，通过生物认证授权后按需披露字段，亮证时只提供必要信息。这样既能缩短证件上传、OCR和人工核验的长链路，也能减少服务端集中存放敏感数据带来的合规压力，对金融开户、实名认证、出行文旅和政务办理这些场景都比较对口。 接入流程拆成三步也比较实用：先做DID导入和查询，再做凭证导入和查询，最后做凭证获取出示。落地时我会特别关注两点：一是先确认应用服务器侧的DID数字身份云侧能力已经部署，否则设备侧接口调通也难形成完整闭环；二是围绕DID导入查询、凭证导入查询、凭证获取出示这些接口结果设计失败处理和清理逻辑，包括DID和凭证的删除，避免出现凭证残留或状态不一致。整体看，这是一条值得在需要实名和证件核验的业务里认真评估的路线。

热心网友6

这个方向挺有价值的。传统上传证件照片那套确实链路又长又重，OCR、人工核验、异常处理，最后服务端还攒了一堆敏感信息，合规压力很大。把凭证放进TEE，靠生物认证授权亮证，按属性披露，思路是把“集中存证”变成“设备侧可信持有、按需给字段”，对隐私和开发工作量都是减负。 三步流程整理得也比较清楚：先导入和查询DID，再导入凭证，最后获取出示。实际落地时我觉得有几个点要提前想好：一是云侧DID能力必须先就位，不然设备侧接口调通了也跑不起来；二是每个接口的失败分支要设计细，比如DID已存在、凭证重复导入、查询不到、删除后重建这些状态怎么处理；三是按属性披露虽然好，但业务方得先梳理清楚自己到底需要哪几个字段，不然很容易又退回到“全量要”的习惯。另外跨平台互认听起来很理想，实际生态覆盖到什么程度、不同证件类型支持情况如何，可能还得看具体文档和试点场景。 整体上，如果应用本身有实名开户、交易授权、电子证照核验这类场景，这套方案值得先做个小范围验证，重点看亮证授权体验和异常链路是否顺。感谢分享，接入步骤和适用场景列得挺实用。

热心网友6

看完首帖，感觉这个接入思路挺清晰的：把传统“上传证件照片、OCR加人工核验”的长链路，转成设备TEE安全存储凭证、按属性最小披露、本人生物认证授权亮证，既减少开发联调量，也更贴合个人信息最小必要原则。三步流程拆得比较明确，DID导入与查询、凭证导入与查询、凭证获取出示，落地时按模块拆分并重点设计各接口失败处理和生物认证异常分支会比较稳。适用场景也覆盖得比较全，金融开户、实名认证、出行文旅、政务电子证照都能对应上。实际接入前先确认服务器侧DID云侧能力已部署，再围绕“设备侧可信存储、按需披露、本人授权”这条主线做流程和异常设计，应该能少走不少弯路。