:1)确定AIK证书（的时间戳）（有效性信息也可 以被获取为例如使用计数器的值）；2)验证AIK证书上的PCA签名；3)验证TCTicket 350 中的CSK公钥散列（hash)上的AIK签名；4)验证TCTicket 350中的身份和服务请求上的 签名；5)确认测量列表中的项；和/或6)验证实际（引用）（PCR)值对应于测量列表ML。 在对AIK证书的确认中，验证的是本地客户端自身的受保护的计数器值是否没有达到在 AIK证书中指示的"最大"数目。本地客户端的受保护的计数器值可以指示例如证书和/或 openID客户端软件的安装数目。
[0069] 如果在验证过程中的一项失效，则客户端不被认证。权证服务器305和PCA 315 可以建立特定的凭证链，例如AIK证书-证实的CSK-标记的请求。验证状态消息365可以 被发送给用户。这也可以通过例如图2中的重定向消息262来示出。在该示例中，消息262 可以将用户的浏览器重定向到服务提供方的返回url，或者用户可以在服务提供方处被认 证。如果上述认证失败（证书失效和/或系统完整性失效），则所述重定向可以将用户发送 到OpenID提供方处的认证失败页。在认证失败的情况中，定制结果页可以在OpenID提供 方处被创建。定制结果页可以显示失败原因。这可以包括向用户显示哪些模块或软件没有 通过完整性检查和/或可以被补充（leverage)到向用户建议将他的系统带回到可信赖状 态的下一个步骤的系统。
[0070] 根据这里所公开的，针对与特定服务提供方215使用的每个不完全（partial) 身份，可以调用一次PCA 275。在初始注册中，客户端/用户平台210可以将其平台身份 与匿名的不完全身份相关联。PCA 275可以提供用于该匿名身份的证书和/或存储该匿 名身份与平台身份的关联。该数据可以是高度隐私的，因此必须得到保护。与当前权证 系统相比，PCA 275的定位可以允许附加选项。这里公开的信任模式和方法可以允许将 PCA 275放置在身份提供方220以外的位置以及用户选择的位置。这可能不够隐私友好 (privacy-friendly)，因为用户必须信任身份提供方（IdP)选择的PCA。
[0071] 明文测量文件可以被其它类型的文件替换，该其它类型的文件可以具有关于由本 地客户端设备执行的测量的信息，例如为了机密保护而被加密的测量值（例如使用绑定到 平台的密钥）；和/或概括个体测量文件的值。一个示例可以是多个个体测量文件，其指示 例如一组组件的完整性（而不是单个组件的完整性）。这些组件可以例如属于可以一起体 现本地客户端平台的特定功能和/或特性的群组。
[0072] 依据权证服务器305与权证质询方310之间所使用的认证协议（例如OpenID IdP 协议），可能将该协议缩小至质询响应协议。质询响应协议可以包括1)权证质询方310可 以发送质询（id， req)和/或现时到权证服务器305,和/或2)权证服务器305可以用TCT、 引用Q和/或测量列表ML来做出响应。这样的协议可以允许对在其它协议中通信的权证 质询方310 (例如在0P处）和权证服务器305 (例如在客户端/用户机处）进行更容易的 整合。例如，该整合可以使用HTTP协议来执行，该HTTP协议例如可以使用简单的质询/响 应方案。
[0073] 用户认证可以使用质询响应中的OpenID来进行（图3A和3B中所示）。用户可以 输入用户密码。之前已经向OpenID注册了该用户密码，由此，相同的密码（如果包含在质 询响应中）可以指示该用户是在第一次的情况中注册密码的同一个个体。用户密码可以指 示一些种类的其它事实，例如从预先共享的秘密中导出的数据。
[0074] 在TOpenID中，如这里所述可以实现用户认证和设备信任证明。用户认证可以被 实现，是因为用户可以已经向OpenID提供方注册了用于用户设备的AIK和/或CSK的证书 和/或硬绑定到用户设备的TPM。在质询响应步骤，用户可以发送用这些AIK和/或CSK的 私钥标记的数据。因此，一旦这些密钥的公共部分被验证，和/或一旦验证用户使用已经预 注册的相同的AIK和/或相同的CSK，则OpenID提供方可以知道使用设备发送质询响应的 用户与向该OpenID提供方注册的用户是同一个用户。例如，用户设备在其上可以具有相同 的硬绑定TPM。
[0075] 可以实现设备信任证明。例如，设备信任证明可以被实现，是因为OpenID提供方 可以验证PCR的TPM_Quote、测量日志、和/或权证的一部分（例如用户ID或请求）是否使 用目前验证的AIK CSK来标记。设备信任证明还可以被实现是因为OpenID提供方可以验证 PCR的TPM-Quote、测量日志和/或权证的一部分实际是否产生期望的比较结果。如果两者 匹配，则OpenID提供方可以验证用户用于发送OpenID请求的设备实际上是可信赖的。根据 一个示例，如果对用户和请求的验证被实现，但是PCR值和测量日志的比较失败，则OpenID 提供方在指示设备可能被攻击且处于不同于期望的配置状态中之前，可以知道从预注册的 相同设备中发送的信任相关数据。
[0076] TOpenID可以不违反OpenID规范，和/或TOpenID可以被整合到OpenID中而不 改变OpenID规范。用于OpenID身份的一些认证选项是可能的且可以被实施。协议流可以 被分成标准化流。协议流可以描述信赖方（RP)和IdP的交互，这可以通过间接通信进行。 例如，RP和IdP的交互可以通过将用户的浏览器重定向到不同的网页和/或在消息的HTTP 字段中传输必要数据来进行。
[0077] 图 4 示出了与可信 OpenID 有关的示例方法。在 401，403,405,407,410,411，413， 414,415以及416,可以示出客户端的浏览器、OpenID IdP和/或RP的交互工作。在409， 进行用户认证，但是可以故意不指定用户认证。OpenID可以不指定身份服务器验证用户拥 有其URL所使用的方法。在一些情况中，该验证可以经由cookie来执行。服务器可以向用 户提示用户是否希望验证消费方（consumer)的用户身份。
[0078] 如图4所示，在401，协议流可以包括用户输入其身份URL。消费方可以取得 身份URL。在403。消费方可以处理针对openid.server(openid?服务器）和openid. delegate (openid.代表）链接关系的文档。如果代表（delegate)，贝lj取得被代表的文档并 将其解析（parse)以用于openid. server。在405,消费方可以生成与用户身份服务器共享 的秘密，并对其进行缓存。在407,消费方可以建立用于检查的URL并将用户浏览器重定向 到该URL。在409,可以确定服务器是否可以断定用户拥有URL。在410,如果服务器不能断 定用户拥有URL，贝lj如果消费方请求checkid_immediate (立即检查id)，则服务器返回用于 checkid_setup (设置检查id)模式的URL。在410,如果消费方请求了 checkid_setup，则服 务器可以返回取消。在409,如果服务器可以断定用户拥有URL，则在411，服务器可以将用 户浏览器重定向到在具有标记的参数的消费方请求中指定的return_to(返回至）URL。在 413,可以确定消费方是否为服务器对共享秘密进行了环城。如果消费方对共享秘密进行了 缓存，则在414可以使用该秘密来验证标记的参数。如果在413消费方没有对共享秘密进 行缓存，则在415消费方可以生成具有a SS〇Ciati〇n_handle (关联处理）和服务器返回的 签名的检查-认证请求。在416,服务器可以返回签名是否有效。
[0079] TOpenID可以在认证步骤中包括由IdP进行的平台确认数据和/或完整性检查。 TOpenID中的认证可以被绑定到特定TPM(或例如单个平台），因为可以使用TPM绑定AIK 来注册OpenID标识符。TPM和/或AIK证明过程的安全性特性可以保证标识符在另一个平 台上不被使用。Idp进行的完整性确认可以确保正确的平台（或如果指定可信子系统，则包 括可信权证服务器）在正确配置中运行。
[0080] 上述方法可以应用于图2所示的TOpenID协议流。OpenID身份提供方（IdP)和/ 或用户系统可以包括使用TPM及其完整性确认协议执行认证步骤的能力。这些能力可以实 施为客户端和/或服务器上的软件模块和/或库。例如，这些能力可以在客户端/用户平 台210处和/或OpenID提供方220 (例如TT验证方258、质询消息252、质询答复消息259、 TPM 270、PCA 275和/或存储介质280)处被实施。OpenID的开放式的概念可以产生很多种 不同的OpenID IdP实施。因此，OpenID IdP可以开发在它们中间进行区分的概念。OpenID IDP可以使用以对其进行区分的一个功能可以例如是对增强的安全性特征的断定。该断定 可以向用户保证它们的（OpenID)身份被保护（例如如果其为HW绑定的话）。可以向用户 保证该IdP可以使RP信赖从IdP接收到的信息。例如，使存储库（bank)或其它要求安全 性的应用使用具有知晓安全性且被证实的OpenID IdP的白名单（whitelist)的OpenID。
[0081] 用于实施TOpenID的一种方法可以使用第二种基于非HTTP的协议来执行平台确 认。例如，使用第二种协议，质询消息可以从OpenID提供方220被发送到客户端/用户平 台210,且响应可以被发回OpenID提供方220。这可以经由后台过程来执行，该后台过程可 以将控制返回到OpenID提供方220的主认证过程。主认证过程可以开始于从客户端/用 户平台210重定向到OpenID提供方220 (如图2所示）。然后可以从OpenID提供方220到 客户端/用户平台210执行HTTP重定向（如图2所示）。
[0082] 依据服务器和/或用户设备的能力，不同的协议可以用于传输数据。
[0083] 产生用于服务接入的凭证或权证的实体可以被整合在客户端中。这可以通过客户 端中的可信功能实体（例如图2所示的权证服务器250)来执行而不需要降低TKerberos的 安全性。权证服务器可以向OpenID提供方确认客户端及其自身。由于安全性信息和操作 可能集中在权证服务器组件中，因此可以信任该组件合适地处理AIK证书和/或CSK。可以 信任权证服务器来：不将AIK证书和/或CSK复制到其它平台，保护权证和凭证，保护用户 授权的安全性操作凭证，提供将被集成到公共网络浏览器并由其访问的安全选项，收集、处 理并发送平台确认数据，和/或基于用于标识重放攻击的现时的有效性来提供接入控制。
[0084] 如这里所述，特定凭证链可以由权证服务器和PCA来建立。TOpenID中的凭证链可 以是AIK证书 -证实的CSK-标记的请求。
[0085] 在TKerberos系统中放置PCA的实施可以包括以下内容。在OpenID提供方中包 括PCA可以降低复杂度。这可以是经由网络形式的对向OpenID提供方进行注册的无缝替 换。在TOpenID中，用户可以1)选择任意外部PCA，其AIK证书可以被TOpenID提供方接 受，和/或2)使用由TOpenID提供方直接或间接提供的PCA功能。
[0086] 由于其安全性架构，TOpenID可以减小对基于OpenID的系统的特定的威胁。在 TKerberos中，AIK证书在客户端可能是不可见的而是在TGT中被加密，且可以由TGS解密。 客户端可以知道AIK证书且AIK证书不具有例如可能威胁隐私的隐藏信息。OpenID实施可 以向用户展现OpenID提供方登录形式。用户可以输入其凭证且OpenID提供方可以向客户 端发送cookie。该cookie然后可以用于每个后续的启用OpenID的服务接入。这可能导致 对OpenID协议的攻击的可能性，例如：1)对用于登录到它们的OpenID提供方的用户凭证 的直接攻击（使用假OpenID提供方页进行钓鱼（phishing)可以暴露大量的用户凭证，允 许身份偷窃），或2)涉及在认证后对客户端计算机的cookie进行重复使用、复制和/或偷 窃的攻击，其可以导致身份失窃。通过使用可信OpenID可以减少攻击。由于用户密码可以 是本地的和/或被提供给本地可信权证服务器，因此可以阻止凭证钓鱼。匿名身份可以被 绑定到平台。也就是说，这些匿名身份不可以被复制到另一个设备。
[0087] 在客户端平台上可能没有存储cookie。这可以阻止本地重复使用的威胁，例如在 计算机由多人共享时。在一个示例中，如果用户A登入到其OpenID账户，并忘记退出，则用 户B可以尝试使用存储的cookie来假扮用户A。通过将可信OpenID认证无缝整合到网络 浏览器中可以防止该重复使用。当用户想要使用可信OpenID接入服务时，OpenID提供方可 以针对权证服务器创建新的质询。用户可以从其可信权证服务器应用中