用于创建对用户身份鉴权的证书的方法和系统与流程

本申请要求2015年5月27日递交的发明名称为“用于创建对用户身份鉴权的证书的方法和系统(METHOD AND SYSTEM FOR CREATING A CERTIFICATE TO AUTHENTICATE A USER IDENTITY)”第14/723,350号美国非临时专利申请案的在先申请优先权，该在先申请又要求2014年5月28日递交的发明名称为“来自多个身份提供者的PGP类型用户身份(PGP-STYLE USER IDENTITIES FROM MULTIPLE IDENTITY PROVIDERS)”第62/003,980号美国专利申请案的在先申请优先权，这两个在先申请的全部内容均以引入的方式并入本文本中。

技术领域

本发明实施例大体涉及身份认证。具体而言，本发明实施例涉及用于安全互联网浏览的身份认证，尤其涉及一种用于创建对用户身份鉴权的证书的方法和系统。

背景技术：

网页浏览器实时通信(Real-time communication in web browsers，RTCWEB)安全架构基于联合身份系统，其中浏览器依赖于第三方身份提供者(Identity Provider，IdP)来提供若干服务。IdP的示例包括OpenID、OAuth和Mozilla Persona。一种服务是将数据报传输层安全(Datagram Transport Layer Security，DTLS)证书指纹以加密形式绑定到用户身份，使得向用户确保加密媒体流(即，安全实时传输协议(Secure Real-time Transport Protocol，SRTP))来自、去往鉴权用户所拥有的源。另一种服务允许用户在呼叫发起期间通过独立于呼叫站点的IdP相互鉴权。例如，两个用户可以通过扑克网站的呼叫应用利用他们的社交媒体账号相互鉴权。

用户可能想要由不同的IdP核实身份，从而避免单点故障或流量瓶颈。在当前身份协议中，每个用户身份绑定一个IdP，并且每个身份只存在一个核实路径。在某些场景下，所有关键IdP可能变为不可用，但是网络仍允许浏览器以点到点(point-to-point，P2P)方式通信。当前身份协议不支持这种用户之间的直接鉴权。出于各种原因，用户可能想要在不失去两者之间的联系的情况下将旧身份替换为新身份。然而，当前身份协议不允许一种身份以加密形式绑定到另一种身份，从而使得核实这种联系变得困难且昂贵。

技术实现要素：

通过以上内容，所属领域的技术人员将理解需要创建允许用户具有多个身份且这些身份可被不止一个身份提供者认证的身份架构。根据本发明，提供一种用于创建对用户身份鉴权的证书的方法和系统，极大减少并基本消除与传统身份系统相关的问题。

根据一实施例，一种用于在网页浏览器创建对用户身份鉴权的证书的方法包括接收包含用户的第一用户身份的登录请求，以及使用将所述第一用户身份关联到所述网页浏览器的公共密钥和秘密密钥生成第一浏览器签名证书。将所述第一浏览器签名证书发送给第一身份提供者服务器；作为响应，接收来自所述第一身份提供者服务器的第一服务器签名证书。所述第一服务器签名证书将所述第一用户身份关联到所述第一身份提供者服务器。通过将所述第一浏览器签名证书和所述第一服务器签名证书合并来生成最终证书。

根据另一实施例，一种用于创建对用户身份鉴权的证书的身份提供者服务器包括网络接口，用于接收来自浏览器的第一浏览器签名证书。所述第一浏览器签名证书将第一用户身份关联到所述浏览器。处理器用于使用将所述第一用户身份关联到所述第一身份提供者服务器的公共密钥和秘密秘钥根据所述第一浏览器签名证书生成第一服务器签名证书。所述网络接口用于将所述第一服务器签名证书发送给所述浏览器。

本发明描述传统身份系统的许多技术优势。例如，一个技术优势是为用户建立适用于多个用户身份的单个证书。另一技术优势是在多个身份提供者间交叉认证用户证书。又一技术优势是在呼叫鉴权期间使用并修改证书。对于本领域技术人员来说，其它技术优势从下文附图、描述和权利要求显而易见并且可识别。

附图说明

为了更完整地理解本发明各实施例及其优点，现在参考下文结合附图进行的描述，相同参考标号表示相同部分，其中：

图1示出了根据本发明实施例的身份架构；

图2描绘了身份架构中使用的扩展良好隐私加密(Extended Pretty Good Privacy，E-PGP)证书方案；

图3示出了根据本发明一实施例的示例性过程；

图4示出了身份架构中使用的E-PGP安全原语表；

图5描绘了在身份架构中为用户生成身份确认证书的工作流；

图6A至6B示出了通过身份提供者间的交叉认证在身份架构中扩展证书的工作流；

图7示出了在身份架构中的浏览器之间的呼叫中使用并扩展证书的工作流；

图8示出了在浏览器之间的呼叫中将不同网页身份与证书关联的方法；以及

图9示出了用于实施浏览器和/或身份提供者服务器的网络部件的图。

具体实施方式

现在将详细地给出一些实施例的参考。虽然结合可替代的实施例描述该主题但应该理解它们不是旨在将请求保护的主题限制于这些实施例。相反，请求保护的主题旨在覆盖可以包括在由附加的权利要求书限定的请求保护的主题的精神和范围内的替代物、修改和等同物。

另外在以下详细描述中阐述了许多具体细节以便提供对请求保护主题的透彻理解。然而所属领域的技术人员将认识到可以在没有这些具体细节的情况下实践实施例。在其它实例中没有详细描述众所周知的方法、流程、部件和电路以免对本请求保护的主题的各方面和特征造成不必要地模糊。

以流程、步骤、逻辑块、处理和对数据比特的操作的其它符号表示的观点展示了一些详细描述部分，这些操作可以在计算机存储器上执行。这些描述和表述为数据处理领域技术人员用来将其工作的实质最有效地传达给本领域其它技术人员。程序、计算机执行的步骤、逻辑块、过程等通常被认为是导致期望结果的自洽步骤或指令顺序。这些步骤是那些需要物理量的物理运算的步骤。通常，虽然不一定，但是这些量采取能够在计算机系统中存储、传送、合并、比较或者操作的电信号或磁信号的形式。有时很方便，主要原因是共同使用，将这些信号称为比特、值、元素、符号、字符、术语、数字等。

然而应牢记所有这些和类似术语与适当物理量相关联且仅为应用于这些量的方便标签。除非确切地陈述为从以下论述显而易见，否则应了解利用例如“访问”、“写入”、“包括”、“存储”、“传输”、“遍历”、“关联”、“标识”等术语的论述是指将表示为计算机系统的寄存器和存储器内的物理(电子)量的数据操控和变换为类似地表示为计算机系统存储器或寄存器或其它此类信息储存、传输或显示设备内的物理量的其它数据的计算机系统或类似电子计算设备的动作和进程。

以下所述图1至图8以及该专利文档中的各种实施例仅通过举例说明的方式描述本发明的原理，而不应以任何方式理解为对本发明范围的限制。本领域技术人员可以理解的是，本发明的原理可通过任何一种设置合理的设备和系统实现。一个附图中示出和论述的特点可适当实施在一个或多个其它附图中。

图1示出了示例身份架构100。身份架构100可在多种场景下使用，包括网页实时通信(web real-time communications，WebRTC)应用。身份架构100包括用户102(用户0 102a和用户1 102b)、浏览器104(浏览器0 104a和浏览器1 104b)、数据库106(DB0 106a和DB1 106b)，以及身份提供者(identity provider，IdP)服务器(IdP1服务器108、IdP2服务器110，以及IdP3服务器112).身份架构100还包括提供WebRTC和其它应用的网页服务器114。根据一个方面，本发明实施例提供了一种在WebRTC架构中认证并核实用户身份的方法。在一实施例中，用户102(用户0 102a)通过浏览器104(浏览器0)登录身份提供者服务器IdP1 108。浏览器0 104通过用户0 102使用IdP1服务器108的登录账号所对应的网页身份协议116与IdP1服务器108连接。浏览器0 104与IdP1服务器108连接来创建并认证用户0 102的第一扩展良好隐私加密(E-PGP)证书。E-PGP证书在浏览器0 104和IdP1服务器108中通过E-PGP客户端-服务器协议118认证。浏览器0 104随后通过网页身份协议116和E-PGP客户端-服务器协议118与IdP2服务器110连接来认证第一E-PGP证书、创建第二E-PGP证书，并将第一、第二E-PGP证书合并为单个证书。在创建第二E-PGP证书时，IdP2服务器110通过E-PGP服务器-服务器协议120与IdP1服务器108连接。

E-PGP客户端-服务器协议118允许浏览器通过多个IdP服务器认证多个用户身份和别名。E-PGP服务器-服务器协议120允许E-PGP证书在IdP服务器间交叉认证。网页浏览器可通过E-PGP客户端-服务器协议118和E-PGP服务器-服务器协议120请求多个IdP服务器交叉认证这些服务器鉴权的用户的E-PGP证书。网页浏览器随后可在端到端(Peer-to-Peer，P2P)通信中(例如，发起WebRTC呼叫)对用户进行鉴权并使用E-PGP证书相互认证。如果特定IdP服务器中出现故障，用户身份可通过身份架构100中的不同路径核实。多个用户身份可包含在一个E-PGP证书中。E-PGP证书可以在客户端-服务器、服务器-服务器，以及端到端(peer-to-peer，P2P)架构中使用。

良好隐私加密(PGP)是一种为数据通信提供加密隐私和鉴权的数据加解密程序。PGP经常用于对文本、邮件、文件、目录和整个磁盘分区进行签名、加密和解密，以及增加邮件通信的安全。每个用户具有公开已知的加密密钥和仅为该用户所知晓的秘密密钥。发送方所发送的消息使用接收方的公共密钥进行加密。该消息在接收后使用接收方的秘密密钥进行解密。PGP使用快速加密算法通过会话密钥对该消息进行加密，会话密钥是一种一次性秘密密钥。会话密钥使用接收方的公共密钥进行加密。加密消息和会话密钥都发送给接收方，接收方首先使用接收方的秘密密钥来解密会话密钥，随后使用会话密钥来解密消息。PGP在发送数字签名时使用高效算法，该高效算法根据用户姓名和其它签名信息生成哈希(一种由数学运算生成的总结)或指纹。该指纹哈希码随后使用发送方的秘密密钥进行加密。接收方使用发送方的公共密钥来解密哈希码。如果该哈希码与作为消息数字签名发送的哈希码匹配，则接收方确定该消息安全地来自指定发送方。

数字证书简化了建立公共密钥是否确实属于所宣称的所有者的任务。数字证书是功能与实体证书非常类似的数据。数字证书是包含个人公共密钥的信息，有助于其他人核实密钥是真实的或是有效的。数字证书用于阻止尝试将某个人的密钥替换为其他人的密钥。数字证书包含三项：公共密钥、证书信息(用户“身份”信息，例如姓名、用户ID等)以及一个或多个数字签名。证书上的电子签名旨在声明证书信息已被其他人或实体证明。数字签名只能证明带签名的身份信息伴随着，或者绑定到，公共密钥，而不会证明整个证书的真实性。

图2所示为E-PGP证书的示例。标准PGP证书200包括(但不限于)以下信息：PGP版本号、证书持有者的公共密钥、证书持有者信息、证书持有者的数字签名、证书有效期，以及公共密钥的优选对称加密算法。PGP版本号标识使用PGP的哪个版本来创建与证书关联的密钥。证书持有者的公共密钥是密钥对和Rivest-Shamir-Adleman(RSA)、Diffie-Hellman(DH)，或数字签名算法(Digital Signature Algorithm，DSA)等密钥算法的公共部分。证书持有者信息包括用户“身份”信息，例如姓名、用户ID、照片等。证书所有者的数字签名，也称为自签名，是使用与证书关联的公共密钥的对应私有(或秘密)密钥的签名。证书有效期是指示证书何时过期的开始日期/时间和到期日期/时间。密钥的优选对称加密算法指示证书所有者倾向于加密信息所用的加密算法。支持的算法包括Carlisle Adams Stafford Tavares(CAST)、国际数据加密算法(International Data Encryption Algorithm，IDEA)，以及三重数据加密标准(Triple Data Encryption Standard，3DES)。

标准的PGP证书是一种绑定一个或多个“标签”的公共密钥。这些‘标签’包含标识密钥所有者的信息以及密钥所有者的签名，该签名声明密钥和身份确认互相关联。PGP证书格式的一个独特之处在于单个证书可以包含多个签名。几个人或多个人可为密钥/身份确认对进行签名以证明他们保证公共密钥确实属于指定所有者。一些PGP证书包括含若干标签的公共密钥，每个标签包含标识密钥所有者的不同方式(例如，所有者姓名和公司邮箱账号，所有者昵称和家庭邮箱账号，所有者照片—所有这些信息都在一个证书中)。每个身份的签名列表可能不同，签名证明一个标签属于公共密钥的真实性，而不能证明密钥上的所有标签是真实的。

E-PGP证书202是带有附加字段的标准PGP证书。附加字段包括签名到期时间字段和用户资源信息字段。签名到期时间字段允许认证器独立于该证书的生存期和其它认证器控制身份有效性。证书的每个认证器可指定各个认证有效的时段。只要还未达到另一个认证器的到期时间，某个认证器的时段到期不会使证书失效。例如，认证器A认证cert_{x}5个小时，而认证器B认证cert_{x}30天。在这种方式下，无需创建两个证书分别用于A和B以便具有不同的有效期。因此，本发明实施例提供一种避免使所有相关私有密钥和缓存副本无效化的无用证书调用的方法。用户资源信息字段提供证书重续和密钥获取服务。

图3所示为用于创建对用户身份鉴权的证书的一般流程图300。流程图300开始于在方框302处，在浏览器104a处接收来自用户102a的含用户身份的登录请求。浏览器104a在方框304处通过身份提供者108对用户身份鉴权，并通过向用户身份应用浏览器签名建立初始浏览器签名证书。在方框306处，身份提供者108接收来自浏览器104a的初始浏览器证书，并将其身份提供者签名应用于初始浏览器证书，从而创建身份提供者服务器签名证书。身份提供者108还可将别名身份与用户关联。在方框308处，身份提供者108将别名身份添加到身份提供者服务器签名证书中。在方框310处，身份提供者108将其身份提供者签名应用于身份提供者服务器签名证书中的别名身份。在方框312处，浏览器104a接收身份提供者服务器签名证书并将其浏览器签名应用于该证书中的别名身份，在方框314处，浏览器104a将身份提供者服务器签名证书和初始浏览器签名证书合并来获取在认证用户102a的各种身份中使用的最终浏览器签名证书。在方框316处，在身份提供者之间执行交叉认证，这样用户之间的交互，例如WebRTC呼叫，可以很容易进行鉴权。

图4所示为用于E-PGP证书管理的示例应用编程接口。图4所示示例原语指定证书树格式，生成自签名证书，将新身份(别名)添加到现有证书中，通过一个证书对另一证书中的身份进行签名，核实身份已被认证并且签名尚未过期，通过一组信任规范验证证书，将两个证书树合并为一个证书，通过证书为一个字符串签名从而产生签名，以及使用证书核实字符串上的签名。在一个方面，如果存在某种标准，例如，只要IdP接受可以在E-PGP证书中使用的用户标识符，证书生成和扩展过程独立于IdP所使用的登录协议。在一实施例中，在到期之前，用户只需向IdP鉴权一次。示例原语与当前的PGP标准和若干实施方案(例如，OpenPGP和GnuPGP)兼容，只有一些细微修改，但并不改变任何加密算法。这些示例原语在本文所描述的提供网页浏览器和IdP服务器之间以及网页浏览器之间的用户鉴权和认证。

图5所示为用于生成身份确认证书的E-PGP客户端-服务器协议118的示例工作流500。将工作流500划分为三部分—鉴权502、证书关联504，以及别名生成和证书合并506。在步骤1至5中执行鉴权部分502。IdP1服务器108生成其自身的带有含公共密钥和秘密密钥的签名s1的证书cert1(步骤1)。用户0 102a通过浏览器0 104a使用其身份id1登录IdP1服务器108(步骤2和3)。IdP1服务器108对id1进行鉴权(步骤4)并通知浏览器0 104a(步骤5)鉴权成功。

在步骤6至8中执行证书关联部分504。浏览器0 104a为身份id1生成带有含公共密钥和秘密密钥的签名s0的浏览器签名证明cert0(步骤6)，并将浏览器签名证书cert0传输给IdP1服务器108(步骤7)。IdP1服务器108通过将其证书cert1和含公共和私有密钥的签名s1与证书cert0的身份id1关联来生成服务器签名证书cert2(步骤8)。IdP1服务器108现在使用其签名s1为身份id1签名。IdP1服务器108还在生成服务器签名证书cert2中包含到期时间字段和统一资源信息字段。

在步骤9至14中执行别名生成和证书合并部分506。IdP1服务器108可将一个或多个别名身份与用户0 102a关联。在所示示例中，将一个别名身份a1添加到服务器签名证书cert2中(步骤9)。别名身份a1用于隐藏用户0 102a的真实身份id1。IdP1服务器108随后在服务器签名证书cert2中将别名身份a1绑定到其证书cert1和签名s1(步骤10)。IdP1服务器108通过核实的身份id1和a1将服务器签名证书cert2发送给浏览器0 104a(步骤11)。浏览器0 104a将其签名应用于别名身份a1并将签名到期时间和统一资源信息字段插入到服务器签名证书cert2中(步骤12)。浏览器0 104a将其原先创建的浏览器签名证书cert0和由IdP1服务器108原先创建并由浏览器0 104a修改的服务器签名证书cert2合并来创建最终的E-PGP证书508。浏览器签名证书cert0和服务器签名证书cert2具有相同的公共密钥，因为证书cert2通过添加别名和签名从证书cert0派生而来。浏览器签名证书cert0现在具有由浏览器0 104a和IdP1服务器108签名的身份id1和别名身份a1。

图6A至6B所示为在多个IdP服务器对证书进行交叉认证的E-PGP服务器-服务器协议120的示例工作流600。工作流600允许IdP服务器108对E-PGP证书进行交叉认证。从图6A开始，IdP1服务器108如先前那样生成其自身的带有含公共密钥和秘密密钥的签名s1的证书cert1(步骤1)。IdP2服务器110生成其自身的带有含公共密钥和秘密密钥的签名s2的证书cert3(步骤2)。用户0 102a通过浏览器0 104a使用其身份id2登录IdP2服务器110(步骤3和4)。IdP2服务器110对id2进行鉴权(步骤5)并通知浏览器0 104a(步骤6)鉴权成功。在一方面，用户可以在不完全信任特定IdP服务器的情况下使用特定IdP服务器，例如IdP2服务器110，进行鉴权。用户可通过使用别名向第三方IdP服务器隐藏其真实身份(例如，可路由的邮箱地址)。有利的是，这可使得接收到的垃圾邮件和/或呼叫数量减少。在这种情况下，浏览器0 104a将使用别名身份a1进行认证(步骤7和8)。浏览器0 104a创建浏览器签名证书cert4以将身份id2添加到浏览器签名证书cert0中以便与别名身份a1关联(步骤9)。浏览器0 104a将其签名s0应用于身份id2，包括为浏览器签名证书cert4填充与身份id2关联的签名到期时间字段和统一资源信息字段(步骤10)。将新创建的浏览器签名证书cert4提供给IdP2服务器110(步骤11)。

IdP2服务器110将其签名s2应用于身份id2以创建服务器签名证书cert5(步骤12)。IdP2服务器110认识到浏览器签名证书cert4与IdP1服务器108的证书cert1和别名身份a1绑定。IdP2服务器110请求并接收来自IdP1服务器108的证书cert1(步骤13和14)。IdP2服务器110检查IdP1服务器108认证别名身份a1并检查签名尚未过期(步骤15)。IdP2服务器110使用信任规范对服务器签名证书cert5进行验证(步骤16)。验证后，IdP2服务器110使用其签名s2对别名身份a1进行签名(步骤17)，并在需要时添加签名到期时间和统一资源信息字段。在该时间点，IdP2服务器110可将用户0 102a的第二别名身份a2添加到服务器签名证书cert5中(步骤18)。如果这样的话，IdP2服务器110使用其签名s2对别名身份a2进行签名(步骤19)，并在需要时添加签名到期时间和统一资源信息字段。

移至图6B，IdP2服务器110将服务器签名证书cert5发送给IdP1服务器108(步骤20)。IdP1服务器108现执行认证服务器签名证书cert5和别名身份a2的过程。IdP1服务器108认识到服务器签名证书cert5与IdP2服务器110的证书cert3和别名身份a2绑定。IdP1服务器108请求并接收来自IdP2服务器110的证书cert3(步骤21和22)。IdP1服务器108检查IdP2服务器110认证别名身份a2并检查签名尚未过期(步骤23)。IdP1服务器108使用信任规范对服务器签名证书cert5进行验证(步骤24)。验证后，IdP1服务器108使用其签名s1对别名身份a2进行签名(步骤25)，并在需要时添加签名到期时间和统一资源信息字段来创建服务器签名证书cert6。此时，IdP1服务器108已对身份id1、别名身份a1和别名身份a2进行签名和核实。IdP1服务器108将服务器签名证书cert6发送给IdP2服务器110(步骤26)。IdP2服务器110将从IdP1服务器108接收到的服务器签名证书cert6与服务器签名证书cert5合并(步骤27)。此时，IdP2服务器110已对身份id2、别名身份a1和别名身份a2进行签名和核实。

将合并后的服务器签名证书cert5发送到给浏览器0 104a(步骤28)。浏览器0 104a将其签名s0应用于别名身份a2，包括为浏览器签名证书cert4填充与别名身份a2关联的签名到期时间字段和统一资源信息字段(步骤29)。浏览器0 104a将其原先创建的浏览器签名证书cert0和浏览器签名证书cert4合并来创建最终的E-PGP证书602(步骤30)。浏览器签名证书cert0和浏览器签名证书cert4具有相同的公共密钥，因为浏览器签名证书cert4通过添加身份id2、别名身份a2和签名从证书cert0派生而来。浏览器签名证书cert0现具有浏览器0 104a和IdP1服务器108签名的身份id1、浏览器0 104a和IdP2服务器110签名的身份id2，以及浏览器0 104a、IdP1服务器108和IdP2服务器110签名的别名身份。通知用户0 102a交叉认证过程完成(步骤31)。图6B所示为执行E-PGP服务器-服务器协议120之前的交叉认证前状态604，以及完成E-PGP服务器-服务器协议120之后的交叉认证后状态606。

图7所示为使用E-PGP证书对WebRTC呼叫进行鉴权的示例工作流700。工作流700开始于用户0 102a使用别名身份a1向用户1 102b发起呼叫提议(步骤1)。在接收来自用户0 102a的呼叫提议请求之后，浏览器0 104a为呼叫生成E-PGP证书的数据报传输层安全(Datagram Transport Layer Security，DTLS)协议指纹f0(步骤2)。指纹是用户证书的哈希并作为证书的一个属性出现。DTLS指纹将媒体平面的DTLS密钥交换绑定到信令平面。用户1 102b能够核实在DTLS握手中进行鉴权所使用的呼叫方的用户0 102a证书可以关联到呼叫提议中包含的证书指纹。当用户1 102b接受该呼叫提议时，将包含用户1 102b指纹的应答提供给用户0 102a。用户0 102a可以接受或拒绝用户1 102b证书，且如果接受的话，向用户1 102b指示媒体是安全的。

浏览器0 104a对证书cert0和指纹f0进行签名(步骤3)。浏览器0 104a将包含签名、指纹和证书的呼叫提议转发给具有呼叫应用的网页服务器114(步骤4)。网页服务器114处理该呼叫提议并将该呼叫提议转发给浏览器1 104b(步骤5)。在认识到浏览器签名证书cert0与证书cert1和cert3绑定时，浏览器1 104b请求并接收来自IdP1服务器108的证书cert1(步骤6和7)。浏览器1 104b检查IdP1服务器108认证别名身份a1并检查签名尚未过期(步骤8)。浏览器1 104b请求并接收来自IdP1服务器110的证书cert3(步骤9和10)。浏览器1 104b检查IdP2服务器110认证别名身份a1并检查签名尚未过期(步骤11)。浏览器1 104使用信任规范验证浏览器签名证书cert0(步骤12)。浏览器1 104b核实浏览器0 104a所提供的签名、指纹和证书(步骤13)。浏览器1 104b在核实之后将该呼叫转发给用户1 102b。

如果用户1 102b接受该呼叫，浏览器1 104b使用与用户1 102b关联的浏览器签名证书cert7和别名身份a4识别该呼叫(步骤15)。浏览器签名证书cert7和别名身份a4先前在浏览器1 104b中生成，生成方式类似于上文论述的例如与IdP2服务器110的交互中浏览器0 104a生成证书和别名身份。浏览器1 104b将其签名s3应用于别名身份a2来创建浏览器签名证书cert8(步骤16)。浏览器1 104b为该呼叫生成浏览器签名证书cert8的DTLS协议指纹f8(步骤17)。浏览器0 104b对浏览器签名证书cert8和指纹f8进行签名(步骤18)。尽管未在此处特别示出，浏览器1 104b可执行合并功能将证书cert0、cert1和cert3合并来特别为浏览器1 104b创建最终E-PGP证书。

浏览器1 104b将包含签名、指纹和证书的呼叫应答转发给网页服务器114(步骤19)。网页服务器114处理该应答并将该应答转发给浏览器0 104a(步骤20)。浏览器0 104a如先前所述执行检测、验证、核实和合并步骤，这样浏览器0 104a可以更新与别名身份a4关联的E-PGP证书(步骤21)。浏览器0 104将该应答转发给用户0 102a(步骤22)。该呼叫通过浏览器0 104a和浏览器1 104b使用安全实时传输协议(Secure Real-time Transport Protocol，SRTP)在用户0 102a和用户1 102b之间进行(步骤23)。呼叫状态702显示在用户0 102a和用户1 102b之间建立呼叫时绑定证书。浏览器1 104现直接关联用户0 102a的别名身份a1。浏览器1 104现在能够直接认证别名身份a1。可通过E-PGP服务器-服务器协议120执行其它交叉认证过程来更新各个E-PGP证书。

频繁使用E-PGP证书可缩短身份架构100中的实体间的处理路径。例如，实体A经过实体B到达实体C的路径可缩短为实体A到实体C之间的直接路径。如图所示，浏览器1与身份a1的新添加证书关系缩短了浏览器1在后续呼叫中认证身份的路径长度。有利的是，实体的多个混合鉴权路径增加了身份可用性和系统健壮性。

图8所示为指示不同网页身份通过单个E-PGP证书连接的简化示例工作流800。工作流800开始于用户0 102a使用别名身份a1向用户1 102b发起呼叫(步骤1)。浏览器0 104a处理该呼叫请求并将呼叫提议提供给网页服务器114(步骤2)。网页服务器114处理该呼叫提议并将该呼叫提议转发给此示例中的浏览器1 104b(步骤3)。浏览器1 104b如上所述处理该呼叫提议的别名身份a1(步骤4)。将该呼叫提议提供给用户1 102b(步骤5)。在接受到该呼叫提议后，浏览器1 104b如上所述处理证书并将结果转发给网页服务器114(步骤6)。网页服务器114将呼叫应答提供给浏览器0 104a(步骤7)并向用户0 102a提供呼叫细节以便与用户1 102b通信(步骤8)。

用户0 102a使用别名身份a2向用户1 102b发起二次呼叫(步骤9)。浏览器0 104a处理该呼叫请求并将呼叫提议提供给网页服务器114(步骤10)。网页服务器114处理该呼叫提议并将该呼叫提议转发给此示例中的浏览器1 104b(步骤11)。浏览器1 104b处理别名身份a2并从E-PGP证书中确定别名身份a1与别名身份a2相同。(步骤12)。浏览器1 104b将别名身份a1与别名身份a2关联并以上文论述的方式处理该呼叫提议(步骤13)。将该呼叫提议提供给用户1 102b(步骤14)。在接受到该呼叫提议后，浏览器1 104b如上所述处理证书并将结果转发给网页服务器114(步骤15)。网页服务器114将呼叫应答提供给浏览器0 104a(步骤16)并向用户0 102a提供呼叫细节以便与用户1 102b通信(步骤17)。

呼叫状态802显示浏览器1 104b如何认识到具有相同公共密钥的两个身份之间的身份对等性。身份对等性提供了避免断开路径这种优点。例如，工作流800示出了避免路径断开的示例。使用与别名身份a1对应的E-PGP证书的呼叫可能失败。可以使用与别名身份a2对应的E-PGP证书发起后续呼叫。在一实施例中，身份对等性提供了一种出于个人、隐私或商业原因改变身份的机制。本发明实施例提供了基于身份的呼叫历史以及呼叫控制服务(例如，呼叫阻塞)，包括自动重鉴权。

根据本发明实施例生成的证书和那些根据PGP、Browser ID和Convergence等其它技术生成的证书之间存在一些差异。使用PGP时，PGP库(例如，OpenPGP和GnuPGP)最常与邮件客户端一起使用用于出于隐私目的对邮件消息进行签名和加密，而不是与本发明实施例所提供的任意身份系统一起使用。PGP库不定义调用API原语来对用户进行鉴权和认证的系统或网络协议，而本发明实施例在系统和协议层起作用。此外，本发明实施例向标准PGP证书提供额外特征，例如，签名URI和到期时间。BrowserID使用PKI类型的证书，只允许一个身份和一个签名；而本发明实施例可使用E-PGP类型的证书，允许多个身份和多个签名。BrowserID只允许用户向网页服务器鉴权浏览器，而本发明实施例还允许用户向一个浏览器鉴权另一个浏览器。BrowserID具有单个回落IdP服务器，而本发明实施例可具有多个能够按照所需处理E-PGP证书的IdP服务器。BrowserID不提供本发明实施例实现的其它特征，例如，改变身份。与本文所公开的扩展E-PGP证书能力不同，PKI类型的证书一旦创建，BrowserID不允许对其进行改变。BrowserID不支持所公开的IdP服务器之间的交叉认证或身份选择和别名生成。对于Convergence，一组公证服务器用于检查单个网站的证书。然而，Convergence允许网页浏览器对网页服务器进行鉴权，但并不允许网页浏览器之间的端到端相互鉴权。Convergence使用现有的PKI X.509证书，没有改变证书的能力。公证服务器不具有允许进行交叉认证来适当调整E-PGP证书的功能。

图9示出了根据本文所公开的一项或多项实施例的适用于实施浏览器和/或身份提供者服务器的典型通用网络部件900。上文描述的浏览器和身份提供者功能可在任何通用网络部件上实施，例如具有足够的处理能力、内存资源，以及网络吞吐能力以处理所承受的必要工作量的计算机或网络部件。网络部件900包括处理器902(其还可称为中央处理器或CPU)，其可与包括辅助存储器904、只读存储器(read only memory，ROM)906、随机存取存储器(random access memory，RAM)908、输入/输出(input/output，I/O)设备910和网络接口设备912在内的存储器设备通信。处理器902可以实施为一个或多个CPU芯片，或可为一个或多个专用集成电路(application specific integrated circuit，ASIC)的一部分。

辅助存储器904通常包括一个或多个磁盘驱动器或磁带驱动器，并且可用于数据的非易失性存储，而且如果RAM 908的容量不足以存储所有工作数据，辅助存储器则用作溢流数据存储设备。辅助存储器904可用于当程序被选择执行时存储这类加载到RAM 908的程序。ROM 906用于存储指令，可能还有在程序执行期间读取的数据。ROM 906是非易失性存储器设备，通常具有相对于辅助存储器904的大存储容量来说较小的内存容量。RAM 908可用于存储易失性数据，可能还存储指令。访问ROM 906和RAM 908通常都快于访问辅助存储器904。

在示例配置中，浏览器0 104a可在网络部件900中实施，用于创建对用户身份鉴权的证书。在一项实施例中，处理器902接收包括用户的第一用户身份的登录请求。处理器902使用将第一用户身份关联到网页浏览器的公共密钥和秘密密钥生成第一浏览器签名证书。网络接口912将第一浏览器签名证书发送给第一身份提供者服务器。网络接口912接收来自第一身份提供者服务器的第一服务器签名证书。第一服务器签名证书将第一用户身份关联到第一身份提供者服务器。处理器902通过将第一浏览器签名证书和第一服务器签名证书合并来生成最终证书。如果处理器902在第一服务器签名证书中识别用户的第一别名身份，处理器902使用浏览器签名对第一服务器签名证书的第一别名身份进行签名。处理器902还可接收包含与第二身份提供者服务器关联的用户的第二用户身份的登录请求。在接收第二用户身份之后，处理器902调整最终证书以将第二用户身份添加到最终证书中。网络接口912将调整后的最终证书发送给第二身份提供者服务器，随后接收来自第二身份提供者服务器的第二服务器签名证书。处理器902将调整后的最终证书和第二服务器签名证书合并来创建最终合并的证书。如果第二别名身份包含在第二服务器签名证书中，处理器902使用浏览器签名对第二服务器签名证书的的第二别名身份进行签名。

在另一示例配置中，IdP1 108可在网络部件900中实施，用于创建对用户身份鉴权的证书。在一项实施例中，网络接口912接受来自浏览器的第一浏览器签名证书。第一浏览器签名证书将第一用户身份关联到浏览器。处理器902使用将第一用户身份关联到第一身份提供者服务器的公共密钥和秘密秘钥根据第一浏览器签名证书生成第一服务器签名证书。网络接口912将第一服务器签名证书发送给浏览器。处理器902在识别用户的第一别名身份之后，使用身份提供者签名对第一别名身份进行签名以便包含在第一服务器签名证书中。网络接口912可接收来自第二身份提供者服务器的第二服务器签名证书。处理器902可对第二服务器签名证书和第一服务器签名证书进行交叉认证。处理器902可将第二服务器签名证书和第一服务器签名证书合并。如果第二服务器签名证书包括用户的第二别名身份，处理器902使用身份提供者签名对第二别名身份进行签名以便包含在第一服务器签名证书中。

总而言之，本发明实施例提供了身份可扩展性、多重性和对等性。根据本发明的证书允许多个身份和多个签名。鉴权路径可扩展为关联新身份和签名的证书。可根据本发明实施生成别名身份用于用户身份鉴权。可认证某个IdP服务器生成的别名用于另一个IdP服务器。身份架构和协议基于一种新型的PGP证书(E-PGP)和/或信任网(web of trust，WoT)模型。用户可从信任IdP服务器扩展WoT网络，尽管它们之间没有信任链。证书可通过别名生成和IdP服务器间的交叉认证进行扩展。建立协议来向多个身份提供者增量认证多个用户身份和别名，以及在多个身份提供者服务器上对证书进行交叉认证。

在某些实施例中，一个或多个所述设备的部分或全部功能或流程由计算机可读程序代码构成的且内嵌于计算机可读介质中的计算机程序来实现或提供支持。术语“代码”包括任意类型的计算机代码，包括源代码、目标代码以及可执行代码。术语“计算机可读介质”包括任何类型的可以被计算机访问的非易失性介质，比如，只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、硬盘驱动器、光盘(compact disc，CD)、数字化视频光盘(digital video disc，DVD)或者任何其他类型的存储器。

为本专利文档中使用的特定术语和短语进行定义是有帮助的。术语“包括”和“包含”以及它们的派生词表示没有限制的包括。术语“或者”是包容性的，意为和/或。短语“与……关联”和“与其关联”以及其派生的短语意味着包括、被包括在内、与……互连、包含、被包含在内、连接到或与……连接、耦合到或与……耦合、可与……通信、与……配合、交织、并列、接近、被绑定到或与……绑定、具有、具有……属性，等等。

虽然本发明就某些实施例和一般相关方法方面进行了描述，但是对本领域技术人员而言，在不脱离下文权利要求书所定义的本发明范围的情况下，对实施例和方法的各种改变、替代、更改和变更将是显而易见的并且可识别。因此，示例实施例的上述描述不限定或约束本发明，本发明不应被解释为受这些示例实施例的限制，而是根据以下权利要去书进行解释。