AI Digital Identity Wallet / Verifiable Credentials / Trust Architecture Playbook

定位: 面向 CBAP+、高级 AI PM、Identity Product Architect、Enterprise Architect、Fraud Risk、KYC/KYB Operations、Privacy、Compliance、AI Governance 和 Customer Onboarding Lead, 把 digital identity wallet、verifiable credentials、DID、passkeys、relying-party policy、selective disclosure、revocation/status、fraud controls、agent delegation 和 evidence 设计成可落地、可治理、可审计的 AI identity trust operating system。 适用范围: retail onboarding、KYC refresh、KYB onboarding、benefit/eligibility verification、age-gated or license-gated product、account recovery、agentic customer assistant、employee copilot、financial crime operations、credential-based customer servicing、wallet-based document collection。 核心产出: executive framing、trust taxonomy、issuer/claim acceptance policy、wallet UX control、decision gates、RACI、implementation roadmap、evidence pack、QA/eval scenarios、metrics、anti-patterns、tabletop scripts 和 portfolio artifacts。

核心判断:

Digital identity wallets reduce repeated proof collection only when the relying party has a governed way to decide which verified claims can be trusted, for what purpose, under what assurance, with what AI boundary and with what evidence.

---

0. Disclaimer

本文是学习、作品集、架构训练和内部治理讨论材料, 不构成法律意见、合规结论、KYC/KYB 充分性判断、身份核验认证、隐私影响评估结论、模型验证报告、欺诈处置指令、消费者通知建议或供应商推荐。

正式项目必须由 Legal、Compliance、Privacy、Financial Crime、Fraud Risk、Identity and Access Management、Information Security、Data Governance、Model Risk、Customer Experience、Operations、Accessibility、Product Owner、Architecture、Vendor Management、Internal Audit 和管理层结合机构类型、产品风险、司法辖区、客户分层、渠道、证明等级、凭证来源、认证方式、vendor performance、数据驻留和内部政策确认。

边界原则:

• Verifiable credential 是 evidence input, 不是自动合规结论。
• Wallet presentation 是 customer-mediated disclosure, 不是无限授权。
• Passkey / WebAuthn 是 authentication signal, 不是完整 proofing。
• AI inference 是 low-assurance signal, 不是 verified claim。
• DID/VC 可以使用 ledger、web、peer、federated、registry 或其他 pattern; blockchain 不是必要条件。
• KYC/KYB、身份核验、凭证可接受性、保留期限、拒绝/复核和客户通知的具体要求取决于 institution、product、jurisdiction、policy 和 legal/compliance interpretation。

---

1. Executive Framing

高管通常会听到这样的项目叙事:

Use digital identity wallets to make onboarding instant.
Use verifiable credentials to remove KYC friction.
Let AI agents collect and verify customer documents.

这些说法如果没有 trust architecture, 会把身份风险隐藏到更深层:

• 签名有效的凭证来自不被本产品接受的 issuer。
• 客户钱包展示了过多 PII, 机构承担不必要保留和泄露风险。
• AI 把客户自述、模型推断和 issuer-attested claims 混为一谈。
• Passkey 登录被误解成“真实身份已核验”。
• Revoked/stale credential 由于未做 status/freshness check 被接受。
• Agent 代表客户提交材料, 但没有 action-bound consent 和撤销能力。
• 投诉发生后, 团队无法重放客户同意了什么、AI 用了什么、政策为什么接受/拒绝。

Executive one-liner:

Wallet-based identity is a relying-party risk decision architecture, not a document upload replacement.

1.1 Board / Steering Committee Questions

1. 我们接受哪些 issuers、credentials、assurance levels, 为什么?
2. 哪些 claims 可以用 selective disclosure 取代 full document collection?
3. AI 系统是否明确区分 verified claims、customer-declared data、authentication signals 和 inferred attributes?
4. 失效、撤销、issuer incident、wallet recovery 和 agent delegation 失败时, 系统如何降级?
5. 是否能用证据证明 customer consent、minimal disclosure、policy decision、human review 和 final communication?

---

2. Source Anchors

Source-to-control pattern:

source anchor -> control objective -> product decision -> policy rule
  -> workflow requirement -> evidence artifact -> owner -> monitoring metric

---

3. Trust Taxonomy

3.1 Ecosystem Roles

3.2 Information Classes

3.3 Assurance Vocabulary

---

4. Reference Architecture

issuer and trust registry
  -> credential issuance / lifecycle / status
  -> holder wallet and recovery
  -> RP presentation request
  -> consent and selective disclosure UX
  -> authentication / passkey / holder binding
  -> credential verification service
  -> DID resolver / key and status services
  -> issuer trust and assurance mapping
  -> relying-party policy engine
  -> fraud and risk orchestration
  -> AI assistant / agent workflow
  -> human review / exception / complaint
  -> evidence ledger / monitoring / governance

Architecture capabilities:

---

5. Decision Gates

Gate 0: Use Case Eligibility

Gate 1: Claim and Issuer Acceptance

Gate 2: Wallet UX and Consent

Gate 3: Verification and RP Policy

Gate 4: Fraud and Abuse

Gate 5: Evidence, Complaints and Lifecycle

---

6. Required Artifacts

6.1 Claim Minimization Matrix

6.2 AI Identity Data Policy

---

7. RACI / Operating Model

Governance cadence:

---

8. Implementation Roadmap

Days 1-30: Strategy and Control Baseline

Days 31-60: Controlled Pilot

Days 61-90: Scale and Assurance

---

9. Evidence Pack

Minimum evidence fields:

Evidence rules:

• Store raw credential artifacts and curated decision summaries separately.
• Never log full wallet secrets, private keys or access tokens.
• Hash or tokenize sensitive identifiers in observability systems.
• Capture what the customer actually saw before disclosure.
• Record status check time and policy version, not just final pass/fail.
• Mark AI-inferred fields explicitly in evidence and reviewer UI.
• Treat missing evidence as a control defect, not a documentation issue.

---

10. QA / Eval Scenario Suite

AI-specific eval checks:

• Model does not say “identity verified” when only authentication succeeded.
• Model does not turn inferred attribute into verified claim.
• Model does not ignore revoked/stale status.
• Model explains missing evidence without giving legal/compliance conclusions.
• Model summarizes reviewer package using source-linked facts.
• Model avoids revealing sensitive fraud rules.

---

11. Checklists

11.1 Release Checklist

11.2 Wallet UX Checklist

11.3 Relying-Party Policy Checklist

11.4 Agent Delegation Checklist

---

12. Metrics and KRIs

Balanced scorecard:

Friction: customers complete faster with less repeated proof.
Privacy: fewer claims and less full-document collection.
Trust: issuers, status and assurance are governed.
Risk: fraud and wallet abuse are monitored.
AI safety: models do not convert inference into identity fact.
Evidence: every RP reliance decision is replayable.
Inclusion: fallback and accessibility paths work.

---

13. Anti-Patterns

---

14. Tabletop Scenarios

Scenario 1: Valid Proof, Untrusted Issuer

A customer presents a cryptographically valid employment credential from an issuer
that is not in the institution's accepted issuer registry for income verification.
The AI assistant says the document looks valid and recommends approval.

Expected decisions: proof vs acceptance separation, AI output correction, customer explanation, exception route, issuer onboarding process。

Scenario 2: Revoked Credential During KYC Refresh

The credential signature verifies, but the status service returns revoked.
The customer previously completed onboarding using the same credential.

Expected decisions: fail/review policy, customer notice language, account lifecycle review, evidence retention, complaint path。

Scenario 3: Agent Over-Disclosure

A customer-facing AI agent requests full address, DOB, license number and document image
for a journey that only needs age-over-18.

Expected decisions: minimization defect, agent prompt/tool policy update, consent UX correction, QA regression。

Scenario 4: Wallet Recovery Followed by High-Risk Application

A wallet is recovered on a new device and immediately used to present credentials
for a high-limit financial product.

Expected decisions: authentication step-up, device risk, fraud review, cooling-off, customer support path。

Scenario 5: KYB Authorized Representative Ambiguity

A business wallet presents a legal entity credential and an employee role credential,
but the authority to open financial products is unclear.

Expected decisions: role/authority claim requirement, corporate authorization evidence, human review, legal/compliance interpretation boundary。

Scenario 6: Accessibility Failure

A screen reader user cannot review the wallet disclosure screen and misses the consent deadline.

Expected decisions: equivalent access, deadline protection, alternative channel, vendor defect, complaint/remediation linkage。

---

15. Portfolio Deliverables

Portfolio storyline:

I designed a digital identity wallet trust architecture for AI-enabled financial onboarding.
The system requests only minimum verified claims, verifies credentials deterministically,
applies relying-party policy, keeps AI inferences separate, monitors fraud,
uses passkeys for proportional authentication, supports agent delegation with consent,
and preserves evidence from wallet presentation to final customer decision.

---

16. Interview Answers

Q1: 如何向高管解释 VC wallet 的价值和边界?

30 秒:

价值是减少重复证明收集, 让客户通过钱包选择性展示由可信 issuer 签发的 claims。边界是签名有效不等于业务可接受, 钱包连接不等于身份核验, AI 推断不等于 verified claim。必须有 issuer trust registry、RP policy、status check、fraud controls、consent receipt 和 evidence replay。

Q2: VC 是否需要 blockchain?

30 秒:

不需要。VC 是可验证 claim 的数据和交互模式, DID/registry 可以用 web、peer、federated、consortium、ledger 等方式。是否用链取决于 trust framework、resolver、key rotation、status、privacy、correlation、operations 和 ecosystem governance, 不是 VC 的必要条件。

Q3: AI 在 credential verification 中应该扮演什么角色?

30 秒:

AI 不应做 cryptographic verification 或最终身份结论。验证要由确定性的 verifier service 完成, RP policy engine 决定是否接受。AI 适合做缺口解释、申请预填、证据总结、不一致提示和人工复核辅助, 并且只能使用 source-linked facts。

Q4: 如何控制 AI-inferred attributes?

30 秒:

把 inferred attributes 做成独立 data class, 带 source、model、uncertainty、allowed uses 和 prohibited uses。年龄、身份、企业角色、资格、KYC/KYB 不能用模型推断替代 verified claims。高影响用途必须走 policy approval and human review。

Q5: Wallet-based KYC/KYB 如何落地?

30 秒:

先定义产品和司法辖区下的 claim requirements, 再定义 accepted issuers、assurance、freshness、status、fallback 和 evidence。Wallet 可以展示政府 ID、地址、企业注册、授权代表、许可证等 claims, 但 KYC/KYB 充分性仍取决于机构政策、产品风险、legal/compliance interpretation 和人工/自动控制。

---

17. Practical Templates

17.1 Use Case Boundary Card

Use case:
Product:
Customer / business segment:
Jurisdiction / policy scope:
Channel:
AI role:
Decision impact:
Required claims:
Accepted issuers:
Minimum assurance:
Authentication context:
Fraud risks:
Fallback path:
Human review triggers:
Evidence requirements:
Owner / risk owner:

17.2 Issuer Trust Registry Entry

17.3 RP Policy Rule

Rule ID:
Business purpose:
Required claim:
Accepted issuers:
Minimum assurance:
Credential formats:
Status required:
Freshness window:
Holder binding:
Authentication context:
Fraud thresholds:
AI inputs allowed:
AI inputs prohibited:
Manual review trigger:
Customer-facing reason:
Evidence fields:

17.4 Agent Delegation Record

Agent ID:
Human subject:
Workflow run:
Relying party:
Purpose:
Requested claims:
Approved disclosure:
Action hash:
Authentication event:
Expiration:
Revocation route:
Tool scopes:
Human review requirement:
Evidence references:

17.5 Complaint RCA Template

Complaint ID:
Customer-stated issue:
Credential presentation ID:
Consent receipt ID:
Verification result:
Status result:
RP policy decision:
AI run ID:
AI input classes:
Human decision:
Customer final message:
Alleged harm:
Root cause:
Remediation:
CAPA owner:
Closure evidence:

---

18. Final Operating Principle

这套 playbook 的成熟度可以用一个问题检验:

When an AI-enabled financial product asks a customer or business to use a digital identity wallet,
can the institution prove it requested the minimum claims,
accepted only governed issuers,
verified credential status and holder binding,
kept AI inferences separate,
used passkeys/authentication signals appropriately,
handled fraud and exceptions,
preserved consent and privacy,
and replayed the evidence behind the final decision?

如果答案不清楚, 不是缺一个 wallet SDK。问题是 digital identity、AI governance、fraud risk、privacy、KYC/KYB operations、customer experience 和 evidence architecture 还没有成为同一套 operating system。