概述
笔者在日常工作和生活当中，频繁使用微软验证器(Microsoft Authticator, MA)这个APP软件(Android版本)。笔者原来使用的是Google的验证器软件，但发现微软的验证器功能更加强大，而且兼容谷歌验证程序，并且提供一些额外的功能。这样，这个软件就变成了笔者日常使用的验证器软件。
通常使用的验证器功能原理非常简单，就是一个TOTP程序。当验证器项目配置的时候，它会使用一个和应用程序服务端用户相同的密钥，定时生成相同的OTP编码，就可以作为一个第二个验证因子，来提高验证过程的安全性。关于这个模式，笔者有其他的文章已经有所讨论，这里不再赘述。
本文想要讨论的问题，是笔者在验证器程序中，发现的另外一个比较令人感兴趣的功能，就是名为"已验证ID"的功能模块(下图)。笔者很早就注意到这个功能，但始终没有找到在可以应用和体验的场景。最近由于在研究PasswordLess认证相关的问题，刚好接触到一篇文章，讨论了已验证ID这个技术，然后就根据其中的描述和引导，自己体验了一些这个过程，也觉得可以讨论和分享出来，遂有本文。
验证ID技术
笔者发现，微软验证器"验证ID"相关的功能，其实是在微软的技术体系中，其实是其"Microsoft Entra Verified ID "技术的一个部分。相关技术文档的链接如下：
Microsoft Entra 外部 ID 文档 - Microsoft Entra External ID | Microsoft Learn
关于这部分的内容，笔者自己也在逐步的阅读和理解当中。感觉到它将扩展成为一个更大的技术体系，名为分布式身份识别(Decentralized Identity, 直译应为去中心化标识？)。其基本架构和原理如下：
-
- W3C 分散式标识符 (DID)
用户独立于任何组织或政府创建、所有和控制ID。 DID 是全局唯一的标识符，链接到分散式公钥基础结构 (DPKI)，其元数据由 JSON 文档组成，包含公钥材料、身份验证描述符和服务终结点。
-
- 信任系统
为了能够解析 DID 文档，通常将 DID 记录在某种表示信任系统的基础网络上。 Microsoft目前支持 di：web 信任系统。 did：web 信任系统是基于权限的模型，允许使用 Web 域的现有信誉进行信任。 did:web 的支持状态为正式发布。
-
- DID 用户代理/钱包
例如： Microsoft Authenticator 应用。允许真人使用分散式身份识别和可验证凭据。 Microsoft Authenticator 创建 DID，辅助可验证凭据的颁发和演示请求，并通过加密的钱包文件管理 DID 种子备份。
-
- Microsoft 解析程序
一个 API，使用 did:web方法查找和解析 DID 并返回 DID 文档对象 (DDO)。 DDO 包含与 DID 关联的 DPKI 元数据，如公钥和服务终结点。
- Microsoft Entra 验证 ID 服务
Azure 中的颁发和验证服务以及使用 did:web 方法签名的 W3C 可验证凭据的 REST API。 允许身份所有者生成、提供和验证声明。 此服务构成了系统用户之间的信任基础。
为了便于说明和理解，文中还提供了一个模拟实际应用场景的示例方案、流程和示例应用站点。这正好给了笔者一个契机，先从用户的角度，来体验一下在实际应用场景中的用户操作和体验，特别是微软验证器验证ID相关的功能。
当然，关于这个系统本身不是本文的重点，因为这部分内容还在笔者的理解和消化过程当中。所以本文的重点暂时先放在这个体验流程当中。
示例站点
文中提到的示例站点如下：
woodgroveemployee.azurewebsites.net/verificatio...
关于这个入口，笔者还遇到一个有趣的情况。在和AI交流的过程中，它其实提到了这个站点，名为"End To End Demo"(端到端示例)，但笔者继续追问AI，能否搜索或者获取这个Demo的链接的时候，它却无法提供。最后笔者还是在浏览整个文档树的过程中，看到了其实专门有一个Samples章节，其中就有这个Demo的链接。
打开链接，是一个示例站点，用户可以使用自己的账户试图登录：
然后，会进入一个引导页面，如果用户从来没有在这里注册过验证ID，应当选择"Verify With True Identity"(使用真实标识进行认证)：
然后是一个模拟实人验证的流程，包括可能上传照片和证件等等：
然后，就可以进入本文的核心环节，创建验证ID。这是Demo站点会展示一个二维码，用户可以使用手机上的微软验证器程序来扫码创建验证ID(这个步骤称为颁发验证ID)：
打开微软验证器程序，点击验证ID，点击扫码按钮，扫描屏幕上的二维码，然后按照扫描页面的提示，输入Pin码，就可以创建一个新的验证ID了。
在手机应用的验证ID页面中，点击添加ID，或者点击扫码按钮：
扫描屏幕上的二维码：
按照提示，输入Pin码：
创建成功后，新添加的项目，会展示的验证ID列表当中(注意这里其实有重复添加的项目)：
同时，在站点页面也有成功信息如下：
随后返回用户主页，应当能够看到，可选项目已经发生了变化(下图)，现在就可以使用这个验证ID进行其他的操作了。比如在示例中，用户可以使用这个验证ID，在系统中进行登录和验证。
在这个页面中，点击"Access Personalized Portal"(访问个人主页),站点会展示一个登录用的二维码:
在手机上，使用验证器软件扫码，界面上会提示，当前这个验证ID，是否与另一个服务(WoodGrove)共享：
确认并继续之后，在演示站点中，会显示认证成功的信息：
点击后会导向个人主页:
这是，用户已经使用验证ID，在WoodGrove站点中，进行了认证。
要继续将用户在公司站点中的验证ID，获取到手机之上，可以点击"Retrieve my Verfied ID"(获得我的验证ID)
这是页面会展示一个二维码。同样使用验证器程序扫码，并输入Pin码后就可以在手机上创建用户在公司系统中职员的验证ID(可以注意到这个ID的标识和前面的不同了)：
职员的验证ID还可以在外部使用。如在个人主页上，点击"Visit Proseware"，会跳转到一个外部的第三方商城页面。公司已经和这个电商达成了协议，如果职员在这个商城购物，可以享受员工折扣：
现在商城展示的是正常的架构，点击右上角的"Access Discount"(访问折扣)，可以选择使用验证ID进行认证：
还是扫码：
在手机验证器程序中，选择相应的验证ID，并确认和Proseware商城的共享：
成功验证后，将显示员工折扣：
然后，用户可以在验证器程序中，查看这个已验证ID的详细信息：
至此，整个过程基本就是这样。简单总结一下，从操作的流程而言，可以分为以下几个过程：
- 用户正常的在业务系统中注册和登录，但这个注册，并不包括提供密码，只是提供用户的基础信息
- 注册完成后，系统展示一个用于关联注册的认证ID二维码
- 用户使用MA进行扫码，将会在手机应用中，创建一个已认证ID项目
- 下次认证时，可以在"使用认证ID进行认证"页面中扫描完成认证，无需再输入其他认证信息(如密码)
- 相关第三方系统，可以配置成为可以共享来自本系统的认证ID
- 第三方系统可以使用相同的方式，完成认证ID的认证，并获取用户标识，提供对应服务
关于已验证ID的一些问题
在微软验证器程序的帮助文件中，总结了一些常见的问题和解答，笔者觉得非常有代表性，也能够更充分的帮助我们理解验证器的工作方式和原理，这里也简单列举分析一下。
- 为什么MA不适用于电脑或 Mac？
Microsoft Authenticator 不适用于台式计算机，因为验证器应用通常是为智能手机设计的，主要有两个原因：
安全性：在单独的设备上设置安全问题的第二个因素可增强安全性。 如果两个因素（密码和身份验证）位于同一设备上，则攻击者更容易同时入侵这两者。
可用性：移动设备几乎总是伴随着用户，这使得它们便于进行身份验证。 另一方面，台式机的便携性不强。 仅在电脑上使用验证器意味着无法离开家或办公桌登录
笔者认为，这里还有一个隐含的假设，就是现在手机作为一个非常重要的个人和个性化的资产，其安全性本身也被用户非常重视，是可以当作一个个人的WhatUGot的物品使用的。当然，基于此原因，现在的智能化手机硬件和系统，所能够提供的安全性，也是要远超过传统的个人电脑系统的(如各种指纹和人类识别、应用沙盒等等)。
- 什么是验证ID？
验证ID是安全的受信任凭据，网站和组织可以使用这些凭据来简化帐户设置并使其更安全。
通常情况下，你将使用设备的摄像头捕获站点上的 QR 码，以获取新的验证ID或验证设备上已有的 ID。 仍可使用密码来访问凭据，以与其他组织共享。请求验证 ID的网站将显示在验证 ID 卡详细信息的使用历史记录中。
笔者其实对这个解答不是很满意，但现在确实也没有找到更合适的描述和解释，只能在应用的过程中逐渐体会其工作过程和作用。当总体而言，微软的可验证ID技术和实现，看起来应该可以实现逻辑和技术安全的无密码验证(PasswordLess)和验证共享的设计愿景。
- 是否需要连接到互联网来使用MA？
这个需要分情况讨论，不同的功能可能的需求不同。如验证码就无需连接互联网(其原理是共享密钥和基于时间的计算)，也无需相关的服务系统。 但登录响应或者消息，需要连接到互联网来获取登录信息和状态，并接收信息。
显然，下载、注册和初始化MA是需要互联网连接和MicroSoft服务账户的。但总体而言，在正常的初始化完成后，验证器程序是可以离线工作的，并不需要将连接互联网来作为其启动和运行的前提。
- 为什么验证器代码Microsoft旁边的数字会持续倒计时？
这是TOPT程序工作的原理。有效验证码每30秒更改一次，因此如果有人了解你昨天甚至一分钟前用于验证登录的代码，他们就无法使用该代码进入你的帐户。 此计时器是验证码更改为下一个代码的倒计时。 与密码不同，你不需要记住此数字。 只有有权访问你的手机的人员才能获取你的验证码。
- MA通知是否适用于非Microsoft帐户？
否，通知仅适用于Microsoft个人帐户、工作帐户或学校帐户。 工作或学校IT管理员可能会关闭此功能。
- MA是否兼容Google的身份验证器
事实证明是可以的，你可以在MA中，添加谷歌身份验证器项目，也可以正常工作。因为道理很简单，它们使用相同的TOTP生成算法。如果愿必要的话，你甚至可以自己编写一个验证器APP软件，来兼容MA或者谷歌验证器，或者实现自己的TOPT算法（调整时间偏移、摘要算法参数等等），当然这个验证器将会失去标准验证项目的兼容性。
小结
经过简单的操作和体验，笔者完成了使用微软验证器使用验证ID进行认证和连接外部服务的基本过程。总体而言，是比较清晰和流畅的，按照屏幕上的提示操作即可，虽然过程略显繁琐，但整体而言其设计的用户体验还是不错的。
通过这个过程，笔者感觉到这是微软准备向下一个认证技术发展的大的趋势，就是：
- 减少和消除传统基于密码的验证方式
- 身份标识和验证的结果可以分享和传递，从而方便构建更庞大复杂的应用体系
- 更安全也更易用
- 兼容第三方应用和系统
但其实笔者关注的并不是这些操作和过程，而是验证ID这个技术本身，以及这个技术能够在笔者相关现有应用系统中的集成和实现。经过本文的操作体验，笔者已经有了初步的理解和想法，但还是有技术方面的一些问题没有特别清晰，特别是信息安全保证、实现细节和生态系统方面的，这也是笔者在下一阶段的研究和学习的主要目的。