看到提示，例如要 求用户输入本地AIK密码的提示，这对答复质询是必须的。权证服务器不会存储该AIK认 证秘密。如果在同一个平台的另一个用户B想要接入服务，则OpenID提供方可以再次质询 权证服务器和/或用户B必须提供用户A的本地AIK密码（这不为用户B所知）。这可以 需要使用一次性cookie，该cookie不会被存储在客户端平台上。
[0088] 发布的cookie可以被加密，由此目标平台和/或用户可以对其进行解密并将其用 作认证令牌。OpenID提供方可以使用公共CSK对cookie进行加密和/或将其发送到客户 端侧的权证服务器。使用TPM，在需要时可以对cookie进行解密。该解密可以需要用户例 如使用（本地）CSK秘密对CSK的使用进行认证。权证服务器可以确保cookie被加密存 储并在需要时被解密。对加密的cookie的存储和/或使用的另一种实施可以是使用命令 TPM-Seal (TPM密封）来存储cookie，由此在进行密封操作时将该cookie绑定到平台的完 整性。在下一次获取之前密封的cookie值时，平台完整性可以被验证为与其在进行密封操 作时的值相同。在该示例中，当平台完整性与其之前的值匹配时，可以获取密封的cookie 值。
[0089] 可信OpenID可以被扩展至可信Google API。组合OpenID与OAuth可以依赖 OpenID认证过程，由此除了例如在OpenID提供方处的传统"登录"之外，不需要进一步的用 户交互。
[0090] 用户的TPM可以通过网络应用请求来标记由OpenID提供方提供的组合的OpenID/ OAuth质询，而不是由TPM来标记OpenID质询。用户标识和授权，以及对数据接入的接 受，可以由TPM安全地标记。如在可信OpenID环境中，用户的安全性可以通过以下来改 进：1)将登录和授权绑定到硬件TPM，和/或2)包括OpenID/OAuth提供方进行的可选平 台完整性验证，以防止在客户端上运行的恶意软件偷取敏感数据。完整性验证可以增加 网络应用的安全性等级。对服务的接入可以被限制在处于已证明的完整性证实状态中的 客户端。这可以允许建立用于安全性和隐私应用的新网络服务。该过程可以提供非抛弃 (non-repudiation)，例如OAuth接入令牌可以由TPM标记，这可以是被唯一标识的。这可 以促进由网络应用的提供方执行的收费过程。签名可以允许网络应用提供方来证明用户请 求并接入了该服务。
[0091] 基于TPM的用户认证可以允许平台身份关联到OpenID身份。可以需要OpenID提 供方保存针对给定平台的已注册身份的数据库。OpenID提供方可以通过给定平台凭证从攻 击者中区分合法用户。当检测到来自另一个平台的登录尝试时，OpenID提供方可以：1)拒 绝认证，和/或2)在合法拥有者下一次登录时通知其该身份。
[0092] TOpenID与OpenID/GBA认证方案的可能整合可以是给NAF/IdP配备TOpenID IdP的能力，以验证平台完整性值。来自NAF/IdP的GBA授权报头可以包括以串行化 (serialize)形式的来自TOpenID协议的质询（例如id，req，现时）。一旦进行接收，ME/ UE然后可以对该执行进行解串行化，并将其复用到可信权证服务器和GBA密钥导出功能， 该功能可以用于计算授权摘要。随后，两者的返回值，例如来自可信权证服务器的标记的引 用和ML以及来自GBA过程的摘要值，可以在HTTP响应消息中返回到NAF/IdP。
[0093] 可以对认证和信任评估进行组合。该组合可以将特定UICC(例如GBA客户端） 的使用绑定到单个平台。如果平台处于完整性证明状态，如果平台可以被认证（例如通过 AIK)，以及如果用户可以被认证（例如通过拥有UICC/GBA)，则NAF可以授权OpenID标识 符。这样的协议可以允许锁定用户，使用户与具有单个UICC的单个配置中的单个平台使用 其OpenID标识符。
[0094] 图5和图6是用于绑定UICC(例如与用户相关联）和WTRU以供OpenID使用的示 例图。图5示出了示例呼叫流图。图6示出了组件之间的示例关系。实施可以确保与不可 信WTRU元件（例如浏览器）的安全通信。参照图5,示例协议步骤可以包括以下中的一个 或多个：1)用户可以建立到RP的连接；2)RP可以发起与0P/NAF的关联；3)RP可以将WTRU 的浏览器重定向到0P/NAF ;4)WTRU与0P/NAF之间的通信可以经由TTS，该TTS可用于认 证（例如，TTS可以一起接收TOpenID质询与GBA质询）；5) TTS可以建立到UICC的安全信 道；6) TTS可以将GBA质询转发到UICC ;7) UICC可以如OpenID/GBA协议中一样计算摘要； 7a)UICC可以将GBA响应发送到TSS (例如具有OpenID/GBA摘要）；8) TTS可以获取用于 TOpenID协议的平台确认数据/证明数据，其中平台确认数据/证明数据可以包括对WTRU 的信赖度的测量（例如用AIK标记的SML和PCR引用）；9) TTS可以以整理的响应对0P/NAF 做出响应，该整理的响应包括UICC GBA响应和平台确认数据/证明数据；10)0P/NAF可以 验证GBA响应并用平台确认数据/证明数据验证完整性（例如验证SML PCR引用与由0P/ NAF之前接收的之前生成的参考值相匹配，这可以指示WTRU的当前系统状态与之前状态相 匹配）；以及11) 0P/NAF可以经由WTRU的浏览器将肯定断定发送到RP (例如，作为ME浏览 器的到RP的重定向操作的一部分）。也就是说，NAF可以发送平台验证，该平台验证指示 NAF已经验证了平台确认数据和/或用户。平台验证可以被直接或间接传送（例如平台验 证可以包括WTRU/用户被授权接入信赖方（RP))。
[0095] TTS不必必须建立与UICC的安全信道。可以执行两个独立会话，UICC与0P/NAF 之间的一个GBA会话和TTS与0P/NAF之间的证明会话。如果两个协议都成功，则0P/NAF 可以发布肯定断定。在该并行的会话情形中，0P必须链接这两个会话（至少在内部），以将 证明结果绑定到GBA协议的认证结果。
[0096] 确认任务可能需要执行网络和设备上的大量资源。被确认的设备可以针对后续的 认证过程或与网络组件的交互重复使用确认信息，例如不必经历新的确认过程。例如，从与 网络的较早的确认会话中生成的确认信息可以被重复使用。可信权证服务器可以如下提供 确认权证（或证书）。在设备向网络成功确认之后，MN0网络内的0P/NAF实体可以发布权 证，其可以被传送到该设备，以用于经要求重新递送到其它网络实体，或其可以被参考，从 而网络实体可以从0P/NAF实体中间接获得该权证。0P/NAF实体可以包括具有权证的信息， 使得权证包括权证/设备信赖度的指示。例如，0P/NAF实体可以提供时间戳、起点时间戳、 权证的寿命期限、权证的结束日期、使用参数限制等。时间信息可以使网络组件能够确定设 备的信赖状态以及何时执行评估。接收权证的实体可以认为该信息符合与设备进行安全事 务（transaction)的要求或可以依据设备中特定应用的信任要求执行重新确认。
[0097] 这样的权证可以用于平台确认和管理。可以对权证进行完整性保护和/或机密保 护，使得该权证被绑定到0P/NAF实体和设备，且使得该权证不可以由数据被绑定到的不同 于设备或0P/NAF的实体所更改。设备中的可信环境（TrE)可以安全存储权证并在与网络 的后续交互中使用该权证，而不需要执行重新确认。设备可以分配权证以向其它网络组件 提供确认状态数据。设备可以传播权证的参考，其它网络实体可以从该参考中咨询0P/NAF 实体以获得确认彳目息。
[0098] 对于组合的TOpenID/GBA情况，可信评估器的位置可以改变，其中该可信评估器 可以是例如从TTS接收测量并能够将该测量与参考度量进行比较以基于该评估得出对平 台确认或信赖度的陈述的实体。
[0099] 图7示出了在TOpenID/GBA情况中作为信任评估器的平台确认实体（PVE)的示 例。图7包括平台确认实体（PVE 705)、BSF 710、UE 720、0P/NAF 730以及RP 740。有可 能重新使用已经拥有信任评估的参考完整性度量的已有的网络实体，而不是在MN0网络内 的0P/NAF实体中整合信任确认过程。这种示例可以称为平台确认实体，例如PVE 705。PVE 705可以被装配有参考度量且能够将接收到的确认数据与参考度量进行比较并发布关于设 备信赖度的陈述。在该情形中，0P/NAF 730可以将内部网络中的确认数据转发到PVE 705， 而该PVE 705可以执行信任确认。
[0100] 可以通过可信第三方（TTP)来执行信任评估。如果MN0内部实体不可用于执行对 接收到的确认数据的确认，则0P/NAF可以将该确认数据通过安全信道转发到外部可信第 三方。TTP然后可以执行验证和确认并将关于平台信赖度的陈述发回0P/NAF。
[0101] 在用户平台的成功认证和验证后，服务提供方（SP)可以发送标记的java applet 到WTRU，其可以在WTRU的可信环境（TrE)中被安装。TrE可以，在在可信环境中安装java applet并答复针对安全UI的SP质询之前，例如经由来自SP的签名和/或证书或由IdP 或可信第三方（TTP)提供的R頂证书来验证applet完整性。TrE可以使用安全UI来载入 applet，向用户指示当前应用可以在安全环境中运行。该方案可以被保护不受假SP的侵 害，例如SP可以被要求认证并向IdP证明完整性。该方案也可以被保护不受假TrE的侵害， 例如通过IdP验证TrE完整性和功能并且如果检查成功则发布权证。
[0102] 可以实施经过隔离/沙箱（sandbox)处理的网络浏览器。与典型的浏览器解决方 案相比，该方案旨在网络应用（例如在线银行、网络邮件、视频流等）的发行方，并为他们的 网络应用定义特定清单（manifest)。该数字标记的清单可以包括允许网络应用连接到的 网站的列表以及应该运行网络应用的浏览器。该浏览器的可视化实体（例如到vm图像的 URL)可以被定义在该清单中，且可以被实施为将网络应用与其它网络应用和/或主操作系 统（0S)隔离。可以通过使用图形边界显示例如信任状态来表现（render)每个经过沙箱处 理的网络应用。该概念可以使用XEN可视化来实现。WTRU可以使用TTS来执行平台证明， 然后使用设备上的TrE(运行小的可信经过沙箱处理的Java applet的环境）来执行应用 证明。注意TTS和TrE可以被建立于WTRU设备中的一些公共可信硬件组件之上，并使用这 些公共可信硬件组件的功能。
[0103] 安全用户界面（安全UI)可以需要TOpenID和OpenID以增加安全性。基础TOpenID 协议可以从可信权证服务器中得到该协议的增加的安全性，该可信权证服务器可以收集设 备完整性信息。OpenID IdP可以评估该设备完整性信息。如果在设备上运行的软件处于公 知和可信状态，则认证可以成功。该认证可以绑定到由TPM存储并由PCA证实的AIK。AIK 可以用于标记用于证明的PCR引用。认证可以被限制为在给定状态中使用给定平台（例如 具有TPM的设备）的实施。
[0104] 证明和完整性检查可以被限制在某些组件，例如TOpenID的安全操作所需的组 件。在该方法中，设备可以被分成可信/安全部分和不可信部分。可信权证服务器可以运 行为可信世界内的可信的且经过完整性检查的应用。对硬件（包括驱动器）的接入可以通 过可信世界中的服务实例来保护。对设备能力的接入可以通过可以向不可信世界提供必要 的API的这种服务实例来限制。这些API可以提供对设备能力的接入，并可以被配备有可 以允许执行接入限制的安全性策略框架。
[0105] 如果IdP进行的完整性检查和验证被限制在设备的某些部分，则用户可能需要与 可信权证服务器确认OpenIDID的使用，以及确认该输入不可以由中间人或设备中的人/ 浏览器攻击中的人截取或重放。可信部分可以提供可信用户界面（UI)，该UI可以保护输入 并向用户指示他可以在安全模式中使用设备。示例的指示器可以是发光二极管（LED)，其可 以在设备（处理器）在可信模式中运行时被点亮。LED可以由可信或安全元件来控制。当 用户将要输入用于OpenID权证的使用的凭证时，安全UI可以指示设备在安全模式中操作。 设备（例如LED)可以处于连接到外部处理器接口的可映射地址空间，其可经由安全硬件接 口被保护，其中接入可以被限制在安全和可信环境。
[0106] 图形设备的受保护帧缓冲器的某些部分可以被使用。其它驱动器可以不被允许从 设备存储器的该部分中写或读。安全/可信驱动器然后可以通过直接写入到显示帧缓冲 器的方式来使用该帧缓冲存储器通过在设备的显示器上显示图形信息来指示安全UI的使 用，从而阻止恶意软件显示"安全图标"。
[0107] 可以用作用于OpenID认