一、先明确适用范围
银行对接数字钱包的功能边界怎么确认，首先要把“对接”拆成具体功能：是身份信息衔接、账户信息查询，还是提交业务请求？不同功能涉及的权限并不相同，不能以“已接入银行”概括全部能力。
以下讨论适用于通过网络服务连接银行与钱包的通用身份和授权问题，不代表某家银行或钱包已经开放相关功能，也不构成业务资质或监管许可的判断。
二、区分身份确认与访问授权
NIST SP 800-63-4《数字身份指南》覆盖身份核验、认证与身份联合等领域，主要面向通过网络与政府信息系统交互的用户。它可以作为理解身份技术边界的参考，但不是银行钱包业务权限清单。
确认身份回答的是“用户是谁”或“是否控制相应认证器”；访问授权回答的是“应用可以访问什么”。钱包用户完成认证，不意味着钱包自动获得其银行账户的全部访问权，更不意味着可以代为执行所有业务。
三、把授权落实到具体资源和操作
RFC 6749将OAuth 2.0定义为授权框架，使第三方应用能够获得对HTTP服务的有限访问。其核心是限定访问，而不是把用户的完整账户控制权交给第三方。
对接时可按功能记录访问对象、允许操作、授权主体和有效期限。例如，查询账户信息与提交资金业务请求应分别描述，不能用模糊的“账户权限”合并表达。实际可执行的业务，还需要与银行端业务规则对应。
四、同时确认数据边界和业务责任
接口权限只说明技术上允许访问什么，不能单独说明取得的数据可以如何使用。功能说明还应列明返回字段、使用目的、保存安排以及解除关联后的处理方式，避免把一次授权解释为无限期、无限用途的数据使用许可。
业务责任也要独立说明：谁接收用户请求，谁进行业务审核，谁维护最终状态，谁处理差错与投诉。这些事项不能仅凭身份认证成功或取得访问令牌来推定，应由实际服务安排和双方约定明确。
五、用边界清单完成核对
可为每项功能建立一份清单，写明功能名称、参与方、身份确认方式、授权范围、数据字段、业务限制、授权结束后的处理和责任归属。由产品、技术、安全及合规相关人员对照接口说明与业务文件核对，重点消除各方对同一权限名称的不同理解。
确认的目标不是证明“接口能调用”，而是确保用户看到的说明、应用获得的权限、银行实际允许的操作与责任约定彼此一致。
六、常见问题
登录成功是否等于绑卡或支付授权成功？不能这样判断。身份认证、账户关联与具体业务授权属于不同事项，需要分别确认。
采用OAuth是否就能证明对接合规？不能。授权框架解决有限访问的技术问题，无法单独证明业务资质、数据使用或合同安排符合适用要求。
解除钱包关联后是否意味着历史数据立即删除？不能直接推定。停止后续访问与处理已保存数据是不同问题，需要分别明确规则。