Microsoft Entra 验证 ID 简介
在当今世界，我们的数字生活和现实生活正日益与我们使用的应用、服务和设备交织在一起。 这场数字革命开辟了一个可能性的世界，使我们能够以曾经难以想象的方式与无数公司和个人联系。
这种连接性的增加带来了更大的身份盗窃和数据泄露风险。 这些违规行为对我们的个人和职业生活可能具有毁灭性。 Microsoft积极与各种组织和标准机构合作，创建分散式标识解决方案，使个人能够控制自己的数字标识。 分散式标识技术提供了一种安全且私密的方式来管理标识数据，而无需依赖集中式当局或中介。
为何需要分散式身份识别
如今，我们不管是工作还是生活都要用到数字身份，它存在于我们使用的每个应用、服务和设备当中。 这种身份由我们所说的、做和经历生活中的一切组成——购买活动门票、入住酒店，甚至订购午餐。 目前，我们的身份和所有数字交互都依赖于第三方，在某些情况下，即使没有我们的知识。
用户每天授予应用和设备对其数据的访问权限。 他们需要付出大量精力来跟踪谁有权访问哪些信息。 对企业来说，与消费者和合作伙伴的合作需要高度接触的业务流程，确保数据交换过程安全，保证所有参与方的隐私和安全。
我们相信，基于标准的分散式身份识别系统可以提供一种全新的体验，使用户和组织能够更好地控制其数据，并为应用、设备和服务提供商提供更高程度的信任和安全性。
领先的开放标准
Microsoft 正在与分散式身份识别基金会 (DIF) 成员、W3C 凭据社区集团和更广泛的身份识别社区积极合作。 以下标准在我们的服务中实现。
什么是 DID？
在我们了解分散式标识符 (DID) 之前，将它们与其他身份识别系统进行比较是有帮助的。 电子邮件地址和社交网络 ID 是用于协作的友好别名，但现在过度使用，作为数据访问控制点存在于许多协作之外的场景中。 这种情况会产生潜在问题，因为可以随时删除对这些 ID 的访问。 分散标式身份识别方法 (DID) 不同。 DID 是植于去中心化信任系统上的用户生成、自拥有的全局唯一身份识别方法。 它们具有独特的特征，比如更好的防篡改保障、删减对抗和改动规避。 这些特征对于旨在提供自行所有权和用户控制的任何 ID 系统至关重要。
Microsoft 的可验证凭据解决方案使用去中心化凭据 (DID)，以加密的方式签署身份验证，即信赖方（验证程序）需通过信息验证证明其是否为可验证凭据的所有者。 建议需要根据 Microsoft 产品/服务创建可验证凭据解决方案的用户对 DID 有一个基本的理解。
什么是可验证凭据？
我们在日常生活中都会用到 ID。 我们用驾照证明我们有操纵汽车的能力。 大学颁发学位证书证明我们的教育水平。 我们使用护照向当局证明我们的身份，当我们到达外国目的地时。 数据模型描述在互联网上工作时我们如何处理这类情形，但是是以尊重用户隐私的安全方式。 你可以在可验证凭据数据模型 1.0中获取更多信息。
简而言之，可验证凭据是由颁发者对使用者信息验证的声明组成的数据对象。 架构标识这些声明。 声明包括证书颁发者和使用者的 DID。 证书颁发者的 DID 生成数字签名，作为对该信息的证明
分散式身份识别的工作原理是什么？
我们需要一种新的身份识别方式。 我们需要一种身份识别方式，它能将技术和标准结合在一起，表现出如自我所有权和删减对抗的身份识别特征。 使用现有的系统难以实现这些功能。
为了满足这些承诺，我们需要由七个关键创新构成的技术基础。 一项密钥创新是用户拥有的标识符、用于管理与此类标识符关联的密钥的用户代理，以及加密的用户控制的数据存储。
1. W3C 分散式标识符 (DID)。 用户独立于任何组织或政府创建、所有和控制 ID。 DID 是全局唯一的标识符，链接到分散式公钥基础结构 (DPKI)，其元数据由 JSON 文档组成，包含公钥材料、身份验证描述符和服务终结点。
2. 信任系统。 为了能够解析 DID 文档，通常将 DID 记录在某种表示信任系统的基础网络上。 Microsoft 目前支持 DID:Web 信任系统。 DID:Web 是基于权限的模型，允许使用 Web 域的现有信誉进行信任。 DID：Web 处于支持状态“常规可用”。
3. DID 用户代理/钱包：Microsoft Authenticator 应用。 允许真人使用分散式身份识别和可验证凭据。 Microsoft Authenticator 创建 DID，辅助可验证凭据的颁发和演示请求，并通过加密的钱包文件管理 DID 种子备份。
4. Microsoft 解析程序。
一个 API，使用 did:web方法查找和解析 DID 并返回 DID 文档对象 (DDO)。 DDO 包含与 DID 关联的 DPKI 元数据，如公钥和服务终结点。
5. Microsoft Entra 验证 ID 服务。
Azure 中的颁发和验证服务以及使用 方法签名的 did:web的 REST API。 允许身份所有者生成、提供和验证声明。 此服务构成了系统用户之间的信任基础。
示例方案
我们用于说明可验证凭据的工作原理的方案包括：
- Woodgrove Inc. 公司。
- Proseware，一家为 Woodgrove 员工提供折扣的公司。
- Alice，是 Woodgrove，Inc. 的员工，想获得 Proseware 的折扣
今天，Alice 拿出用户名和密码，登录到了 Woodgrove 的网络环境。 Woodgrove 正在部署可验证凭据解决方案，为 Alice 提供更易管理的方式，以证明她在 Woodgrove 的就业状况。 Proseware 接受 Woodgrove 颁发的可验证凭据作为雇用证明，这些证明在公司折扣计划中可以提供对企业折扣的访问权限。
Alice 请求 Woodgrove Inc 提供雇佣证明可验证凭据。 Woodgrove Inc 证明 Alice 的身份，并提供一个已签名的可验证凭据，Alice 可以接受该凭据，并将其存储在数字钱包应用程序中。 Alice 现在可以在 Proseware 站点上提供此可验证凭据作为雇用证明。 成功展示凭证后，Alice 有资格获得 Proseware 的折扣。 该交易记录在 Alice 的钱包应用程序中。 日志条目帮助 Alice 跟踪她把就业证明的可验证凭证展示给哪些地方和哪些人。
可验证凭据解决方案中的角色
可验证凭据解决方案中有三个主要参与者。 在下图中：
- 在步骤 1 中，用户从颁发者那里请求可验证凭据。
- 在步骤 2 中，凭据的颁发者会证实用户提供的证明是否准确，并创建一个使用其 DID 签名的可验证凭据，用户的 DID 是其使用方。
- 在步骤 3 中，用户使用其 DID 签署可验证的演示文稿 (VP) 并将其发送到验证方。然后，验证方通过将其与 DPKI 中放置的公钥进行匹配来验证凭据。
此方案中的角色是：
颁发者
颁发者是从用户处请求信息以创建颁发解决方案的组织。 信息用于验证用户的身份。 例如，Woodgrove，Inc. 提供一个颁发解决方案，使他们能够创建 (VC) 可验证凭据并将其分发给所有员工。 员工使用其用户名和密码登录 Authenticator 应用程序，该应用程序将 ID 令牌传递给颁发服务。 Woodgrove，Inc. 验证提交的 ID 令牌后，颁发解决方案会创建一个 VC，其中包含有关员工的声明，声明经过 Woodgrove，Inc. 的 DID 签名。 员工现在就有了一个由雇主签署的可验证凭据，其中包括员工的 DID 作为使用者的 DID。
用户
用户是请求 VC 的人员或实体。 例如，Alice 是 Woodgrove 的一名新员工，此前她已被授予就业可验证凭据证明。 当 Alice 需要提供雇用证明以便在 ProseWare 上获得折扣时，她可以通过对可验证呈现签名，以证明 Alice 是该 DID 的所有者，从而授予对 Authenticator 应用中的凭据的访问权限。 Proseware 能够验证 Woodgrove 颁发的凭据和 Alice 的可验证凭据所有权。
验证方
验证方是公司或实体，需要验证其所信任的一个或多个颁发者发出的声明。 例如，Proseware 相信 Woodgrove，Inc. 为验证其员工的身份做了充足的工作，并颁发真实、有效的 VC。 当 Alice 试图订购她工作所需的设备时，Proseware 使用开放标准（如 Self-Issued OpenID 提供程序（SIOP）和 Presentation Exchange 来请求用户提供的凭据，证明他们是 Woodgrove， Inc 的员工。例如，Proseware 可能会向 Alice 提供一个指向网站的链接，其中包含她使用手机摄像头扫描的 QR 码。 这会为特定的 VC 启动请求，Authenticator 将分析该请求，并赋予 Alice 批准请求的能力，证明其雇佣 Proseware。 Proseware 可以使用可验证凭据服务 API 或 SDK 来验证可验证展示的真实性。 基于 Alice 提供的信息，他们就会为 Alice 提供折扣。 如果其他公司和组织知道 Woodgrove，Inc. 向其员工颁发 VCs，他们还可以创建一个验证解决方案，并使用 Woodgrove，Inc. 的可验证凭据，为 Woodgrove，Inc. 的员工提供专门优惠。
注意
验证程序可以使用开放标准来执行演示和验证，或 配置自己的Microsoft Entra 租户，让 Microsoft Entra 验证 ID 服务执行大部分工作。
后续步骤
了解 DID 和可验证凭据后，请按照入门文章或我们其中一篇讲述可验证凭据概念更多信息的文章自行体验。