由去中心化标识符锚定的去中心化认证的制作方法

由去中心化标识符锚定的去中心化认证


背景技术：

1.目前使用的大多数证明身份的文档或记录都是由中心组织发布的，诸如政府、学校、雇主或其他服务中心或监管组织。这些组织经常在中心化身份管理系统中维护每个成员的身份。中心化身份管理系统是用于组织管理发布的身份、它们的认证、授权、角色和权限的中心化信息系统。中心化身份管理系统被认为是安全的，因为它们经常使用专业维护的硬件和软件。通常，身份发布组织设置用于向组织注册人员的条款和要求。最后，当一方需要验证另一方的身份时，验证方经常需要通过中心化身份管理系统来获取验证和/或认证另一方的身份的信息。
2.去中心化标识符(did)是一种新型标识符，其独立于任何中心化注册机构、身份提供者或证书机构。分布式账本技术(诸如区块链)为使用完全去中心化的标识符提供了机会。分布式账本技术使用全球分布式账本以可验证的方式记录两方或更多方之间的交易。一旦交易被记录，分布式账本的一部分中的数据就无法在不更改该分布式账本的所有后续部分的情况下被追溯更改，这提供了相当安全的平台。在这样的去中心化环境中，每个did的所有者通常使用他/她的did来控制他/她自身的数据。did所有者经由did管理模块访问存储在与did相关联的个人存储装置中的数据，该模块是移动应用(例如，钱包应用)、个人计算机、浏览器等。
3.本文要求保护的主题不限于解决任何缺陷或仅在诸如上述环境中操作的实施例。相反，提供该背景仅为了说明本文描述的一些实施例可以被实践的一个示例性技术领域。


技术实现要素：

4.本发明内容被提供为以简化形式来介绍概念的选择，这将在下面的具体实施方式中进一步描述。本发明内容不旨在标识所要求保护的主题的关键特征或基本特征，也不旨在用于帮助确定所要求保护的主题范围。
5.在中心化环境中，用户的用户名和密码通常被存储在凭证数据库中。当用户需要访问中心化服务时，用户输入他们的用户名和密码。中心化服务将用户的输入与凭证数据库中存储的数据相比较。如果找到匹配项，则用户被证明是该账户的所有者，并允许该用户访问该服务。如果未找到匹配项，则该用户无法被证明是该账户的所有者，因此，该用户被拒绝访问该服务。
6.但是，这种机制不适用于去中心化系统，因为去中心化系统没有用来存储用户名和密码的中心化存储装置；相反，去中心化系统使用分布式账本来记录交易。具体而言，在公开可用的去中心化系统中，对应的分布式账本对公众可用，其不能用来记录用户名和密码。因此，在去中心化环境中，当与去中心化标识符(did)相关联的用户发起与另一实体的通信或交易时，另一实体无法以在中心化环境中那样的类似方式验证该用户是否是did的所有者或证明该用户具有对did的控制权。本技术旨在解决上述问题，使得验证实体能够在去中心化环境中认证发起交易的用户是否对did具有控制权。
7.本文描述的原理在用户的管理模块(例如，钱包应用)、用户代理和/或id中心中实
现。管理模块是指安装在用户的设备上的移动应用程序或计算机应用程序。用户代理或id中心被托管为用户可以访问的web服务，并且其可以代表用户执行操作。例如，管理模块通常不打算存储分布式账本的完整副本，也不打算存储所有的用户个人数据，因为用户的设备通常具有有限的存储空间，并且也可能无法随时连接到计算机网络。另一方面，用户代理和/或id中心是可以不断连接到计算机网络的服务，并且也可以提供足够的存储空间来存储大量的用户个人数据。因此，在许多实施例中，管理模块被配置为安全地存储和管理用户的did和各种密钥，而用户代理和/或id中心被配置为存储分布式账本的完整副本(或其大部分)以及大量的用户数据。用户可以使用其管理模块与用户代理和/或id中心交互，来完成交易并与其他did所有者或设备通信。
8.本文描述的实施例涉及由去中心化标识符锚定的去中心化认证。首先，计算系统(其充当did所有者的管理模块、用户代理和/或id中心)接收用以生成去中心化标识符的用户指示。该用户指示包括选择多个认证机制中的至少一个认证机制。响应于用户指示，去中心化标识符(did)和did文档被生成。did文档包括至少(1)与去中心化标识符相关的数据以及(2)与所选择的至少一个认证机制相关的数据。接下来，did文档中包含的数据的至少一部分被传播到分布式账本。
9.在一些实施例中，当用户使用did发起动作时，验证实体接收用户动作的指示。例如，用户的动作可以是针对来自验证实体的服务的请求。在验证实体完全响应用户的动作(例如，提供用户请求的服务)之前，验证实体通常希望用户对自身进行认证，即证明用户(其发起该动作)具有对did的控制权。为了让用户认证其自身，验证实体首先访问分布式账本以获取与did相关联的(多个)认证机制。基于(多个)认证机制，验证实体生成认证请求并将该请求发送到用户的设备。响应于接收到验证实体的请求，基于至少一个认证机制，生成认证数据。
10.在一些实施例中，认证数据由计算系统生成。在一些实施例中，认证数据由用户的第二计算系统和/或认证服务生成。继而使认证数据被发送到验证实体。当验证实体接收到认证数据时，验证实体被致使基于至少一个认证机制核验认证数据。
11.例如，在一些实施例中，至少一个认证机制包括公钥基础设施(pki)。生成did包括生成私-公密钥对。密钥对中的公钥被记录在did文档中并被传播到分布式账本上。在验证实体请求用户认证其自身之后，用户的设备(用户的计算系统或第二计算系统)生成密码签名作为认证数据，其由密钥对中的私钥签名并将密码签名发送给验证实体。验证实体从分布式账本中获取与公钥相关的数据，并使用公钥来核验密码签名。因此，认证以去中心化的方式完成，无需具有中心化服务来存储和验证所有用户的用户名和密码。
12.附加特征和优点将在下面的描述中阐述，并且部分地从描述中是显而易见的，或者可以通过本文教导的实践而获知。本发明的特征和优点可以通过所附权利要求中特别指出的工具和组合来实现和获得。本发明的特征将通过以下描述和所附权利要求变得更加明显，或者可以通过如下文所述的本发明的实践而获知。
附图说明
13.为了描述能够获得上述和其他优点和特征的方式，将通过参考附图中示出的具体实施例来对上文简要描述的主题进行更具体的描述。应理解，这些附图仅描绘了典型的实
施例并且因此不应被认为是对范围的限制，将通过使用附图以附加的特异性和细节来描述和解释实施例，其中：
14.图1示出了示例计算系统，其中采用了本文描述的原理；
15.图2示出了用于创建去中心化标识或标识符(did)的示例环境；
16.图3示出了示例环境，其中实现了本文描述的原理；
17.图4a至图4c示出了允许用户生成或更新与did相关联的认证机制的管理模块或钱包应用的示例用户界面；
18.图5示出了用于生成或更新did文档的示例实施例；
19.图6a至图6c示出了示例did文档；
20.图7示出了执行用户动作的认证的示例环境；
21.图8a和图8b示出了由验证实体生成的示例认证请求；
22.图9a和图9b示出了由主体实体的设备或认证服务生成的示例认证响应；
23.图10a至图10e示出了在认证过程期间发生的各种示例通信模式；
24.图11示出了用于基于对(多个)认证机制的用户选择来生成did和did文档的示例方法的流程图；以及
25.图12示出了用于基于与did相关联的(多个)认证机制来认证与did相关联的用户动作的示例方法的流程图。
具体实施方式
26.本文描述的实施例涉及由去中心化标识符锚定的去中心化认证。首先，计算系统(充当did所有者的管理模块、用户代理和/或id中心)接收用以生成去中心化标识符的用户指示。用户指示包括选择多个认证机制中的至少一个认证机制。响应于用户指示，生成去中心化标识符(did)和did文档。did文档包括至少(1)与去中心化标识符相关的数据以及(2)与所选择的至少一个认证机制相关的数据。接下来，did文档中的至少一部分数据被传播到分布式账本。
27.在一些实施例中，当用户使用did发起动作时，验证实体接收用户动作的指示。例如，用户的行为可能是来自验证实体的服务请求。在验证实体完全响应用户的操作(例如，提供用户请求的服务)之前，验证实体通常希望用户对自身进行认证，即证明用户(发起该操作)具有对did的控制权。为了让用户验证其自身，验证实体首先访问分布式账本以获取与did关联的认证机制。基于认证机制，验证实体生成认证请求并将请求发送到用户的设备。响应于接收到验证实体的请求，基于至少一个认证机制，生成认证数据并发送至验证实体。
28.在一些实施例中，认证数据由计算系统生成。在一些实施例中，认证数据由用户的第二计算系统和/或认证服务生成。然后使认证数据被发送到验证实体。当验证实体接收到认证数据时，使验证实体基于至少一个认证机制对认证数据进行核验。
29.多个认证机制包括但不限于(1)公钥基础设施，(2)认证服务，(3)自发布声明，或(4)可验证声明。当所选择的至少一个认证机制包括公钥基础设施时，生成did包括生成包括公钥和私钥的密钥对。生成did文档包括将公钥记录在did文档中。将did文档中包含的数据的至少一部分传播到分布式账本包括在分布式账本中至少记录与公钥相关的数据。例
如，在一些实施例中，did和/或公钥本身被传播到分布式账本上。在一些实施例中，did的散列、公钥的散列和/或did和/或公钥的任何变换被传播到分布式账本上，只要该变换可以用于证明其与did或公钥的关系。
30.当公钥基础设施是选择的认证机制时，响应于来自验证实体的认证用户动作的请求，生成认证数据包括生成由密钥对的私钥加密的密码签名作为认证数据。该密码签名继而被发送到验证实体。在一些实施例中，密码密钥由计算系统生成。在一些实施例中，密码密钥由用户的第二计算系统生成。
31.接收到密码密钥后，验证实体被致使经由分布式账本获取与公钥相关的数据，并尝试通过所获取的公钥解码密码签名。响应于有效的解密结果，验证实体确定用户的动作是经过认证的(即，用户动作被证明是由did的所有者发起的)；否则，认证失败。
32.在一些实施例中，当(多个)至少一个认证机制包括认证服务时，生成did文档包括记录引用认证服务(例如，认证服务的端点)的地址(例如，url)。在一些实施例中，当(多个)至少一个认证机制包括自发布声明时，生成did文档包括记录被要求在自发布声明中传达的至少一个身份属性。在另一些其他实施例中，(多个)至少一个认证机制包括可验证声明，该可验证声明可由声明发布者验证，生成did文档包括记录(1)经由可验证声明可验证的至少一个身份属性，以及(2)发布该可验证声明的声明发布者的标识符。在某些情况下，声明发布者的标识符包括声明发布者的did。
33.因为本文描述的原理是在计算系统的上下文中执行的，所以将参考图1描述计算系统的一些介绍性讨论。然后，本说明书将参考其余附图返回到did平台的原理。
34.计算系统现在越来越多地采用多种形式。例如，计算系统可以是手持设备、电器、膝上型计算机、台式计算机、大型机、分布式计算系统、数据中心、或者甚至是传统上不被视为计算系统的设备，诸如可穿戴设备(例如，眼镜)。在本说明书和权利要求书中，术语“计算系统”被广义地定义为包括：包括物理且有形的至少一个处理器的任何设备或系统(或其组合)、以及能够在其上具有由处理器执行的计算机可执行指令的物理且有形的存储器。存储器采用任何形式并且取决于计算系统的性质和形式。计算系统分布在网络环境中并且包括多个组成计算系统。
35.如图1所示，在其最基本的配置中，计算系统100通常包括至少一个硬件处理单元102和存储器104。处理单元102包括通用处理器并且还包括现场可编程门阵列(fpga)()、专用集成电路(asic)或任何其他专用电路。存储器104是物理系统存储器，它是易失性、非易失性或两者的某种组合。术语“存储器”在本文中也用于指非易失性大容量存储器，例如物理存储介质。如果计算系统是分布式的，则处理、存储器和/或存储能力也是分布式的。
36.计算系统100在其上还具有通常被称为“可执行组件”的多个结构。例如，计算系统100的存储器104被示为包括可执行组件106。术语“可执行组件”是计算领域的本领域普通技术人员熟知的结构的名称，其可以是软件、硬件或其组合的结构。例如，当以软件实现时，本领域的普通技术人员将理解可执行组件的结构包括在计算系统上执行的软件对象、例程、方法等，无论这样的可执行组件是否存在于计算系统的堆中，或者该可执行组件是否存在于计算机可读存储介质上。
37.在这种情况下，本领域普通技术人员将认识到可执行组件的结构存在于计算机可读介质上，使得当由计算系统的一个或多个处理器(例如，由处理器线程)解释时，计算系统
被致使执行功能。这样的结构是由处理器直接计算机可读的(如果可执行部件是二进制的就是这种情况)。备选地，该结构被构造为可解释的和/或经编译的(无论是在单个阶段还是在多个阶段中)，以便生成由处理器直接可解释的这种二进制文件。当使用术语“可执行部件”时，对可执行部件的示例结构的这种理解完全在计算领域的普通技术人员的理解范围内。
38.术语“可执行部件”也被普通技术人员很好地理解为包括排他地或几乎排他地在硬件中实现的结构，例如硬编码或硬接线的逻辑门，例如现场可编程门阵列(fpga)、专用集成电路(asic)或任何其他专用电路内的结构。因此，无论是以软件、硬件还是其组合实现，术语“可执行部件”是计算领域的普通技术人员很好理解的结构的术语。在本说明书中，术语“部件”、“代理”、“管理器”、“服务”、“引擎”、“模块”、“虚拟机”等也被使用。如在本说明书和案例中使用的，这些术语(无论是否带有修改条款)也旨在与术语“可执行部件”同义，并且因此也具有计算领域的普通技术人员所熟知的结构。
39.在下面的描述中，参考由一个或多个计算系统执行的动作来描述实施例。如果这些动作以软件实现，则(执行动作的相关计算系统的)一个或多个处理器响应于已执行构成可执行组件的计算机可执行指令来指导计算系统的操作。例如，这样的计算机可执行指令体现在形成计算机程序产品的一个或多个计算机可读介质上。这种操作的示例涉及数据的操作。如果这些动作仅在硬件中实现或几乎仅在硬件中实现，诸如在fpga或asic内，则计算机可执行指令是硬编码或硬连线的逻辑门。计算机可执行指令(和经处理的数据)被存储在计算系统100的存储器104中。计算系统100还包含允许计算系统100通过例如网络110与其他计算系统通信的通信信道108。
40.尽管并非所有计算系统都需要用户界面，但在一些实施例中，计算系统100包括用于与用户交互的用户界面系统112。用户界面系统112包括输出机制112a以及输入机制112b。本文描述的原理不限于精确的输出机制112a或输入机制112b，因为其将取决于设备的性质。然而，输出机制112a可以包括例如扬声器、显示器、触觉输出、全息图等等。输入机制112b的示例可以包括例如麦克风、触摸屏、全息图、摄像机、键盘、鼠标或其他指针输入、任何类型的传感器等等。
41.本文描述的实施例包括或利用包括计算机硬件的专用或通用计算系统，例如一个或多个处理器和系统存储器，如下面更详细讨论的。本文描述的实施例还包括用于承载或存储计算机可执行指令和/或数据结构的物理计算机可读介质和其他计算机可读介质。这样的计算机可读介质可以是通用或专用计算系统可以访问的任何可用介质。存储计算机可执行指令的计算机可读介质是物理存储介质。承载计算机可执行指令的计算机可读介质是传输介质。因此，作为示例而非限制，本发明的实施例可以包括至少两种截然不同的计算机可读介质：存储介质和传输介质。
42.计算机可读存储介质包括ram、rom、eeprom、cd-rom或其他光盘存储、磁盘存储或其他磁存储设备、或任何其他物理且有形的存储介质，该存储介质可以用于以计算机可执行指令或数据结构的形式存储所需程序代码装置并且可以由通用或专用计算系统访问。
[0043]“网络”被定义为能够在计算系统和/或模块和/或其他电子设备之间传输电子数据的一个或多个数据链路。当信息通过网络或另一通信连接(硬连线、无线或硬连线或无线的组合)传输或提供到计算系统时，计算系统适当地将连接视为传输介质。传输介质可以包
括网络和/或数据链路，其可以用于以计算机可执行指令或数据结构的形式承载所需程序代码装置并且可以由通用或专用计算系统访问。上述的组合也应包括在计算机可读介质的范围内。
[0044]
此外，在到达各种计算系统部件时，计算机可执行指令或数据结构形式的程序代码装置可以从传输介质自动传输到存储介质(反之亦然)。例如，通过网络或数据链路接收的计算机可执行指令或数据结构可以缓存在网络接口模块(例如，“nic”)内的ram中，并且然后最终传输到计算系统ram和/或计算系统处的较不易失性的存储介质。因此，应当理解，存储介质可以包括在也(或甚至主要)利用传输介质的计算系统部件中。
[0045]
计算机可执行指令包括例如指令和数据，当这些指令或数据在处理器处被执行时，使通用计算系统、专用计算系统或专用处理设备执行特定功能或功能组。备选地或附加地，计算机可执行指令将计算系统配置为执行特定功能或功能组。计算机可执行指令是例如，二进制文件或甚至在由处理器直接执行之前经过一些翻译(诸如编译)的指令，例如诸如汇编语言之类的中间格式指令，甚至源代码。
[0046]
尽管已经以特定于结构特征和/或方法行为的语言描述了主题，但是应当理解，在所附权利要求中定义的主题不一定限于上述描述的特征或行为。相反，所描述的特征和动作被公开为实施权利要求的示例形式。
[0047]
本领域技术人员将理解，本发明在具有多种类型的计算系统配置的网络计算环境中实施，计算系统配置包括个人计算机、台式计算机、膝上型计算机、消息处理器、手持设备、多处理器系统、基于微处理器的或可编程的消费电子产品、网络pc、小型计算机、大型计算机、移动电话、pda、寻呼机、路由器、交换机、数据中心、可穿戴设备(例如眼镜)等。在一些情况下，本发明还在分布式系统环境中实践，其中本地和远程计算系统通过网络链接(通过硬连线数据链路、无线数据链路或通过硬连线和无线数据链路的组合)，二者都执行任务。在分布式系统环境中，程序模块位于本地和远程存储器存储设备中。
[0048]
本领域技术人员还将理解，本发明在云计算环境中实践。云计算环境是分布式的，但这不是必需的。当分布式时，云计算环境可以在组织内国际地分布和/或具有跨多个组织拥有的部件。在本说明书和所附权利要求中，“云计算”被定义为用于实现对可配置计算资源(例如，网络、服务器、存储、应用和服务)的共享池的按需网络访问的模型。“云计算”的定义不限于适当部署时可以从此类模型中获得的其他众多优点中的任何一个。
[0049]
其余附图讨论了对应于先前描述的计算系统100的各种计算系统。其余附图的计算系统包括实现如将要解释的本文公开的各种实施例的各种组件或功能块。各种组件或功能块在本地计算系统上实现或在分布式计算系统上实现，该分布式计算系统包括驻留在云端的元素或实现云计算的各方面的元素。各种组件或功能块被实现为软件、硬件或软件与硬件的组合。其余附图中的计算系统包括比图中所示的更多或更少的组件，并且某些组件在情况允许时被组合。尽管未必被示出，但计算系统的各种组件根据需要访问和/或利用处理器和存储器，诸如处理器102和存储器104，以执行它们的各种功能。
[0050]
关于去中心化标识(did)及其被创建和驻留的环境的一些介绍性讨论将不会参考图2给出。如图2所示，did所有者201拥有或控制代表did所有者201的身份的did 205。did所有者201使用创建和注册服务来注册did，这将在下面更详细地解释。
[0051]
did所有者201是可以从did受益的任何实体。例如，did所有者201是人类或人类的
组织。这样的组织可以包括公司、部门、政府、机构或任何其他组织或组织群组。每个人都可能具有did，而每个人所属的(多个)组织也同样可能具有did。
[0052]
did所有者201可替换地是机器、系统、或设备，或(多个)机器、(第一个)设备和/或(多个)系统的集合。在其他实施例中，did所有者201是机器、系统或设备的子部分。例如，设备可以是印刷电路板，其中该电路板的子部分是电路板的各个组件。在这样的实施例中，机器或设备具有did并且每个子部分也具有did。did所有者也可以是软件组件，例如上面关于图1描述的可执行组件106。复杂的可执行组件106的示例可以是人工智能。人工智能也拥有did。
[0053]
因此，did所有者201是能够创建did 205或至少具有为其创建并与其相关联的did 205的任何合理的实体、人类或非人类。尽管did所有者201被示为具有单个did 205，但这不一定是这种情况，因为在情况允许时存在与did所有者201相关联的任何数量的did。
[0054]
如所提到的，did所有者201创建并注册did 205。did 205是与did所有者201相关联的任何标识符。优选地，该标识符对于该did所有者201是唯一的，至少在did预期被使用的范围内是唯一的。作为示例，标识符是本地唯一标识符，并且可能更理想地是用于预期在全球操作的身份系统的全球唯一标识符。在一些实施例中，did 205是将did所有者201与参与与did所有者1001的可信任交互的机制相关联的统一资源标识符(uri)(诸如统一资源定位符(url))或其他指针。
[0055]
did 205是“去中心化的”，因为它不需要中心化的第三方管理系统来生成、管理或使用。因此，did 205仍处于did所有者201的控制下。这不同于传统的中心化id，其基于对中心化机构的信任，并且处于公司目录服务、证书机构、域名注册机构或其他中心化机构的控制下(本文中统称为“中心化机构”)。因此，did 205是在did所有者201的控制下并且独立于任何中心化机构的任何标识符。
[0056]
在一些实施例中，did 205的结构像用户名或一些其他人类可理解的术语一样简单。然而，在其他实施例中，为了提高安全性，did 205优选地是数字和字母的随机字符串。在一个实施例中，did 205是128个字母和数字的字符串。因此，本文公开的实施例不依赖于did 205的任何具体实现。在一个非常简单的示例中，did 205被示为“123abc”。
[0057]
还如图2所示，did所有者201控制与did20相关联的私钥206和公钥207对。因为did 205独立于任何中心化机构，所以私钥206应始终完全由did所有者201控制。也就是说，私钥和公钥应当以去中心化的方式被生成，以确保它们保持在did所有者201的控制之下。
[0058]
如将在下文更详细描述的，私钥206和公钥207对在由did所有者201控制的设备上生成。私钥206和公钥207对不应在由任何中心化机构控制的服务器上生成，因为这会导致私钥206和公钥207对不能始终完全在did所有者201的控制之下。尽管图2和本说明书描述了私钥和公钥对，但还应注意，其他类型的合理密码信息和/或机制也可以根据情况而被使用。
[0059]
图2还示出了与did 205相关联的did文档210。如将在下面更详细地解释的，did文档210在创建did 205时被生成。在其最简单的形式中，did文档210描述了如何使用did 205。因此，did文档210包括对did 205的引用，它是由did文档210描述的did。在一些实施例中，did文档210是根据分布式账本220指定的方法实现的，分布式账本220将用于存储did 205的表示，这将在下面更详细地解释。因此，取决于具体的分布式账本，did文档210具有不
同的方法。
[0060]
did文档210还包括由did所有者201创建的公钥207或一些其他等效密码信息。公钥207被did所有者201给予许可的第三方实体使用以访问did所有者201所拥有的信息和数据。公钥207还可以通过验证did所有者201实际上拥有或控制did205来被使用。
[0061]
did文档210还包括认证信息211。认证信息211指定一个或多个机制，did所有者201能够通过该一个或多个机制证明did所有者201拥有did 205。换言之，认证信息211的机制显示did 205(因此它是did所有者201)和did文档210之间的绑定证明。在一个实施例中，认证信息211指定公钥207用于在签名操作中证明did 205的所有权。备选地或附加地，认证信息211指定公钥207用于在生物特征操作中证明did 205的所有权。因此，认证信息211包括任何数量的机制，did所有者201能够通过这些机制证明did所有者201拥有did 205。
[0062]
did文档210还包括授权信息212。授权信息212允许did所有者201授权第三方实体修改did文档210或文档的某些部分的权利，而不赋予第三方证明对did 205的所有权的权利。例如，授权信息212允许第三方使用任何指定的更新机制来更新did文档210中的一个或多个字段的任何指定集合。或者，授权信息允许第三方将did所有者201对did 205的使用限制在指定时间段内。这在did所有者201是未成年子女且第三方是子女的父母或监护人时很有用。授权信息212允许父母或监护人限制对did 205的使用，直到子女不再是未成年人。
[0063]
授权信息212还指定第三方将需要遵循以证明他们被授权修改did文档210的一个或多个机制。在一些实施例中，该机制类似于先前关于认证信息211所讨论的那些机制。
[0064]
did文档210还包括一个或多个服务端点213。服务端点包括如下网络地址，在该网络地址处服务代表did所有者201操作。特定服务的示例包括发现服务、社交网络、诸如身份服务器或中心(hub)的文件存储服务、以及可验证声明存储库服务。因此，服务端点213用作代表did所有者201操作的服务的指针。这些指针被did所有者201或第三方实体用来访问代表did所有者201操作的服务。下面将更详细地解释服务端点213的具体示例。
[0065]
did文档210还包括标识信息214。标识信息214包括个人可标识信息，诸如did所有者201的姓名、地址、职业、家庭成员、年龄、爱好、兴趣等等。因此，did文档210中列出的标识信息214代表did所有者201针对不同目的的不同角色。例如，角色是伪匿名的，例如，在将did所有者201标识为在博客上发表文章的作者时，他或她可以在did文档中包括笔名；角色是完全匿名的，例如，did所有者201仅希望在did文档中公开他或她的职位或其他背景数据(例如，学校教师、fbi特工、21岁以上的成年人等)，而不公开他或她的姓名；以及角色是特定于did所有者201作为个体的人，例如，did所有者201包括将他或她标识为特定慈善组织的志愿者、特定公司的雇员、特定奖项的获奖者等的信息。
[0066]
did文档210还包括凭证信息215，其在本文中也被称为证明。凭证信息215是与did所有者201的背景相关联的任何信息。例如，凭证信息215是(但不限于)资格、成就、政府id、诸如护照或驾驶执照等政府权利、数字资产提供者或银行账户、大学学位或其他教育史、就业状况和历史，或有关did所有者201的背景的任何其他信息。
[0067]
did文档210还包括各种其他信息216。在一些实施例中，其他信息216包括指定did文档210何时被创建和/或何时被最后修改的元数据。在其他实施例中，其他信息216包括did文档210的完整性的密码证明。在更进一步的实施例中，其他信息216包括由实现did文档的特定方法指定或由did所有者201期望的附加信息。
[0068]
图2还示出了分布式账本或区块链220。分布式账本220是任何去中心化的分布式网络，其包括相互通信的各种计算系统。例如，分布式账本220包括第一分布式计算系统230、第二分布式计算系统240、第三分布式计算系统250，以及由省略号260表示的任意数量的附加分布式计算系统。分布式账本或区块链220根据分布式账本的任何已知标准或方法操作。对应于分布式账本或区块链220的常规分布式账本的示例包括但不限于比特币。
[0069]
在did 205的上下文中，分布式账本或区块链220用于存储指向did文档210的did 205的表示。在一些实施例中，did文档210存储在实际分布式账本上。备选地，在其他实施例中，did文档210被存储在与分布式账本或区块链220相关联的数据存储器(未示出)中。
[0070]
如前所述，did 205的表示存储在分布式账本或区块链220的每个分布式计算系统上。例如，在图2中，这被示为did散列231，did散列241，did散列251，它们在理想情况下是相同did的相同副本。did散列231、did散列241和did散列251然后指向did文档210的位置。分布式账本或区块链220还存储如由附图标记232、233、234、242、243、244、252、253和254所示的其他did的许多其他表示。
[0071]
在一个实施例中，当did所有者201创建did 205和相关联的did文档210时，did散列231、did散列241和did散列251被写入分布式账本或区块链220。分布式账本或区块链220因此记录did 205现在存在。由于分布式账本或区块链220是去中心化的，因此did 205不受did所有者201之外的任何实体的控制。除了指向did文档210的指针之外，did散列231、did散列241、did散列251还包括指定did 205何时被创建的记录或时间戳。后续，在对did文档210进行修改时，这也记录在did散列231、did散列241、以及did散列251中。did散列231、did散列241以及did散列251还包括公钥207的副本，以便did 205加密绑定到did文档210。
[0072]
已经参考图2描述了did以及它们一般如何操作，现在将解释去中心化式认证的特定实施例。转向图3，现在将解释去中心化环境300，该去中心化环境300允许did所有者访问服务并与其他did所有者执行交易同时认证其自身。应当理解，为了便于解释，图3的环境根据需要参考来自图2的元素。
[0073]
如图3所示，去中心化环境300包括与服务提供者310相关联的设备和用户320、330的钱包应用321和311。省略号340表示去中心化环境300中可以有与任何数量的服务提供者相关联的任何数量的设备和/或用户。(多个)服务提供者和用户320、330中的每一个对应于图2的did所有者201。设备310和钱包应用321、331中的每一个都可以经由计算机网络350访问分布式账本。
[0074]
用户320使用钱包应用321来管理他/她的did，并且用户330使用钱包应用331来管理他/她的did。钱包应用321或331连接到相应的id中心322或332。钱包321、331和/或id中心322、332中的每一个都可以经由计算机网络350访问分布式账本360。在一些实施例中，钱包应用321或331经由id中心322或332间接访问分布式账本。在一些实施例中，钱包应用321或331被配置为存储分布式账本的完整副本，或者经由计算机网络350直接访问分布式账本。服务提供者310的设备和每个钱包应用321、331和/或id中心322、332能够经由各种通信信道相互通信，各种通信信道包括但不限于局域网、广域网、ble信标信号和/或近场通信(nfc)。通信也可以经由由一个钱包应用321生成条形码或qr码，并由另一钱包应用331或服务提供者310的设备扫描该条形码或qr码来执行。条形码或qr代码包括与用户320相关的标识信息，诸如与用户320相关的did。
[0075]
在一些实施例中，用户320可以通过钱包应用321请求访问由服务提供者310提供的服务。在该请求中，钱包应用321可以包括或者也不包括用户的标识信息(例如，用户的did)。当请求不包括用户的标识信息时，服务310可能请求用户的钱包应用321提供这样的信息。随后，钱包应用321继而将用户的did和/或认证数据发送到服务310。在一些实施例中，为了进一步验证用户是did或安装钱包应用321的设备的真正所有者，钱包应用321还要求用户输入一些输入以证明该用户是设备的真正所有者。例如，在某些情况下，在钱包应用321生成认证数据之前，用户需要输入设备密码和/或生物特征数据(包括但不限于指纹和虹膜扫描)。一旦服务310接收到did和认证数据，服务310继而从分布式账本中获取与did相关的相关数据，并使用所获取的数据来核验从钱包应用321接收到的认证数据。
[0076]
类似的过程也可以发生在两个用户的钱包321、322之间，以允许两个用户320和330相互通信或交易。例如，可以由钱包应用321发起通信或交易并将其传输到钱包应用331。当钱包应用331接收到用户320的did时，钱包应用311将访问分布式账本以获取与did相关联的(多个)认证机制。基于所获取的认证机制，钱包应用331生成认证请求并将其发送到钱包应用321。接收到认证请求后，钱包应用321然后生成其认证数据并将其发送回钱包应用331。然后，钱包应用331对认证数据的有效性进行认证。
[0077]
可以在去中心化式系统中实现各种认证机制。各种认证机制包括但不限于使用公钥基础设施(pki)、使用(多个)认证服务、使用(多个)自发布声明和/或使用(多个)可验证声明。在某些情况下，用户被允许选择将针对其did实施哪个(哪些)认证机制。在某些情况下，服务提供者或did方法被允许选择或定义针对使用其服务的用户需要哪个(哪些)认证机制。
[0078]
在一些实施例中，当用户要生成新的did时，钱包应用、用户代理和/或id中心向用户提供用户可以选择的各种选项。图4a至图4c示出了用户的钱包应用、用户代理和/或id中心的示例用户界面400a到400c，其对应于图3的钱包应用321、331。如图4a所示，用户界面400a包括允许用户选择各种did方法的did方法菜单410a。did方法定义了如何以及在何处可以找到did。例如，比特币、以太坊、sovrin、ipfs和veres one是现有did方法的示例。
[0079]
用户界面400a还包括认证机制菜单420a，其允许用户选择各种认证机制，诸如pki421a、认证服务422a、(多个)自发布声明423a和/或(多个)可验证声明424a。省略号425a表示可以有用户可以从中选择的任何数量的认证机制。省略号430a表示用户界面400a可以包括任意数量的可视化或字段，用户可以通过它们输入与要生成的did相关的附加信息。
[0080]
一旦用户选择了一个或多个特定认证机制，在一些实施例中，为用户填充(多个)附加用户界面以进一步指定每个选择的认证机制。图4b示出了这样的示例用户界面400b，其包括用于每个选择的认证机制的单独的输入字段。假设用户已经经由用户界面400a选择了pki421a、(多个)认证服务422a和(多个)自发布声明423a。在用户按下确认按钮440a之后，钱包应用向用户呈现下一用户界面400b，包括pki输入字段410b、(多个)认证服务输入字段420b和(多个)自发布声明输入字段430b，它们中的每个都允许用户输入与这些认证机制相关的附加信息。
[0081]
如图4b所示，pki输入字段410b允许用户选择用户期望的密钥长度。例如，用户可以选择256比特411b或2048比特412b作为密钥的长度。总体而言，密钥越长，加密就越安全。省略号413b表示可以存在用户可以选择的附加选项。替代地或附加地，可以允许用户输入
与密钥相关的特定数字或附加偏好。
[0082]
(多个)认证服务输入字段420b允许用户选择或输入一个或多个认证服务提供者。例如，用户可以选择服务a 421b和/或服务b422b作为将用于认证用户的身份的认证服务。(多个)自发布声明输入字段420b允许用户选择或输入将被包括在自发布声明中的属性。例如，用户可以选择或定义他/她的全名431b和/或电子邮件地址432b将被包括在要在认证过程期间发布的自发布声明中。省略号423b和433b表示可以向用户提供任意数量的选择。替代地或另外地，可以允许用户手动输入与对应的认证机制相关的附加信息。
[0083]
此外，还应允许用户修改或更新此前选择的认证机制。图4c示出了允许用户更新现有did的认证机制的示例用户界面400c。如图4c所示，用户界面400c包括现有的did菜单410c，用户可以通过该菜单选择用户想要修改的现有did。用户界面400c还包括(多个)更新认证机制菜单420c，用户可以通过该菜单更新对一个或多个认证机制的先前选择。一旦用户点击确认按钮440c，然后用户可以被带到另一用户界面(例如，用户界面400b)，该用户界面允许用户进一步输入关于所选择的认证机制的附加细节。
[0084]
图4a至图4c仅仅是关于如何允许用户为其自身的did实施各种认证机制的一些示例。服务提供者和did方法也可以定义或要求特定的认证机制。在这种情况下，钱包应用可以使用户界面400a到400c灰显did方法不接受的认证机制。备选地或附加地，钱包应用可以自动选择did方法为用户接受的认证机制。
[0085]
一旦选择并定义了用户did的认证机制，用户的钱包应用(或代理或id中心)就被触发以生成或更新did及其相应的did文档。图5示出了由钱包应用510实现的示例实施例500，钱包应用510对应于图3的钱包应用321或331。响应于生成新did或修改现有did的用户指示，钱包应用510生成或者更新对应的did文档520。did文档520至少包括与did 521相关的数据和与选择的(多个)认证机制522相关的数据。省略号523表示在did文档520中可能存在附加信息记录，这取决于did方法和用户打算使用的服务。此后，包含在did文档520中的数据的至少一部分经由计算机网络530被传播到分布式账本540上。
[0086]
如之前关于图2所述，did文档用于记录一组描述did主体(即，did所有者201)的数据。图6a至图6c进一步示出了示例did文档。图6a示出了did文档600a的示例结构。did文档600a包括与主体相关联的did 610a。did文档600a还包括与用于认证用户的(多个)认证机制620a相关的数据。当有多个认证机制被选择时，与每个选择的认证机制相关的单独的一组数据被记录在did文档中。例如，当认证机制a和b都被选择时，did文档600a将包括与认证机制a621a相关的数据以及与认证机制b622a相关的数据。省略号623a表示可能存在与did文档600a中记录的任意数量的选定认证机制相关联的任意数据集。省略号630a表示可能存在与did文档600a中记录的did主体相关的附加数据。
[0087]
图6b和6c进一步示出了以基于图形的数据格式(例如，json-ld格式)编写的两个示例did文档600b和600c。图6b示出了did文档600b，其指示认证机制是rsa签名认证2018，它是特定的pki类型。did文档600b包括与did相关的数据610b和与所选择的认证机制相关的数据620b和630b。基于与did相关的数据610b，应当理解did方法为“方法a”(methoda)，did为“123456789”。基于与所选择的认证机制相关的数据620b，可以理解所选择的认证机制是“rsasignatureauthentication2018”，是特定的pki类型。因此，针对这种认证机制生成私钥-公钥对。该私钥-公钥对然后被链接到did 123456789，并且与公钥相关的数据继而
被记录为did文档600b中的630b。注意，只有与公钥相关的数据被记录在did文档600b中并传播到分布式账本上。私钥将始终保密。可以实施各种方法来安全地存储私钥。例如，在一些实施例中，私钥由用户设备的用户密码加密，并存储在安装钱包应用的设备上。
[0088]
图6c示出了另一示例did文档600c，其指示认证机制是认证服务。did文档600c还包括与did相关的数据610c和与所选择的认证机制相关的数据620c。这里，基于与did相关的数据610c，应当理解did方法为“方法b”(methodb)，did为“abcdefghijk”。基于与认证机制相关的数据620c，应当理解所选择的认证机制是“didauthservice”(did认证服务)，它是经由服务端点在“https://didauth.microsoft.eom/did:methodb:abcdefghijk”提供的。”[0089]
图7进一步示出了示例环境700，其中执行用户动作的认证。在环境700中，用户711具有对一个或多个设备710的控制权。用户首先向服务提供者730请求服务，由箭头721表示。这样的请求可以经由服务730的网站被发起。替代地或附加地，这样的请求也可以通过直接与服务730相关联的设备通信来被发起，包括但不限于使用自组织wifi、ble信标、扫描条形码和/或nfc。该请求可能包括也可能不包括用户的身份信息。
[0090]
当服务提供者730接收到请求时，服务提供者730想要知道用户的身份并且还想要验证发起请求的人是否真正与所呈现的身份相关联。因此，服务提供者730想要请求用户711呈现他/她的身份并认证所呈现的身份，由箭头722表示。在某些情况下，如果服务提供者730已经接收到与用户711相关联的did，服务提供者730去分布式账本获取与did相关联的(多个)认证机制。当存在不止一个认证机制可用时，服务提供者730在可用机制之间选择一个或多个优选的认证机制，并基于(多个)优选的认证机制来生成认证请求。
[0091]
接收到认证请求后，用户的设备710将呈现其did，并且还基于认证请求722和基于与did相关联的(多个)认证机制生成认证数据，由箭头723表示。例如，如果pki被用作认证机制，则用户设备710将生成密码签名。密码签名由did的私钥加密。
[0092]
在一些实施例中，密码签名可以由钱包应用生成。在一些实施例中，用户的浏览器可以安装did管理插件模型，密码签名可以由用户的浏览器直接生成。在一些情况下，在生成认证数据之前，(多个)用户设备710中的至少一个需要经由密码和/或生物特征信息进一步验证用户。例如，在生成认证数据之前，用户可能需要在移动设备上输入密码和/或扫描他/她的指纹或虹膜。
[0093]
所生成的认证数据继而被发送到服务提供者730，如箭头724所示。接收到认证数据后，服务提供者730将核验认证数据，如箭头725所示。例如，在某些情况下，如果使用pki作为认证机制，并且服务提供者730接收到密码签名，则服务提供者730将从分布式账本740获取did的公钥，并使用获取的公钥尝试解密密码签名。如果密码签名被正确解密，则服务提供者730确定用户的身份已经被认证，否则，用户的身份未被认证。
[0094]
在一些实施例中，公钥的散列被传播到分布式账本上。在这种情况下，认证数据不仅包括密码签名，还包括公钥。服务提供者730将获取记录在分布式账本上的散列，使用接收到的公钥来验证公钥对应于散列，然后使用接收到的公钥来验证密码签名是有效的。
[0095]
一旦完成核验，服务提供者730通常将提供或拒绝用户的服务请求，由箭头726表示。例如，用户正试图访问他/她的云存储。当用户的身份已被成功核验时，服务提供者730将授予用户访问他/她的云存储的权限。作为另一示例，用户正在尝试租车。当用户的身份被成功核验后，服务提供者730将向用户提供租车的钥匙。
[0096]
上述场景只是服务提供者认证用户的身份的一个示例。在用户的两个钱包应用之间也可以使用类似的认证机制。在这种情况下，服务730被另一用户的设备替换。此外，在很多情况下，双方既是验证实体也是验证实体。例如，不止一个did所有者想要认证另一did所有者的用户；该另一did所有者也想认证第一个did所有者。在这种情况下，附加的镜像通信将从图7所示的相反方向发生。
[0097]
如上所述，验证实体(例如，服务提供者730)可以从分布式账本获取与特定did相关联的可用认证机制，并根据可用认证机制调整其认证请求。图8a和8b示出了针对特定认证机制定制的两个示例认证请求，它们都被编写为json web令牌(jwt)格式。
[0098]
图8a示出了由验证实体发布的请求令牌800a，验证实体对应于图7的服务提供者730。在该令牌800a中，令牌发布者(即，验证实体)请求主体实体(即，did所有者)提供他/她的姓名、电话号码和邮政编码(有或没有任何认证要求)。认证请求令牌800a包括指示令牌发布者的数据810a和指示令牌发布时间的数据820。认证请求令牌800还包括数据830a，其指示验证实体请求主体实体提供他/她的“姓名”、“电话”和“邮政编码”。请求令牌800a还包括回调地址https://service.microsoft.com/abcdefghijk 840a，它是要求did所有者将其响应发送到的url。最后，还有到期时间850，其指示请求令牌800a的到期时间，因此，did所有者必须在到期时间之前对请求令牌800a进行响应。省略号860a表示请求令牌800a还可以包括与令牌发布者、did所有者或认证机制相关的附加数据。
[0099]
图8b示出了另一示例认证请求令牌800b，其中验证实体要求经由可验证声明来执行认证。如图8b所示，请求令牌800b包括指示令牌800b被发布的时间的数据810b。请求令牌800b还包括数据820b，其指示所请求的可验证凭证。这里，所需的可验证凭证的类型是电子邮件凭证830b，即，验证实体要求did所有者提供并证明他/她的电子邮件地址。省略号840b表示在所请求的凭证字段820b中可能包括进一步指定可验证电子邮件地址的要求的附加数据。请求令牌800b还包括请求者的身份850b，即验证实体的did。最后，请求令牌800b还包括回调地址“https://service.microsoft.com/abcdefghijk”860b，它是请求认证服务将其响应发送到的url。
[0100]
接收到认证请求令牌后，与did相关联的设备(例如，用户设备710)将基于认证请求和可用的(多个)认证机制来调整其响应。图9a和9b示出了了由did主体(例如，(多个)用户设备710和/或用户的钱包应用321、322)生成的两个示例认证响应。
[0101]
图9a示出了与请求令牌800a对应的响应令牌900a。响应令牌900a包括指示该令牌900a被发布的时间的数据910a。响应令牌900a还包括指示令牌900a的到期时间的数据920。此外，响应令牌900a还包括语句930，其声明请求令牌800a所请求的did主体的姓名、电话号码和邮政编码。此外，响应令牌900a还包括公钥940a和令牌发布者950a。这里，令牌发布者是did所有者(例如，用户711)。公钥940a与did所有者相关联。省略号960a表示响应令牌900a中可能包括附加数据，诸如由did主体的私钥签署的密码签名。该响应令牌900a将被发送到请求令牌800a中包含的回调url“https://service.microsoft.com/abcdefghijk”840a，使得当验证实体接收到该响应令牌900a时，可以理解为该响应令牌900a旨在响应请求令牌800a。
[0102]
图9b示出了对应于请求令牌800b的另一示例响应令牌900b。响应令牌900b包括指示可验证声明的发布者的数据910b和指示该声明被发布的时间的数据920b。响应令牌900b
还包括声明930b，其包括所声明的事项和证明。该证明包括由声明发布者910b的私钥签署的签名，使得当验证实体接收到响应时，它可以获取与声明发布者的公钥相关的数据并使用与公钥相关的数据核验签名。响应令牌900b将被发送回请求令牌800b的回调url860b。
[0103]
在认证过程中，可以实现各种通信模式来达到认证目的。图10a至10e示出了可能在认证过程中出现的若干示例通信模式。图10a示出了在did所有者1011a与服务提供者1030a之间发生的示例通信模式1000a。在这种情况下，服务提供者1030a是验证实体。如图10a所示，用户1011a正在经由浏览器1020a从服务提供者的网页请求服务，这由箭头1021a表示。假设该请求包含用户的did。响应于服务请求1021a，服务提供者1030a访问分布式账本1040a以获取与did相关联的(多个)认证机制有关的数据，这由箭头1031a和1032a表示。
[0104]
基于所获取的与(多个)认证机制相关的数据，服务提供者1030a生成认证请求(对应于图8a或图8b的示例认证请求令牌800a、800b)，其由箭头1022a表示。所生成的认证请求被发送到用户的浏览器1020a，这由箭头1024a表示。从服务提供者1030a接收到认证请求，用户的浏览器1020a将认证请求传递至用户的钱包应用1010a，这由箭头1024a表示。
[0105]
在某些情况下，当用户的浏览器1020a和用户的钱包应用程序1010a驻留在相同设备上时，这样的通信在浏览器与钱包应用之间自动地在内部发生。备选地，当用户的浏览器1020a和钱包应用1010a驻留在不同设备上时，用户的浏览器1020a可以显示被配置为供用户的钱包应用1010a扫描的条形码或qr码。条形码或qr码包括在从服务提供者1030a接收的认证请求中包含的数据的至少一部分。用户1011a然后使用他/她的钱包应用1010a来扫描显示在浏览器1020a上的条形码或qr码。这样，认证请求经由条形码或qr码从浏览器1020a被发送至钱包应用1010a。这样的通信也可以经由自组织wifi、ble信标和/或nfc完成。
[0106]
接下来，基于接收到的认证请求，钱包应用1010a生成用于响应认证请求的认证数据，由箭头1025a表示。所生成的认证数据继而被封装在响应中并被发回服务提供者1030a，这由箭头1026a表示。从钱包应用1010a接收到包括认证数据的响应，服务提供者1030a继而核验认证数据，这由箭头1027a表示。响应于核验，服务提供者1030a将准许或拒绝用户1011a的服务请求。
[0107]
图10b示出了另一通信模式1000b，其发生在两个用户的钱包应用1010b与1020b之间。如图10b所示，用户1011b具有对钱包应用1010b的控制权，并且用户1021b具有对钱包应用1020b的控制权。这里，用户1011b是主体实体，而用户1020b是验证实体。例如，用户1011b可以是承包商，而用户1020b可以是正在寻找承包商来改造他/她的厨房的房主。当承包商(即，主体实体)1011b与房主(即，验证实体)1020b会面时，房主1020b想要验证承包商1010b的身份。
[0108]
首先，承包商1011b将经由他们的钱包应用1010b和1020b将他/她的did提供给房主1020b，这由箭头1031b表示。房主的钱包应用1020b继而访问分布式账本1030b来获得与认证机制相关的数据，这由箭头1032b和1033b表示。基于接收到的认证数据，房主的钱包应用1020b生成认证请求，由箭头1034b表示。认证请求继而从房主的钱包应用1020b被发送到承包商的钱包应用1010b，这由箭头1035b表示。接收到认证请求，承包商的钱包应用1010b继而生成相应的认证数据并将认证数据封装在响应中，这由箭头1036b表示。该响应然后从承包商的钱包应用1010b被发送到房主的钱包应用1020b，由箭头1037b表示。接收到包括认证数据的响应，房主的钱包应用1020b继而核验认证数据，这由箭头1038b表示。基于核验结
果，房主的钱包应用1020b然后向承包商的钱包应用1010b发送响应，由箭头1039b表示。例如，当核验成功时，房主1021b可以使用他/她的钱包应用1020b来发起与承包商的钱包应用1010b的额外交易，诸如签署合同或进行支付。
[0109]
钱包应用1010b与1020b之间的通信可以经由任何可用的通信通道执行，包括但不限于网络服务器、自组织wifi、ble信标信号、nfc、条形码或qr码扫描，等等。
[0110]
图10c示出了在用户1011c、认证服务1030c和服务提供者1040c之间发送的另一通信模式1000c。实线箭头表示一个实施例中的通信模式，而虚线箭头表示可能出现在其他备选实施例中的备选通信模式。
[0111]
首先，用户1011c经由服务提供者1040c的网页从浏览器1020c请求服务或发起通信，这由箭头1021c表示。该请求包括用户1011c的did。接收到请求，服务提供者1040c访问分布式账本1050c以获取与did相关联的一个或多个认证机制，其由箭头1022c和1023c表示。基于所获取的(多个)认证机制，服务提供者1040c生成认证请求，由箭头1024c表示。
[0112]
这里，所获取的(多个)认证机制中的至少一个认证机制是经由认证服务1030c。因此，在一些实施例中，生成的认证请求被直接发送到认证服务1030c，由箭头1025c表示。接收到来自服务提供者的认证请求，认证服务1030c继而生成认证数据，由箭头1026c表示。由认证服务1030c生成的认证数据然后被发送到用户的钱包应用1010c，由箭头1027c表示。然后，用户的钱包应用1010c转而将认证数据传递给服务提供者1040c，由箭头1028c表示。接收到认证数据，服务提供者1040c然后核验认证数据，由箭头1029c表示，并且响应用户的浏览器1020c，由箭头1031c表示。
[0113]
备选地，在一些实施例中，在服务提供者1040c生成认证请求(由箭头1024c表示)之后，服务提供者1040c将认证请求发送到浏览器1020c，由虚线箭头1032c表示。浏览器1032c可以将认证请求传递给认证服务1030c(由虚线箭头1033c表示)或者传递给钱包应用1010c(由虚线箭头1034c表示)。
[0114]
此外，在认证服务1030c生成认证数据(由箭头1026c表示)之后，在一些实施例中，认证服务1030c仅联系钱包应用1010c以通知用户接收到认证请求并获得用户的同意(由箭头1027c表示)。当用户的钱包应用1010c接收到通知时，钱包应用1010c同意并将同意发送回认证服务，由虚线箭头1035c表示。接收到用户的同意后，认证服务1030c继而将认证数据直接发送到服务提供者1040c，由虚线箭头1036c表示。
[0115]
图10d示出了在两个用户钱包1010d、1020d与认证服务1030d之间发生的另一通信模式。类似于图10b的场景，用户1011d可以是承包商，并且用户1021d可以是雇佣合同来改造他/她的厨房的房主。承包商1011d控制钱包应用1010d，而房主1020d控制钱包应用1020d。首先，承包商的钱包应用1010d向房主的钱包应用1020d发送承包商的did，由箭头1031d表示。接收到承包商的did之后，房主的钱包应用1020d继而访问分布式账本1040d以获得与did相关联的一个或多个认证机制有关的数据，由箭头1022d和1023d表示。
[0116]
基于获取的一个或多个认证机制，房主的钱包应用1020d然后生成认证请求(由箭头1034d表示)。认证请求继而被发送到承包商的钱包应用1010d(由箭头1035d表示)。接收到认证请求后，承包商的钱包应用1010d然后将认证请求传递给认证服务1030d(由箭头1036d表示)。基于认证请求，认证服务然后生成认证数据(由箭头1037d表示)。所生成的认证数据然后被发送到房主的钱包应用1020d(由箭头1038d表示)。房主的钱包应用1020d然
后核验认证数据(由箭头1039d表示)。基于核验结果，房主的钱包应用1020d然后还与承包商的钱包应用1010d通信(由箭头1041d表示)。
[0117]
类似于图10c所示的备选实施例，钱包应用1010d、1020d与认证服务1030d之间的通信也可以在不同模式中发生。例如，认证服务1030d还可以将认证数据发送到主体实体的钱包应用1010d，并让主体实体的钱包应用1010d将认证数据传递给验证实体的钱包应用1020d。
[0118]
最后，在许多交易中，认证是由双方共同执行的。在这种情况下，每个涉及方既是主体实体又是验证实体。图10e示出了在相互认证情况下发生的通信模式1000e。如图10e所示，第一用户1011e控制钱包应用1010e，并且第二用户1021e控制钱包应用1020e。一开始，钱包1010e与1020e交换彼此的did，由箭头1031e和1032e表示。接下来，钱包1010e和1020e中的每一个访问分布式账本以获得彼此的(多个)认证方法，由箭头1033e、1034e、1035e和1036e表示。钱包1010e和1020e中的每一个然后基于另一个did的(多个)认证方法生成其自身的认证请求，由箭头1037e和1038e表示。所生成的认证数据被发送到另一实体的钱包，由箭头1039e和1041e表示。接收到彼此的认证数据后，钱包应用1010e和1020e中的每一个核验接收到的认证数据(由箭头1042e和1043e表示)。基于核验结果，钱包1010e和1020e然后可以执行额外的通信(由箭头1044e和1045e表示)。
[0119]
请注意，在图10a到10e中，由钱包应用执行的所有通信也可以由id中心和/或用户代理执行。在一些实施例中，id中心和/或用户代理被配置为在认证过程中执行完整的通信或通信的至少一部分。因此，图10a至10e中所示的钱包应用并不旨在将实施例的范围限制为仅由钱包应用执行，并且所示的钱包应用中的每一个都可以由管理模块、id中心和/或一个用户代理代替。
[0120]
此外，尽管以特定顺序讨论了通信箭头或以通信序列示出了通信箭头，但是除非特别说明，否则不要求特定排序，或者因为通信依赖于在该通信被发送之前完成的另一通信而要求特定排序。
[0121]
下面的讨论现在参考许多方法和所执行的方法动作。图11示出了示例方法1100的流程图，示例方法1100用于生成可以经由一个或多个认证机制被认证的did。方法1100由充当管理模块(例如，钱包应用)、用户代理和/或id中心的计算系统执行。方法1100包括接收用以生成去中心化标识符的用户指示(1110)。用户指示包括对多个认证机制中的至少一个认证机制的选择。多个认证机制包括但不限于(1)pki、(2)认证服务、(3)自发布声明和/或(4)可验证声明。
[0122]
响应于用户指示，计算系统生成去中心化标识符(1120)以及对应的did文档(1130)。然后，计算系统将包含在did文档中的数据的至少一部分传播到分布式账本(1140)。did文档包括至少(1)与did相关的数据，以及(2)与至少一个认证机制相关的数据。在一些实施例中，与did相关的数据是did或did的散列。当所选择的至少一个认证机制包括pki，生成去中心化标识符包括生成密钥对，包括公钥和私钥。生成did文档包括将公钥记录在did文档中。将在did文档中包含的数据的至少一部分传播到分布式账本包括至少将与公钥相关的数据记录在分布式账本中(1141)。在一些实施例中，与公钥相关的数据是公钥；或者，与公钥相关的数据是公钥的散列，或者可以用作公钥的证明或用来核验公钥的公钥的任何变换。
[0123]
在一些实施例中，当至少一个认证机制是认证服务时，传播到分布式账本的数据包括与认证服务相关的数据(1142)。在某些情况下，与认证服务相关的数据包括认证服务的标识符(例如，did)。在一些实施例中，当至少一个认证机制是自发布声明或可验证声明时，要被包括在声明中的一个或多个属性被传播到分布式账本(1143)。例如，一个或多个属性可以包括电子邮件地址。
[0124]
方法1100还包括接收来自验证实体的用于认证用户动作的请求(1150)。例如，用户可能正在请求验证实体提供的服务，而验证实体想知道用户的身份，也想验证代表用户行动的人，实际上，did所有者。响应于认证请求，计算系统基于至少一个认证机制生成认证数据(1160)。
[0125]
在一些实施例中，当至少一个认证机制包括pki时，认证数据包括密码签名(1161)。当至少一个认证机制包括认证服务时，认证包括认证服务的端点(1162)。在某些情况下，认证服务的端点是url，其引用认证服务的端点以验证特定did，因此，每个url对应于一特定did。在一些实施例中，当至少一个认证机制包括可验证声明时，认证数据包括声明发布者的身份(例如，声明发布者的did)和/或声明发布者发布的声明(1163)。
[0126]
接下来，所生成的认证数据被发送到验证实体(1170)，并且验证实体被致使依据正在实施的(多个)认证机制来核验认证数据(1180)。注意，在某些情况下，验证实体不一定要求主体的信息是可验证的，而只是希望主体实体提供一些关于其自身的信息。如图8a所示，验证实体只需要用户提供他/她的姓名、电话号码和邮政编码。在这种情况下，验证实体可以将所要求的信息放入请求中，并且主体实体可以将响应包括在认证数据中，而无需执行任何认证机制。备选地，验证实体也可以请求经由密码签名来认证这些信息。在这种情况下，主体实体将被要求在响应的末尾附加密码签名，至少用来认证该响应是由did的所有者生成的。
[0127]
图12示出了用于认证与did相关联的用户的示例方法1200。方法1200由充当服务提供者、钱包应用、用户代理和/或id中心的验证实体的计算系统执行。方法1200包括接收来自用户的设备接收来自用户的设备的请求，该用户与去中心化标识符(did)相关联(1210)。基于用户的did，计算系统访问分布式账本以获得与did相关联的(多个)认证机制相关的数据(1220)。在一些实施例中，当(多个)认证机制包括pki时，与did的公钥相关的数据是从分布式账本获得的(1221)。在一些实施例中，当(多个)认证机制包括认证服务时，获得与认证服务相关的数据(1222)。在一些实施例中，当认证机制包括可验证声明时，声明发布者的身份被获得(1223)。
[0128]
基于获得的认证机制，计算系统然后生成认证请求(1230)。如图8a和8b所示，取决于认证机制，生成不同的认证请求800a或800b。然后将生成的认证请求发送到用户的设备或认证服务(1240)。接收到认证请求后，认证服务或用户的设备生成包括认证数据的响应。然后计算系统接收包含认证数据的响应(1250)。
[0129]
当(多个)认证机制包括密码签名(1251)时，从用户的设备接收认证数据，并且该认证数据包括密码签名。当(多个)认证机制包括认证服务时，认证数据从用户的设备被接收，或者直接从认证服务被接收。接收到的认证数据可以包括认证服务的端点(例如，与认证服务的端点对应的url，该认证服务与特定did对应)。在一些实施例中，当认证机制包括可验证声明时，认证数据包括声明发布者的身份和由声明发布者签署的声明。
[0130]
一旦接收到认证数据，计算系统继而基于所使用的认证机制来核验认证数据(1260)。当至少一个认证机制包括pki时，验证实体将尝试使用主体实体的公钥来解密密码签名。如果解密结果是有效的，则指示密码签名确实是由did的所有者生成的，因此用户的动作是有效的。如果解密结果是无效的，则指示密码签名不是由did的所有者生成的，因此用户动作无效。当认证成功时，验证实体最终将执行附加通信或动作以完成请求的交易。当认证不成功时，验证实体将拒绝来自主体实体的请求和/或向主体实体通知该拒绝。
[0131]
对于本文所公开的过程和方法，在过程和方法中执行的操作可以以不同的顺序实施。尽管方法动作可以按特定顺序讨论或在流程图中被示为按特定顺序发生，但是除非特别说明，否则不需要特定排序，或者由于一个动作依赖于在该动作开始之前完成的另一动作而需要特定排序。此外，所概述的操作仅作为示例提供，一些操作可以是可选的，可以组合成更少的步骤和操作，补充进一步的操作，或者扩展成附加的操作，而不偏离所公开的实施例的本质。
[0132]
本发明可以在不背离其精神或特征的情况下以其他具体形式体现。所描述的实施例在所有方面都被认为仅是说明性的而非限制性的。因此，本发明的范围由所附权利要求而不是由以上描述来指示。在权利要求的等同物的含义和范围内的所有变化都应包含在权利要求的范围内。