AI Digital Identity Wallet / Verifiable Credentials / Trust Architecture 解读

面向对象: Advanced AI PM / Senior BA / Product Architect / Identity Architect / Fraud Risk Architect / Enterprise Architect / AI Governance / Privacy / Compliance / KYC-KYB Operations / Customer Onboarding Lead。 核心问题: AI 系统如何安全使用 digital identity wallet、verifiable credentials、DID、passkeys、proofing assurance、relying-party policy、selective disclosure、revocation/status、fraud controls 和 evidence, 同时避免把 AI-inferred attributes 当成 verified identity claims? 学习目标: 建立 AI identity trust architecture、wallet-mediated onboarding、credential verification pipeline、trust framework governance、RP policy decisioning、agent delegation、privacy-preserving disclosure、KYC/KYB evidence chain、fraud/risk monitoring 和 senior PM/architect decision framework。

0. Disclaimer

本文是学习、架构训练和作品集材料, 不构成法律意见、监管意见、KYC/KYB 合规结论、身份核验合格结论、隐私影响评估结论、模型验证报告、认证方案认证、消费者通知建议或 vendor endorsement。

正式项目必须由 Legal、Compliance、Privacy、Identity and Access Management、Fraud Risk、Financial Crime、Model Risk、Information Security、Data Governance、Customer Experience、Operations、Accessibility、Product Owner、Architecture、Vendor Management、Internal Audit 和必要的外部顾问共同判断。身份核验、KYC、KYB、证明等级、记录保留、客户通知、拒绝/申诉、制裁/AML、消费者保护、跨境数据和可接受凭证要求, 都取决于 institution、product、jurisdiction、customer segment、channel、risk appetite、policy、vendor contract 和 legal/compliance interpretation。

本文不假设 verifiable credentials 必须使用 blockchain。DID / VC / wallet 可以落在多种 registry、resolver、PKI、federated、web、ledger 或 consortium pattern 上。架构判断应基于 trust framework、interoperability、privacy、operability、revocation、evidence 和 customer outcome, 而不是基于某种底层技术叙事。

---

Source Anchors

一句话:

AI identity wallet architecture is not "let the model ask for ID". It is a trust decision system that separates verified claims, authenticator signals, issuer trust, relying-party policy, inferred attributes, fraud context, consent and evidence.

---

1. Thesis

AI 系统使用数字身份钱包和 verifiable credentials 的核心价值, 不是把 onboarding 表单换成更酷的钱包弹窗。真正的架构变化是:

from: customer says / uploads / AI infers
to: issuer-attested claim + holder-mediated disclosure + verifier policy decision + evidence replay

成熟架构必须同时回答八个问题:

1. 谁签发了 claim, 签发机构是否在本产品的 trust framework 内?
2. claim 指向哪个 subject, holder 是否有权展示它?
3. credential 是否未过期、未撤销、schema 可理解、proof 可验证?
4. relying party 是否只请求完成业务目的所需的最小 claim?
5. passkey / WebAuthn / session / device signals 证明了什么, 不能证明什么?
6. AI 推断出的属性是否被清楚标记为 inference, 并禁止当成 verified identity claim?
7. 高风险 onboarding、KYC、KYB、account recovery、agent delegation 和 fraud review 是否有 human/accountability boundary?
8. 事后能否重放 consent、presentation、verification、policy、AI run、risk score、人工决定和客户最终看到的内容?

关键原则:

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.

VC 可以让 claim 更 machine-verifiable, 但是否可以依赖, 取决于 verifier policy、issuer trust、assurance mapping、claim freshness、business purpose、risk tier、status check、fraud context 和合规解释。

---

2. Why It Matters

金融零售 AI 的 identity problem 正从“表单 + KYC vendor + 登录 MFA”升级为多方 trust architecture:

AI 放大了身份系统的两类错误:

• False reliance: 模型看到 credential proof valid, 就把 claim 当成产品可接受、合规充分、风险低。
• False inference: 模型从行为、语言、设备、地址、购买记录或公开资料推断身份属性, 并把推断当成 verified fact。

高级 PM / Architect 的目标不是让 AI “识别用户是谁”。更成熟的问题是:

What claims can the institution rely on for this purpose,
under which assurance and trust policy,
with which customer-mediated disclosure,
and what evidence proves the decision was proportionate, private and auditable?

---

3. Claim Taxonomy for AI Systems

AI 系统中的 identity-related information 至少分成六类。混用这些类别是身份架构的高风险根源。

设计上建议每个 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

字段命名要避免暗示模型推断等同事实:

---

4. Trust Architecture Model

参考架构:

issuer / authority / enterprise registry
  -> credential issuance and lifecycle controls
  -> holder wallet / credential repository
  -> wallet UX: purpose, consent, selective disclosure
  -> verifier / relying party presentation request
  -> 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 workflow / 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

---

5. DID / VC / Wallet Patterns Without Blockchain Assumption

Verifiable credentials 是一种 claim expression and verification pattern, 不是 blockchain 产品类别。DID 也是 identifier and verification-method pattern, 不是必须上链。

架构原则:

• 先定义 trust framework, 再选择 DID method 或 credential format。
• 先定义 RP policy 和 evidence needs, 再选择 wallet UX。
• 先定义 privacy/correlation threat model, 再决定 identifier persistence。
• 先定义 revocation/status model, 再决定 issuer operations。
• 先定义 recovery and accessibility paths, 再决定 mobile-only wallet。

判断底层技术时, 问题不是“去中心化程度够不够”, 而是:

Can the relying party verify the issuer, credential, subject binding and status;
can the holder disclose the minimum necessary;
can the ecosystem rotate keys and recover wallets;
can fraud teams detect abuse;
can governance teams audit decisions;
and can customers understand and contest outcomes?

---

6. Proofing Levels, Authentication Signals and Relying-Party Policy

NIST SP 800-63 的 IAL / AAL / FAL 对 AI wallet architecture 的价值在于拆开三个常被混淆的问题。

Passkeys / WebAuthn 的关键价值:

• 使用 RP-scoped public key credentials 降低 phishing and credential stuffing 风险。
• 通过 authenticator 提供用户同意、本地验证、attestation/context signals。
• 给 wallet access、credential presentation、high-risk disclosure 和 agent delegation 提供 step-up authentication signal。

但 passkey 信号不能回答:

• 客户是否就是证件上的人。
• 企业实控人是否真实。
• 年龄、收入、居住地、许可证是否仍然有效。
• 客户是否被诈骗或受胁迫。
• AI agent 是否被授权执行某个业务动作。

Relying-party policy 必须把 proofing/authentication/federation 分开建模:

required_claims
acceptable_issuers
minimum_assurance
acceptable_credential_formats
freshness_window
status_check_required
holder_binding_required
authentication_context_required
fraud_review_threshold
manual_exception_path
retention_and_evidence_rule
customer_explanation_rule

弱设计:

if credential_signature_valid then approve onboarding

强设计:

if signature valid
and issuer in accepted trust framework
and schema matches product policy
and claim status is current
and proofing assurance meets journey risk
and holder binding/auth context is sufficient
and fraud signals are within appetite
then accept claim for this purpose
else route to exception/review/fallback

---

7. Credential Verification Pipeline

Credential verification 不应由 LLM 自己完成。它应该是 deterministic verification service + policy engine + AI assist。

AI 可以参与:

• 向客户解释缺少哪些 claim。
• 把 issuer status code 翻译成内部可读原因。
• 总结 credential package for reviewer。
• 比对 customer-declared data 与 verified claims 的差异。
• 生成 exception queue 的 case summary。
• 识别 presentation pattern anomalies for review。

AI 不应单独:

• 判断 credential 是否 cryptographically valid。
• 决定 issuer 是否在 trust framework 内。
• 把 invalid / stale / revoked credential 改写为可接受。
• 生成 KYC/KYB 合规结论。
• 伪造或补全缺失 claim。
• 给客户暴露内部 fraud rules。

---

8. Verified Claims vs AI-Inferred Attributes

这一节是 AI identity architecture 的核心。AI 系统必须把 verified claims 和 inferred attributes 做成不同 data class、不同 UI、不同 policy path。

建议数据治理:

• verified_claim_store: 保存可验证 claim metadata and evidence references。
• inference_feature_store: 保存 AI/risk feature, 明确 model/source/uncertainty。
• decision_policy_store: 规定哪些 use case 可以用哪类输入。
• customer_explanation_store: 保存客户可理解的原因, 避免暴露 fraud secret。
• appeal_exception_store: 保存客户补充证明、人工复核和纠正路径。

推断属性进入 AI 模型前应带上限制:

inferred_attribute = true
not_for_identity_proofing = true
not_for_eligibility_decision = true unless policy-approved
requires_human_review_for_high_impact_use = true
source_and_uncertainty_required = true

---

9. Wallet UX and Consent Architecture

钱包 UX 不是一个“Connect Wallet”按钮。它是客户授权、最小披露、信任理解和证据生成的关键控制点。

客户文案应避免:

"AI will verify your identity."
"Sharing this credential guarantees approval."
"We only need your wallet."

更好的文案:

We will request only the claims needed for this application.
Your wallet will show what is being shared and with whom.
We will verify the credential and apply our product policy.
Some products may require additional review or evidence.

Consent 要与 authorization 区分:

• Consent: 客户允许展示或使用某些 claims for a purpose。
• Authentication: 客户证明当前 session / authenticator control。
• Authorization: 客户或员工允许某个 action 发生。
• RP acceptance: 机构决定 claim 是否满足该业务政策。

---

10. Revocation / Status / Refresh

Revocation 和 status 是 VC 生产架构中最容易被低估的部分。签名有效只说明 credential 没被篡改, 不说明 credential 仍可接受。

设计问题:

• status endpoint unavailable 时, 是否 fail closed、fail open、manual review、grace window?
• status check 是否会产生 verifier-customer correlation?
• revocation reason 是否可对 RP 或客户可见?
• credential 被撤销后, 已完成 onboarding 的账户如何做 lifecycle review?
• issuer key compromise 时, RP 如何批量识别受影响 cases?
• wallet 丢失、设备被盗、holder key rotation 如何处理?

Evidence 需要记录:

credential_id_or_hash
issuer_id
status_method
status_list_version
status_checked_at
status_result
cache_policy
freshness_policy
policy_decision
exception_reason

---

11. Fraud and Risk Architecture

Wallet + VC 不会自动消灭欺诈。攻击面会改变:

Fraud monitoring 指标:

• presentation velocity by wallet / issuer / device / RP。
• issuer error or revocation spike。
• credential package inconsistency rate。
• stale credential acceptance attempts。
• wallet recovery followed by high-risk action。
• manual review overturn rate。
• synthetic identity escape rate among wallet-onboarded customers。
• high-risk RP request abandoned after over-disclosure warning。

---

12. Agent Delegation and AI Wallet Use

Agentic AI 会让身份边界更复杂:

customer
  -> wallet
  -> customer-facing agent
  -> relying party
  -> verification service
  -> downstream onboarding / KYC / KYB system

设计原则:

1. Agent 不应直接持有客户长期 wallet private keys 或完整 credential vault。
2. Agent 可以准备 presentation request、解释缺口、组织申请材料, 但 disclosure 应由 holder-mediated consent 完成。
3. 高风险提交需要 action-bound approval: what, to whom, for what purpose, using which claims。
4. Agent identity 与 human identity 必须同时进入 trace。
5. Agent 只能消费 verification result and accepted claims, 不应自行决定 cryptographic validity。
6. 撤销 customer consent、agent capability、workflow run 或 RP session 时, 后续 presentation and tool calls 必须停止。

Agent delegation claim set:

弱模式:

Agent asks user to upload all documents and "handles identity verification".

强模式:

Agent explains required claims,
wallet mediates selective disclosure,
verification service validates credentials,
RP policy accepts or routes exceptions,
agent drafts next-step communication,
human/customer approves high-impact actions.

---

13. KYC / KYB and Customer Onboarding

Wallet-based onboarding 可以显著减少重复输入, 但不能把 VC 技术结果直接翻译成 KYC/KYB 合规结论。具体要求取决于机构、产品、jurisdiction、客户类型、风险等级、政策和法律/合规解释。

13.1 Individual Onboarding

13.2 Business Onboarding / KYB

AI 的角色:

• prefill application from accepted claims。
• identify missing or inconsistent evidence。
• summarize KYB package for operations。
• explain why additional proof is needed。
• route higher-risk cases to review。
• maintain evidence pack across refresh cycles。

AI 不应:

• 宣称 KYC/KYB “已合规完成”。
• 自行接受 AI-inferred beneficial owner。
• 因 claim 缺失自动做不可申诉拒绝。
• 使用客户未授权的 credential for cross-sell or unrelated profiling。

---

14. Product / Architecture Decisions

---

15. Control Matrix

---

16. Metrics

Balanced executive dashboard:

Friction: customers disclose less and finish faster.
Trust: accepted claims come from governed issuers with current status.
Risk: fraud and synthetic identity do not bypass controls.
Privacy: RP requests only what is needed.
AI safety: inferences are not treated as verified facts.
Evidence: every reliance decision is replayable.

---

17. Failure Modes

---

18. Interview-Ready Takeaways

Q1: VC 签名有效是否等于身份可信?

不等于。签名有效只证明 credential 没被篡改且可由某个 issuer key 验证。是否能依赖, 还要看 issuer 是否在 trust framework 内、proofing assurance、claim freshness、status/revocation、holder binding、product policy、fraud context 和合规解释。

Q2: AI 系统如何使用钱包凭证才专业?

AI 不应该自己验证凭证或做身份结论。架构上由 verification service 验 proof/status/schema, 由 RP policy engine 判断可接受性, AI 负责解释缺口、总结证据、识别不一致、辅助人工复核和生成客户沟通草稿。所有 inferred attributes 必须和 verified claims 分开。

Q3: Passkeys 在身份钱包里解决什么问题?

Passkeys / WebAuthn 主要证明当前用户控制某个 RP-scoped authenticator, 降低 phishing 和密码风险, 可用于钱包访问、presentation step-up 和 holder binding。它不证明真实世界身份属性, 也不证明客户未被诈骗或 credential 业务上可接受。

Q4: 如何避免 VC 钱包变成过度收集 PII 的新入口?

用 purpose-bound presentation request、selective disclosure、abstract claims、claim minimization、consent receipt、retention rules 和 fallback path。默认不请求完整证件, 只请求当前业务需要的最小 claim。

Q5: KYC/KYB 能否直接用 wallet credential 自动完成?

技术上可以减少采集和验证摩擦, 但不能直接得出合规结论。KYC/KYB 要求取决于机构、产品、jurisdiction、客户类型、风险等级、政策和 legal/compliance interpretation。钱包凭证是 evidence input, 不是最终合规判断。

---

19. Practical Templates

19.1 Credential Acceptance Card

19.2 AI Identity Input Classification

19.3 Wallet Presentation Request

Verifier:
Business purpose:
Requested claims:
Optional claims:
Why each claim is needed:
How long evidence is retained:
Whether data is used for AI model training:
Fallback path:
Customer review/withdrawal route:
Credential status check required:
Authentication step-up required:

19.4 Relying-Party Policy Decision Record

Decision ID:
Customer / business case reference:
Credential presentation ID:
Issuer:
Credential schema and version:
Claims accepted:
Claims rejected:
Verification result:
Status result:
Authentication context:
Fraud/risk result:
AI assistance used:
Human reviewer:
Decision reason:
Customer-facing explanation:
Retention/evidence reference:

---

20. Final Operating Principle

成熟的 AI digital identity wallet architecture 可以用一个问题检验:

Can the institution accept only the minimum verified claims it needs,
from issuers it has decided to trust,
under policy it can explain,
with authentication and fraud controls proportionate to risk,
while keeping AI inferences separate,
preserving customer consent and privacy,
and replaying the evidence behind every reliance decision?

如果答案不清楚, 企业不是缺一个 wallet integration。它缺的是 issuer trust、credential verification、relying-party policy、AI governance、fraud controls、privacy minimization、agent delegation 和 evidence replay 组成的 trust architecture。