AI 底层逻辑 / 经典论文
AI Digital Identity Wallet：可验证凭证信任架构
AI identity wallet architecture 不是“让模型要身份证”。它是一套 trust decision system：把 issuer-attested claims、holder-mediated disclosure、authentication signals、relying-party policy、fraud context、AI inference、custom
231 行ai-foundations/papers/134-ai-digital-identity-wallet-verifiable-credentials-trust-architecture.md
AI Digital Identity Wallet / Verifiable Credentials / Trust Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_DIGITAL_IDENTITY_WALLET_VERIFIABLE_CREDENTIALS_TRUST_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
重要说明: 本文只讨论 AI 系统使用 digital identity wallet、verifiable credentials、DID、passkeys、proofing assurance、relying-party policy、selective disclosure、revocation/status、fraud controls 和 evidence 的产品与架构设计，不构成法律、监管、KYC/KYB、身份核验、隐私影响评估、模型验证、认证方案、消费者通知或 vendor endorsement 结论。身份核验、KYC/KYB、证明等级、记录保留、制裁/AML、消费者保护和跨境数据要求必须由 Legal、Compliance、Privacy、Identity/IAM、Fraud Risk、Financial Crime、Model Risk、Information Security、Data Governance、Operations、Vendor Management、Internal Audit 等共同确认。
本文不假设 verifiable credentials 必须使用 blockchain。DID / VC / wallet 可以落在 registry、resolver、PKI、federated、web、ledger 或 consortium pattern 上；架构判断应基于 trust framework、interoperability、privacy、revocation、evidence、fraud controls 和 customer outcome。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST SP 800-63-4 Digital Identity Guidelines | https://pages.nist.gov/800-63-4/ | 用 IAL / AAL / FAL、risk management、fraud controls、subscriber-controlled wallets、passkeys、customer experience 和 continuous evaluation 组织 identity assurance architecture |
| NIST Digital Identity Guidelines | https://www.nist.gov/identity-access-management/digital-identity-guidelines | 用 NIST digital identity guidance 作为 identity proofing、authentication、federation、安全、隐私和 customer experience 的官方锚点 |
| NIST Digital Identity Guidelines project page | https://www.nist.gov/identity-access-management/projects/nist-special-publication-800-63-digital-identity-guidelines | 用 NIST 对 SP 800-63 Revision 4 的项目说明连接 identity proofing、authentication、federation、安全、隐私和客户体验 |
| W3C Verifiable Credentials Data Model 2.0 | https://www.w3.org/TR/vc-data-model-2.0/ | 用 issuer / holder / verifier、claim、presentation、status、terms of use、evidence、privacy considerations 和 verifier policy 设计 VC verification pipeline |
| W3C Decentralized Identifiers DID Core | https://www.w3.org/TR/did-core/ | 用 DID controller、DID document、verification methods、DID resolution、key rotation、revocation 和 correlation risks 设计 identifier layer |
| W3C Web Authentication Level 3 | https://www.w3.org/TR/webauthn-3/ | 用 public-key credentials、RP-scoped credentials、authenticator consent、attestation 和 passkey signals 设计 authentication and holder-binding controls |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 AI 使用身份 claims 的风险治理、eval、monitoring、human oversight 和 evidence |
| ISO/IEC 42001 overview | https://www.iso.org/standard/42001 | 用 AI management system、policy、roles、operation、performance evaluation、internal audit 和 continual improvement 建立 operating model |
核心导读
AI identity wallet architecture 不是“让模型要身份证”。它是一套 trust decision system：把 issuer-attested claims、holder-mediated disclosure、authentication signals、relying-party policy、fraud context、AI inference、customer consent 和 evidence replay 分层处理，避免把“可验证签名”误当成“业务可接受”。
问题定义
数字身份钱包和 verifiable credentials 的价值，不是把 onboarding 表单换成钱包弹窗，而是把身份输入从“客户自述/上传/模型推断”升级为“issuer-attested claim + holder-mediated disclosure + verifier policy decision + evidence replay”。
必须回答的问题：
谁签发了 claim，issuer 是否在本产品 trust framework 内?
claim 指向哪个 subject，holder 是否有权展示?
credential 是否未过期、未撤销、schema 可理解、proof 可验证?
relying party 是否只请求完成业务目的所需最小 claim?
passkey/WebAuthn/session/device signal 证明了什么，不能证明什么?
AI 推断属性是否被标记为 inference，并禁止当成 verified identity claim?
高风险 onboarding、KYC、KYB、account recovery、agent delegation 是否有人类和政策边界?
事后能否重放 consent、presentation、verification、policy、AI run、human decision 和 final message?
关键边界：
Verifiable does not mean acceptable.
Authenticated does not mean proofed.
Wallet-held does not mean legally sufficient.
AI-inferred does not mean verified.
Blockchain-based does not mean trusted.
核心原理/方法
身份相关输入至少分成六类：
| Information class | 示例 | AI 使用边界 |
|---|---|---|
| Issuer-attested verified claim | age-over-18、bank account ownership、business registration | 可进入 policy engine，但要检查 issuer trust、purpose、freshness、status |
| Relying-party observed fact | passkey login、device binding、account tenure | 可用于 risk/context，不证明真实世界身份属性 |
| Customer-declared attribute | job title、expected income、address、beneficial owner statement | 需要 proofing/evidence policy 决定能否依赖 |
| AI-inferred attribute | likely student、affluent segment、business owner、age band | 只能作为低影响 UX/support signal；不得当成 verified claim |
| Third-party risk signal | device risk、sanctions hit、fraud consortium signal | 用于 review/routing；高影响动作需要 policy/human boundary |
| Authentication signal | WebAuthn assertion、MFA method、session age | 证明 authenticator/session 控制，不等同 identity proofing |
每个 identity input 应带 metadata：
source_type
issuer_or_observer
assurance_level
verification_method
status_checked_at
freshness_window
business_purpose
allowed_decision_uses
prohibited_decision_uses
ai_inference_flag
human_review_requirement
evidence_reference
系统/架构模型
参考架构：
issuer / authority / enterprise registry
-> credential issuance and lifecycle controls
-> holder wallet / credential repository
-> wallet UX: purpose, consent, selective disclosure
-> relying party presentation request
-> deterministic credential verification service
-> issuer trust and assurance mapping
-> status / revocation / freshness check
-> holder binding and authentication context
-> relying-party policy engine
-> fraud and risk orchestration
-> AI product / agent workflow
-> human review / exception / appeal
-> evidence ledger and governance monitoring
分层 trust：
cryptographic validity
!= issuer trust
!= subject binding
!= claim freshness
!= business acceptability
!= legal sufficiency
!= fraud risk acceptability
Verification pipeline：
| Step | 控制问题 | Evidence |
|---|---|---|
| Parse and normalize | format、schema、claim names、version 是否识别 | parser version、schema id |
| Verify proof | signature、DID resolution、key material 是否有效 | proof result、verification method |
| Verify issuer trust | issuer 是否在 accepted trust registry | issuer policy id、snapshot |
| Verify holder binding | holder 是否有权展示 credential | VP proof、nonce/challenge、auth context |
| Check status/freshness | revoked、suspended、expired、superseded? | status result、checked_at |
| Apply RP policy | 产品、地区、风险等级是否接受 | policy decision、reason code |
| Run fraud checks | replay、velocity、device/session anomaly | risk score、fraud reason |
| Produce artifact | accept、request more、manual review、reject claim use | decision record、customer explanation |
关键机制与取舍
DID / VC / wallet pattern 不等于技术信仰选择：
| Pattern | 适合场景 | 取舍 |
|---|---|---|
| DID:web / web-origin issuer | 企业、学校、银行、政府通过 domain trust 发布 material | operationally familiar，但要管 domain、key rotation、resolver trust |
| Pairwise identifiers | 高隐私 bilateral relationship | 降低 correlation，但恢复和跨设备复杂 |
| Consortium / trust registry | 多机构互认 issuer、schemas、assurance、status | 需要 governance、membership、liability、audit |
| Ledger-anchored DID | 生态需要公共可解析 registry | 可能带来 correlation、成本、治理和删除性问题 |
| Non-DID signed credentials | JWT / SD-JWT / mdoc / X.509-like patterns | 可能更易集成现有 IAM，但 holder-control 模型不同 |
NIST IAL/AAL/FAL 的核心价值是拆开常被混淆的问题：
| Dimension | 回答 | 不回答 |
|---|---|---|
| IAL / proofing | 申请人与真实世界身份/属性绑定强度 | 当前 session 是否被本人控制 |
| AAL / authentication | claimant 对 authenticator 控制强度 | 真实世界身份属性是否已核验 |
| FAL / federation | federation assertion 的保护强度 | issuer 业务可信度和 claim 业务含义 |
Wallet UX 关键机制：
- presentation request 显示 verifier、purpose、requested claims、retention、fallback。
- selective disclosure 优先请求 abstract claims，例如 age-over-X、residency state、authorized role。
- high-risk disclosure 前使用 passkey/WebAuthn/session step-up。
- consent、authentication、authorization 和 RP acceptance 分开记录。
- wallet recovery、lost device、assistive channel 和 non-wallet fallback 必须可用。
Revocation/status 取舍：
| Concept | 架构控制 |
|---|---|
| Expiration | RP policy 检查有效期和 freshness window |
| Revocation | status check、cache policy、incident handling |
| Suspension | 区分 temporary unavailable 与 permanent invalid |
| Refresh | wallet and issuer refresh UX |
| Supersession | 新旧 credential version handling |
| Status privacy | status check 可能暴露 verifier-customer linkage，需要 privacy-preserving design |
证据与控制
Credential reliance decision record：
decision_id
customer / business case reference
credential presentation id
issuer id
credential schema and version
claims requested / disclosed / accepted / rejected
verification result
status result and checked_at
authentication context
holder binding evidence
RP policy version and reason code
fraud/risk result
AI assistance used
human reviewer
customer-facing explanation
retention/evidence reference
控制矩阵：
| Control objective | Control activity | Evidence |
|---|---|---|
| 只接受可信 issuer | 按 claim type、product、jurisdiction、assurance 维护 trust registry | registry snapshot、approval record |
| 确定性验证 credential | verification service 处理 proof、DID resolution、schema、status、holder binding | verification result、resolver log |
| 分离 verification 与 acceptance | RP policy engine 判断 verified claim 是否适用于业务 | policy decision id、reason code |
| 最小披露 | 优先请求 abstract/selective claims | presentation request、disclosed claim set |
| 保存 consent | 展示 verifier、purpose、claims、retention、fallback | consent receipt、UI version |
| 控制 AI inference | inferred attributes 单独标记、限制用途、高影响 human review | data dictionary、policy rule、eval evidence |
| 防 replay | nonce、audience binding、single-use presentation | challenge id、VP proof |
| 管理 revocation | status/freshness checks、outage/cache rules | status log、cache policy |
| 治理 agent delegation | purpose-bound、time-bound、action-bound approvals | approval id、run id、agent id |
| 支持 audit replay | 保存 credential、AI、policy、human、customer communication evidence | evidence bundle、complaint link |
金融零售/AI产品场景
- Consumer onboarding：wallet 提供 name、DOB、address、age-over-X claim；verification service 验 proof/status，RP policy 决定是否接受，AI 只解释缺口和预填申请。
- KYB onboarding：business registry、authorized representative、license、beneficial ownership evidence 进入 policy review；AI 不可自行接受 inferred beneficial owner。
- Account recovery：passkey/WebAuthn 证明当前 authenticator 控制，但不能替代重新 proofing；高风险恢复需 fraud and human review。
- Agent-assisted application：AI agent 组织材料和解释请求，但 disclosure 必须 holder-mediated，提交动作需要 action-bound approval。
- Age-gated product：只接受 issuer-attested age-over-X 或 approved alternate proofing；禁止用头像、语言、行为推断年龄。
- Wallet outage/fallback：客户无智能手机、设备丢失或使用 assistive technology 时，有等效 proofing 路径和证据保留。
反模式
| 反模式 | 风险 | 更好的控制 |
|---|---|---|
| signature-valid = business-accepted | 接受错误 issuer 或 assurance | issuer trust + RP policy |
| wallet-connected = identity-proofed | 混淆 session control 和 real-world proofing | proofing assurance + claim acceptance |
| AI-inferred age/role 用于资格 | bias、unfairness、unsupported decision | eligibility 只用 verified claims 或 approved evidence |
| full credential over-collection | privacy harm and breach blast radius | selective disclosure and abstract claims |
| 只验签不查 status | 接受 stale/revoked claims | status/freshness policy |
| blockchain immutability assumption | correlation/deletion/privacy 风险被忽略 | technology-neutral threat model |
| mobile-only wallet path | 排除无设备或有无障碍需求客户 | assisted and alternate proofing |
| LLM 直接解析凭证 | prompt injection and hallucinated verification | deterministic verifier + grounded AI |
| agent 持有 wallet secrets | unauthorized disclosure 难撤销 | holder-mediated presentation |
| complaint 无 credential trace | 无法解释或补救 | evidence bundle links consent、VP、policy、message |
最终心智模型
身份钱包架构的核心不是“连接一个 wallet”，而是建立 trust architecture。成熟系统应能只请求最小 verified claims，依赖已治理 issuer，在可解释 RP policy 下完成 verification、status、holder binding、fraud review 和 human exception，始终把 AI inference 与 verified claim 分开，并能在客户投诉、欺诈调查或审计中重放每一次依赖身份凭证的理由和证据。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。