Uber 如何规模化数字身份验证：从 Apple Wallet 证件到跨场景 Identity Verification Platform-北京尧图网络

本文是对 Scaling Verify with Wallet for Identity Verification at Uber 的整理与翻译。内容结构概览本文会围绕 Uber 如何将 Apple 的 Verify with Wallet API 接入并规模化到自己的身份验证平台展开主要包括为什么身份验证是 Uber Trusted Identity 组织的重要能力Uber 原有身份验证方式证件扫描、自拍、人脸和文档处理Apple Wallet 中的移动证件 mDocs、mDL、Photo ID 是什么Verify with Wallet 相比传统证件扫描有什么优势为什么它能减少用户摩擦、提升验证成功率隐私设计只请求必要数据不让用户过度分享Uber 面临的核心挑战多个 App、多个业务场景、不同数据需求Apple Entitlement 机制为什么让平台化设计变复杂Uber 为什么不能为每个场景做一次性集成整体架构Uber Apps、Identity Verification Service、PassKit / Wallet 验证流程App 端如何配置多个用例所需的 Entitlements为什么真正的 per-use-case scope enforcement 放在服务端NSIdentityUsageDescription 和 iOS 26.2 的 usageDescriptionKey服务端如何编排 data elements 和 IntentToStore平台无关 mapping layer从 Uber 内部身份模型到 PassKit 对象为什么这个 mapping layer 让系统更容易支持未来数字证件标准Apple Wallet 返回的数据如何解密HPKE、Identity Access Certificate、CBOR 分别承担什么角色session transcript 如何防止 replay attack三步验证MSO verification、device binding、issuer certificate chainIACA 证书为什么是政府背书数字身份的 trust anchorUber 如何维护和更新 IACA certificate registryAAMVA Digital Trust Service VICAL 的作用为什么证书轮换会影响身份验证系统的可靠性后续方向支持新数字证件类型和跨平台数字身份生态对后端、安全、移动和平台工程的启发一、身份验证为什么是 Uber 的核心能力Uber 是一个跨区域、跨产品、跨角色的平台。它不只是一个打车 App也包括 Uber Eats、Postmates、司机端、配送端、租车、商家、支付、年龄限制商品、合规审查等大量场景。这些场景背后有一个共同问题这个人到底是谁他是否满足当前业务要求身份验证对 Uber 至少有三类价值。第一支持市场扩张。不同国家、州、市有不同监管要求。要进入更多市场就必须满足当地对用户、司机、配送员、年龄限制商品、身份真实性等方面的规则。第二满足合规要求。比如驾驶资格、年龄验证、法律责任、平台安全、反欺诈、商家和用户保护都离不开可靠身份数据。第三提升平台信任。身份验证不是单纯为了“过审”它也是构建可信市场的基础。乘客、司机、配送员、消费者、商家之间的信任都依赖平台能够在合适场景下确认相关主体身份。Uber 的 Trusted Identity 组织负责这类能力。原有身份验证组合里已经包括内部文档扫描、自自拍摄、图像处理、人工或自动校验等方式。随着技术演进Uber 又将 Apple 的 Verify with Wallet API 接入到跨 App 的 Identity Verification Platform 中。这篇文章讲的就是这件事Uber 如何把 Apple Wallet 里的政府背书数字证件接入一个可扩展、可合规、可复用的身份验证平台。二、传统身份验证的问题不是不能用而是摩擦太大传统身份验证通常会让用户做这些事情找到实体证件打开 App 拍摄证件正面拍摄证件背面拍自拍等待图像上传等待 OCR / 图像识别等待防伪检测等待人脸和证件比对遇到光线、反光、模糊、遮挡、证件磨损时重新拍这种流程能解决很多问题但用户体验并不好。它会遇到用户找不到实体 ID证件照片模糊光线不足反光OCR 失败图像处理错误用户输入错误上传慢重试多转化率下降运营和客服成本上升对平台来说身份验证越重要流程就越不能随便。但对用户来说验证越复杂越容易中途放弃。所以一个理想方案应该同时满足两个目标安全可靠用户摩擦低Apple Wallet 中的数字身份能力正是为了解决这类问题提供了新的路径。三、mDocs、mDL 和 Photo ID移动钱包里的数字证件随着移动钱包技术演进Apple Wallet 这类应用不再只是存银行卡、票券和交通卡也可以存储移动数字证件。原文提到的几个概念包括mDocsmobile documents移动文档或移动证件 mDLMobile Driver’s License移动驾驶证 Photo IDs带照片的身份 ID这些数字证件不是用户自己随便拍一张证件照片放进手机。它们背后有政府签发机构、证书链、移动设备绑定、加密传输和标准化验证流程。用户可以在现实场景、App 内或网站上出示这些证件用于身份验证或年龄验证。对 Uber 来说这意味着用户不一定需要拿出实体证件拍照而可以直接通过 Wallet 完成数字身份分享。四、Verify with Wallet 是什么Apple 的 Verify with Wallet API 是在 WWDC 2022 引入的一套能力允许 App 请求用户在 Apple Wallet 中存储的数字身份信息。它和传统文档扫描不同。传统文档扫描的输入是“用户拍的照片”。Verify with Wallet 的输入是“来自 Wallet 中政府背书数字证件的数据”。这带来几个优势。第一用户体验更顺。用户不需要找证件、拍照、重拍而是在系统界面中确认要分享哪些身份信息。第二错误更少。传统扫描依赖图像质量、OCR、文档处理和用户操作。Wallet 数字证件可以减少很多图像处理错误。第三验证速度更快。原文强调这类集成让用户可以在几秒内完成 Uber 账号验证而不是几分钟。第四数据来源更可信。这些身份数据具有政府背书 provenance也就是来源可信性。第五隐私边界更清晰。App 请求哪些字段、请求多久、是否存储都可以明确展示和控制。所以 Verify with Wallet 对 Uber 的意义不是“多一种登录方式”而是把身份验证从“拍摄和识别证件图像”推进到“验证标准化数字证件数据”。五、隐私设计只请求必要数据不让用户过度分享这篇文章里一个非常重要的点是隐私。传统证件扫描常见问题是用户为了证明一个小事实可能不得不交出整张证件。比如某些场景只需要确认用户是否成年但实体证件上有姓名、生日、地址、证件号、照片等大量信息。如果直接拍整张证件就可能造成过度分享。Verify with Wallet 的设计更细。App 可以只请求完成当前交易所需的具体字段而不是要求用户把整张身份信息全给出去。原文强调App 只能请求完成交易所需的数据用户能清楚看到 App 要请求什么用户也能知道请求用途和保存期限发证机构和 Apple 都看不到用户何时、何地分享了 mDL 或 Photo ID这对身份验证平台非常关键。因为越是高信任身份系统越不能只关注“拿到更多数据”。真正成熟的身份系统应该遵循数据最小化原则能少要就少要能不存就不存只为当前用例请求必要字段。Uber 在集成 Verify with Wallet 时把这种隐私约束放进平台能力里而不是让每个业务团队自己处理。六、Uber 的复杂性不是一个 App、一个场景、一个字段如果 Uber 只有一个 App、一个验证流程那么集成 Verify with Wallet 会简单很多。但真实情况不是这样。Uber 有多个 App 和多个 marketplace segmentsUberUber EatsPostmates司机端相关流程配送相关流程年龄限制商品购买租车场景账号身份验证其他合规场景每个场景需要的身份数据不同。例如司机 onboarding 可能需要驾驶资格和更多身份信息年龄限制商品下单可能只需要年龄或出生日期相关信息租车场景可能需要驾驶证相关信息账号验证可能只需要确认身份和部分字段所以 Uber 面临的不是“能不能调用 Apple API”而是如何让一个统一身份验证平台支持多 App、多业务、多数据元素、多合规边界同时保证每个用例只请求它被批准的数据。这就是文章的核心工程挑战。七、Apple Entitlement 机制带来的平台设计难题Verify with Wallet 通过 App-level Entitlement 配置来支持不同身份数据元素。简单说App 要请求某些身份字段需要在 entitlement 中声明并且每个数据元素都要根据具体用途经过 Apple 审批。这意味着一个 App 可能被允许请求一组字段但某个具体业务用例只能请求其中一部分字段举个简化例子。假设 Uber App 总体被批准可以请求姓名出生日期驾驶证相关信息照片地址但某个年龄验证用例也许只应该请求是否达到年龄要求出生日期或年龄相关字段它不能因为 App entitlement 中有更多字段就顺手请求全部字段。所以平台必须同时满足两个要求足够灵活能支持任意组合的已批准数据元素足够严格每个具体 use case 不能超出自己的批准范围这正是为什么 Uber 把 per-use-case enforcement 放在服务端而不是只依赖 App 端配置。八、整体架构App 发起Identity Verification Service 编排Wallet 返回数据原文的架构图展示了 Uber 的 Verify with Wallet 集成流程。可以简化成Uber Apps ↓ Identity Verification Service ↓ PassKit / Verify with Wallet API ↓ Apple Wallet 数字证件 ↓ 加密响应 ↓ Uber 后端解密和验证 ↓ Uber 内部身份验证流程这里面最关键的是 Identity Verification Service。它不是一个简单 proxy而是平台化编排核心。它负责根据 use case 决定请求哪些 data elements根据服务端配置生成身份请求控制 IntentToStore把 Uber 内部身份模型映射到 PassKit 需要的对象校验返回数据是否符合当前 use case 配置解密 Apple Wallet 返回 payload执行 ISO/IEC 18013-5 相关验证验证证书链和政府签发机构 trust anchor将可信数据交给 Uber 内部身份检查流程也就是说移动端负责发起和展示用户授权体验但真正的合规边界、安全验证和平台抽象主要在后端。九、App 端配置一个 App 包含多个用例的 EntitlementsUber 的每个 App 都包含一个 Entitlements file。这个文件包含该 App 所有相关用例需要的身份元素集合。但这不表示每个用例都可以请求全集。真正的 per-use-case scoping 由 Uber Identity Verification Service 在后端执行。这种设计有一个明显好处App 端可以具备完整能力但每次请求的实际数据范围由服务端配置严格控制。这样可以支持平台扩展。当 Uber 新增一个已批准的用例时不一定需要重写整个 App 集成逻辑。服务端可以根据 use case 配置编排数据元素。同时它也保护隐私和合规。即使 App entitlement 覆盖了更多字段服务端也会确保当前请求只包含该用例预先审查过的数据元素。十、NSIdentityUsageDescription告诉用户为什么请求身份信息iOS 应用请求身份信息时需要向用户解释原因。原文提到每个 App 都配置了NSIdentityUsageDescription它是一段消息用来告诉用户 App 为什么请求身份信息。这类似很多 iOS 权限请求里的说明文本。比如请求相机权限时App 要说明为什么要用相机请求身份信息时也要说明用途。但 Uber 的问题是一个 App 中有多个身份验证用例不同用例的说明应该不同。司机 onboarding、年龄验证、租车、账号验证不应该都显示同一段泛泛说明。因此原文提到 iOS 26.2 引入了新的usageDescriptionKey这个 API 允许服务在配置PKIdentityRequest时为不同用例定制说明消息。这让用户看到的解释更贴近当前场景。比如当前是年龄验证就解释为什么需要年龄信息当前是租车就解释为什么需要驾驶证相关信息这也是隐私体验的一部分。用户不只是被动授权而是知道当前请求和当前交易之间的关系。十一、服务端编排 data elements 和 IntentToStoreUber 的 Identity Verification Service 使用服务端配置管理请求流程。这些配置定义两类核心信息。第一类是 data elements。也就是当前 use case 要请求哪些身份数据字段。比如姓名年龄或生日证件类型驾驶证字段照片地址其他经过批准的数据元素第二类是 IntentToStore。它表示数据是用于一次性验证还是需要长期保存。这是一个非常重要的隐私和合规参数。很多场景中平台可能只需要确认某个事实而不需要长期保存原始身份数据。比如只需要确认“用户满足年龄要求”那就不应该长期保存更多证件字段。而另一些场景可能因为法律、合规或业务原因需要持久化部分信息。所以 IntentToStore 的存在让系统能够明确区分只访问一次用完即走需要存储用于长期合规或业务流程Uber 将这些决策放在服务端配置中避免业务团队在客户端随意组合字段和保存策略。十二、mapping layer把 Uber 内部身份模型映射到 PassKit 对象为了保持架构可扩展Uber 实现了一个 mapping layer。它负责把 Uber 内部 identity configuration objects 转换成 PassKit / Verify with Wallet API 需要的领域对象。原文提到的例子包括PKIdentityIntentToStore这个 mapping layer 很重要。如果 Uber 的业务逻辑直接依赖 Apple 的 API 对象那么系统会变得 vendor-specific。未来如果要支持其他数字身份提供方或者支持其他符合 ISO/IEC 18013-5 的方案就会很难拆。所以 Uber 选择把内部模型和 vendor API 解耦。简化理解Uber 内部身份配置模型 ↓ mapping layer PassKit-specific 对象未来如果接入其他标准兼容的身份系统可以再实现另一个 mappingUber 内部身份配置模型 ↓ mapping layer 其他数字身份 API 对象这就是平台化的意义。它不是为了一个 Apple API 写一次性代码而是为未来数字身份生态预留扩展能力。十三、服务端返回校验不能相信客户端也不能只相信字段存在当 Wallet 返回数据后Uber 后端会进行多层验证。第一层是配置匹配验证。也就是说服务端会确认返回的数据元素是否和当前 use case 预期配置一致。如果当前用例只被允许请求某几个字段返回内容也应该严格匹配这些字段范围。这可以防止意外越权、配置错误或集成错误。第二层是密码学验证。因为数字证件不是普通 JSON 数据不能只看字段格式。必须验证数据来源、完整性、设备绑定、证书链和有效期。所以 Uber 在收到响应后会对每个 data element 执行 cryptographic validations确保其 origin 和 integrity。这就是数字身份和普通表单输入的区别。普通表单输入只是一段用户提供的数据。数字身份数据必须能证明它来自可信签发机构没有被篡改属于授权设备对应当前会话证书链可信仍在有效期内十四、解密 Apple Wallet payloadHPKE、证书和 CBORApple Wallet 返回的身份数据不是明文返回给 Uber。它会经过加密。原文提到传输中的安全依赖HPKEHybrid Public Key EncryptionRFC 9180当移动 App 发起请求时响应会使用 App 的 Identity Access Certificate 加密。这个证书来自 Apple Developer 网站生成。Uber 后端收到响应后使用相应能力解密 payload。payload 编码格式是CBORConcise Binary Object RepresentationCBOR 是一种紧凑二进制对象表示格式。相比 JSON它更适合小体积、高效率地传输结构化数据。所以这条链路可以理解成Wallet 生成身份响应 ↓ 使用 Identity Access Certificate 加密 ↓ 以 CBOR 编码身份数据 ↓ Uber 后端解密 ↓ 解析并验证这里的重点是身份数据在传输过程中不是普通明文对象而是经过标准化加密和紧凑二进制编码。十五、session transcript防止响应被拦截后重放原文特别提到一个关键结构session transcript它把响应绑定到特定交易。session transcript 组合了unique generated noncerequesting client identifierspublic key hash它的作用是建立一个密码学绑定让这次响应只对这次交易有效。这可以防止 replay attack。什么是 replay attack攻击者如果截获了一次合法响应尝试在另一个请求中重复使用这份响应就叫重放攻击。没有 session binding 的系统可能会被这种方式欺骗响应本身是真的但不是为当前这次请求生成的。session transcript 的作用就是让响应和当前会话绑定这份数据是为这个客户端、这个 nonce、这个公钥上下文生成的不能拿到别处重复使用这对身份验证非常重要。因为身份凭证不是只要“看起来有效”就够了还必须证明它和当前验证流程绑定。十六、三步验证MSO、设备绑定、签发机构证书链解密后Uber 的 Identity Verification Service 会执行三步验证。第一步MSO verificationMSO 是Mobile Security Object它包含用于验证移动证件数据完整性和有效性的关键信息。MSO verification 要确认数据自签发以来没有被修改当前日期在 MSO 有效期内这一步解决两个问题。第一数据是否被篡改。第二凭证是否仍然有效。如果证件数据被修改或者 MSO 已过期就不能继续信任。第二步Device binding设备绑定验证会用 MSO 中的 public key 来验证 device signature。这一步的目标是确认这份 ID 是由原始授权设备出示的不是伪造 payload 不是从别处复制过来的数据移动数字证件不只是“一个文件”。它应该和持有它的设备绑定。如果没有设备绑定攻击者可能复制某个数据包到另一台设备或另一个环境使用。Device binding 让数字证件验证更接近真实世界中的“本人持证出示”而不是简单传输一份静态数据。第三步Issuer certificate chain第三步是验证签发证书链。系统会确认签名证书链能追溯到可信 IACA root certificate。IACA 是Issuing Authority Certificate Authority可以理解成发证机构证书权威。它是政府背书数字身份体系中的 root of trust。验证证书链的意思是这份证件数据是由可信签发机构签发的签名链条能一路追溯到受信任的根证书只有通过这一步Uber 才能确信凭证具有政府签发来源而不是某个第三方伪造的数字对象。十七、IACA政府背书数字证件的信任根IACA certificate 是整套验证链路里的 trust anchor。没有可信根证书系统就不知道该信任谁。这和浏览器 HTTPS 证书有点类似。浏览器之所以信任某个网站证书是因为它能追溯到受信任 CA。数字身份系统也需要类似机制某个数字驾驶证或 Photo ID 的签名必须能追溯到受信任的签发机构根证书。在 Uber 的场景里这些 IACA 证书来自各个受支持签发机构。原文提到Uber 维护了一个 IACA certificate registry用于保存每个支持签发机构的证书。这些 trust anchors 来源包括官方 jurisdiction portal例如 DMV 网站 AAMVA Digital Trust Service VICAL其中 AAMVA Digital Trust Service VICAL 是 Verified Issuer Certificate Authority List用于聚合北美 motor vehicle administrators 的证书。这说明 Uber 不是只接一个证书而是要长期维护多个地区、多个签发机构、多个版本证书的信任列表。十八、为什么证书轮换是一个平台问题证书不会永远不变。政府签发机构可能会发布新的 root certificate轮换 authority key废弃旧证书吊销某些证书更新基础设施接入新的数字证件标准如果 Uber 的系统只支持每个 jurisdiction 一个固定证书就很容易在证书轮换时中断验证。例如某州更新了 root certificate。新签发的 ID 使用新证书签名。旧 ID 仍然使用旧证书签名。如果系统只信任新证书旧 ID 可能被误拒。如果系统只信任旧证书新 ID 又可能无法验证。所以 Uber 的 registry 支持每个 jurisdiction 多个 active certificates这可以保证旧 key 签发的 ID 仍然有效新 key 签发的 ID 同时可接受这就是平台可靠性的体现。身份验证系统不能因为某个州轮换证书就突然大面积失败。十九、Uber 如何保持 trust registry 更新原文提到Uber 和 key ecosystem partners 密切合作保持 registry 最新。这包括ingestion of new authority keysdeprecation of revoked certificates跟踪官方 jurisdiction portal接入 AAMVA VICAL支持证书轮换保证验证逻辑不中断这是一项长期运维能力。很多人理解数字身份时只关注一次验证流程请求、授权、返回、解密、验证。但真正规模化后更难的是如何长期维护信任根。如果 trust anchor 过期、缺失、轮换处理错误整套数字身份验证就可能失败。所以 Uber 的方案不只是“接入 Apple Wallet”还包含一套 certificate lifecycle management 策略。二十、为什么 Uber 要把它做成平台而不是一次性接入这篇文章反复强调 platform。原因很简单Uber 的身份验证需求太多不适合每个 use case 各写一套。如果每个场景都做一次性集成会出现这些问题每个团队重复理解 Apple API 每个团队重复处理 entitlement 和字段范围每个团队重复做 HPKE 解密和 CBOR 解析每个团队重复做 ISO/IEC 18013-5 验证每个团队重复维护 IACA 证书每个团队重复处理 IntentToStore 每个团队重复处理 privacy scope 每个团队重复处理错误和合规风险这会导致系统碎片化也会增加安全风险。Uber 的做法是把这些能力集中到 Identity Verification Platform一次实现底层安全能力多个 App 和 use case 复用服务端配置控制每个用例 mapping layer 解耦 vendor API trust registry 统一维护这样未来新增用例时只需要在平台框架下配置和扩展而不是重新造一个验证系统。二十一、下一步支持更多数字证件类型原文提到随着数字身份文档 adoption 继续发展Uber 会继续扩大 Verify with Wallet 集成的覆盖范围和技术能力。第一个潜在方向是Support new digital document types也就是支持新的数字证件类型。文章特别提到 Photo IDs且这些证件可能遵循ISO/IEC 23220-2这说明 Uber 并不只看 mDL也在关注更广泛的高可信数字凭证。未来数字身份生态可能不只是驾驶证也可能包括Photo ID国家或地区身份凭证年龄证明其他政府背书高可信凭证Uber 的平台要能容纳这些新类型同时继续保持高真实性、安全性和隐私保护标准。二十二、下一步跨平台支持和开放标准第二个方向是Cross-platform support也就是加深与全球身份解决方案的集成尤其是那些遵循 ISO/IEC 18013-5 和更广泛 digital credentials ecosystem 的方案。这点很重要。Apple Verify with Wallet 是一个强入口但 Uber 不希望自己的身份验证平台只绑定某一家供应商或某一种设备生态。平台要面向未来就必须支持开放标准支持不同平台支持不同国家和地区的数字身份体系支持不同数字证件类型保持内部模型和外部 API 解耦支持标准兼容的验证流程这也是前面 mapping layer 和 ISO/IEC 18013-5 兼容设计的意义。Uber 要构建的不是“Apple Wallet 验证小功能”而是“政府背书数字凭证验证平台”。二十三、这次集成对用户体验意味着什么从用户角度看这件事最直观的变化是身份验证可以从几分钟变成几秒不需要找实体证件不需要拍照不需要反复重拍不需要提交过多身份信息能清楚看到当前 App 请求哪些信息这对转化率非常重要。每一个身份验证流程都是用户旅程中的摩擦点。如果摩擦太大一部分用户会退出。比如司机注册流程中途放弃用户年龄验证失败导致无法下单租车流程因为证件拍摄问题卡住账号验证反复失败Verify with Wallet 的价值在于把这些摩擦降低。但它不是以牺牲安全为代价换体验。相反它通过政府背书数字身份、设备绑定、证书链、HPKE 加密、session transcript 等机制提高了验证可信度。这就是一个好的身份验证体验应该做到的用户感觉更简单系统实际更严格二十四、这次集成对隐私意味着什么隐私层面最重要的是数据最小化。传统证件扫描经常是整张证件提交。而 Verify with Wallet 允许 App 请求具体所需数据元素。对于 Uber 来说这意味着不同 use case 可以有不同请求范围。年龄验证不必拿到过多驾驶证字段。一次性验证不必默认长期保存。App entitlement 覆盖范围大不代表每个 use case 都能用全部字段。再加上 Apple 和 issuing authority 都看不到用户何时何地分享了 mDL 或 Photo ID这进一步降低了隐私暴露面。所以这套方案的隐私价值不只是“数据加密”还包括明确请求字段明确用途说明明确保存意图每个场景只请求必要数据服务端强制 scope减少过度分享避免签发机构或平台方看到分享上下文这对现代身份系统非常重要。二十五、这次集成对安全意味着什么安全层面Uber 的方案覆盖了几个关键方向。1. 传输安全使用 HPKE 加密 payload确保身份数据传输过程中受到保护。2. 数据完整性通过 MSO verification 确认数据自签发以来没有被修改。3. 有效期通过 MSO validity period 检查当前日期是否在有效期内。4. 设备绑定通过 device signature 和 MSO 中的 public key确认凭证来自原始授权设备。5. 防重放通过 session transcript 绑定当前 transaction防止截获响应后重复使用。6. 签发机构真实性通过 issuer certificate chain 验证证书链可追溯到可信 IACA root certificate。7. Trust anchor 生命周期通过 registry 和证书轮换机制长期维护可信根证书集合。8. Use-case scope enforcement通过服务端配置确保当前场景不会请求超出批准范围的数据。所以安全不是单点措施而是端到端链路请求配置用户授权加密传输解密解析会话绑定数据完整性设备绑定证书链根证书管理内部身份检查这才是高可信身份验证系统的完整形态。二十六、从后端工程角度看这篇文章讲的是“平台抽象”如果你是后端工程师这篇文章最值得学的是抽象边界。Uber 没有直接在业务流程里写调用 Apple Verify with Wallet 拿字段做验证存结果而是把能力拆成平台层use case configuration data element orchestration IntentToStore mapping layer PassKit object generation payload decryption ISO/IEC 18013-5 validation IACA registry certificate rotation internal identity checks这使得它可以支持多个业务而不是被一个用例绑死。这也是大型平台工程的基本思路不要围绕某个当前功能写死流程而要围绕领域模型和稳定边界构建平台。在这里稳定边界不是 Apple API而是Uber 需要验证用户身份不同 use case 需要不同数据元素请求范围必须合规数据必须可验证保存意图必须明确数字证件生态会继续演进Apple Verify with Wallet 是当前集成对象之一但平台本身要面向更长远的数字身份生态。二十七、从移动端角度看用户授权体验和服务端配置要配合移动端在这个流程里非常重要但它不应该承担所有合规逻辑。App 需要配置 Entitlements设置 NSIdentityUsageDescription发起 PKIdentityRequest让用户看到要分享的数据接收 Wallet 响应将响应安全传给后端但真正的 use-case scoping、字段编排、IntentToStore、加密 payload 验证、证书链和 trust anchor 管理都在服务端。这是一种合理分工。移动端负责用户体验和系统 API 调用。服务端负责合规、安全、平台化和验证结果落地。尤其在 Uber 这种多 App、多用例系统里如果把大量规则写死在客户端会带来版本发布和一致性问题。服务端配置能让平台更灵活也更容易审计和更新。二十八、从安全工程角度看标准和证书生命周期是重点如果你是安全工程师这篇文章里最重要的关键词是ISO/IEC 18013-5 HPKE CBOR MSO Device Binding Session Transcript IACA Certificate Chain VICAL Certificate Rotation这些不是装饰性术语而是数字身份系统的安全骨架。传统身份验证很多时候依赖图像识别和业务规则。数字身份验证则更像证书和密码学系统。你需要关心标准是否正确实现payload 是否正确解密会话是否绑定数据是否被篡改设备是否可信证书链是否可信根证书是否最新吊销和轮换如何处理过期凭证如何拒绝老证书和新证书如何并行接受use case 是否越权请求数据这说明数字身份验证不是一个纯业务功能而是安全基础设施。二十九、这篇文章和 Uber 其他工程文章的共同点如果你看过 Uber 最近几篇工程文章会发现它们有一个共同特点不只是解决一个局部问题而是把问题平台化。比如Go 栈优化文章里他们不是手工调某个服务而是做 profile-guided stack-size tuning数据库过载文章里他们不是写一个限流器而是做 Unified Load Shedding EngineOpenSearch gRPC 文章里他们不是写一个 Gateway 转换层而是推动原生 gRPC transport 和 schema 生成 pipeline这篇身份验证文章里他们不是一次性接入 Apple API而是把 Verify with Wallet 纳入 Identity Verification PlatformUber 的工程风格是先找到高价值场景然后抽象成平台能力再把配置、安全、可观测性、扩展性和长期演进一起考虑这也是大规模工程系统和普通功能开发最大的区别。三十、对普通团队有什么启发即使你的团队没有 Uber 的规模这篇文章也有很多启发。第一不要把身份验证当成“上传证件照片”这么简单身份验证是信任基础设施。它涉及用户体验、合规、安全、隐私、数据保存、证书和风控。第二数据最小化要内建到平台里不要让每个业务团队自己决定“多拿点数据以防以后要用”。正确做法是用平台能力限制每个 use case 请求必要字段。第三服务端配置比客户端写死更适合多场景如果身份验证场景多字段和保存策略应该服务端配置化。否则每次调整都要发版且容易出现 App 之间行为不一致。第四vendor-specific API 要隔离今天接 Apple Wallet明天可能接其他数字身份系统。内部 identity model 不应该直接被某个外部 API 对象污染。第五证书轮换必须从第一天考虑如果系统依赖政府或机构证书链就必须维护 trust anchor lifecycle。不要等证书轮换导致线上验证失败时再补。第六数字身份系统要同时关注 UX 和密码学用户流程越简单越好但后端验证不能简单。好的设计应该是前端体验顺滑后端验证严格。第七平台能力要支持未来标准数字身份生态还在发展。基于 ISO/IEC 18013-5、ISO/IEC 23220-2 这类标准做抽象比绑定某一个供应商更稳。三十一、我的理解这是数字身份从“拍照识别”到“凭证验证”的转变我觉得这篇文章最核心的变化是身份验证正在从 document scanning 走向 credential verification。过去系统经常做的是用户拍一张证件照片系统识别图像系统判断这张图是否像真的系统提取字段系统做业务验证未来越来越多场景会变成用户从数字钱包选择要分享的身份数据系统验证这份数字凭证的签名、设备绑定和证书链系统只接收当前交易需要的数据元素系统做业务验证前者重点是图像处理和防伪。后者重点是数字凭证、密码学、证书链、隐私控制和标准互操作。这不是简单的体验升级而是身份验证模型的变化。传统证件扫描像是在“看一张图片是不是可信”。Verify with Wallet 更像是在“验证一份由政府签发并由设备安全呈现的数字凭证”。这也解释了为什么 Uber 要把它做成平台。因为数字身份未来会继续扩展更多国家和地区更多证件类型更多钱包和平台更多标准更多 use case更严格的隐私和合规要求如果今天只做一个一次性集成明天就会被新场景拖垮。三十二、总结Uber 这篇文章讲的是他们如何将 Apple 的 Verify with Wallet API 接入并规模化到自己的 Identity Verification Platform。身份验证是 Uber Trusted Identity 组织的重要能力服务于市场扩张、合规、法律责任和平台信任。传统证件扫描和自拍验证虽然可用但用户摩擦较大容易受到图像质量、OCR、证件拍摄错误等因素影响。随着 Apple Wallet 支持 mDocs、mDL 和 Photo IDsUber 采用 Verify with Wallet 作为新的数字身份验证方式。它允许用户通过 Wallet 分享政府背书的数字身份数据让验证从几分钟缩短到几秒同时减少用户寻找实体证件、拍照和重试的成本。这套能力的核心优势不仅是方便还包括隐私和安全App 只请求完成当前交易所需的数据用户可以看到请求哪些身份信息以及用途 Apple 和发证机构看不到用户何时何地分享身份信息 payload 使用 HPKE 加密数据以 CBOR 编码 session transcript 防止重放攻击服务端执行 ISO/IEC 18013-5 标准相关验证Uber 面临的工程挑战在于它有多个 App 和多个业务场景每个场景需要不同身份数据。司机 onboarding、年龄限制商品、租车、账号验证等用例的字段范围不同而 Apple 的 Entitlement 需要每个 data element 根据用途审批。因此Uber 没有做一次性集成而是把 Verify with Wallet 纳入 Identity Verification Platform。每个 App 的 Entitlements 覆盖所有获批能力但真正的 per-use-case scoping 在服务端 Identity Verification Service 中执行。服务端通过配置管理 data elements 和 IntentToStore并通过 mapping layer 将 Uber 内部身份模型转换成 PassKit 所需对象同时保持对未来 ISO/IEC 18013-5 兼容集成的扩展能力。在安全验证上Uber 后端会解密 Wallet 返回的 payload并执行三步验证MSO verification确认数据未被篡改且仍在有效期 Device binding验证设备签名确认凭证来自授权设备 Issuer certificate chain验证签发证书链可追溯到可信 IACA root certificate为了长期保持信任链Uber 维护 IACA certificate registry从官方 jurisdiction portals 和 AAMVA Digital Trust Service VICAL 等来源获取 trust anchors并支持同一 jurisdiction 多个 active certificates以处理政府签发机构的 root certificate 和 authority key 轮换。未来Uber 计划支持更多数字证件类型例如符合 ISO/IEC 23220-2 的 Photo IDs同时继续扩展跨平台数字身份能力面向更广泛的政府背书数字凭证生态。这篇文章真正的启发是数字身份验证不是简单“调用 Wallet API”。大规模平台需要同时处理用户体验、隐私最小化、服务端字段编排、密码学验证、证书链、信任根更新、标准兼容和未来扩展。Uber 的做法是把一次身份验证能力抽象成可复用的身份验证平台。这也是大规模工程系统最值得学习的地方不是把某个 API 接通就结束而是把它变成一个能服务多个业务、多个 App、多个国家地区和未来标准演进的平台能力。参考资料Scaling Verify with Wallet for Identity Verification at Uber

Uber 如何规模化数字身份验证：从 Apple Wallet 证件到跨场景 Identity Verification Platform

相关推荐

WebP图片质量不调，体积大得离谱

Docker run/exec/attach 命令区别 + 容器资源限制实战

本地AI图像视频生成工具部署指南：从环境配置到批量任务实战

更多资讯

3步搞定FreeTube错误报告：让开发者快速定位问题的实用指南

告别隐私泄露：FreeTube安全更新机制全解析

告别信息过载：用FreeTube订阅分组打造专属视频流

解锁影院级体验：FreeTube音频增强全攻略

告别卡顿！FreeTube双版本无缝切换：稳定版与测试版全指南

如何让你的旧 Mac 跑起最新 macOS：OCLP 完整使用教程（含排错）

今日更新

多智能体协作系统架构设计与实践优化

大模型系统性入门实战指南：从原理到部署微调的全链路路线

鸿蒙文件系统沙箱机制解析与开发实践

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？