先定义“钱包”具体承担什么职责
“类似数字人民币钱包”不能只按界面或登录方式判断。功能边界通常要回答四个问题：系统是否保存或管理支付凭证，是否展示或处理余额，是否发起支付指令，是否参与交易记账、清算或对账。只有把这些职责拆开，才能判断某个产品究竟是钱包、支付入口、身份认证工具，还是提供相关服务的业务平台。
提供的中国人民银行网站内容主要展示其在货币、支付体系、金融科技等领域的信息栏目，材料本身没有证明某一具体钱包项目的功能清单。因此，涉及具体产品时，应以该产品公开的协议、服务条款、用户界面和监管说明逐项核实，不能仅凭名称作出结论。
把身份认证与钱包能力分开
WebAuthn的核心是让网站为用户创建并使用基于公钥的凭证。凭证由认证器保存，并限定给特定网站来源；后续认证需要用户同意，认证器还可要求输入密码、PIN或生物识别等本地授权方式。这个机制能够证明用户控制了某个已登记的认证凭证，但不会自动产生余额、货币或支付账户。
因此，一个应用即使使用手机生物识别、硬件安全密钥或WebAuthn，也只能据此说明它具备某种身份验证或操作授权能力。是否属于钱包，还要继续确认它是否管理支付对象、承载余额信息、提交支付请求，以及这些行为由谁完成。认证成功也不等同于支付已经完成。
用四层模型划定功能范围
可以把系统分成四层来审查。第一层是身份层，负责注册、登录、设备绑定和账户恢复；第二层是授权层，负责确认用户是否同意某次敏感操作；第三层是钱包或支付层，负责支付凭证、余额展示、收付款指令及交易状态；第四层是后台业务层，负责风控、记账、清算、对账和客户服务。WebAuthn主要对应前两层，不能据此推断其覆盖后两层。
判断边界时，还要记录每项功能的触发条件和结果。例如，“验证用户”属于身份层，“用户确认一次付款”属于授权层，“扣减余额并生成交易记录”属于支付或记账层。若一个组件只返回认证结果，业务系统仍需自行决定是否允许后续操作，并承担相应的交易处理责任。
适用条件与核验清单
在设计或评估类似钱包的产品时，至少应核对以下内容：凭证由谁创建和保存；凭证绑定的是哪个网站或应用来源；用户授权的是登录、绑定设备，还是某一笔具体交易；支付指令由哪个系统生成；余额和交易记录由谁维护；失败、撤销、重复提交和设备丢失由谁处理。每一项都应能在产品说明、接口约定或服务规则中找到对应依据。
如果功能跨越多个系统，还应画清调用关系和责任边界。浏览器、操作系统、认证器、钱包应用、支付后台和外部服务可能分别承担不同职责。WebAuthn规范强调凭证受网站来源约束，并区分注册与认证流程，这有助于确认“谁可以发起认证”；但它不能单独确认资金归属、支付结算关系或具体金融服务属性。
常见问题
问：有登录密码和生物识别，就能称为数字钱包吗？答：不能。它们只能说明系统采用了某种登录或授权方式，仍需核实是否存在钱包账户、支付凭证、余额管理和交易处理能力。
问：认证器能否直接替代支付系统？答：通常不能。认证器负责保护凭证并返回认证结果，支付系统还需要验证请求、检查业务条件、记录交易状态并完成后续处理。
问：如何确认一次认证是否代表单笔支付授权？答：要看业务请求是否明确绑定交易内容、金额、收款对象和有效期限，并检查后台是否在验证认证结果后重新核对这些信息。仅有“认证成功”提示，不足以证明用户授权了某项具体支付。