CN102783115B - 用于可信联合标识的方法和装置 - Google Patents

用于可信联合标识的方法和装置 Download PDF

Info

Publication number
CN102783115B
CN102783115B CN201180009229.6A CN201180009229A CN102783115B CN 102783115 B CN102783115 B CN 102783115B CN 201180009229 A CN201180009229 A CN 201180009229A CN 102783115 B CN102783115 B CN 102783115B
Authority
CN
China
Prior art keywords
user
openid
signature
secret
mno
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
CN201180009229.6A
Other languages
English (en)
Other versions
CN102783115A (zh
Inventor
I·查
A·施米特
A·莱切尔
Y·C·沙阿
L·J·古乔内
D·F·豪利
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
InterDigital Patent Holdings Inc
Original Assignee
InterDigital Patent Holdings Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by InterDigital Patent Holdings Inc filed Critical InterDigital Patent Holdings Inc
Publication of CN102783115A publication Critical patent/CN102783115A/zh
Application granted granted Critical
Publication of CN102783115B publication Critical patent/CN102783115B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G06F21/35—User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2115—Third party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

诸如智能卡、UICC、Java卡、全球平台等之类的可信计算环境可以被用作本地主机信任中心和单点登录（SSO）供应方的代理。这可以被称为本地SSO供应方（OP）。举例来说，通过执行该处理，可以将认证业务保持在本地，并且避免可能对运营商网络造成负担的空中通信。为了在可信环境中建立OP代理，可信环境可以采用多种方式来绑定到SSO供应方。例如，SSO供应方可以与基于UICC的UE认证或GBA交互操作。在这种方式下，用户设备可以平衡可信环境，以便提供提升的安全性，并且降低OP或运营商网络上的空中通信及认证负担。

Description

用于可信联合标识的方法和装置
交叉引用
本申请要求享有2010年5月28日提交的名为“IdentityManagementonaCommunicationsDevice（通信设备上的标识管理）”的申请号为61/396,602的美国临时专利申请、以及2010年2月9日提交的名为“MethodandApparatusforImplementingLocalandMobileOpenIDProvider（用于实施本地和移动OpenID供应方的方法和装置）”的申请号为61/302,890的美国临时专利申请的优先权，其中这些申请的内容在这里全部引入作为参考。
背景技术
因特网用户通常具有多个可以用于用户认证的用户名和密码，以便接入多个网站。例如，因特网用户可以具有用于接入诸如Facebook之类的社交网站的用户名/密码组合，以及另一个用于接入诸如Gmail之类的电子邮件站点的用户名/密码组合。虽然具有多个用户名/密码组合有可能是用户认证所必需的，但是因特网用户可能会发现，要想记忆每一个用户名/密码组合是很麻烦的。例如，因特网用户有可能遗忘其在某个网站的用户名/密码组合，并且将无法接入该网站。
为使因特网用户的用户认证不再那么麻烦，目前已经提出了诸如开放ID（OpenID）之类的单点登录（SSO）解决方案。但是，在将SSO作为网络（web）服务实施的时候存在着一些缺陷。例如，用户有可能不具有至基于网络的SSO供应方的安全信道。此外，用户对SSO供应方的控制有可能是很有限的。
此外，SSO中的认证有可能产生通过空中接口的通信，这样则有可能因为增加的业务而对网络实体（即OpenID供应方（OP或NAF）以及网络本身产生负荷。另外，移动网络运营商（MNO）可能不得不承担这个附加业务和处理的成本。
发明内容
在本申请中，我们描述了允许在可信环境中实现本地和分布式单点登录（SSO）供应方的实施方式，其中举例来说，所述可信环境可以是智能卡、无线智能电话、H(e)NB或其他类型的设备。单点登录供应方可以是OpenID供应方、基于自由联盟或坎塔拉倡议（KantaraInitiative）的标识供应方、使用安全断言标记语言（SAML）的标识供应方、开放认证（OAUTH）供应方等等。本申请提供了很多不同方案及其实施选项。虽然描述的概念有可能是在OpenID协议的上下文中的，但是这些思想可以扩展到其他的单点登录（SSO）协议和/或联合标识协议。
在一个示例实施方式中，用户环境可以用于启用开放管理安全协议，以使可依赖方（RP）能对用户进行认证。该用户环境可以包括：
用户接口，该用户接口使用单点登录安全协议来与RP进行通信，以便代表用户来请求接入RP提供的服务，其中RP可以处于用户环境之外，并且可以与单点登录证书的可信供应方进行通信，以便发起用户认证；以及
处理器，例如可信的计算环境，其在用户环境内部为可信供应方认证用户，该处理器被配置成在本地执行单点登录证书供应方的至少一些功能，以便在认证过程期间限制用户环境以外的通信。
在另一个示例实施方式中，方法可以用于保护用户环境和/或本地断言（assertion）实体（LAE），以便在OpenID之类的开放管理安全协议中为可依赖方（RP）认证用户。该方法可以包括：
经由用户接口接收来自RP的重定向（redirect），其中该RP希望对用户进行认证，该RP能够与诸如OpenID供应方（OP）之类的单点登录（SSO）证书的可信供应方进行通信；
通过用户接口接收来自用户的用户证书；
使用接收到的用户证书来为RP认证用户，以便在本地执行诸如OP之类的SSO证书的可信供应方的至少一些功能，从而在认证过程期间限制用户环境以外的通信；以及
经由用户接口来将认证响应传送到RP。
本发明内容是为了以简化形式引入众多概念而被提供的，并且在以下的详细描述中将会进一步描述这些概念。本发明内容的目的并不是标识所要求保护的主题的关键特征或基本特征，也不试图用于限制所要求保护的主题的范围。此外，所要求保护的主题并不受限于解决了在本公开文本的任何部分中指出的任意或所有缺陷的实施方式。
附图说明
更详细的理解可以从以下结合附图并借助示例给出的描述中得到，其中：
图1A示出的是可以实施所公开的一个或多个实施方式的示例通信系统。
图1B示出的是可以实施所公开的一个或多个实施方式的示例无线发射/接收单元。
图1C示出的是可以实施所公开的一个或多个实施方式的示例系统无线电接入网络。
图2示出的是在标识供应方与服务供应方之间交换认证和数据的SAML协议流程。
图3示出的是允许用户使用单个OP登录到不同可依赖方站点的OpenID协议流程。
图4示出的是为SSO协议提供可信计算环境上的集成OP的协议流程的示例实施方式。
图5示出的是为SSO协议提供可信计算环境上的集成OP的协议流程的示例实施方式。
图6示出的是用于基于关联的通信的OpenID协议流程。
图7示出的是用于无状态签名核验（verify）的OpenID协议流程。
图8示出的是将BONDI与基于关联的OpenID相集成的示例实施方式。
图9示出的是将BONDI与无状态签名核验相集成的示例实施方式。
图10示出的是启用拆分（split）OP的示例实施方式。
图11示出的是启用拆分OP的另一个示例实施方式。
图12示出的是在GBA架构中使用的BSF功能。
图13示出的是GBA架构概述。
图14示出的是来自3GPPTS33.220的GBA参考模块。
图15示出的是来自3GPPTS33.220的访问网络NAF的参考模块。
图16示出的是用于自由（Liberty）/GBA的架构方案。
图17示出的是供用于MMO支持的标识断言的GBA使用的示例实施方式。
图18示出的是启用拆分OP的另一个示例实施方式。
图19示出的是启用拆分终端/本地OpenId的示例实施方式。
图20示出的是标准的OpenID协议。
图21示出的是来自3GPPTR33.924v9.1.0的OpenID/GBA的业务流程。
图22示出的是用于减小空中业务的协议流程的示例实施方式。
图23示出的是用于SCWS上的OP的内部路由的示例实施方式。
图24示出的是允许RP使用无状态模式来执行OpenID认证的协议流程的示例实施方式。
图25示出的是允许RP使用基于关联的模式来执行OpenID用户认证的协议流程的示例实施方式。
图26示出的是用于改进的无状态模式的协议流程的示例实施方式。
图27示出的是用于改进的基于关联的模式的协议流程的示例实施方式。
图28示出的是来自NIST-FIPSPUB198-1的键入式散列（hash）消息认证码（HMAC）。
图29示出的是OpenID/GBA的业务流程。
图30示出的是用于基于关联的通信模式的协议流程的另一个示例实施方式。
图31示出的是用于基于关联的通信模式的协议流程的另一个示例实施方式。
图32示出的是用于基于关联的通信模式的协议流程的另一个示例实施方式。
图33示出的是用于无状态模式的协议流程的另一个示例实施方式。
图34示出的是用于拆分终端的协议流程的示例实施方式。
图35示出的是OpenID中的信任关系。
图36示出的是与本地OP的信任关系的示例实施方式。
图37示出的是与MNO的信任关系的示例实施方式。
图38示出的是具有发布方SD的SD分层的示例实施方式。
图39示出的是具有DM的SD分层的示例实施方式。
图41示出的是作为GP应用的SCWS的示例实施方式。
图42示出的是在卡的运行时间环境中实施的SCWS的示例实施方式。
具体实施方式
在本申请中，我们描述了在可信计算环境（例如用户设备（UE）、智能卡、智能电话、H(e)NB或其他类型的设备）中实施的本地和分布式单点登录（SSO）供应方的思想和概念。所述单点登录供应方可以是OpenID供应方、自由联盟供应方、开放认证（OAUTH）供应方等等。本申请提供了很多不同的方案及其实施选项。虽然描述的这些概念有可能是在OpenID协议的上下文中的，但是这些思想可以扩展到其他的单点登录（SSO）协议和/或联合标识协议。
诸如本地移动OpenID之类的本地移动SSO协议是允许位于本地的模块或实体来执行作为诸如OpenID协议之类的SSO或标识管理协议的一部分的标识认证/断言功能的概念。位于本地的模块可以是智能卡、SIM、通用集成电路卡（UICC）、Java卡、启用智能卡网络服务器（SCWS）的智能卡、诸如智能电话之类的无线设备等等。
本地移动SSO是用于统指那些可以借以将部分或是所有那些通常由基于网络的SSO服务器执行的单点登录（singlesign-on，SSO）及相关标识管理功能改由基于本地的实体和/或模块执行的方法的术语，其中所述实体和/或模块是通信设备本身的一部分或是全部，或者此类实体/模块在物理和/或逻辑上位于（也就是位于本地）通信设备和/或其用户附近。例如，实体/模块可以嵌入到设备中；附着到设备；或者通过本地接口、线路或短距离无线装置连接到设备。
本地OpenID也可以用作术语来指示本地移动SSO方法的子集，由此，所述SSO或标识管理方法是以OpenID协议为基础的。例如，本地OpenID可以用于指示那些可以由位于本地的实体/模块执行的OpenID标识供应方（简写成OP或OpenIDIdP）的功能。
本地IdP是用于指示执行OpenID服务器的功能的实体或模块的术语。首字母组合词OPloc可以用于表示本地IdP。本地IdP的一个主要功能可以是通过关于用户和/或设备标识的断言来促成用户和/或设备的认证。这种断言可以从本地IdP发送到在设备上运行的浏览器代理（BA），然后，浏览器代理可以将该断言转发给外部的可依赖方（RP）。当将本地IdP提供的功能主要限制成提供这种标识断言，那么可以将本地IdP称为本地断言实体（LAE）。
本地IdP可以处理、创建、管理或者发送断言消息至一个或多个外部接收方。这些断言消息可以断言与用户和/或设备相关的一个或多个标识的核验状态。例如在OpenID协议中，称为可依赖方（RP）的第三方实体可以是断言消息的接收方之一。本地IdP还可以使用签名、加密密钥、密码等等来对断言消息进行签名。
本地OpenID方法可以使用一个或多个密码密钥，例如根会话密钥。根会话密钥可以用Krp来表示，并且可以是在RP与OP之间要使用的会话密钥。Krp还可以充当RP与能够得到其他密钥的OP之间的根会话密钥。本地OpenID方法还可以使用断言密钥，该断言密钥可以用Kasc表示。Kasc可以是用于对一个或多个断言消息进行签名以进行用户认证的签名密钥。Kasc可以从Krp中得出。
本地OpenId方法还可以使用称为OpenID服务器功能（OPSF）的服务，其作用可以是生成、共享以及分发那些可以供本地IdP和/或可依赖方（RP）使用的秘密（secret）。外部RP可以将OPSF和本地IdP视为单个实体。OPSF还能够核验本地OpenID发布的签名，并且可由RP例如经由公共因特网直接到达。通过修改设备上的本地DNS解析缓存以使OPSF的地址映射到本地IdP，可以将设备上的浏览器重定向到本地IdP。
本地OpenID方法还可以使用一种用OP-agg表示的服务，其作用可以是便于代表RP来发现本地IdP。
1通信系统
图1A是可以实施所公开的一个或多个实施方式的示例通信系统100的图示。通信系统100可以是为多个无线用户提供语音、数据、视频、消息传递、广播等内容的多接入系统。该通信系统100能使多个无线用户通过共享包括固定的有线或无线通信带宽在内的系统资源来访问这些内容。举例来说，通信系统100可以使用一种或多种固定的有线或无线信道接入方法，例如码分多址（CDMA）、时分多址（TDMA）、频分多址（FDMA）、正交FDMA（OFDMA）、单载波FDMA（SC-FDMA）等等。
如图1A所示，通信系统100可以包括无线发射/接收单元（WTRU）102a、102b、102c、102d，无线电接入网络（RAN）104，核心网络106，公共交换电话网络（PSTN）108，因特网110以及其他网络112，但是应该了解，所公开的实施方式设想了任意数量的WTRU、基站、网络和/或网络元件。WTRU102a、102b、102c、102d中的每一个可以是被配置成在无线或固定的有线环境中工作和/或通信的任何类型的设备。例如，WTRU102a、102b、102c、102d可以被配置成传送和/或接收无线信号，并且可以包括用户设备（UE）、移动站、固定或移动用户单元、寻呼机、蜂窝电话、个人数字助理（PDA）、智能电话、膝上型计算机、上网本、个人计算机、无线传感器、消费类电子设备等等。
通信系统100还可以包括基站114a和基站114b。基站114a、114b中的每一个可以是被配置成与WTRU102a、102b、102c、102d中的至少一个无线对接来促成针对一个或多个通信网络的接入的任何类型的设备，其中举例来说，该网络可以是核心网络106、因特网110和/或网络112。举个例子，基站114a、114b可以是基地收发信台（BTS）、节点B、e节点B、家庭节点B、家庭e节点B、站点控制器、接入点（AP）、无线路由器等等。虽然每一个基站114a、114b都被描述成单个部件，但是应该了解，基站114a、114b可以包括任何数量的互连基站和/或网络元件。
基站114a可以是RAN104的一部分，其中该RAN还可以包括其他基站和/或网络元件（未显示），例如基站控制器（BSC）、无线电网络控制器（RNC）、中继节点等等。基站114a和/或基站114b可以被配置成在称为小区（未显示）的特定地理区域内部传送和/或接收无线信号。所述小区可以进一步分成小区扇区。例如，与基站114a相关联的小区可以分成三个扇区。因此，在一个实施方式中，基站114a可以包括三个收发信机，即每一个收发信机对应于小区的一个扇区。在另一个实施方式中，基站114a可以使用多输入多输出（MIMO）技术，由此可以为小区中的每个扇区使用多个收发信机。
基站114a、114b可以通过空中接口116来与一个或多个WTRU102a、102b、102c、102d进行通信，该空中接口可以是任何适当的无线通信链路（例如射频（RF）、微波、红外（IR）、紫外（UV）、可见光等等）。空中接口116可以使用任何适当的无线电接入技术（RAT）来建立。
更具体地说，如上所述，通信系统100可以是多接入系统，并且可以使用一种或多种固定的有线或无线信道接入方案，例如CDMA、TDMA、FDMA、OFDMA、SC-FDMA等等。举例来说，RAN104中的基站114a与WTRU102a、102b、102c可以实施诸如通用移动电信系统（UMTS）陆地无线电接入（UTRA）之类的无线电技术，该无线电技术可以使用宽带CDMA（WCDMA）来建立空中接口116。WCDMA可以包括诸如高速分组接入（HSPA）和/或演进型HSPA（HSPA+）之类的通信协议。HSPA可以包括高速下行链路分组接入（HSDPA）和/或高速上行链路分组接入（HSUPA）。
在另一个实施方式中，基站114a和WTRU102a、102b、102c可以实施诸如演进型UMTS陆地无线电接入（E-UTRA）之类的无线电技术，该无线电技术可以使用长期演进（LTE）和/或高级LTE（LTE-A）来建立空中接口116。
在其他实施方式中，基站114a与WTRU102a、102b、102c可以实施诸如IEEE802.16（全球微波互通接入（WiMAX））、CDMA2000、CDMA20001X、CDMA2000EV-DO、临时标准2000（IS-2000）、临时标准95（IS-95）、临时标准856（IS-856）、全球移动通信系统（GSM）、用于GSM演进的增强型数据速率（EDGE）、GSMEDGE（GERAN）等之类的无线电接入技术。
图1A中的基站114b可以例如是无线路由器、家庭节点B、家庭e节点B或接入点，并且可以使用任何适当的RAT来促成诸如营业场所、住宅、交通工具、校园等之类的局部区域中的无线连接。在一个实施方式中，基站114b和WTRU102c、102d可以通过实施诸如IEEE802.11之类的无线电技术来建立无线局域网（WLAN）。在另一个实施方式中，基站114b和WTRU102c、102d可以实施诸如IEEE802.15之类的无线电技术来建立无线个域网（WPAN）。在另一个实施方式中，基站114b和WTRU102c、102d可以使用基于蜂窝的RAT（例如WCDMA、CDMA2000、GSM、LTE、LTE-A等等）来建立微微小区或毫微微小区。如图1A所示，基站114b可以具有到因特网110的直接连接。因此，基站114b可以不需要经由核心网络106来接入因特网110。
RAN104可以与核心网络106进行通信，所述核心网络106可以是被配置成向WTRU102a、102b、102c、102d中的一个或多个提供语音、数据、应用和/或网际协议上的语音（VoIP）服务的任何类型的网络。例如，核心网络106可以提供呼叫控制、记账服务、基于移动位置的服务、预付费呼叫、因特网连接、视频分发等等，和/或执行如用户认证之类的高级安全功能。虽然图1A中没有显示，但是应该了解，RAN104和/或核心网络106可以直接或间接地和其他那些使用与RAN104相同的RAT或不同的RAT的RAN进行通信。例如，除了连接到可以使用E-UTRA无线电技术的RAN104之外，核心网络106还可以与使用GSM无线电技术的另一个RAN（未显示）通信。
核心网络106还可以充当供WTRU102a、102b、102c、102d接入PSTN108、因特网110和/或其他网络112的网关。PSTN108可以包括提供简易老式电话服务（POTS）的电路交换电话网络。因特网110可以包括使用公共通信协议的全球性互联计算机网络设备系统，该公共协议例如是TCP/IP网际协议族中的传输控制协议（TCP）、用户数据报协议（UDP）以及网际协议（IP）。网络112可以包括由其他服务供应方拥有和/或运营的有线或无线通信网络。例如，网络112可以包括与一个或多个RAN相连的另一个核心网络，其中所述一个或多个RAN可以使用与RAN104相同的RAT，也可以使用不同的RAT。
通信系统100中的一些或所有WTRU102a、102b、102c、102d可以包括多模能力，换言之，WTRU102a、102b、102c、102d可以包括用于通过不同的无线链路与不同无线网络通信的多个收发信机。例如，图1A所示的WTRU102c可以被配置成与使用基于蜂窝的无线电技术的基站114a通信，并且可以与使用IEEE802无线电技术的基站114b通信。
图1B是示例WTRU102的系统图示。如图1B所示，WTRU102可以包括处理器118、收发信机120、发射/接收元件122、扬声器/麦克风124、键盘126、显示器/触摸板128、不可移除存储器106、可移除存储器132、电源134、全球定位系统（GPS）芯片组136以及其他外围设备138。应该了解的是，在保持符合实施方式的同时，WTRU102可以包括前述元件的任何子组合。
处理器118可以是通用处理器、专用处理器、常规处理器、数字信号处理器（DSP）、多个微处理器、与DSP核心相关联的一个或多个微处理器、控制器、微控制器、专用集成电路（ASIC）、现场可编程门阵列（FPGA）电路、其他任何类型的集成电路（IC）、状态机等等。处理器118可以执行信号编码、数据处理、功率控制、输入/输出处理和/或其他任何能使WTRU102在无线环境中工作的功能。处理器118可以耦合至收发信机120，收发信机120可以耦合至发射/接收元件122。虽然图1B将处理器118和收发信机120描述成是独立组件，但是应该了解，处理器118和收发信机120可以一起集成在电子封装或芯片中。
发射/接收元件122可以被配置成通过空中接口116来传送或接收去往或来自基站（例如基站114a）的信号。举个例子，在一个实施方式中，发射/接收元件122可以是被配置成传送和/或接收RF信号的天线。在另一个实施方式中，举例来说，发射/接收元件122可以是被配置成传送和/或接收IR、UV或可见光信号的发射器/检测器。在又一个实施方式中，发射/接收元件122可以被配置成传送和接收RF和光信号两者。应该了解的是，发射/接收元件122可以被配置成传送和/或接收无线信号的任何组合。
此外，虽然在图1B中将发射/接收元件122描述成是单个元件，但是WTRU102可以包括任何数量的发射/接收元件122。更具体地说，WTRU102可以使用MIMO技术。因此，在一个实施方式中，WTRU102可以包括两个或多个通过空中接口116来传送和接收无线信号的发射/接收元件122（例如多个天线）。
收发信机120可以被配置成对发射/接收元件122将要传送的信号进行调制，以及对发射/接收元件122接收的信号进行解调。如上所述，WTRU102可以具有多模能力。因此，收发信机120可以包括允许WTRU102经由诸如UTRA和IEEE802.11之类的多个RAT来进行通信的多个收发信机。
WTRU102的处理器118可以被耦合至扬声器/麦克风124、键盘126和/或显示器/触摸板128（例如液晶显示器（LCD）显示单元或有机发光二极管（OLED）显示单元），并且从上述设备接收用户输入数据。处理器118还可以向扬声器/麦克风124、键盘126和/或显示器/触摸板128输出用户数据。此外，处理器118可以从诸如不可移除存储器106和/或可移除存储器132之类的任何适当类型的存储器中访问信息，以及将数据存入这些存储器。所述不可移除存储器106可以包括随机存取存储器（RAM）、只读存储器（ROM）、硬盘或是其他任何类型的记忆存储设备。可移除存储器132可以包括用户标识模块（SIM）卡、记忆棒、安全数字（SD）记忆卡等等。在其他实施方式中，处理器118可以从那些并非物理位于WTRU102的存储器访问信息，以及将数据存入这些存储器，其中举例来说，所述存储器可以位于服务器或家庭计算机上（未显示）。
处理器118可以执行应用层程序（例如，浏览器）、无线电接入层（RAN）程序、和/或通信程序。处理器118可以执行如认证之类的安全操作；安全密钥协定（agreement）操作；和/或密码操作等。这些操作可以在接入层、应用层等处被执行。
处理器118可以接收来自电源134的电力，并且可以被配置分发和/或控制用于WTRU102中的其他组件的电力。电源134可以是为WTRU102供电的任何适当的设备。例如，电源134可以包括一个或多个干电池组（如镍镉（NiCd）、镍锌（NiZn）、镍氢（NiMH）、锂离子（Li-ion）等等）、太阳能电池、燃料电池等等。
处理器118还可以耦合到GPS芯片组136，该GPS芯片组136可以被配置成提供与WTRU102的当前位置相关的位置信息（例如经度和纬度）。作为来自GPS芯片组136的信息的补充或替换，WTRU102可以通过空中接口116接收来自基站（例如基站114a、114b）的位置信息，和/或根据从两个或多个附近基站接收的信号定时来确定其位置。应该了解的是，在保持符合实施方式的同时，WTRU102可以借助任何适当的位置确定方法来获取位置信息。
处理器118还可以耦合到其他外围设备138，这些外围设备可以包括提供附加特征、功能和/或有线或无线连接的一个或多个软件和/或硬件模块。例如，外围设备138可以包括加速度计、电子指南针、卫星收发信机、数码相机（用于照片和视频）、通用串行总线（USB）端口、振动设备、电视收发信机、免提耳机、蓝牙模块、调频（FM）无线电单元、数字音乐播放器、媒体播放器、视频游戏机模块、因特网浏览器等等。
图1C是根据一个实施方式的RAN104和核心网络106的系统图示。如上所述，RAN104可以使用E-UTRA无线电技术以通过空中接口116来与WTRU102a、102b、102c进行通信。RAN104还可以与核心网络106通信。
RAN104可以包括e节点B140a、140b、140c，但是应该了解，在保持与实施方式相符合的同时，RAN104可以包括任何数量的e节点B。每一个e节点B140a、140b、140c都可以包括一个或多个收发信机，以便通过空中接口116来与WTRU102a、102b、102c通信。在一个实施方式中，e节点B140a、140b、140c可以实施MIMO技术。因此举例来说，e节点B140a可以使用多个天线来向WTRU102a传送无线信号，以及接收来自WTRU102a的无线信号。
每一个e节点B140a、140b、140c都可以与特定小区（未显示）相关联，并且可以被配置成处理无线电资源管理决策、切换决策、上行链路和/或下行链路中的用户调度等等。如图1C所示，e节点B140a、140b、140c可以通过X2接口来彼此通信。
图1C所示的核心网络106可以包括移动性管理网关（MME）142、服务网关144以及分组数据网络（PDN）网关146。虽然每一个前述元件都被描述成是核心网络106的一部分，但是应该了解，这些元件中的任一元件都可以由核心网络运营商之外的实体拥有和/或运营。
MME142可以经由S1接口来与RAN104中的e节点B142a、142b、142c中的每一个相连，并且可以充当控制节点。例如，MME142可以负责认证WTRU102a、102b、102c的用户，承载激活/去激活，在WTRU102a、102b、102c的初始附着期间选择特定的服务网关等等。MME142还可以提供控制平面功能，以便在RAN104与使用诸如GSM或WCDMA之类的其他无线电技术的其他RAN（未显示）之间进行切换。
服务网关144可以经由S1接口而与RAN104中的e节点B140a、140b、140c中的每一个相连。该服务网关144通常可以路由和转发去往/来自WTRU102a、102b、102c的用户数据分组。该服务网关144还可以执行其他功能，例如在e节点B间的切换期间锚定用户平面，在下行链路数据可供WTRU102a、102b、102c使用时触发寻呼，管理和存储WTRU102a、102b、102c的上下文等等。
服务网关144还可以连接到PDN网关146，该PDN网关146可以为WTRU102a、102b、102c提供针对诸如因特网110之类的分组交换网络的接入，以便促成WTRU102a、102b、102c与IP使能设备之间的通信。
核心网络106可以促成与其他网络的通信。例如，核心网络106可以为WTRU102a、102b、102c提供针对诸如PSTN108之类的电路交换网络的接入，以便促成WTRU102a、102b、102c与传统的陆线通信设备之间的通信。举例来说，核心网络106可以包括IP网关（例如IP多媒体子系统（IMS）服务器）或与该IP网关通信，其中该IP网关充当核心网络106与PSTN108之间的接口。此外，核心网络106可以为WTRU102a、102b、102c提供针对网络112的接入，该网络112可以包括由其他服务供应方拥有和/或运营的其他有线或无线网络。
2.3标识管理和可用安全性
当用户开始在移动设备上访问信息时，他们面临着为一个网络服务到另一个网络服务处理过多用户证书的困境。用户面对的是记忆这些证书以及在每次访问网络服务时输入登录和密码信息的烦琐任务。虽然设备有可能记忆这些证书，但是设备有可能会被丢失或被盗窃，并且有可能最终落在不该拥有的人的手里。
所提供的可以是一种将本地用户认证与透明的网络认证组合在一起以安全地管理用户证书和接入网络服务的牢固的认证解决方案。例如，多种密码或令牌项和/或生物计量（biometric）认证技术可以与问候式的（complimentary）无缝网络认证方案结合使用，其中所述方案是与网络服务门户合作的。这些方案可以被称为单点登录（SSO）或联合标识。
可以包括UE的移动平台可以支持多种专有处理器架构和操作系统。这样为软件/固件开发人员创造了一个零散的市场，并且迫使运营商与OEM协商来引入并支持诸如接入控制和认证之类的公共技术。以下部分讨论的是在移动平台上提供SSO协议的实施方式。
在一个示例实施方式中，用户环境可以用于启用开放管理安全协议，以使可依赖方（RP）能够认证用户。该开放管理安全协议可以是单点登录协议（SSO），例如OpenID协议、自由联盟协议、开放认证（OAUTH）协议、安全断言标记语言、标识保证框架等等。可依赖方可以是希望认证或核验用户证书的一方。
用户环境可以包括用户接口和/或处理器，例如可信计算环境。
用户接口可以在UE与用户之间提供接口。例如，该用户接口可以是网络浏览器、网页、应用等等。用户接口还可以接收用户证书。该用户证书可以是用户名、密码、PIN码、密钥、令牌、生物计量标识等等的组合。
用户接口可以提供接口和/或使用诸如OpenID之类的SSO协议来与RP进行通信，以便代表用户来请求访问RP提供的服务。例如，用户可以使用诸如网络浏览器之类的用户接口代理来访问RP，并且可以使用OpenID来选择进行登录。该用户接口还可以从RP接收表明该RP希望对用户进行认证的指示。例如，用户接口可以接收来自RP的重定向消息，其中该重定向消息指示用户接口使用可信计算环境来对用户进行认证。
用户接口还可以与SSO证书的可信供应方进行通信以发起用户认证。例如，RP可以将用户接口重定向到可与可信供应方相关联的可信计算环境。该可信供应方可以是用户证书供应方。例如，可信供应方有可能知道用户，并且能够通过用户提供的证书来认证用户。
处理器可以是通用处理器，专用处理器，常规处理器，数字信号处理器（DSP），多个微处理器，与DSP核相关联的一个或多个微处理器，控制器，微控制器，专用集成电路（ASIC），现场可编程门阵列（FPGA）电路，任何其他类型的集成电路（IC），状态机等等。此外，处理器
在一个示例实施方式中，处理器可以是可信的计算环境，例如UMTS集成电路卡（UICC），用户标识模块（SIM），机器对机器（M2M）设备，智能卡，Java卡，全球平台智能卡，安全集成芯片卡（ICC）等等。该可信计算环境可以使用智能卡网络服务器（SCWS）来实施。
该可信计算环境可以在用户环境内部为可信供应方认证用户。为了认证用户，可信计算环境可以在本地执行单点登录证书的可信供应方的至少一些功能，以便在认证过程期间限制用户环境以外的通信。例如，用户可以通过PIN码、生物计量标识、令牌等等或是其（即PIN码和生物计量标识）组合而在可信计算环境本地进行认证。可信计算环境可以生成认证响应。该可信计算环境可以使用重定向消息来将用户接口代理重定向到RP，其中该重定向消息可以包括用户被认证的断言。然后，用户接口可以被重定向到RP，并且在RP核验了来自可信计算环境的断言之后，用户可以登录。
在一个示例实施方式中，可信计算环境可以计算一个签名，例如base64（基本64位）编码的HMAC签名，并且可以将该签名经由用户接口提供给RP。举例来说，通过执行该处理，可以允许RP核验可信计算环境的证书。可信环境可以基于该可信计算环境与可能与MNO或OP关联的可信供应方之间的共享秘密来计算签名。该共享秘密可以是通过用户接口而在可信计算环境与可信供应方之间建立的。该签名可以用于对从RP接收的参数列表进行签名。
可依赖方（RP）可以是服务、网站、数据库、应用等等。在一个示例实施方式中，RP可以处于用户环境以外。例如，RP可以是在用户环境以外的服务器上托管的网站，其中该用户环境可以例如是用户用于访问网站的蜂窝电话或其他UE。RP有可能必须建立一个连接，例如使用移动网络运营商（MNO）提供的针对网络服务实体的公共因特网通信来建立连接。举例来说，该处理可以在可依赖方（RP）无法直接与可信计算环境通信的时候进行。MNO可以具有到可信计算环境的远程管理接口，以及诸如SMS之类的附加通信信道，这样可以允许MNO与UE和/或可信计算环境进行通信。MNO可以充当RP与可信计算环境上的OP之间的协商桥梁。
在另一个示例实施方式中，RP可以处于用户环境内。例如，RP可以位于可包括用户接口和可信计算环境的UE的内部。
在一个示例实施方式中，RP可以被配置成传送认证请求，以便允许RP核验可信计算环境的证书。用户接口可以接收来自RP的认证请求。该认证请求可以包括关联句柄。用户接口可以将这个关联句柄提供给可信计算环境。该可信计算环境可以基于共享秘密来生成签名，并且可以生成包括签名和关联句柄的认证响应。用户接口或可信计算环境可以将可信环境生成的认证响应提供给RP。
在一个示例实施方式中，用户环境可以处于用户设备（UE）内部。例如，用户接口和可信计算环境可以被包括在单个UE内部。在另一个示例实施方式中，用户环境可以以拆分终端配置来部署，其中用户接口和可信计算环境可以驻留在分离的UE中。例如，用户接口可以是在属于用户的蜂窝电话上，而可信计算环境则可以存在于属于用户的银行卡或UICC上。另举一例，用户接口可以是在属于用户的个人计算机上的，而可信计算环境则有可能在属于用户的蜂窝电话上。
在一个示例实施方式中，用于保护用户环境和/或本地断言实体（LAE）的方法可以被提供，以在开放管理安全协议中为可依赖方（RP）认证用户。在一个示例实施方式中，LAE可以处于处理器内部，例如处于可信计算环境以内。来自RP的指示可以经由用户接口而被接收，其中该指示表明RP希望对用户进行认证。RP可以处于用户环境以外，并且能够与单点登录（SSO）证书的可信供应方进行通信。用户证书可以是通过用户接口而从用户那里接收的。所述用户可以用接收到的用户证书来认证。例如，如可信计算环境之类的处理器可以使用接收到的用户证书来为RP认证用户，以便在本地执行SSO证书的可信供应方的至少一些功能，从而在认证处理期间限制用户环境以外的通信。认证可以通过使用智能卡网络服务器（SCWS）来进行。
认证响应可以经由用户接口传送到RP。例如，该认证响应可以在用户已被认证的时候传送。
从RP接收的指示可以是重定向消息。该重定向消息可以指示用户接口使用可信计算环境来认证用户。例如，重定向消息可以指示浏览器在本地认证用户，而不是由可信供应方来进行认证。
如base64编码的HMAC签名之类的签名可被计算并经由用户接口提供给RP。例如，通过执行该处理，可以允许RP核验可信计算环境的证书。可信计算环境可以基于该可信计算环境与诸如OpenID供应方之类的可与MNO相关联的可信供应方之间的共享秘密来计算证书。该共享秘密可以是通过用户接口而在可信计算环境与可信供应方之间建立的。
在一个示例实施方式中，认证请求可以是从RP接收的，这样可以允许RP核验可信计算环境的证书。例如，用户接口可以接收来自RP的认证请求。该认证请求可以包括关联句柄。用户接口可以将关联句柄提供给可信计算环境。可以生成基于共享秘密的签名。此外还可以生成包括所述签名和关联句柄的认证响应。然后，该认证响应可被提供给RP。
2.3.2使用OpenID和SCWS的单点登录的实施方式
OpenID可以为运营商提供一个轻松的角色，以便以最小的努力和风险向可依赖方（RP）提供OpenID供应方（OP）中的信任。OpenID可以与先前已有的认证方法协作，由此运营商可以使用自己的AAA和在UICC中预先提供的AKA证书或其他认证方法来支持针对OP的认证过程，所述其他认证方法包括但不局限于PKI、预共享密钥、SIP摘要证书、TLS等等。
OpenID与智能卡的组合提供了一条通向令人关注的价值主张的途径。智能卡网络服务器（SCWS）提供了新的基于IP的服务，该新的基于IP的服务可以为用户提供更丰富且非常安全的网络体验。网络服务器的基本功能是使用HTTP协议来递送网页。这一点对驻留在智能卡或UICC上的SCWS来说也是一样的。SCWS可以是将UICC作为网络节点集成在移动电话供应方的IP网络中的第一步。
在一个示例实施方式中，UICC可被用作运营商的本地信任中心和代理。例如，通过执行该处理，可以将认证业务保持在本地，并且避免加重运营商网络的负担。OP能够通过缩放认证强度来启用多种用于将OpenID证书绑定到UICC和/或设备和/或用户标识和/或用户的方法。例如，OpenID可以与基于UICC的UE认证AKA证书、或GBA或其他形式的认证机制进行交互操作，其中所述其他形式的认证机制如基于证书的认证机制。在这里公开的实施方式中，UE可以为设备上的OP代理平衡运营商的信任和声誉，以便通过标准的OpenID协议来提供更高的安全性。
2.3.3智能卡上的OP
在以下的第4节中描述的若干实施方式描述了将OP集成在智能卡上。例如，其中一个实施方式描述了驻留有智能卡网络服务器（SCWS）的智能卡上的OpenID。另一个示例实施方式描述了对SCWS上的OpenID的改进。
从这里描述的实施方式中得到的益处可以包括：
·使用OpenID时的用户移动性
·改进了对证书的用户控制（增强的安全保护），这是因为这个重要信息现在是在卡上而不是在云中
·减小了对于使用GBA的需要，由此显著减小了网络资源的负担
·认证业务被限制在网络实体之间的公共因特网上，而不需要空中传送——对于SCWS上的OpenID的改进协议来说，这一点是很明显的
3标准化前景
有很多正式和事实上的（产业）标准化组织从事的是标识管理（IdM）；但是，这其中的大多数组织将重点放在了IdM在台式机环境中的使用。这里公开的实施方式是通过本地和/或分布式SSO供应方来提供IdM的，这些供应方可以在如智能卡之类的可信环境中实施，或者可以在可包括可信计算环境的平台上实施，例如智能电话、H(e)NB或其他类型的设备。单点登录供应方可以由标准化组织提供，例如自由联盟供应方、SAML供应方、KantaraInitiative供应方、OpenID供应方等等。
3.2自由联盟
自由联盟是作为由如BT、AOL、Oracle、Intel、NTT、CA、FidelityInvestment、NTT以及SunMicrosystems之类的公司领导的产业论坛发起的。该联盟已经发布了从事ID联合（ID-FF）和标识网络服务（ID-WSF）的LibertyAllianceFrameworks（自由联合框架）系列规范。
自由标识联合（ID-FF）规范1.0是这样一个规范，它允许基于因特网的服务和电子商务应用的消费者及用户从任意设备认证并登录一次网络或域，然后访问来自多个网站的服务，由此回避了用户重新认证和控制隐私问题的需要。自由联盟还发布了两个版本的标识联合规范，并将其联合规范提供给了OASIS（http://www.oasis.org），由此形成了安全断言标记语言（SAML）2.0的基础。此外，自由联盟还发布了自由标识网络服务框架（ID-WSF），该框架解决的是基于标识的网络服务。这个规范是用于在安全和尊重隐私的联合社交网络中部署并管理多种基于标识的网络服务的开放框架，例如，这些网络服务可以是地理定位、联络簿、日历、移动消息传递等等。
这里公开的实施方式公开的是可以用于在UE上下文中为自由联盟标准的安全和其他方面提供支持的创新。例如，一个实施方式公开了一种移动设备，该移动设备具有作为可拆除模块或作为集成模块的安全环境，例如UICC、智能卡或集成可信环境（TrE），其中所述安全环境可以单独或共同托管所公开的一些功能，例如UE上的可信权证服务器或TTverifier（TT核验器）的功能。与只支持已有自由联盟客户端协议的常规UE当前可用的功能相比，所公开的这些功能可以单独或共同添加更多的安全性和信任证据。
3.3OASIS和SAML
结构化信息标准促进组织（OASIS）是一个用于开发、融合并采用电子商务及网络服务标准的全球性开放协会。在IdM上下文中，OASIS开发了安全断言标记语言（SAML），其当前版本是2.0。
SAML是基于XML的标准，用于在安全域之间、也就是在标识供应方（关于标识的断言的产生者）与服务供应方（所述断言的使用者）之间交换认证和授权数据。SAML尝试解决网络浏览器的单点登录（WebSSO）问题，以便将基于内部网的传统SSO解决方案扩展到网络的开放环境中。SAML尝试使用基于XML（和XHTML）的开放的标准化协议来克服不可互操作的专用技术的增殖效应。SAML与诸如OpenID之类的其他IdM技术的不同之处在于其依靠用户代理来提供请求和断言。
图2示出的是用于在标识供应方与服务供应方之间交换认证和数据的SAML协议。
这里公开的实施方式公开的是可以用于在UE的上下文中为SAML的安全性和其他方面提供支持的创新。例如，其中一个实施方式公开了一种移动设备，该设备具有作为可拆除模块或作为集成模块的安全环境，例如UICC、智能卡或集成可信环境（TrE），其中所述安全环境可以单独或共同托管所公开的一些功能，例如UE上的可信权证服务器或TTverifier的功能。与只支持已有SAML客户端协议的常规UE当前可用的功能相比，所公开的这些功能可以单独或共同添加更多的安全性和信任证据。
3.4KantaraInitiative
KantaraInitiative是自由联盟的后继组织，并且由自由联盟的一些初始支持者领导，该自由联盟例如BT、NTT、T-Mobile、AOL和FidelityInvestment。Kantara并不是一个标准定义组织（SDO），这是因为Kantara发布的都是建议，并且其重点放在两个主要的技术主题上：标识保证和互操作性。
Kantara首先规定的是扩展了自由联盟做出的IAPv1.0规范工作的标识保证框架（IAP）v2.0。IAP规范初始详述了很多标识保证等级，这有助于以公共的标准化规则以及与每一个标识保证等级相关联的安全风险评定为基础来将启用可信标识的企业、社交网络以及Web2.0应用联系在一起。同样，该框架启用了针对标识要求和评估的灵活且粒度的（granular）信任保证。所规定的保证等级以NISTSpecialPublication（特定公开）800-63第1.0.1版概述的四个保证等级为基础，并且其置信等级范围是从低到很高。
这里公开的实施方式公开的是可以用于在UE上下文中为IAP的安全性和其他方面提供支持的创新。例如，其中一个实施方式公开了一种移动设备，该设备具有作为可拆除模块或集成模块的安全环境，例如UICC、智能卡或集成可信环境（TrE），其中所述安全环境可以单独或共同托管所公开的一些功能，例如UE上的可信权证服务器或TTverifier的功能。与只支持已有KantaraIAP客户端协议的常规UE当前可用的功能相比，所公开的这些功能可以单独或共同添加更多的安全性和信任证据。
3.5OpenID
OpenID是用于认证用户的开放标准，该标准可被用于访问控制，以便在不同服务信任了认证组织的情况下允许用户使用相同的数字标识登录这些服务。OpenID取代了常规的用户登录过程，由此允许用户登录一次并获得对多个软件系统的资源的接入。术语OpenID也可以是指在标准中使用的ID。
OpenID是由OpenID基金会开发和维护的，该基金会是一个美国的非营利组织。该OpenID基金会（OIDF）是由致力于启用、促进和保护OpenID技术的个人和公司组成的。
作为OpenID协议所用的ID的术语，OpenID采用了唯一URL的形式，并且由用户的OpenID供应方（即托管其OpenIDURL的实体）进行认证。OpenID协议不依靠中心机构来认证用户标识，也不依赖特定的认证方法本身。由于OpenID协议和需要标识的网站都不能强制执行（mandate）特定类型的认证，因此可以使用多种认证处理，例如使用智能卡、生物计量或常规密码。
这里公开的实施方式公开的是可以用于在UE上下文中为OpenID的安全性和其他方面提供支持的创新。例如，其中一个实施方式公开了一种移动设备，该设备具有作为可拆除模块或作为集成模块的安全环境，例如UICC、智能卡或集成可信环境（TrE）。这里使用的OpenID是作为示例性协议的，其中诸如可信权证服务器（TTS）、TTverifier和TCTicket（TC权证）之类的新公开的功能可以由UE中的所述安全环境托管，并且可以单独或者共同使得UE更加安全可靠，此外，在UE依照OpenID协议执行用户标识客户端功能时，通过使用所公开的这些方法，还会使得这种增强的安全性和可信赖性是能在外部核验的。
3.63GPPSA3及其关于OpenID的工作
3GPPSA3是一个3GPP安全标准化工作组，在3GPPSA3中，在2G、3G和下一代（beyond）的移动电话、终端和系统的广泛的安全性方面采用了一种综合处理方法。当前，在IdM空间中，存在一个关于OpenID与通用自举（Bootstrapping）架构（GBA）的集成的技术报告（TR33.924）。此外还有另一个关于自由联盟与GBA互通的技术报告（TR33.980)。
这里公开的实施方式公开的是可以用于在UE上下文中为OpenID的安全性和其他方面和/或OpenID与GBA或其他认证机制的集成提供支持的创新。例如，其中一个实施方式公开了一种移动设备，该移动设备具有作为可拆除模块或作为集成模块的安全环境，例如UICC、智能卡或集成可信环境（TrE），其中所述安全环境可以单独或共同托管所公开的一些功能，例如UE上的可信权证服务器或TTverifier的功能。与只支持3GPP规定的已有协议而在3G网络上实现OpenID或自由联盟互通的常规UE当前可用的功能相比，所公开的这些功能可以单独或共同添加更多的安全性和信任证据。
4技术概述
本节提供的是能够提供标识管理（IdM）解决方案的实施方式的技术概述。例如，这些实施方式可被用于将OpenID供应方（OP）服务器功能置于移动本地平台中，尤其是智能卡中。
在第4.1节，我们提供的是对OpenID的介绍。
第4.2节论述的是提供智能卡上的OpenID以及架构、实施选项、变体、和3GPPGBA的集成（通用自举架构）的实施方式。
第4.3节论述的是设想了OpenID供应方（OP）实施平台选项的实施方式。此外，第4.3节还论述了实施兼容JavaCardTM的智能卡的实施方式，以及在智能卡网络服务器（SCWS）上实施OP的实施方式。
第4.4节论述的是处理本地用户认证的实施方式。本地用户认证是一个涉及OpenID和其他SSO技术的主题。此外，第4.4节还论述了使用生物计量学的实施方式。
第4.5节论述的是提供了可以在OpenID上下文中发展的“信任”和“信任关系”方法的实施方式。例如，在这里描述的是若干个公开了MNO的作用的实施方式，此外还详细探讨了所述MNO与OpenID协议中的其他实体/行动者可能具有的信任关系。在一个示例实施方式中，MNO一个并且与主标识供应方（IdP）是完全相同的，并且智能卡上的OP是MNO的代理（充当IDP）。在第二示例实施方式中，MNO并不拥有或管理智能卡上的OP，并且该MNO不是IdP，相反，第三方IdP拥有并管理智能卡上的OP。
第4.6节论述的是允许在智能卡之外的平台上实施OP的实施方式。例如，实施方式公开的是JavaCardTM和嵌入式安全元件上的实施可行性。此外，实施方式描述的是如何集成平台信任概念（如可信计算中一样）与移动OP的概念，以便为移动OP提供更高的信任和安全等级。
4.1关于OpenID的介绍
OpenID允许用户使用单个OP登录到不同的可依赖方站点。OP是用户标识的中心存储位置，并且充当了用户的单个认证点。由于用户是针对其OP被认证的，因此，该OP可以向可依赖方（RP）发布断言，所述可依赖方则转而允许用户访问服务。为了方便起见，OP还被允许存储那些可以与用户简档相比的个人信息。然后，在登录过程之后，该信息可以在OP与RP之间交换，以便为RP提供关于用户的更详细信息。
图3示出的是用于允许用户使用单个OP登录到不同的可依赖方站点的OpenID协议流程。如图3所示，用户尝试执行OpenID登录，而这将会导致RP启动发现OpenIDURI的处理。在RP与OP之间可以创建一个建立了共享秘密的可选安全关联。当发现过程完成时，RP会将用户重定向到尝试进行用户认证的OP。OP为用户提供登录网页，在该登录网页中，一旦输入了恰当的证书，则用户被认证。一旦认证成功，则将用户重定向回到RP，并且在那里向用户显示针对网络服务的登录。
4.2智能卡上的OpenID
在OpenID协议中，OP可以是用户证书及其他用户个人信息的储存库。从而，由于通过窃取用于向OP进行认证的用户证书可以允许攻击者以用户的名义来访问所有启用OpenID的站点，因此，在OpenID协议中，OP变成了大多数攻击的目标。在更温和的攻击方案中，举例来说，攻击者会在用户向其OP进行了认证之后使用登录用户的浏览器会话，例如代表用户来执行隐蔽的操作，在此类攻击方案中，攻击者并未得到用户证书，因此不能使用这些证书来登录任意站点。但是，OpenID协议的设计允许攻击者登录到用户在先前的浏览器会话中登录的所有RP站点。攻击者不必访问用户的机器，例如通过恶意软件或MITM，这种攻击可以由任何站点（该站点不必是RP站点）通过将XSRF攻击使用网站中的隐蔽框架来执行。如果攻击者能够注入恶意软件或是充当MITM，那么整个登录过程都有可能会被捕获，然后在需要时在单独的浏览器会话中重放。此外，如果用户决定（在OP处）允许后续登录而无需再次向OP提供其证书（举例来说，如果OP在用户浏览器中存储了永久性cookie）并且站点使用了OpenID协议的“请求立即认证”选项，那么用户有可能未经通知即被攻击者获得登录。因此，对于OpenID实施来说，OP安全性是一个主要的问题。
OpenID本身允许用户在其拥有的诸如博客之类的网站上安装自己的OP。但是，用户不太可能拥有主机。因此，用户相信其主机供应方运作正确且以恰当方式保护其私有数据。虽然具有用户专用设计的定制OP可以阻碍网络钓鱼攻击，但是，由于攻击不再以简单自动的方式执行，因此，所有那些使用了OP实施以及用户浏览器到OP的接口的弱点的攻击（MITM，恶意软件等等）仍旧是可能存在的。
在一个示例实施方式中，诸如OP之类的SSO供应方的功能可被带给用户控制和/或拥有的UE。例如，通过执行该处理，可以提供集中环境来管理用户标识，同时提供OpenID协议供应的无缝和简易认证的好处。如果用户能在其控制的安全设备上具有自己的OP，那么某些攻击将更难以常规方式进行。这种为用户存储和执行OP的设备可以是用户在其移动设备中携带的可信计算环境，例如智能卡。大多数智能卡（例如UICC、Java卡等）都能执行增强的功能，并且能与用户交互。
通过在属于用户的智能卡上运行OP，可以允许用户对其私有数据保持更多的控制。对于一些方案来说，例如当RP针对其服务收取费用时，如果将基于智能卡的OP的可信性信息从MNO传送到RP，那么将会是很有用的。这其中可以包括允许RP经由MNO来向用户收费的反向信道。用户可以使用本地信道来向OP进行认证，例如经由PIN码。OP可以由MNO远程安装，以及用于OP的必要证书可以经由GBA协议带给智能卡。
图4示出的是为SSO协议提供可信计算环境上的集成OP的协议流程的示例实施方式。例如，该协议流程可以被使用以为OpenID提供处于智能卡上的集成OP。
如图4所示，在201处，用户可以使用诸如网络浏览器之类的用户接口代理来访问RP，并且可以选择使用OpenID进行登录。在202处，RP可以将用户接口代理重定向到可能被包括在例如智能卡、UICC、Java卡等之类的可信计算环境内部的本地OP。在203处，用户可以在本地通过PIN码、生物计量标识等等来向可信计算环境上的OP进行认证。在204处，可信计算环境内部的OP可以产生认证响应。在205处，OP可以将用户接口代理重定向到RP，并且可以包括用户已认证的断言。在206处，用户接口代理可被重定向到RP，并在RP核验了来自OP的断言之后，用户可以被登入。
RP有可能必须使用诸如公共因特网通信来建立到MNO提供的网络服务实体的连接（如果OP是由MNO提供的）。例如，该处理有可能在RP无法直接与可信计算环境上的OP通信的时候进行。MNO可以具有到可信计算环境的远程管理接口以及附加通信信道，例如SMS，这样允许MNO与设备和/或可信计算环境进行通信。该MNO可以充当RP与可信计算环境上的OP之间的协商桥梁。
图5示出的是用于为OpenID提供处于智能卡上的集成OP的协议流程的示例实施方式。
如图5所示，在207处，用户可以访问RP，并且选择使用OpenID进行登录。在208处，该服务可以将用户（用户浏览器）重定向到其本地OP。例如，用户可以在本地使用PIN码并经由智能卡接口和/或生物计量标识来向OP进行认证。在210处，OP可以产生认证响应。在211处，OP可以将浏览器重定向到RP，并且可以包括用户已被认证的断言。在212处，浏览器可以被重定向到RP，并在RP核验了来自OP的断言之后，用户可以被登入。
RP有可能必须使用诸如公共因特网通信来建立到MNO提供的网络服务实体的连接（如果OP是由MNO提供的）。例如，该处理可以在RP无法直接与智能卡上的OP进行通信的时候进行。MNO可以具有到智能卡的远程管理接口以及附加通信信道，例如SMS，这样允许MNO与设备和/或智能卡进行通信。该MNO可以充当RP与智能卡上的OP之间的的协商桥梁。
4.2.1架构和偏好
4.2.1.1RPOP通信需求
在一个示例实施方式中，为使RP从在诸如智能卡之类的可信计算环境上运行的OP获得断言，RP必须与OP进行通信。该RP可以将用户标识符传送到OP，然后，OP可以在认证之后向RP告知认证结果。
OpenID协议在协议期间使用了两种不同类型的通信。间接通信是经由HTTP重定向或HTML表单提交执行的。就该通信经过用户浏览器的意义上讲，该通信是间接的。间接通信被用于认证请求（从RP经由浏览器到达OP）和认证响应（从OP经由浏览器到达RP）。直接通信是在RP与OP之间直接执行的，并且其被用于与OP直接建立关联并核验断言。
由于在RP与OP之间建立关联（由此建立共享秘密）的处理并不是强制性的，因此有两个用于OpenID认证的协议流程。
这里描述的实施方式可以使用任何一个用于OpenID认证的协议流程来实施。
4.2.1.1.1基于关联的通信的背景
图6示出的是用于基于关联的通信的OpenID协议流程。
如图6所示，在OpenID协议中，OP与RP之间的关联不依赖于OP与RP之间预先共享的秘密。它是在用户向RP提供其OpenID标识符并且希望使用OpenID登录RP之后由RP执行的初始步骤。在215处，RP连接到OP（经由HTTPS），并且执行迪菲-赫尔曼（Diffie-Hellmann）密钥交换来与OP建立（短期的逐个认证会话）共享秘密k。然后，在230处，RP稍后使用该共享秘密来核验最初源自OP但却是由RP经由间接通信（浏览器重定向）而从用户浏览器那里接收的断言消息的签名。
在220处，如果在RP与OP之间建立了关联（并且由此建立了共享秘密k），则在认证请求和响应中传递该关联句柄（经由间接通信）。在225处，来自OP的认证响应包含了关联句柄以及使用共享秘密k的断言的签名。然后，RP可以使用k来自动地核验该签名。关联句柄的使用允许OP和RP两者追踪多个同时进行的会话。
4.2.1.1.2无状态签名核验的背景
图7示出的是用于无状态签名核验的OpenID协议流程。
如图7所示，如果在RP与OP之间没有建立关联，那么在240处，RP必须在去往OP的直接消息中核验在235处接收的认证响应中的签名。在245处，如果该断言有效并且确实是由OP发布的，那么OP必须向RP发布包含了被设置成“是”的“isvalid”字段的声明（statement）。
虽然认证请求和响应是借助HTTP重定向并通过用户浏览器传递的，并且由此在任何方案中都不需要在RP与OP之间具有任何直接通信信道，但是必定有一种方法供RP核验接收到的断言上的签名。如果初始协议必须保持符合标准，那么RP至少必须能在接收到用于签名核验的断言之后与OP联系一次。然后将不再需要建立关联。
4.2.1.2用于认证的本地设备上的OP的发现的实施方式
当使用OpenID协议时，RP未必需要在执行间接通信的时候发现OP。
在一个示例实施方式中，用于访问RP的浏览器将会得到指向智能卡上的本地OP的重定向。由于使用的是浏览器与RP之间的信道，因此，该RP甚至可以不需要知道OP的地址。但是，该重定向有可能需要将浏览器指向一个地址。该地址可以作为设备本地的IP地址（类似于指示本地主机的127.0.0.1）来给出，并且浏览器将会辨认出这个地址，然后参与本地认证。
在另一个实施方式中，可以使用由浏览器出于重定向到本地OP以及继续进行用户认证的目的而转换的专门标识符。例如，此类标识符可以采用sc://openid/identifier（标识符）的形式，而这将会告知浏览器参与到与智能卡上的OP进行的关于标识符的认证会话中。该认证请求可以采用正确的通信格式来变换，以便用于诸如智能卡之类的可信计算环境。然后，依照UICC能力，在用户与UICC之间可以经由恰当的接口来进行认证。例如，认证可以使用PIN码、生物计量核验等等来进行。该认证可以指示用户已经以其它方式赞同认证。例如，如果攻击者或非授权用户在不了解用户的情况下使用智能卡来进行认证，那么通过执行该处理，可以防止在这种情况下可能发生的攻击。
通过将认证与用户交互耦合，用户可以知道正在进行的事务处理。依照智能卡的能力，显示实际事务处理细节是好的，也就是哪一个站点充当RP、RP上的返回URL、以及将要使用哪一个标识。如果智能卡上的OP支持多个OpenID标识，那么OP甚至可以向用户呈现与该RP结合使用的可选标识。在进行了针对OP的本地认证之后（例如使用PIN码），浏览器被重定向到RP，由此包括来自OP的肯定断言。
在一个示例实施方式中，断言可以由RP核验，并由此需要在RP与OP之间进行直接通信，其中该直接通信经由关联或经由先前章节中描述的直接签名核验进行。用于断言核验的方法是实施特定的，并在下面的第4.2.2.1节中对其进行了进一步描述。
4.2.1.3用于MNO断言的标识的实施方式
在一个示例实施方式中，诸如智能卡之类的可信计算环境上的本地OP被用于本地用户认证。该MNO可以是在接收到来自智能卡上的本地OP的触发消息之后向RP提供必要断言的实体，由此声明用户已被成功认证。在第4.2.2.1.2节的拆分OP方案中更进一步地描述了该实施方式。
4.2.2实施选项和实施方式变体
本节意图论述的是可以与这里公开的更一般概念结合的实施方式的实施选项和变体。
4.2.2.1用于断言核验的RP-OP通信的实施方式
4.2.2.1.1用于集成BONDI的实施方式
在一个示例实施方式中，RP与OP之间的直接通信信道至少可以用于核验断言签名。例如，该直接信道可以通过在OP与RP之间的用户浏览器而以隧道方式传送业务来提供。该概念有可能需要浏览器在当前会话内部执行附加的重定向。
在另一个实施方式中，浏览器可以充当RP的单个接触点，以便实施可以用于在RP与OP之间建立通信信道的第二处理。由于在RP与OP之间指定的通信协议是HTTP或HTTPS，因此，该浏览器能够传送所有业务。
为了便于浏览器与诸如智能卡之类的可信计算环境进行通信，可以使用OMTPBONDIAPI。BONDIAPI可以允许浏览器使用JavaScript来与智能卡进行通信，进而与OP进行通信。通过使用BONDI，甚至可以减少重定向。所述RP在其发送给浏览器的网页中包括恰当的JavaScript调用。JavaScript调用援引（invoke）BONDIAPI，并且可以允许访问该智能卡。然后，调用结果可以用相同的JavaScript包装到至RP的响应消息中（例如在HTTP传递（POST）消息中）。依照RP使用BONDI调用的时间，RP可以在所述RP使用认证请求重定向页面中的智能卡调用的时候建立关联，或者它可以使用在RP接收到OP断言之后显示的页面，由此允许RP能够在没有关联的情况下执行直接核验。
图8示出的是将BONDI与基于关联的OpenID进行集成的示例实施方式。如图8所示，在245处，在OP与RP之间通过使用BONDI建立关联。BONDI可以允许浏览器与诸如智能卡之类的可信计算环境和/或可以处于该可信计算环境内部的OP进行通信。在250处，在OP处接收来自RP的认证请求。在255处，将认证响应反向传递到RP。
图9示出的是将BONDI与无状态（没有关联的）的签名核验进行集成的示例实施方式。如图9所示，在260处，OP和RP经由BONDI和浏览器来进行通信。在265处，RP向OP传送认证请求。在270处，OP向RP传送认证响应。
4.2.2.1.2拆分OP的实施方式
在一个示例实施方式中，RP可以通过使用拆分OP来核验接收到的断言。在拆分OP中，在MNO与本地OP之间可以划分OP的功能。虽然本地OP可以负责用户认证，但是MNO可以通过与RP进行通信来核验源自智能卡OP的签名。该处理可以结合在RP与MNO之间建立的关联进行，或者可以经由无状态的签名核验进行。
图10示出的是启用拆分OP的示例实施方式。如图10所示，在275处，在RP与MNO之间可以建立关联。RP可以与MNO建立共享秘密，然后，OP可以在断言消息的签名过程中使用该共享秘密。如果RP与不同用户具有多个同时的连接，那么该断言消息还可能包括关联句柄，以使RP识别正确的共享秘密。该共享秘密可以允许RP核验断言签名，而不必与OP进行通信。该关联可以在执行从RP首次重定向UE浏览器之前进行。
在280处，OP可以向RP传送认证请求。在285处，RP可以向OP传送认证响应。在290处，OP可以与MNO建立关联句柄和签名密钥。该关联句柄和签名密钥可以使用GBA来建立。
如果在RP与MNO之间没有建立关联，那么RP仍旧有可能需要能够通过与MNO处的实体取得联系来核验接收到的签名。该实体有可能需要发布关于签名有效性的声明。在一个示例实施方式中，一个选项是检查OP是否确实属于MNO发布的OP。这种检查有可能需要OP在至RP的认证断言消息中包括唯一标识符，然后，RP会将该消息转发给MNO。OP地址（IMEI/IMSI）甚至也可用作该标识符。如果OP是作为有效OP注册到MNO的，那么MNO会向RP返回具有被设置成“是”的“isvalid”字段的消息，以使RP接受该断言消息（断言核验）。拆分OP方案可以允许MNO以一种将所有认证负担卸载到智能卡上的本地OP的方式来保持其对OpenID过程的控制，同时MNO仍旧可以通过使用被设置成“否”的“is_valid”来回复，从而选择撤销标识。签名核验可以作为协议中的最后一个步骤而在用户登录到RP之前执行。
图11示出的是启用拆分OP的无状态（无关联）实施方式的示例。在295处，在MNO与RP之间可以进行断言核验。在300处，RP可以向OP传送认证请求。在305处，OP可以向RP传送认证响应。在310处，在OP与MNO之间可以建立关联句柄和签名密钥。该关联句柄和签名密钥可以使用GBA来建立。
在另一个示例实施方式中，为使MNO与智能卡上的OP进行通信，还研究了是否可以使用将加密SMS用作承载的标准OTA管理过程。被包括在SMS中的命令可以由SIM卡解密，并且可以依照3GPPTS11.11定义的方式运行。
在另一个示例实施方式中，承载独立协议（BIP）可以与卡应用工具箱传输协议（CAT_TP）结合使用。BIP允许开放从手持机到OTA服务器以及到（U）SIM卡的数据信道，由此产生端到端的数据信道。一个SMS的大小是140字节，与之相比，用于BIP的数据分组包含了1472个字节。BIP可以使用UE的GPRS连接来实施更快的连接。BIP是在3GPPTS31.111中被标准化的，而CATTP则是在ETSITS102124中被标准化的。
4.2.2.2将3GPPGBA用于智能卡上的OP的实施方式
在一个示例实施方式中，GBA可被用于引入在本申请中描述的基于UICC/H(e)NB的OP。例如，GBA协议可以由许多MNO使用和建立。
4.2.2.2.1关于GBA的介绍
3GPPGBA协议规范（3GPPTS33.220）是一种能在归属位置寄存器（HLR）或归属用户服务器（HSS）上使用用户的有效标识来启用用户认证的技术。GBA架构是通过让网络组件质询UE中的SIM卡、以及核验回答与HLR/HSS预测的回答的相似性来进行的。GBA代表的是一种共享密钥认证方法。
自举服务器功能（BSF）是MNO网络实体，其充当的是两个端点之间的中介，并且能使这两个端点建立共享秘密（其寿命可能是有限的）。
以下图示是作为参考而被包括进来的，并且给出的是GBA架构及其元件的概括。
图12示出的是在GBA架构中使用的BSF功能。
图13示出的是GBA架构概括。
图14示出的是来自3GPPTS33.220的GBA参考模块。
图15示出的是来自3GPPTS33.220的访问网络NAF的GBA参考模块。
4.2.2.2.2GBA与SSO集成的现有技术
GBA能够被使用以运用3GPP认证和密钥协定过程而在SSO上下文中产生专用于应用的证书。该使用的一个示例是在描述了GBA与自由联盟SSO协议之间的互通方案的3GPPTR33.980中给出的。描述了GBA与OpenID协议之间的互通方案的3GPPTR33.924中给出了另一个示例。3GPPTR使用了GBA密钥而在作为标识供应方的相同位置的NAF/OP与UE/用户的UICC之间执行用户认证。在本节的剩余部分，举例来说，我们将重点放在了GBA与OpenID之间的互通上。
UE在Ub接口上使用MNOHSS的BSF来创建这些应用层证书。然后，这些证书经由Zn接口与OP/NAF共享。之后，UE客户端可以使用这些证书来与服务供应方直接通信。
图16示出的是用于myMacDonald等人撰写的“AWebServicesShoppingMallforMobileUsers”（用于移动用户的网络服务购物中心）中所示的自由/GBA的架构方案。如图16所示，GBA可以与自由联盟协议集成，以便提供实施自由IdP的购物中心。通过该自由IdP，购物中心（shoppingmall）可以为用户提供可供其在购物服务时使用的标识。该IdP使用了GBA协议作为认证机制。
图16示出了以下步骤：
315一旦进行了注册，则（UE）的用户代理在Ub上执行带有（BSF）的GBAU。
320.为UICC内部的用户代理小应用程序提供Ub参数。
325.用户代理的UICC组件计算Ks，并且为UE提供服务层证书（Ks(int/ext)NAF）。所述Ks始终保持在UICC中。
330.用户代理与（NAF/IdP）进行联系，以便获取“ShoppingMall”标识
335.将适合用户代理的服务证书经由Zn传递给（NAF/IdP）
340.将用于“shoppingmall”的认证令牌从（NAF/IdP）提供给用户代理
345.（UE）使用服务证书来与（SP）进行通信，并且请求服务
350.（SP）确认（UE）服务证书的有效性。
4.2.2.2.3使用GBA和OpenID的实施方式
在一个示例实施方式中，GBA可以被用于在UICC与NAF之间建立共享秘密。NAF可以与其他服务（例如IdP）处于相同位置，并且不必处于MNO网络的内部。NAF可以向BSF（处于MNO网络内部）要求连接。例如，UE内部的UICC与NAF之间的连接可以经由HTTP或HTTPS上的SOAP。在下文进一步论述的其他实施方式中，对于可以用于OP与MNO之间的通信的基于UICC的OP来说，该OP可以使用GBA协议。
4.2.2.2.3.1作为OP的（直接）可信供应方的MNO
在一个示例实施方式中，从MNO可用于在RP与OP之间建立信任的意义上讲，MNO可以直接被包含在RP-OP通信中。
以下实施方式可以与先前在第4.5.2.2.1节中描述的实施方式相结合。用于RP与MNO之间的直接连接的实施方式
图17示出的是将GBA用于MMO支持的标识声明的示例实施方式。
如图17所示，在370处，RP可以连接到MNO的网络实体，以便建立关联。该MNO实体可以充当基于UICC的OP的断言支持；该实体可被称为OPsup。OPsup可以具有集成的NAF功能，并且可以被作为MNO网络内部（但是可到达）或外部（但是可以由MNO操作或验证）的实体。在365处，OPsup和UICC上的OP可以执行必要的自举过程，以便使用GAA/GBA建立共享秘密。在355处，用户浏览器可被从RP重定向到本地OP。在360处，在浏览器与OP之间可以进行通信。
用户可以向本地（UICC）OP进行认证。在进行了360处的本地认证之后（例如使用PIN），在365处，OP可以向OPsup发送包含会话标识符的消息（或是RP在初始重定向中传递的附加现时（nonce）），其中该会话标识符是用从Ks_NAF得到的RP特定的密钥Ks_NAF_RP签名的，并且可选地，用于签名的也可以是会话特定的密钥。在370处，如果已经在OPsup与RP之间建立了安全连接，那么由于所建立的信道已经提供了来源的真实性（authenticity），并且为消息提供了完整性保护，因此，OPsup可以将这个消息转发到RP。但是，OPsup可以用公钥来对消息进行签名，以便在与通信信道无关的情况下提供完整性保护和真实性。RP可以配备一个从Ks_NAF得到的RP专用密钥Ks_NAF_RP来核实OP签名，可选择地，该密钥可以是会话专用密钥。然后，Ks_NAF_RP可以经由OPsup被传递到RP。在另一个实施方式中，KS_NAF可以直接用于签名创建和核验。通过OP的间接通信的实施方式
在一个示例实施方式中，间接通信可以用于将现时从RP传送到OP，然后，OP会将其转发到MNO。MNO对该现时进行签名，其中该现时可以被包括在本地认证成功之后被从OP反向传送到RP的断言中。由于MNO对该现时进行了签名，因此可以向RP提供OP在MNO发布的UICC上运行的保证。
用于组合方法的实施方式
在一个示例实施方式中，可以使用在RP与MNO之间经由直接通信（例如HTTPS连接）建立的共享秘密。然后，在认证完成时，RP可能期望OP将该秘密包括在断言消息中。
在另一个示例实施方式中，可以使用GBA。由于GBA协议不允许在NAF与UICC之间建立任意共享秘密（例如RP的秘密），因此，在这里可以使用间接手段（例如同处一地的OPsup实体）。RP向OPsup发送会话标识符，OPsup可以使用GBA来与UICC建立共享秘密。然后，OPsup使用与UICC（由此结合UICC上的OP）建立的秘密相同的秘密来对会话标识符进行签名，并且可以将被签名的会话标识符发送回RP。RP可以保持这个被签名的会话标识符作为参考。该RP将会话标识符包括在重定向消息中，由此可以允许OP使用GBA秘密来对其进行签名。然后，OP可以将被签名的会话标识符包括在到RP的断言消息中。之后，RP可以比较来自OP和来自OPsup的被签名的消息。如果两者匹配，则RP证明OP属于OPsup的MNO的用户。该实施方式可以代表闭环过程，其中签名匹配加固了消息保护并且建立了OpenID认证。
4.2.2.2.3.2当在MNO与智能卡上的OP（拆分OP）之间拆分OP功能时使用GBA的实施方式
图18示出的是启用拆分OP的示例实施方式。如图18所示，在375处，在RP与MNO之间可以建立关联。RP可以与MNO建立共享秘密，然后，OP可以在断言消息的签名过程中使用该共享秘密。如果RP与不同用户具有多个同时连接，那么该断言消息还有可能需要包括关联句柄，以使RP识别正确的共享秘密。该共享秘密可以允许RP核验断言签名，而不必与OP进行通信。这种关联可以在首次从RP重定向UE浏览器之前执行。
在380处，OP可以向RP传送认证请求。在385处，RP可以向OP传送认证响应。在390处，OP可以与MNO建立关联句柄和签名密钥。该关联句柄和签名密钥可以使用GBA来建立。
在一个示例实施方式中，OP的功能可以划分在MNO与本地OP之间。如果所使用的是RP与MNO之间的关联，那么RP可以与MNO建立共享秘密，然后，OP可以在断言消息的签名过程中使用这个共享秘密。如果RP与不同用户具有多个同时的连接，那么该断言消息还可以包括关联句柄，以使RP识别正确的共享秘密。该共享秘密可以允许RP核验断言签名，而不必与OP进行通信。如果假设执行了GBA，那么可以将MNO与RP之间的共享密钥传递到受Ks_NAF保护的OP。由此，OP可以使用经由关联建立的共享密钥来对断言消息进行签名。
RP可以与MNO建立关联，然后，MNO执行产生MNO与OP之间的共享秘密的GBA过程。MNO可以在RP可到达的服务器上实施NAF功能。NAF可以与UICC上的OP建立共享秘密，而RP则从NAF接收共享秘密。关联句柄（为NAF和RP所知）还可以被从MNO接触点（NAF）发送到OP。然后，OP可以使用包括关联句柄的GBA共享秘密来对发送给RP的断言进行签名。由于RP已经经由关联链路而从NAF那里接收到了相同的共享密钥，因此，RP可以核验OP签名。通过使用关联句柄，可以允许OP和RP处理多个（同时的）会话。
4.2.2.2.3.3在拆分终端情况下的移动OpenID中的GBA的使用
在一个示例实施方式中，可以在浏览器和OP/UICC组合驻留在分离的设备的拆分终端配置中使用GBA。可以假设所使用的是拆分终端类型的配置，但是OP是用户本地的实体，并且其中如前所述，用户在本地与OP执行认证。
图19示出的是启用拆分终端/本地OpenId的示例实施方式。如图19所示，举例来说，确保两个设备之间的信道的安全的处理可以使用蓝牙安全链路完成，或者可以借助TS33.259中描述的用以建立共享密钥Ks本地设备（Ks_local_device）的过程等等来完成。密钥可以在UICC内部计算，并且可以经由安全隧道传递到浏览器。共享秘密的建立可以由GBA来支持。该共享密钥可以从GBA生成的密钥Ks(ext/int)NAF中得到。
在一个示例实施方式中，当使用33.259时，这时可以使用具有基于证书的相互认证的HTTPS来建立用于连接NAF和远程设备的安全隧道。例如，浏览器可以是基于PC的、具有在因特网/TCP连接环境中工作的隧道。隧道的安全性可以借助信任机制来加固。依照移动电话规范（MPWG）中的需求，在这里可以假设包含浏览器的远程设备是兼容TCG的。通过设备中的TPM证据，可以将HTTPS隧道建立绑定到浏览器设备的信任状态。因此，嵌入在此协议中的完整性检查会将Ks_本地_设备绑定到平台。
在另一个示例实施方式中，作为所述过程的一部分，托管用户浏览器的远程设备可以请求UICC主机设备向其发送NAF_ID列表。MiTM可以很容易地产生这种请求并接收被请求的ID。对于保护隧道来说，其证书和相互认证方面结合所假设的恰当信任特征将会确保在拆分终端配置内部不会发生MiTM攻击，或者如果发生了这种攻击，该攻击也是能被检测到的。一旦完成了这种设置，则可以将Ks_本地_设备密钥经由隧道安全地发送到远程设备；随后，远程设备（浏览器）可以发送密钥生成请求消息（完整性受保护），以便在UICC主机设备上发起关于Ks_本地_设备的计算。
在这里描述了用于拆分终端类型配置的标识断言协议。在这里可以假设已经实施了GBA，并且实施了在远程平台（浏览器-PC）与包含UICC/OP（UE）的设备之间建立共享密钥Ks_本地_设备的过程。如图19所示，在405（连接UE和NAF/OPsup）和400（连接UE和PC）处标识的信道可以是安全的。在另一个示例实施方式中，MNO可以用于为这里的基于UICC的OP应用的标识断言提供支持。
在另一个示例实施方式中：
·用户使用OpenID登录表单来将其OP标识符（URL）提供给RP（在395处）
·用户被RP重定向到其OP——该重定向消息包括现时或会话标识符
·RP与MNO建立以及安全关联（例如HTTPS连接——在410处）
·RP还向OPsup发送会话标识符——该消息受前述安全关联保护（在410处）
·用户使用通过浏览器输入的PIN（或密码）进行认证
·在一个消息中将该信息从PC经由400传递到UICC/OP，其中该消息还包括从RP获取的会话标识符——如上所述，该消息是用Ks本地设备保护的
·OPsup使用GBA密钥Ks_(ext/int)_NAF来对会话标识符进行签名，并且将其发送回RP，RP则保持该签名作为参考（410）
·现在，OP同样使用GBA密钥Ks_(ext/int)_NAF来对从浏览器发送给它的会话标识符进行签名，并且将该签名包括在随后发送给RP的断言消息中（395）
·RP比较这两个签名，其中一个签名来自Opsup（410），另一个签名来自OP（395）；如果两者匹配，则RP断定该OP属于OPsup的MNO的用户。
4.3用于智能卡网络服务器上的OP的有效协议的实施方式
本部分旨在显现SCWS上的OP提供的优点，尤其是提供了有效改善并在本申请中被进一步描述的实施方式的优点。例如，所提出的实施方式可以是实施OpenID协议的实施方式，这些实施方式的其中一个优点是认证业务处于本地，并且除了现有HTTP消息流需要的空中接口网络或网络服务之外，该业务不会对其他的空中接口网络或网络服务造成负担。发现和关联业务并没有经由空中接口网络，并且是在运营商OP与RP之间的固定线路的公共因特网上进行的。
4.3.1标准的OpenID
图20示出的是标准的OpenID协议。对该协议来说，本地业务是不存在的，并且从空中网络卸载的业务仅仅是发现过程以及在RP与OP之间建立关联的处理。由于OP是网络服务，因此，用户/浏览器/设备与OP之间的所有通信全都会通过空中接口来进行。例如，信号420、435、440、445、450、455、460和465是在通过作为数据业务（例如HTTP，基于IP的通信）并经由在MNO/空中网络上执行的空中通信过程出现的。这代表了MNO网络上的加载。此外，信号425和430是在固定线路的因特网上出现的业务，并且可以使用现有基础架构。
4.3.2OpenID/GBA
图21示出的是来自3GPPTR33.924v9.1.0的OpenID/GBA的业务流程。对于该协议定义来说，无论RP与MNO之间具有怎样的关联步骤，所有通信都是在空中网络上进行的。但是，由于需要用于认证的472和474，而这又会在空中数据网络以及GBA认证需要的后端服务（称为BSF和NAF子系统）上增加负担，因此，与基于网络的OP相比，OpenID/GBA中的业务甚至还会增大。因此，在这里我们将会看到空中网络业务增大，以及网络实体的负载增大。
4.3.3用于协议改善的实施方式
图22示出的是用于减小空中业务的协议流程的示例实施方式。例如，该有效协议可以用于SCWS上的OpenID。在该实施方式中，可以假设在与SCWS相关联的OP与MNO之间存在长期共享密钥。
如图22所示，空中业务可以被卸载到本地设备，从而减小空中接口网络业务。举例来说，通过执行该处理，可以允许认证业务变为本地，以使认证业务将对空中接口网络或网络服务的负担最小化。此外，发现和/或关联业务未必经由空中接口网络发生，并且可以在固定线路的公共因特网上发生。
在480处，用户可以与诸如浏览器之类的用户接口交互，并且可以访问RP，以及使用OpenID来请求登录。在485处，RP和OP（MNO）可以基于OpenID标识来执行OP服务器的发现。在490处，RP可以向OP传送关联请求。OP可以产生随机的唯一关联句柄A，并且可以计算密钥S。OP可以向RP传送关联响应。该关联响应可以包括关联句柄A和密钥S。所述RP则可以存储密钥S和关联句柄A。
在495处，RP可以向浏览器传送重定向。该重定向可以将浏览器重定向到OP，并且可以将关联句柄A包括在请求参数中。OP可以被关联到SCWS。浏览器可以接收所述重定向，并且可以执行修改的本地DNS查找来映射到SCWS。在500处，浏览器可以向OP传送本地认证请求。在505处，认证可以在本地进行。例如在510处，OP可以基于长期共享密钥K和关联句柄A来核验证书。此外，OP还可以计算密钥S，并且可以使用密钥S来计算签名。该签名可以用于对断言消息进行签名，和/或对诸如returnto（返回到）URL、标识和/或模式之类的参数进行签名。
在515处，OP可以向浏览器传送能将浏览器重定向到RP的重定向。该重定向可以包括关联句柄A和被签名的参数。在520处，浏览器可以向RP传送请求，该请求可以包括来自OP的被签名的断言消息。RP可以使用密钥S来核验断言消息上的签名。然后，在525处，RP可以允许浏览器显示登录页面，并且可以向浏览器提供对服务的接入。
4.4用于在智能卡网络服务器上实施OP的实施方式
存在供用户设备（UE）与SIM卡通信的可用并被标准化的方法，例如，3GPPTS11.14规范定义了可供SIM应用使用的SIM应用工具箱（SAT）接口，但是并未定义如何可以在来自不同SIM厂家的各种SIM卡类型上以统一的方式访问命令。在一个示例实施方式中，通过使用SIM应用工具箱，SIM卡可以获得对UE的临时控制（主动式）。与UE向SIM卡发送请求并且SIM卡做出响应的情形相比，UE可以从SIM那里取得SAT命令。SIM卡向UE发布SAT命令；无论命令是否执行成功，UE都会做出相应的反应，并且向SIM回送响应。
4.4.1智能卡网络服务器上的OP
智能卡网络服务器（SCWS）是在USIM卡上运行的网络服务器，其行为与传统的网络服务器相似。它可以被视为是SIM工具箱的进步，并且在用于显示电话簿的当前应用方案中，它可以被视为使用本地UE浏览器且经由HTML接口的附加MNO服务等等。SCWS使用了标准的HTTP协议来将其内容递送到浏览器，但是与传统的网络服务器不同，SCWS可以使用两个不同的承载：BIP（在T=0智能卡协议之上）或USB接口上的完整TCP/IP栈（在卡上实施）。
UE负责路由那些来自和去往SCWSUSIM的业务，由此充当了将(U)SIM连接到MNO和因特网的网关。如果使用的是BIP，那么ME中的路由器会将来自UE浏览器的某些HTTP请求重定向到本地SCWS。所定义的TCP端口上的HTTP请求将被发送到（U）SIM上的SCWS，并且响应中的HTML页面是由SCWS产生的。不使用专用于BIP的TCP端口的HTTP请求被引导到因特网上的服务器。如果在(U)SIM上将USB协议与完整的TCP/IP栈组合使用，那么UE与将内部网连接到因特网的其他计算机具有相同的IP网关功能。ME网关还取决于使用的IP协议版本，即IPv4或IPv6。与BIP相比，完整的TCP/IP栈还提供了将请求从(U)SIM路由到因特网的可能性。
图23示出的是用于SCWS上的OP的内部路由的示例实施方式。如图23所示，SCWS可以用作OP的基础，并且UE的路由能力可被修改，以便在指定的外部端口上作出反应，以及将通信转发到SCWS上的OP。例如，通过执行该处理，可以在不具有经过浏览器的隧道的情况下创建直接通信。这些业务有可能仍旧经过相同的设备，但是有可能以不同方式被重定向。
UE中的路由功能（RF）可以启用多条通信路径。当用户首次使用浏览器访问RP站点时，RF可以将所述请求经由可用的出站TCP/IP接口（例如3G网络连接性）重定向到RP。现在，由于在该连接上建立了公共会话，因此，RP知道浏览器的IP地址。RP可以使用与用户/浏览器会话中相同的地址来与OP取得联系。RP可以在设备上使用另一个（预定义的）端口，该端口不同于在与浏览器进行的HTTP会话中的端口。RF将这个端口看做是应被路由到SCWS上的OP的端口。RF可以直接将消息重定向到OP，该OP可以允许RP与OP建立关联。RP还有可能向浏览器发布重定向，以便执行OpenID认证。该浏览器可以被重定向到SCWS上的OP。RF可以将来自浏览器的呼叫看做是可被路由到本地SCWS的呼叫。OP可以执行本地用户认证（该处理可以经由安全的UI进行，也可以由SCWS作为控制所述设备的UICC能力的一部分来提供，而这通常需要用户提供PIN码）。
在认证之后，OP可以用肯定断言来将浏览器重定向到RP。由于RP和OP有可能已经建立关联，因此，RP能够自主核验该断言。如果不能创建关联，那么还可以实施OpenID的直接核验方案。在这种情况下，RP在接收到肯定断言之后即可在预定端口联系UE，RF会将请求路由到OP，而OP可以应答核验请求。
在一个示例实施方式中，在本地设备上可以限制针对OP的访问。例如，只有本地浏览器才可被允许获取关于标识的断言。这样做可以防止攻击者从外部设备检索（retrieve）标识断言。RF还可以将入站业务到OP的路由与先前的浏览器请求相耦合。例如，对于与浏览器通信的单个RP来说，路由有可能在有限的时间中是活动的。
MNO还可以使用RF而分别在SCWS和OP上执行管理任务。
4.4.1.1.1一般需求
以下是OpenID规范阐述的一般需求：
（R-1）在OpenID中，RP可以决定在无状态或是以关联为基础的通信模式中工作。由于不能在RP上进行假设，因此，这两个选项全都需要得到OP实施的支持。
（R-2）在无状态模式中，在OP与RP之间没有建立共享秘密，在RP经由浏览器接收到来自OP的断言消息之后，RP会直接与OP取得联系。然后，RP会与OP建立直接的HTTP(S)连接，以便请求OP核验该断言消息上的签名。
OpenID规范允许两种不同类型的（对称）签名方案：HMAC-SHA1-160比特密钥长度以及HMAC-SHA256-256比特密钥长度。如果RP使用了关联，那么，在关联建立处理中，在OP与RP之间可以交换该对称密钥。秘密交换是以如下方式保护的：使用Diffie-Hellman密钥交换保护，随后用DH-密钥-值来加密共享秘密，或者如果没有使用Diffie-Hellman，则必须通过传输层安全措施来保护连接免受窃听者窃听。OP在断言消息上发布的所有签名都是使用了所提及的算法中的一种算法的对称签名。诸如全球平台之类的智能卡术语使用了术语密码或是更常见的“数据认证模式（DAP）”来描述这种密码签名方案。
（R-3）在基于关联的OpenID中，RP与OP建立用关联句柄标识的共享秘密。RP将这个关联句柄包含在初始重定向消息中，该消息将浏览器重定向到OP。然后，OP可以使用关联句柄来发现RP的共享秘密，并且然后使用该秘密来对断言消息进行签名。一旦接收到这个消息，RP可以自动核验接收到的签名。
（R-4）在（R-1）、（R-2）、（R-3）中描述的通信选项全都需要从RP到可以经由公共因特网到达的实体E1的至少一个直接连接，其中对正常OpenID来说，E1是OP服务器。
（R-5）来自（R-4）的实体E1必须能在基于关联的模式中，在OP服务器与RP之间建立共享秘密。在无状态模式中，该秘密必须为OP所知，以便对消息进行签名，此外，该秘密还必须为这个可到达实体E1所知，然后，RP会通过与之联系来核验OP签名。
（R-6）OpenID中的签名一般以HMAC-SHA1为基础，OP和核验方必须能使用恰当算法来对数据进行签名并核验签名。
（R-7）MNO必须提供网络实体E2，所述网络实体E2依照OpenID标准来提供借助于HTML或XRDS发现的OP发现处理。实体E2必须在作为OpenID标识符一部分的DNS地址上运行，例如，如果该标识符是http://openid.mno.com/id，那么MNO必须在http://openid.mno.com上运行网络服务E2，也就是说，MNO必须具有所述域和服务器，以便作为发现服务来运行。发现服务借助于公共因特网进行，并且可以是轻量级的。实体E2可以与来自（R-4）的实体E1共处于提供这两种功能的公共物理实体中。此外，E2可以与E1分离，在这种情况下，发现处理为使用OpenID的漫游设备选项提供了进入点。
（R-8）来自（R-7）的E2的（DNS）地址不应改变，以便为用户提供一致的标识符。
（R-9）OP必须能够由用户浏览器至少经由HTTP到达。
（R-10）与（R-9）中相同的连接可以使用HTTPS而不是HTTP。
可选的（R-11）：OP必须能够产生并显示用作认证页的HTML页面。由于未规定实际认证，因此该处理是可选的。如果未使用认证页面，那么OP至少应向用户告知其OpenID标识符已被使用，以免隐瞒标识的使用情况。但是，不显示认证页面可能有益于为用户提供更为一致的SSO体验，例如，用户每天只对SCWS上的OP进行一次认证，然后，所有的后续认证处理都会自动进行。
可选的（R-12）：如果使用了认证页面，并且该认证页面接收来自用户的数据，例如用户名和密码，那么OP必须能接受该数据，对该数据进行处理和核验，以及执行相应的操作。
可选的（R-13）：如果使用了认证页面，那么该认证页面可以使用RP接收的信息而以易于理解的方式向用户显示附加信息，例如通过显示RP名称以及将在文本中使用、作为图形图标使用或者同时以这两种方式的组合形式使用的标识符。
可选的（R-14）：如果使用了认证页面，则认证页面可以包括被用作指示符的（可视）秘密，该指示符向用户表明该用户正在与合法的OP进行通信。
4.4.1.1.2在OpenID中使用SCWS的实施的实施方式
上一节论述的是OpenID标准设置的一般需求。在本节中，我们将要描述的是用于在如上所述OpenID需求以内实施使用SCWS的本地OP的实施方式。
在一个示例实施方式中，SCWS可以不是从公共因特网直接可到达的，也就是说，RP不能直接与SCWS上的OP取得联系。如果给出了需求（R-1）、（R-2）、（R-3），那么可以使用间接指向。例如，MNO可以提供能够经由公共因特网到达的网络服务，并且该服务能够与关联于SCWS的OP共享秘密（参见本文中关于拆分OP的章节）。此外，该网络服务还能与RP共享该秘密，由此在RP与关联于SCWS的OP之间的共享秘密能够被建立。在另一个实施方式中，RF可以将请求路由到SCWS上的OP。
从MNO到SCWS的通信可以借助HTTP(S)并经由远程管理接口进行，例如经由SCWS远程更新和相关联的小应用程序来进行，该通信也可以来自手持机浏览器并借助本地HTTP(S)来进行。本地连接接口可以被用于OpenID通信。另外，本地连接还可以充当用于与SCWS和OP通信的通用HTTP(S)接口。
ETSISCP定义了借助TCP/IP（9）的智能卡访问，并且该访问可以不仅限于本地访问。例如，从外部实体对SCWS进行的受限访问可能不是技术问题；相反，依照用于SCWS的当前标准规范，它有可能是设备内部的路由功能限制。对SCWS进行的直接HTTP访问可以在SCWS的未来版本中实现。此类访问可以不是管理访问。例如，对OpenID操作而言，RP可以访问由SCWS提供服务的网页（实施OP服务器逻辑的动态小应用程序）。
4.4.1.2用于为OP-相关联的-SCWS实施处理附加和衍生需求的实施方式
当在UICC上实施OP并且OP与SCWS相关联时，以下实施方式有可能产生附加需求：
（RSCWS-1）在一个示例实施方式中，MNO必须实施支持OP服务器功能（OPSF），该OPSF能够与关联于SCWS的本地OP（以及可选地与RP）产生、共享和分发用于OpenID协议的秘密。
所述支持OP功能有可能需要在RP与UE上的本地OP实体之间为在OpenID上的签名中使用的共享秘密充当协商可信方。该支持功能可以提供HTTP(S)接口，以使RP发起关联处理（如果使用了关联）或者在RP请求时确认来自本地OP的签名。因此，它是可以经由公共因特网到达的，并且该功能还必须能与本地OP进行通信，以便交换秘密。这种针对本地OP的通信可能必须至少在用户希望访问的每一个RP上执行一次。在一个示例实施方式中，本地OP由MNO管理和维护。MNO可以通过与本地OP/SCWS进行通信来更新共享秘密，而OMASCWS标准可满足需要。在另一个示例实施方式中，非MNO的远程OpenID标识供应方服务对智能卡上的本地OP进行管理并与之通信，此外，也可以使用全球平台标准。
通常，在OP与RP之间可以为每一个RP建立新的（对称）秘密。由于很难限制用户使用OpenID登录来访问的RP，因此很难为用户希望在未来访问的所有RP预先提供这些共享秘密。如果每一次为UICC中的每一个RP产生秘密（例如从种子值中将其导出），那么可以将该秘密与RP共享，这一点参见在稍后章节中的协议流程，在那里我们将对该选项进行讨论。
（RSCWS-2）在另一个示例实施方式中，来自（RSCWS-1）且由MNO操作的网络实体可以使用不同的信道和通信方法而在与SCWS关联的OP中建立秘密，并将其分发给RP。从MNO到RP的通信被OpenID协议限制成是基于HTTP的通信。从MNO到与SCWS相关联的OP的通信可以使用安全的SMS-PP，或者举例来说，该通信可以由GBA引导，和/或可以使用安全的通信协议，例如HTTP(S)SCWS远程管理接口。
（RSCWS-3）在另一个示例实施方式中，与SCWS相关联的本地OP必须可以访问在来自（RSCWS-1）的MNO实体与智能卡之间共享的秘密。这些秘密并不是网络专用密钥，而是仅用于OpenID协议；如有需要，它们可被调用，并借助OTA措施来重新建立。这些秘密是供OP用于对从RP发送的HTTP参数进行签名的对称密钥。
如果OP拥有本地OP，那么MNO可能不必分发这些秘密，这是因为OP可以与其本地OP建立密钥（得到GP和/或GMA的确认）。MNO有可能需要用于远程管理SCWS的秘密，但是他有可能借助该途径来建立用于本地OP的密钥。
（RSCWS-4）在另一个示例实施方式中，对来自（RSCWS-3）的秘密的保护应该使其不能被从手持机上的其他应用中读取，并且作用于这些秘密的所有算法都是在智能卡提供的安全环境中运行的，由此不会将秘密暴露在智能卡环境中的应用空间之外。
如果本地OP是全球平台应用，那么可以由本地OP的安全域来存储密钥，其中所述本地OP的安全域为本地OP执行密码运算。
（RSCWS-5)在另一个示例实施方式中，与SCWS相关联的本地OP可以存储供OP在以后使用的秘密和关联句柄，从而如果再次访问该RP，则可以减少从MNO到OP的附加OTA业务。
（RSCWS-6）在另一个示例实施方式中，与SCWS相关联的本地OP可以在显示给用户的认证页面中使用只能由合法的本地OP显示的附加安全特征，例如安全地存储在智能卡中的秘密图像。
（RSCWS-7）在另一个示例实施方式中，与SCWS相关联的OP必须实施处理HTTP请求和显示HTML页面的应用逻辑之外的应用逻辑，尤其是用于对来自RP的参数进行签名的应用逻辑。
（RSCWS-8）在另一个示例实施方式中，如果使用了由与SCWS相关联的OP产生秘密的实施选项，那么来自（RSCWS-7）的应用逻辑必须产生对称秘密，并且将其安全传递到MNO网络中的实体。
（RSCWS-9）在另一个示例实施方式中，来自（RSCWS-7）和（RSCWS-8）的应用逻辑可以在由SCWS动态调用的Java小应用程序或小服务程序中实施，以便执行必要的操作，随后将控制权返回给SCWS。所述小应用程序/小服务程序应在UICC中的安全环境里运行。
（RSCWS-10）在另一个示例实施方式中，SCWS可以提供用于认证的动态网页，该网页基于用户简档来显示从MNO检索的信息，例如广告横幅，其中该用户简档可以通过追踪在RP上使用的用户OpenID标识来产生。MNO可以在SCWS上提供用于市场营销/广告目的的RP‘网络空间’。这样做会为SCWS上的OP带来另外的价值。
（RSCWS-11）在另一个示例实施方式中，如果SCWS证明在具体方案中过于受限，那么另一个选项可以是基于模仿SCWS功能的JavaCard应用来实施应用逻辑：该应用接受输入的HTTP请求，为用户提供认证接口（例如PIN），对签名进行计算，生成HTTP响应，以及向浏览器做出回应。在该方案中可以探究BONDI框架是否有助于浏览器与取代SCWS的智能卡应用之间的间接通信部分。
4.4.1.3命名规则
用于实体的下列命名规则是适用的：
·与SCWS相关联的OP：本地OpenID标识供应方，其发布被签名的断言消息，并且将这些消息通过用户浏览器发送到RP。存放SCWS的智能卡乃至OP被假设成与MNO具有关系，由此与MNO关联的所有实体都具有关系。
·RP：依赖方，它可以是任何使用OpenID来为用户提供登录的网站。RP完全独立于所有其他实体，因此，在RP上不能施加附加需求，并且不能改动用于RP的OpenID协议流程。OP必须支持RP选择使用的任一通信模式（无状态或基于关联）。如果MNO决定用户不应该使用某些RP，那么由于用户还可以使用别的标识，因此，MNO不能通过拒绝对于这些RP的OpenID访问来拒绝对于这些站点的访问。MNO只能使用附加装置来限制对于RP的访问，其中所述附加装置通常阻止的是对消耗带宽的站点进行的访问。
·OP-Agg：OP-Agg实施的是来自（R-7）的实体E2，其为RP提供了发现服务。
·OPSF：OP服务功能（OPSF）实施的是能与关联于SCWS的OP并且可选地与来自（RSCWS-1）的RP一起产生、共享和分布秘密的支持OP功能。从RP的角度来看，OPSF和关联于SCWS的OP的行为就好像它们是单个实体。OPSF能够核验与SCWS相关联的OP发布的签名，并且可以由RP经由公共因特网直接到达。通过修改设备上的本地DNS解析缓存，可以将设备上的浏览器重定向到与SCWS相关联的OP，以使OPSF的地址映射到与SCWS相关联的本地OP。
·浏览器：在协议流程图中显示，以便明确往来于与SCWS相关联的OP的路由和消息传递功能。否则，它只是显示和接收用户认证的前端。
4.4.1.4用于在SCWS/UICC上实施OP的实施方式
在尝试保持兼容标准的OpenID认证协议的同时，本节使用了从如上所述的通用概念中得出的实施方式。以下论述了无状态和基于关联的模式协议的两个实施方式；其中第二实施方式使用了密码假设，这其中包括在OP卡功能与网络侧的服务器功能之间共享密钥，以便加强认证过程。
4.4.1.4.1协议流程描述
以下章节描述了用于实施与SCWS相关联的OP的协议流程的示例实施方式。在一个示例实施方式中，如上在（R-1）中显示的，这两个方案（无状态和基于关联）都可被覆盖。在下文中提供了关于实施方式的呼叫流程的协议流程图和描述。通用的OpenID协议则是对照图3示出的。
在图24-图27中显示了多个选项，并在相应的描述中解释了这多个选项。
4.4.1.4.2用于使用无状态模式的RP的协议流程
图24示出的是能使RP使用无状态模式来执行OpenID认证的协议流程的示例实施方式。例如，RP可以使用无状态模式来执行OpenID用户认证。如图24所示。
530：用户可以访问RP网站并输入其OpenID标识符。例如http://op.org/identity。
535：浏览器可以向RP网站发送包含了OpenID标识符的HTTP消息。
540：RP可以使用基于HTTP/HTML的OpenID‘简单’发现处理，并且经由公共因特网来联系OP-Agg，以便检索针对OpenID标识符的标识页面。例如，HTTP获取（GET）http://op.org/identity。
545：OP-agg可以接收该请求，并且使用包含了OPSF的因特网地址的HTML页面来做出响应，例如包含以下地址：
<linkrel=“openid.server”href=http://op.org/server.cgi>
OPSF可以像标准的OpenID标识供应方网络服务一样对RP进行操作，也就是说，在RP请求时，OPSF能够核验断言消息上的签名（由本地OP发布）。OPSF可以经由公共因特网到达，并且可以被假设成具有能够经由http://op.org到达的DNS名称，如op.org。由于外界不可能知道智能卡的IP地址，因此使用了这种间接OP-agg和OPSF来进行通信。
OPSF的地址可以不同于OP-agg的地址。
a．选项1：该项并非必需，而是给出一个选项。如果在这里未使用该选项，则可以在协议的后续阶段中使用570处的选项2。
i．OP-agg通过向OPSF发送RP标识符和OpenID用户标识符来向OPSF告知来自RP的请求。
ii．OPSF可以尝试在本地数据库中查找关于该RP的秘密和OpenID标识。
iii．如果没有发现秘密，则OPSF可以产生新的秘密和关联句柄，并且将这二者发送到与SCWS相关联的OP，所述SCWS则转而对其进行存储。
iv．如果发现秘密，则OPSF会在以后使用该秘密来执行签名核验。可以假设，如果OPSF在本地数据库中发现了秘密，那么与SCWS相关联的OP已经在先前与该RP执行的协议过程中接收到该秘密和关联句柄，由此能够存储并重新使用该秘密。
OPSF用以核验签名的秘密与关联于SCWS的OP用以产生签名的秘密可以是相同的。签名的新鲜度可以由下一个步骤中插入的RP现时来确保，并且该RP现时需要是签名的一部分。OpenID规范对签名秘密本身的新鲜度保持默认。OP负责确保秘密的密码强度，保持其秘密性，以及在需要时确保其新鲜度。OPSF和关联于SCWS的OP可以持续有限寿命或是用于对该目的签名秘密的使用计数。关于秘密共享的选项的更多内容是在第
4.4.1.4.3.1节中描述的。
550：RP可以接收OPSF的地址，并且创建现时和会话标识符，例如现时=123123，会话=用户。RP可以编译return_to（返回到）参数，该参数向OP告知应该在用户认证之后将浏览器重定向到哪一个URL。RP可以发布HTTP重定向，由此将浏览器重定向到OP服务器地址，其中所述HTTP重定向可以包含下列参数：
openid.mode（openid.模式）=checked_setup（核验_建立）,
openid.identity（openid.标识）=http://op.org/identity,
openid.return_to=http://rp.org/return.cgi?session=User&nonce=123123
555：浏览器可以接收重定向，并且开放与RP在重定向消息中规定的URL相连的连接。
560：结合可以将OPSF的URL映射到SCWS本地IP地址的经过修改的本地DNS查找表，例如通过使用具有项http://op.org==127.0.0.1的主机文件，可以将浏览器重定向到与SCWS相关联的本地OP，并且发布包含了来自550的参数的HTTP请求。
经过修改的本地DNS查找表可以在设备上使用，并且它会使设备认为URLhttp://op.org处于SCWS的本地IP地址。因此，浏览器可以开放与SCWS/本地OP的连接，而不是连接到OPSF（可以经由公共因特网而在URLhttp://op.org到达该OPSF）。
565：通过执行以下处理，可以确保将认证业务保持在本地，这些步骤不是OpenID协议规范所需要或规定的：
a.OP可以与SCWS相关联，并显示本地认证页面
b.用户可以输入其认证证书，例如用户名和密码
c.OP可以与SCWS相关联，以核验这些证书
570：如果使用的是处于545的选项1，那么与SCWS相关联的OP有可能具有在关联于SCWS的OP与OPSF之间共享的秘密和关联句柄，其中所述秘密和关联句柄是从OPSF那里新接收的，或者是从秘密和关联句柄的本地存储器中检索得到的。
a．选项2，如果在545处没有使用选项1：
i．与SCWS相关联的OP可以产生新的秘密和关联句柄
ii．与SCWS相关联的OP可以将这个秘密和关联句柄经由SCWS发送到OPSF
iii．OPSF可以接收该秘密，并且安全地存储该秘密，以便用于以后的访问
举例来说，这里的目标可以是在OPSF与本地OP之间共享秘密，因此，如果本地OP生成秘密，则可以在生成该秘密之后将其传递到OPSF。
启用工具箱的本地OP可以使用CAT来主动与手持机通信，从而绕过SCWS。该消息可以依照标准的OTA（例如用于经由SMS-PP承载来发送OPSF的OTA）而被格式化。但是，这种处理有可能需要OPSF经由MNO的OTA系统来与所述卡进行通信。作为替换，BIP网关可以提取工具箱消息的有效载荷，并且手持机可以使用TCP/IP将其发送到OPSF。但这仍旧要求消息经由MNO的OTA服务器。如果所述卡不具有IP地址并且不支持TCP/IP，那么可以使用BIP。
575：与SCWS相关联的OP计算下列参数的签名：returnto、标识以及模式。
580：与SCWS相关联的OP向浏览器发送HTTP重定向消息，其中包含了在步骤550中从RP接收到的参数，此外还包括下列各项：
openid.signed（openid.签名）参数中的一系列被签名的参数，
openid.assoc_handle（openid.关联_句柄）参数中的关联句柄，以及
openid.sig参数中的签名（基本（base）64编码）。
该消息用于将浏览器重定向到RP上的return_toURL。
585：浏览器将用户重定向到RP上的return_toURL。
590：RP接收被签名的断言消息，并且通过经由公共因特网且基于HTTP
（S）的直接通信来参与到与OPSF一起进行的核验过程中。
595：RP发布一个HTTP传递消息，该消息包含了在580中从与SCWS相关联的OP接收到的参数。
600：OPSF使用共享密钥来核验接收到的数据上的签名。
605：如果签名核验成功，则OPSF返回is_valid:真（true）。
610：对RP来说，用户现在被标识为http://op.org/identity。
615：浏览器显示RP的HTML页面。
620：将用户作为http://op.org/identity登录到RP上。
4.4.1.4.3用于无状态模式的附加实施方式
4.4.1.4.3.1共享秘密
OpenID的无状态模式是用RP从OP那里接收被签名的声明的过程来表征的，但是由于RP不知道用于签名的秘密，因此其本身是不能核验该签名的。在无状态模式中，RP再次与OP进行联系，以便核验签名。由于从RP的角度来看，发布签名的OP（与SCWS相关联）和检查签名的OP（OPSF）被视为相同的实体，因此它们必须能够共享秘密。适用于此的选项有若干个。
4.4.1.4.3.1.1选项1：由OPSF来管理秘密
本节概述的是一些使用了在上文中参考图24描述的454处的选项1的实施方式。一旦执行发现过程，则OP-agg可以向OPSF发出通知。然后，OPSF可以创建秘密和关联句柄，并且将这二者发送到与SCWS相关联的OP。如果OPSF是MNO的一部分，那么可以使用SCWS远程管理处理。如果OPSF不是MNO的一部分，那么在假设手持机提供支持的情况下，全球平台方法允许OPSF向所述卡上的本地OP发送密钥。在选项1中，在OPSF上可以实施中心秘密/关联句柄数据库及管理，其在数据库中存储了OpenID标识符、RP到关联句柄以及秘密的映射。一旦OPSF接到通知，则OPSF可以执行标识和RP查找，如果没有发现秘密，则OPSF可以生成新的秘密和关联句柄，并且将其发送到SCWS上的OP。本示例实施方式假设SCWS上的OP能够存储RP的秘密以及关联句柄，并且SCWS上的OP用于签名的秘密与OPSF用于签名核验的秘密是相同的。然后，该过程会在每一个RP上执行一次。
4.4.1.4.3.1.2选项2：由SCWS上的OP生成新秘密
本节概述的是一些使用了在上文中参考图24描述的选项2的实施方式。一旦接收到来自RP的参数，则与SCWS相关联的OP可以产生新的关联句柄和秘密。与SCWS相关联的OP可以使用该秘密来对参数进行签名，然后将这个秘密和关联句柄发送到OPSF。如果SCWS上的OP也能够存储该秘密，那么OPSF可以确定存储这个秘密和关联句柄，以便在以后使用。然后，该过程可以针对每个RP只执行一次。该处理假设已经存在永久性秘密，所述秘密可以允许本地OP对新秘密进行加密，以使其只能被OPSF解密。这种加密处理允许本地OP在不需要传输层安全措施的情况下向OPSF发送新的秘密。
4.4.1.4.3.1.3选项3：从公共种子中导出的秘密
在一个示例实施方式中，如果关联于SCWS的OP和OPSF共享了公共种子，该公共种子可以被预先确立并独立于结合不同RP所使用的一个或多个秘密，那么可以使用另一个变体。假设SCWS上的OP和OPSF共享公共种子值S。通过在唯一识别当前的OpenID过程的通信过程中将加密功能应用于这两者接收的S和信息P，这二者可以拥有相同的秘密。例如，该共享秘密可以通过将散列函数应用于S与P的级联来计算，例如通过将共享秘密作为k=SHA1(S|P)来计算。通过检查关联于SCWS的OP和OPSF接收到的信息P，可以考虑不同的候选者，例如RPIP地址和OpenID标识符、从RP接收的整个参数集、参数子集以及上述各项的任何组合等等。
与预先生成并可以在需要时使用秘密和关联句柄的密钥推导功能中一样，这样导出的秘密也可以依照公共模式来预先生成。
4.4.1.4.3.1.4更进一步的选项
更进一步的选项也是适用的，这些选项可以产生类似的状态，例如OP和OPSF共享相同秘密的状态。
4.4.1.4.3.2认证选项
由于在OpenID规范中并没有规定实际用户认证，因此，不同的选项都是适用的。
4.4.1.4.3.2.1用于集成来自可信OpenID的概念的实施方式
在一个示例实施方式中，举例来说，通过使用TPM，设备可以产生关于软件的量度。然后，这些量度可以在认证会话过程中被传送到与SCWS相关联的OP。本地OP可以具有用于与量度进行比较的参考值，并且只有在所报告的量度与这些已知的良好参考值相对应的情况下，该认证才会成功。
4.4.1.4.3.2.2使用认证证书来解锁OpenID秘密
在一个示例实施方式中，用户和OPSF可以共享公共秘密，例如PIN码。PIN码可以用于在用户每次输入证书的时候计算秘密，这与在4.4.1.4.3.1.3中描述的实施方式相似。该PIN可以通过带外注册处理来共享。
4.4.1.4.3.2.3将用户认证绑定到设备和网络认证
如果智能卡（和SCWS）支持生物计量用户认证，那么可以将OpenID认证与用户提供的生物计量标识符绑定。由于OP位于本地（在智能卡上），因此，它可以直接访问生物计量参考数据，并且不会向MNO或别的因特网实体泄露生物计量数据。
在一个示例实施方式中，通信设备可以连接到网络。该设备可以保持证书，所述证书可以安全地保存在设备或是UICC之类的智能卡上，并且所述证书被用于启用设备对网络的认证。为了向那些只能被所述用户访问的设备和网络服务提供安全的访问，所述设备上可以包括生物计量扫描器，以便提供完全的三要素认证机制，其中所述机制组合了生物计量、用户知道的某些事物（例如pin或密码）、以及用户具有的某些事物（例如安全令牌生成器fob）。
通过与先前描述的用于设备认证的实施方式相结合，还可以在认证过程中引入用户认证。在用户使用这些认证机制的组合而向设备认证了该用户自身之后，设备可以检查用户认证是否正确，也就是说，设备首先对用户进行认证，然后，如果结果证明无误，则将那些已被检查的用户认证信息（例如采用原始形式、散列形式或其他压缩形式而在用户认证过程中使用的用户证书）组合到其自身内部保持的设备证书中，之后则将组合的绑定证书信息发送到网络。
一旦接收到组合的证书，则网络可以评定该设备是否正被合法用户使用，以及设备本身是否合法。
如果设备本身不能检查用户的真实性，那么它可以先将组合的证书信息发送到网络，而不允许用户执行任何其他处理，并且只在网络评定组合证书并且传达了关于用户通过认证的信息之后才允许用户访问它的其他功能。然后，设备可以允许用户访问它的其他功能。
该方法可以提供最严格的安全性，但是基于所实施的安全策略，认证中使用的要素数量有可能减少。
认证机制
可以引入这些实施方式的认证方案包括：
1．用户向设备提供所有的三种形式的认证信息，这样针对设备对用户进行认证。一旦认证成功，则提供对设备功能以及保持在设备上的数据的访问。然后，设备采用正常方式来向网络认证，以便为用户提供设备上可用的基于网络的服务。
2.用户向设备提供所有三种形式的认证信息，这样会使用某些或所有信息来向设备认证该用户，一旦认证成功，则将某些或所有认证信息连同保持在设备上的证书信息一起传送到网络，以便用于与网络进行附加认证。一旦设备与网络间的认证成功，则允许用户访问设备功能、保持在设备上的数据以及基于网络的服务。
3.上述（2）的一个变体是向网络发送生物计量信息或是安全导出的唯一信息元素，例如生物计量信息的模糊散列，以便进行网络级用户认证，而不需要将用户生物计量信息用于针对设备的本地认证。
4.（2）或（3）的另一个变体是允许用户受限访问设备功能和数据，直至网络认证了该用户（以及设备），并且设备获得了网络回送的关于该评定的指示。在该模式中，用户将被允许访问或使用某些预先指定的“安全有保证的”功能、以及那些只有在完成了用户和设备证书的网络认证以及向设备回送了恰当授权之后才允许访问的功能。
将用户认证功能分散在设备与网络之间或者分布于一个实体的上述机制的变体也是可行的。此外，通过将用户认证与设备认证绑定，可以提供关于用户和/或设备的强认证。
虽然可以引入多种生物计量类型，但是示例实施方式可以使用指纹扫描器或视网膜扫描器之类的生物计量扫描。通过引入生物计量扫描作为用户接口的自然延伸，可以采用一种在用户执行功能或者访问处于设备本地或其他经由通信网络的特定服务时，基于触发事件来提供动态透明的用户认证的方式将生物计量扫描引入到安全功能中。例如，指纹扫描器可被引入一个软键，以使手指敲击时触发软键操作，例如“发送”，从而在认证用户的同时进行调用。作为替换，通过结合用户在显示器表面、设备主体或触摸按键上对设备进行的物理接触，可以采用一种不引人注目的认证处理来向设备连续地认证用户。
4.4.1.4.4使用了基于关联的模式的RP的协议流程
图25示出的是允许RP使用基于关联的模式来执行OpenID用户认证的协议流程的示例实施方式。该关联可以在用户首次与RP进行联系并将其OpenID标识符与该RP结合使用之后进行。如果建立了关联，则可以重新使用该关联，这样做会进一步减少通信工作。但是，OP可能不会要求RP的工作模式，并且有可能由RP来决定两种通信模式之一。
该关联在RP与OP之间建立永久性秘密，并且RP可以使用该秘密来对断言消息进行签名，此外，RP还可以使用该秘密来核验OP签名。OP可以决定共享秘密的有效期。RP和OP使用关联句柄作为所述秘密的标识符。该RP将关联句柄包含在去往OP的第一请求消息中，然后，OP可以根据关联句柄来使用相应的秘密。如果OP确定该关联已经到期，那么OP会在响应消息中通知RP。原则上，这样做可以允许OP拒绝任何关联请求。只要RP也能支持无状态模式，则可以使用该处理来迫使RP退回到无状态通信模式。例如，如果OP不能支持RP请求的签名模式（HMAC-SHA1或HMAC-SHA256），那么OP可以拒绝关联请求。
与用户每次登录RP时都在RP与OP之间建立新秘密的无状态通信模式相反，每一个标识和RP都会建立一次关联。如果在OP与RP之间已经建立关联，那么RP和OP可以重新使用该关联。
一旦知道了OPSF的地址，也就是在发现阶段之后，RP可以建立关联，并且在继续执行协议之前，也就是在将关联句柄包含在重定向消息中之前，所述RP必须完成所述关联。
如图25所示：
625：用户可以访问RP站点，以便使用OpenID来进行登录；他可以输入其OpenID标识符，例如http://op.org/identit
630：浏览器可以向RP网址发送包含了OpenID标识符的HTTP消息。
635：RP可以使用基于HTTP/HTML的OpenID‘简单’发现处理，并且经由公共因特网来与OP-agg取得联系，以便在标识页面上检索OpenID标识符，例如HTTP获取http://op.org/identity
640：OP-agg可以接收请求，并且它可以通过使用包含OPSF地址的HTML页面做出响应，举例来说，包含以下地址：
<linkrel=“openid.server”href＝http://op.org/server.cgi>
OPSF的地址可以不同于OP-agg的地址
645：RP可以使用带有下列参数且针对OPSF的HTTPPOST（传递）调用：
openid.mode（openid.模式）=associate（关联）,
openid.assoc_type（openid.关联_类型）=HMAC-SHA1,
openid.session_type（openid.会话_类型）=blank（空）,
openid.dh_*=‘Diffie-HellmanParameters（迪菲赫尔曼参数）’
650：OPSF可以产生用于RP的共享秘密和关联句柄
655：OPSF可以使用将关联句柄和秘密（如果使用了Diffie-Hellman，则该秘密是经过加密的）包含在密钥=数值格式化文档中的HTTP传递来对RP做出响应。每一个RP和OpenID标识都可以建立一次这种关联。由于Diffie-Hellman可能受到MITM攻击的袭击，因此，OpenID最佳安全实践建议使用HTTPS认证
660：RP可以创建会话现时和会话标识符，例如
nonce=123123,
session（会话）=User（用户）
665：RP可以存储从OPSF接收的秘密和关联句柄
670：RP可以将关联句柄包含在重定向消息中
675：RP可以向浏览器发送一个包含下列参数的HTTPREDIRECT（HTTP重定向）消息：openid.mode=checked_setup（核验_建立），
openid.identity=http://op.org/identity，
openid.return_to=http://rp.org/return.cgi?session=User&nonce=123123,
openid.assoc_handle（openid.关联_句柄）=‘association_handle’
680：浏览器可以接收重定向消息，并且开放与RP在重定向消息中规定的URL的连接
685：借助于将OPSF的URL映射到SCWS本地IP地址的经过修改的DNS查找表，例如，通过使用具有项http://op.org==127.0.0.1的主机文件，可以将浏览器重定向到与SCWS相关联的本地OP，并且发布包含了来自675的参数的HTTP请求
在设备上可以使用经过修改的本地DNS查找表，以使所述设备认为URLhttp://op.org处于SCWS的本地IP地址。因此，浏览器可以开放与SCWS/本地OP相连的连接，而不是连接到OPSF（所述OPSF可以经由公共因特网而在URLhttp://op.org处到达）
690：下列各项并非由OpenID协议规范规定：
a.与SCWS相关联的OP可以显示本地认证页面
b.用户可以输入其认证证书，例如用户名和密码
c.与SCWS相关联的OP可以核认证书
695：与SCWS相关联的OP有可能需要使用已经在OPSF与RP之间共享的秘密来对返回消息进行签名，并且可以应用以下若干个选项：
a.选项1：
i.该秘密有可能已经存在，例如由OPSF预先共享和预先配备
b.选项2：
i.OPSF可以向与SCWS相关联的OP发送关联句柄和和秘密，例如经由安全的SMS来发送，或者通过由GBA来引导，和/或使用安全的通信协议，例如SCWSHTTPS远程管理接口
ii.与SCWS相关联的OP可以存储秘密和关联句柄
c.选项3：
i.与SCWS相关联的OP可以通过使用从RP接收的关联句柄来从OPSF那里请求秘密。用于该消息的协议可以借助SMS运行，此外，其他选项也是可行的，其可行性有待进一步研究
ii.OPSF可以基于关联句柄来执行秘密查找
iii.OPSF可以将秘密和关联句柄发送到与SCWS相关联的OP，例如经由安全的SMS-PP发送、或者由GBA引导、和/或使用安全的通信协议，例如SCWSHTTPS远程管理接口
700：与SCWS相关联的OP可以使用秘密来计算return_toURL、标识以及模式参数上的签名
705：与SCWS相关联的OP可以将签名作为附加参数包含在HTTP重定向中
710：与SCWS相关联的OP可以向浏览器发送HTTP重定向消息，该HTTP重定向消息包含下列参数：
openid.mode=id_res,
openid.return_to=http://rp.org/return.cgi?session=User&nonce=123123,
openid.identity=http://op.org/identity,
openid.signed=mode,identity,return_to,
openid.assoc_handle=‘associationhandle’,
openid.sig=‘base64encodedsignature（基本64位编码的签名）’
715：浏览器可以在不需要进一步用户参与的情况下将用户重定向到RP上的return_toURL
720：RP可以接收被签名的断言消息
725：RP可以使用预先建立的共享秘密来核验签名
730：对于RP来说，用户可被标识为http://op.org/identity
735：浏览器可以显示RP的HTML页
740：用户可被作为http://op.org/identity登录到RP
基于关联的模式的附加实施方式
附加实施方式可以基于那些将附加实施方式用于第4.4.1.4.3节的无状态协议的实施方式。
4.4.2用于SCWS上的OP改进的实施方式
4.4.2.1关于改进的一般方法
在第4.4.1节的示例实施方式中，可以关联于SCWS的本地OP以及OPSF有可能需要为每一个RP至少建立一次用于断言签名及其核验的共享秘密。但是，还可以应用其他方法，其中该协议是进一步通过使用附加密码手段改进的，该手段允许在OPSF与本地OP之间只建立一个（长期）共享秘密，然后使用密码函数来导出用于该签名的秘密。此外，OPSF与本地OP之间的秘密交换处理的集成可以在协议消息内部执行。
4.4.2.2关于改进的背景技术信息
以下章节提供的是可能的实施和实施方式的更多技术背景。
SCWS可以使用基于IP的方法或传统UICC方法来与手持机进行安全通信，并且间接地与外界各方进行安全通信；UICC应用的拥有方可以将这些应用下载到UICC，并且对其进行远程管理。
就UICC上的资源的使用情况而言，可以注意到的是，能够支持全球平台、SCWS以及后续IP栈的UICC很有可能支持大容量存储器和USB。这种UICC可以具有足够强大的处理器，并且O/S将会承担资源管理。
在图24中的575处（无状态模式）以及图25中的695处（关联模式），与SCWS相关联的OP可以存储和使用秘密。例如，通过执行该处理，可以将签名密钥保持在其永不丢弃的受保护的存储器中，并且该密钥只供卡本身的密码算法使用。该密钥可以是某个能与另一（可信）方（类似于MNO）安全共享并被保证不会离开智能卡的密钥。对于所下载的小应用程序中的应用特定签名密钥而言，我们需要考虑四个问题：（1）密钥如何进入UICC以及进入小应用程序，（2）如何保持密钥安全性，（3）谁可以使用密钥，以及（4）可以如何更新密钥。
在一个示例实施方式中（对于问题（1）的回答），专用于UICC上的OP的密钥可以作为小应用程序的可执行加载文件的一部分加载，并且可以驻留在小应用程序的指定密钥文件中。该应用下载可以不使用SCWS管理更新处理。但是，SCWS可以调用智能卡应用（意味着任何应用，而不只是SCWS网页）。这意味着本地OP可能是在全球平台框架中运行的小应用程序。对这种复杂的小应用程序来说（它不仅仅是SCWSHTML页面），较为有利的是使用全球平台小应用程序加载过程。
在另一个示例实施方式中（对于问题（2）的回答），属于任何已加载应用的秘密均由UICC的O/S保护。我们可以依靠O/S来实施该处理。UICC加载的程序运行时所在的存储器受O/S保护。
在另一个示例实施方式中（对于问题（3）的回答），举例来说，本地OP可以使用（专用）签名密钥来对一些数据进行签名（或解密/加密）。任何能够经由SCWS来与UICC上的本地OP进行通信的外部实体都可以为小应用程序提供数据，以便执行签名或解密，但是针对SCWS的这种通信有可能必须作为重定向经由终端浏览器进行。对于共享密钥来说，可以由OP之类的密钥所有者来将这类密钥分发给MNO之类的TTP，以使它们可以在与UICC的交互中使用这些密钥。
如果在与SCWS相关联的OP中使用了密钥文件来存储密钥，那么可以使用标准化的小应用程序更新处理来更新密钥文件。如果使用了SCWS管理更新处理，那么该处理可以由SCWS更新处理的所有者完成（假设是MNO）。此外，使用在卡上密钥生成的处理作为替换方案也是可行的。
SCWS提供了BIP/CAT通信以及经由USB的TCP/IP/HTPP。在后一种情况中，在设备与SCWS之间可以使用TLS（基于PSK或PKI）。
在另一个示例实施方式中，OP服务器应用可以作为JavaCard小应用程序而被加载到UICC上，随后则以2006年3月发布的第2.2版的全球平台卡规范中规定的方式来对其进行管理。所述小应用程序可以位于卡发布者（CI）的安全域（SD）或是应用供应方的（AP）SD中，即便这两个域实际由同一方即MNO/CI拥有也是如此。作为替换，OP应用可以是固件或本地应用。
OMA可以为SCWS的内容和设置提供安全处理，其中所述内容和设置是由远程服务器应用使用针对SCWS且经过相互认证的HTTPS来更新的。例如，该处理是为了供作为卡发布方的MNO使用而被执行的，因此是围绕用于传输的传统OTA设计的。该特征并不用于下载那些与SCWS相关联的应用，而是用于更新此类应用（仅仅供MNO使用）。
SCWS可以使用传统的工具箱和OTA技术（其SMS-PP被默认是无处不在的）。因此，如果UICC没有自己的IP地址，那么SCWS描述的是将CAT/BIP用于UICC/ME连接，以便从客户机浏览SCWS上的网页，以及从管理实体传送和管理SCWS上的网页。同样，SCWS还可以支持用于来自远程管理员的消息的级联SMS-PP。但是，如果UICC具有自己的地址，那么SCWS还可以支持处于UICC高速（即USB）接口之上的直接TCP/IP连接，以便从客户机浏览网页，以及通过直接TCP/IP连接上的直接TLS连接来从管理实体传送和管理SCWS上的网页。
4.4.2.3关于SCWS上的改进OP的介绍
以下实施方式描述的是SCWS上的OP的概念的改进变体。SCWS上的OP可以是对OpenID/GBA的改进。例如，这些实施方式可以提供以下优点：
·SCWS上的OP可以使认证处理处于设备本地，并且由此显著降低通信成本，从而改进OpenID/GBA。
·关于SCWS上的OP的进一步改进可以在OP与网络端实体之间通过在标准的OpenID消息字段内部传递认证秘密来进行。这样做可以进一步减小通信开销，并且可以缓解SCWS上的OP与网络实体（OPSF）之间的关系，这样则能够在网络之间迁移OpenID。
此外，以下实施方式可以允许SCWS上的OP为网络运营商产生以下主要优点，例如：
·在移动网络上没有认证业务
·认证业务在公共因特网上
·所有应用数据业务都在移动网络上
4.4.2.4本地OP所做的改进
在示例实施方式中，本地认证可以是对与SCWS相关联的OP执行的，由此显著地减少业务。例如，通过执行该处理，可以将认证业务本地化，从而减小网络本身的负担。在一个示例实施方式中，在网络OPSF实体与关联于SCWS的OP之间可以为用户访问的每个RP建立共享秘密。在这里描述了若干种用于建立这种秘密的机制。例如，在一个示例实施方式中，如果RP使用关联，那么它们可以存储用于签名核验的秘密，并且可以在用户下一次对其进行访问的时候重新使用该秘密。在另一个示例实施方式中，如果RP使用无状态模式，那么RP不能保存该秘密。OP可以创建秘密，并且可以与OPSF安全地共享该秘密。与SCWS相关联的OP可以存储该秘密，并且可以在用户下一次访问相同RP的时候重新使用该秘密，OPSF也可以存储相同的秘密，由此OPSF可以在无状态模式中将其直接用于签名核验。
在另一个示例实施方式中，在某种程度上，在OSPF与关联于SCWS的OP之间共享过一次的秘密是可以被重新使用的。例如，如果在智能卡上可以为OP保存总共5个秘密，那么可以在用户每次访问RP时重新使用这些秘密。举例来说，与在3GPPTR33.924中规定的OpenID/GBA相比，通过执行该处理，可以极大地减小网络业务。例如，日常业务可以缩减一半，如果考虑的是数天，那么由于可以重新使用秘密，因此缩减量甚至会变得更大。
所提到的秘密可以不同于在OpenID/GBA中使用的秘密，在OPSF与关联于SCWS的OP之间共享的秘密是用于对断言消息进行签名的OpenID秘密。与标准的OpenID协议过程中一样，这些秘密是可以与RP共享的，并且是可以作为寿命较长的秘密来建立的，例如，所述秘密比单个登录会话持续的时间更长，由此基本上是允许这种重新使用的。
4.4.2.5更进一步的改进
在一个用于实施SCWS上的OP的协议流程的示例实施方式中，MNO运行的OPSF网络实体可以参与到与关联于设备上的SCWS的OP进行的附加通信中。由于这两个实体都必须配备相同的对称密钥，以使每一个RP对断言消息进行签名或者分别对其进行核验，因此，该通信是必需的。
通过进一步改进这些实施方式，可以极大地减少设备与网络之间的附加通信，以及将建立秘密所必需的信息直接封装到OpenID消息的协议字段中。这些消息是作为HTTP消息经由公共因特网发送的，它们有可能对MNO的空中网络基础架构造成额外负担。例如，通过执行该处理，可以确保认证业务处于本地，也就是介于浏览器与设备中的UICC/SCWS之间，由此可以防止不使用网络。由于将通信从（空中）网络卸载到了设备内部的内部通信上，因此，这种处理能够减少一般的业务。
通过确保在MNO与UICC/设备之间不必执行用于认证的附加信令业务，可以给出对这些实施方式所做的另一个改进。例如，对于每一个认证来说可能没有GBA过程（run），或者在网络与设备之间不会经由空中接口来发送SMS/MMS或控制消息。所有必要的信息都可以在HTTP消息内部直接传送，其中所述HTTP消息可以部分借助空中网络并通过因特网（设备到RP）、而且部分通过固定线路的公共因特网（RP到MNO）被传送。但是该业务可以1）由希望使用OpenID登录的用户触发，2）经由现有数据平面而向用户收费，3）比基于网络的OpenID少，并且比在OpenID/GBA中少。
4.4.2.4关于协议改进的技术细节
4.4.2.4.1命名规则
在这里将会重复如上所述的相同命名规则以供参考：
·与SCWS相关联的OP：本地OpenID标识供应方，其发布被签名的断言消息，并且将这些消息通过用户浏览器发送到RP。假设存放SCWS的智能卡乃至OP与MNO具有关系，并且由此与所有关联于MNO的实体具有关系。
·RP：依赖方，它可以是任何使用OpenID来为用户提供登录的网站。RP完全独立于所有其他实体，因此，在RP上不能施加附加需求，并且不能改动RP的OpenID协议流程。OP必须支持RP选择使用的任意通信模式（无状态或基于关联）。如果MNO决定用户不应该使用某些RP，那么由于用户还可以使用别的标识，因此，MNO不能通过拒绝对于这些RP的OpenID访问来拒绝对于这些站点的访问。MNO只能使用附加装置来限制对于RP的访问，其中所述附加装置通常阻止的是对消耗带宽的站点进行的访问。
·OP-Agg：OP-Agg实施的是依照OpenID协议来为RP提供发现服务的网络实体。
·OPSF：OP服务功能（OPSF）实施的是能与关联于SCWS的OP并且可选地与来自（RSCWS-1）的RP产生、共享和分布秘密的支持OP功能。从RP的角度来看，OPSF和关联于SCWS的OP的行为就好像它们是单个实体。OPSF能够核验与SCWS相关联的OP发布的签名，并且可以由RP经由公共因特网直接到达。通过修改设备上的本地DNS解析缓存，可以将设备上的浏览器重定向到与SCWS相关联的OP，以使OPSF的地址映射到与SCWS相关联的本地OP。
关于该实体OPSF的需求及其必要功能是如上在先前文档“OPonSCWSspecificationdraft（SCWS上的OP规范草案）”中精确描述的。
·浏览器：在协议流程图中显示，以便明确往来于与SCWS相关联的OP的路由和消息传递功能。否则，它只是显示和接收用户认证的前端。
4.4.2.4.2关于实施方式的可能假设
关联于SCWS的OP和OPSF功能可以建立长期秘密K，该长期秘密K由智能卡的安全特性保护，并且只能被与SCWS相关联的OP访问。例如，该秘密既可以借助单个GBA过程建立，也可以用另一个允许从AKA密钥中推导出密钥的密钥推导功能建立，还可以用其他任何在MNO与关联于SCWS的OP之间产生共享秘密的方法来建立，其中所述共享秘密可以由UICC的安全特征来保护。此外，建立秘密的处理可以使用本领域中已知的任何方法来进行。
智能卡也可以提供密码功能（算法和计算），以便计算从K中得到的新秘密。该功能的具体属性可以从安全需求描述中得到。相同或相似的功能也可以为OPSF所知，这样可以允许OPSF从K中推导出密钥。
这两个实体都能为密码操作产生足够长的随机值。
4.4.2.4.3协议流程描述
以下章节描述的是用于实施与SCWS相关联的OP的协议流程的示例实施。
4.4.2.4.3.1使用无状态模式的RP的协议流程的示例实施方式
如果RP使用无状态模式来执行OpenID用户认证，则可以应用图26描述的实施方式。
4.4.2.4.3.1.1关于无状态模式的描述
图26示出的是改进的无状态模式的协议流程的示例实施方式。
745：用户可以访问RP网址，并且为了使用OpenID登录，他输入了他的OpenID标识符，例如http://op.org/identity
750：浏览器可以向RP网址发送包含OpenID标识符的HTTP消息。
755：RP可以使用基于HTTP/HTML的OpenID‘简单’发现处理，并且经由公共因特网来与OP-agg取得联系，以便在标识页面上检索OpenID标识符，例如HTTP获取http://op.org/identity。
760：OP-agg可以接收请求，并且可以使用包含OPSF因特网地址的HTML页面来做出响应。例如，OP-agg可以通过包含以下地址来做出响应：
<linkrel=“openid.server”href＝http://op.org/server.cgi>
OPSF可以像标准的OpenID标识供应方网络服务那样对RP进行操作。例如，OPSF能够按照RP的请求来核验断言消息上的签名（由本地OP发布）。根据需求，OPSF必须可以经由公共因特网到达，由此假设该OPSF具有DNS名称，例如可以经由http://op.org到达的op.org。由于外界不知道智能卡的IP地址，因此，OP-agg和OPSF的这种间接性可被用于通信。
OPSF的地址可以不同于OP-agg的地址。
765：RP可以接收OPSF的地址，并且创建现时和会话标识符，例如nonce=123123，session=User。RP可以编译return_to参数，所述参数会向OP告知应该在用户认证之后将浏览器重定向到哪一个URL。RP可以通过发布包含下列参数的HTTP重定向来将浏览器重定向到OP服务器地址：
openid.mode=checkid_setup,
openid.identity=http://op.org/identity,
openid.return_to=http://rp.org/return.cgi?session=User&nonce=123123
770：浏览器可以接收所述重定向，并且可以开放与RP在重定向消息中规定的URL的连接
775：借助于经过修改而将OPSF的URL映射到SCWS本地IP地址的DNS查找表，例如通过使用具有项http://op.org==127.0.0.1的主机文件，浏览器可被重定向到与SCWS相关联的本地OP，并且发布包含了765处的参数的HTTP请求。
在设备上可以使用经过修改的本地DNS查找表，以使所述设备认为URLhttp://op.org在SCWS的本地IP地址处。浏览器可以开放与SCWS/本地OP的连接，而不是连接到OPSF（所述OPSF可以经由公共因特网而在URLhttp://op.org可到达）。
780：通过执行下列处理，可以确保认证业务保持在本地，这些步骤并不是OpenID协议规范必需或规定的：
a.与SCWS相关联的OP可以显示本地认证页面
b.用户可以输入其认证证书，例如用户名和密码
c.与SCWS相关联的OP可以核认证书
785：与SCWS相关联的OP可以创建唯一的随机关联句柄A。通过使用函数f，可以使用S=f(A,K)来计算断言消息的签名秘密，其中所述f应该是单向的，由此对于A的认识不会展现任何对于K的认识。在一个示例实施方式中，即便展现了S和A，也就是给出了S和A，f也不会展现任何关于K的认识，在计算方面，为函数g计算K=g(S,K)是不可行的。
由于可以将A作为重定向消息中的参数的一部分展现给RP，因此可以假设RP不会在OpenID协议过程的无状态模式中获得对于S的认识。关联句柄A可以包含在重定向消息中。此外还可以假设，用S签名了的被签名的消息m不会向签名核验器展现任何关于K的信息（由于使用了对称密钥签名，因此签名核验器始终需要拥有S来核验签名，由此我们不要求该签名不展现S）。
在这里可以规定关联句柄是长为255个字符或更少的字串，并且可以只包括处于闭区间33-126中的ASCII字符（可打印的非空白字符）。
OPSF用于核验签名的秘密与关联于SCWS的OP用于产生签名的秘密可以是相同的。签名的新鲜度可以由下一个步骤中插入的RP现时来确保，并且该RP现时必须是签名的一部分。OpenID规范对签名秘密本身的新鲜度保持默认。OP负责确保秘密的密码强度，保持其秘密性，以及在需要时确保其新鲜度。OPSF和关联于SCWS的OP可以持续有限寿命或是用于对该目的签名秘密的使用计数。
启用工具箱的本地OP可以使用CAT来主动与手持机通信，同时绕过SCWS。该消息可以依照标准的OTA（例如用于经由SMS-PP承载来发送到OPSF的OTA）而被格式化。但是，这种处理有可能需要OPSF经由MNO的OTA系统来与所述卡进行通信。在另一个示例实施方式中，BIP网关可以提取工具箱消息有效载荷，并且手持机可以使用TCP/IP将其发送到OPSF。这就有可能要求消息经由MNO的OTA服务器而被传送。SCWS声称只有在所述卡不具有IP地址并且不支持TCP/IP的情况下才可以使用BIP。因此，期望的是通过使用TCP/IP经由SCWS进行发送。
d.可以应用进一步的选项，这些选项有可能在关联于SCWS的OP与OPSF之间产生共享秘密。这种方法的可行性有待下一步研究。
790：与SCWS相关联的OP可以计算下列参数上的签名：return_to、标识以及模式。
795：与SCWS相关联的OP可以向浏览器发送HTTP重定向消息，该消息包括在765处从RP接收到的参数。此外还可以包括下列各项：
·openid.signed参数中的一系列被签名的参数
·openid.assochandle参数中的关联句柄A
·openid.sig参数中的签名（经过base64编码）。
该消息可以用于将浏览器重定向到RP处的return_toURL。
800：浏览器可以将用户重定向到RP处的return_toURL。
805：RP可以接收被签名的断言消息，并且在经由公共因特网且基于HTTP（S）的直接通信中加入到与OPSF的核验过程中。
810：RP可以发布HTTP传递消息，该HTTP传递消息包含了在795处从与SCWS相关联的OP接收的参数。HTTP传递消息可以包括由与SCWS相关联的OP产生的关联句柄A。
815：OPSF可以从参数列表中提取A，并且可以与关联于SCWS的OP使用具有相同输入的相同函数f，也就是说，OPSF计算f(A,K)=S，并且使用S作为共享秘密来核验从与SCWS相关联的OP接收的数据上的签名。
820：如果签名核验成功，则OPSF可以返回is_valid:真。
825：对RP来说，现在可以将用户标识为http://op.org/identity。
830：浏览器可以显示RP的HTML页面。
835：用户可以作为http://op.org/identity而在RP上登录
4.4.2.4.3.2使用了基于关联的模式的RP的协议流程
图27示出的是用于改进的基于关联的模式的协议流程的示例实施方式。例如，该处理可以在RP使用基于关联的模式执行OpenID用户认证的时候执行。该关联可以在用户首次与RP进行联系并将其OpenID标识符与该RP结合使用之后发生。如果建立了关联，那么可以重新使用该关联，以便进一步减少通信工作。但是，OP可能不能够要求RP的工作模式，并且有可能是由RP来决定两种通信模式之一。
该关联可以在RP与OP之间建立永久性秘密，并且RP可以使用该秘密来对断言消息进行签名，此外，RP还可以使用该秘密来核验OP签名。OP可以决定共享秘密的有效期。RP和OP可以使用关联句柄作为该秘密的标识符。该RP将关联句柄包含在去往OP的第一请求消息中，然后，OP可以根据关联句柄来使用相应秘密。如果OP确定该关联已经到期，那么OP可以在响应消息中通知RP。这样做可以允许OP拒绝任何关联请求。只要RP能够支持无状态模式，则可以使用该处理来迫使RP退回到无状态通信模式。例如，如果OP不支持RP请求的签名模式（HMAC-SHA1或HMAC-SHA256），那么OP可以拒绝关联请求。
与用户每次登录RP时都可以在RP与OP之间建立新秘密的无状态通信模式相反，每一个标识和RP都会建立一次关联。例如，并不是图27所示的所有项都可以在用户登录的时候执行。如果在OP与RP之间已建立了关联，那么被RP和OP可以重新使用该关联。
一旦知道了OPSF地址，也就是在发现阶段之后，RP可以建立关联，并且在继续执行协议之前，也就是在将关联句柄包含到重定向消息中之前，该RP可以完成所述关联。
如图27所示：
840：用户可以访问RP网址，并且为了使用OpenID进行登录，他可以输入他的OpenID标识符，例如http://op.org/identity。
845：浏览器可以向RP网址发送包含OpenID标识符的HTTP消息。
850：RP可以使用基于HTTP/HTML的OpenID‘简单’发现处理，并且可以经由公共因特网来与OP-agg取得联系，以便在标识页面上检索OpenID标识符，例如HTTP获取http://op.org/identity。
855：OP-agg可以接收该请求，并且使用包含OPSF地址的HTML页面来做出响应，例如，OP-agg可以通过包含下列各项来做出响应：
<linkrel=“openid.server”href＝http://op.org/server.cgi>
OPSF的地址可以不同于OP-agg的地址。
860：RP可以使用带有下列参数且针对OPSF的HTTP传递调用：
openid.mode=associate,
openid.assoc_type=HMAC-SHA1,
openid.session_type=blank,
openid.dh*=‘Diffie-HellmanParameters’
865：OPSF可以为RP产生唯一的随机关联句柄A。另外，OPSF可以使用函数f，并且计算S=f(A,K)。然后，S可被用作RP与OPSF之间的关联（中期）共享秘密。该RP稍后可以使用S核验来自与SCWS相关联的OP的断言消息上的签名。在一个示例实施方式中，由于可以在870处与RP共享A和S，因此，即便A和S是已知的，也可以假设f是保持单向的函数，由此不能在给出S和A的情况下计算出K。函数f本身可以不需要保密。
870：OPSF可以使用HTTP传递来对RP做出响应，该HTTP传递将关联句柄A和秘密S（如果使用了Diffie-Hellman，则该秘密是经过加密的）包含在密钥=数值格式化文档中。每一个RP和OpenID标识都可以建立一次这种关联。
880：RP可以创造会话现时和会话标识符，例如
nonce=123123,
session=User
885：RP可以存储从OPSF接收到的秘密S以及关联句柄A。
890：RP可以将关联句柄A包含在重定向消息中。
895：RP可以向浏览器发送HTTP重定向消息。该HTTP重定向消息可以包括下列参数：
openid.mode=checkid_setup,
openid.identity=http://op.org/identity,
openid.return_to=http://rp.org/return.cgi?session=User&nonce=123123,
openid.assoc_handle=A
900：浏览器可以接收重定向消息，并且可以开放与RP在重定向消息中规定的URL的连接
借助于经过修改而将OPSF的URL映射到SCWS的本地IP地址的DNS查找表，例如通过使用具有项http://op.org==127.0.0.1的主机文件，浏览器可被重定向到与SCWS相关联的本地OP，并且可以发布包含了来自885的参数的HTTP请求。
在设备上可以使用经过修改的本地DNS查找表，而这会让所述设备认为URLhttp://op.org位于SCWS的本地IP地址。
905：浏览器可以开放与SCWS/本地OP的连接，而不是连接到OPSF（所述OPSF可以经由公共因特网而在URLhttp://op.org处可到达）。
910：通过执行下列处理，可以确保认证业务保持在本地，这些步骤并不是OpenID协议规范必需或规定的：
a.与SCWS相关联的OP显示本地认证页面
b.用户输入其认证证书，例如用户名和密码
c.与SCWS相关联的OP核认证书
915：与SCWS相关联的OP有可能需要使用能在OPSF与RP之间共享的秘密S来对返回消息进行签名。参数A可以是从接收到的HTTP请求中提取的，并且在这里可以应用函数f，以使S=f(A,K)。
920：与SCWS相关联的OP可以使用秘密S来计算return_toURL、标识以及模式参数上的签名。我们有可能需要函数f在给出了用S签名的被签名的消息m的情况下，不向m上的签名的核验器展现任何关于K的信息。
925：与SCWS相关联的OP可以将签名作为附加参数包含在HTTP重定向中。
930：与SCWS相关联的OP可以向浏览器发送HTTP重定向消息，该消息可以包括以下参数：
openid.mode=id_res,
openid.return_to=http://rp.org/return.cgi?session=User&nonce=123123,
openid.identity=http://op.org/identity,
openid.signed=mode,identity,return_to,
openid.assoc_handle=A,
openid.sig=‘base64encodedsignaturecalculatedusingS’
935：浏览器可以在不需要进一步的用户参与的情况下将用户重定向到RP处的return_toURL。
940：RP可以接收被签名的断言消息。
945：RP可以使用所确定的共享秘密S来核验签名。
950：对RP来说，现在可以将用户标识为http://op.org/identity。
955：浏览器可以显示RP的HTML页面。
960：用户可以作为http://op.org/identity在RP上登录。基于关联的模式的附加实施方式
以下公开的是与在第4.4.1.4.3节中描述的无状态协议的实施相关的附加实施方式。
4.4.2.5改进的SWCS上的OP与现有OpenID/GBA之间的比较
在OpenID/GBA中，用户使用GBA协议进行认证，也就是为在任何RP处的每一次OpenID登录尝试都会触发使用了经由空中接口的OP/NAF的GBA过程，从而由于业务的增长而对网络实体（OP/NAF）和网络本身造成负担。假设在给出了数量为10,000名用户的客户基础的情况下，每一个用户每天登录到10个不同的RP。依照OpenID/GBA，这会导致每天总共执行100,000个GBA认证过程；如果每一个GBA过程（质询+响应）只消耗1-5kB，那么每天总共会有1-4.8GB的附加认证业务。
4.4.2.6安全性论述
下节提供的是可以在用于无状态和基于关联的模式的SCWS上的OP协议的示例实施方式中使用的密码工具的背景。在这里论述了诸如可以使用的散列算法之类的特性。
4.4.2.6.1概括
函数f可以用于在本地OP与OPSF之间建立共享秘密S。OPSF和本地OP可以具有公共共享长期秘密K，该秘密可以作为f的一个输入使用，并且所述K永不会被泄露给协议中的另一方。但是，在基于关联的模式中，由于RP可能会核验断言消息上的签名，因此有可能将秘密S泄露给RP。由于共享秘密有可能具有安全性含义，因此有必要论述所述RP在了解S的情况下具有的选项。
该处理同样适用于标准的OpenID协议。假设RP是恶意的，那么对于S的认识不能允许该RP在另一个RP上登录用户，这是因为另一个RP将会与OP建立另一个共享秘密S'，由此会将使用S产生的签名认定为无效。因此，将秘密展现给RP未必是安全问题。但是，将S展现给浏览器（或用户）有可能会成为安全问题。在这种情况下，攻击者可以使用受害人的OpenID标识符来启动OpenID协议。如果攻击者可以检索到在RP与OP之间共享的共享秘密S，那么攻击者可以在没有对OP执行实际认证的情况下使用S来对断言消息进行签名。因此，攻击者可以使用受害人的标识符进行登录，而不用在受害人的OP上进行认证。从这种情况中可以看出，RP与OP之间的共享秘密S是不能展现给浏览器的，但是将S暴露给RP则是可以的。
如果恶意用户与RP一起工作，那RP有可能将S发送给浏览器，用户则有可能会在没有在RP上进行认证的情况下登录到RP。但是，由于用户只能登录到单个RP，并且依照假设，该RP已经受其控制（或者至少与该用户协作），因此，这种情况未必会被认为是攻击。由此，即便根本没有执行OpenID认证协议过程，用户也是可以登录的。
4.4.2.6.2示例协议的安全性特征
在一些示例实施方式中，在重定向消息中有可能将A以及使用S签名的消息泄露给浏览器，如果获悉了A和使用S签名的消息，那么可能是无法计算出S的。此外，在给出了相同输入的情况下也是无法计算出K的。
在给出了A和S（可能泄露给除OP和OPSF之外的单个第三方的最多的信息）的情况下，如果所需要的是无法通过计算来得出K（也就是说，假设没有函数f-1来使得f-1(A,S)=K，这可以在以输入为长度的时间多项式中计算），那么没有RP可以得出OPSF与关联于SCWS的OP之间的长期共享秘密K。
由此，在给出了随机输入A和共享秘密K的情况下，有必要由f来产生新的秘密S，以使得S=f(A,K)。在给出了A（以及使用S签名的消息）的情况下，这时是不能计算出S的。如果输入K是正确和存在的，那么有可能要求f可以产生正确的结果。
在多项式时间中有可能可以对f进行计算，并且所述计算优选是在智能卡的受保护区域中进行的。
S可以是在OpenID中使用的签名函数的有效输入。OpenID事先知道使用HMAC-SHA1或HMAC-SHA256作为签名算法。由于OPSF和关联于SCWS的OP有可能预先就具体的签名算法、密钥长度达成一致，因此，函数f的输出长度可以是固定的。在一个示例实施方式中，OPSF和OP可以使用两个共享秘密K和K’，由此可以使用K来为基于SHA1的签名推导出S，并且使用K’来为SHA256签名推导出S。
4.4.2.6.3安全性的实现
本节描述的实施方式是可以满足前一节中指出的需求的密码操作。在一个示例实施方式中，秘密可以直接包含在OpenID消息内部，而这可能会导致认证需要的业务减少。用户认证可以在本地执行（不涉及MNO网络），并且在OpenID协议消息内部可以安全地传递OPSF（MNO网络）与关联于SCWS的OP（在设备中）之间的共享秘密，而不需要在MNO网络与设备之间进行进一步的外部附加通信。
4.4.2.6.3.1HMAC
HMAC是在不使用任何附加机制的情况下认证消息来源及其完整性的键入式散列消息认证码（MAC）。HMAC具有两个功能不同的参数，即消息输入以及仅仅为消息发起方和一个或多个预定接收方所知的密钥。
消息发送方使用HMAC功能来产生通过压缩密钥和消息输入而形成的值（MAC）。MAC通常是与消息一起发送给消息接收方的。接收机使用与发送方使用的密钥和HMAC函数相同的密钥和HMAC函数来计算接收消息上的MAC，并且将计算结果与接收到的MAC进行比较。如果这两个值匹配，则消息已经被正确接收，并且接收方确信发送方是共享密钥的用户团体中的成员。
在给出了HMAC属性的情况下，通过将HMAC用于函数f，可以满足如上所述的所有相关需求。
用于HMAC的相关参数列表：
·B——散列函数输入的块大小，例如用于SHA1的160比特
·H——散列函数（例如SHA1）
·ipad——内部填充符，重复B次的字节x'36'
·K——在OP与OPSF之间共享的密钥
·K0——预处理之后用于获取B字节密钥的密钥K
·L——散列函数的输出块大小，例如用于SHA1的160比特
·opad——外部填充，重复B次的字节x'5c'
·t—MAC字节的数量
·text（文本）——用于从n比特的长度中计算HMAC的明文，其中0<=n<2^B-8B，在我们的范例中将会是A
·||——级联
·XOR——异或
·K应该等于或大于L/2，也就是说，对我们的范例而言，如果使用SHA1，那么K应该大于80比特，或者如果使用SHA256，则应该大于128比特。
·MAC(text)=HMAC(K,text)=H((K0XORopad)||H((K0XORipad)||text))
为了防止攻击，有可能需要通过嵌套执行两个散列函数来计算MAC。结合大多数的散列函数，有可能在不知道密钥K的情况下在消息中增添附加数据，并且可以获取另一个有效MAC。如果使用其他替换方案，那么通过使用MAC=H(message∥key)来添加密钥，可以允许发现（非键入式的）散列函数中的冲突的攻击者得到MAC中的冲突。使用MAC=H(key|message||key)会更好，但是，即便使用两个不同的密钥，不同的安全文件也会展现弱点。
图28示出的是来自NIST-FIPSPUB198-1的键入式散列消息认证码（HMAC）。
由于外部散列函数遮蔽了内部散列的中间结果，因此，当前协定的HMAC版本并未暴露这些弱点。对算法的安全性而言，填充值（ipad和opad）并不重要，但是其被定义成彼此具有很大的汉明距离，因此，内部和外部密钥将具有较少量共同比特，也就是说，通过使用这些填充符，可以从K0中“推导出”两个不同的密钥，以便在散列函数中使用。
在一个示例实施方式中，作为随机输入的text=A可以由OP或OPSF分别产生。A可以包含在重定向消息中，并且通过使用K，这二者可以使用上述机制来重新计算HMAC，所述HMAC结果可以作为共享签名秘密S而被用于OpenID断言消息。
4.4.2.6.3.2关于改进的SCWS上的OP协议的安全性证明
需要显示的是：
1．在协议中，攻击者能够检索A和S（例如作为处于关联模式的RP），因此有必要显示他无法检索K。
2．浏览器/用户进行的检索甚至少于RP，也就是只检索A，并且必须不能从对于A的认识中计算出S。
3．浏览器/用户还必须不能从A中计算出K。
当模拟一个了解S和A的攻击者时，其中该攻击者并未使用在S上给出的信息，关于3.的证明可以从1.中推导得到。
由此必须显示的是：
I．如果给出了S和A，那么应该没有函数f*，以便在S=f(A,K)的情况下使得K=f*(A,S)
II．如果只给出了A，那么必定没有函数g能使得在S=f(A,K）的情况下满足S=g(A)。
在Bellare（贝莱尔）等人提供的关于HMAC（或NMAC）的描述中可以找到关于以上两个定理的证明，其中在（11）中，它们本质上显示的是，如果假设基本压缩散列函数是伪随机的，并且散列函数对冲突的抵抗力很弱，那么HMAC是伪随机函数。在（12）中，依照压缩函数是PRF的唯一假设，这些假设可以通过显示HMAC是PRF来加以缓解。
4.4.2.6.3.3RSA
在一个示例实施方式中，通过使用必须在OPSF与关联于SCWS的OP之间共享的私钥来加密随机创建的唯一关联句柄，可以使用RSA加密方案来从共享密钥K中推导OpenID签名秘密S。假设N=pq表示的是用于RSA方案的模数，其中p，q是素数。更进一步，密钥对是用e，d（私有，公共）表示的，并且是作为长期秘密K共享的。然后，关联句柄A用私有部分e进行签名，以便获取签名秘密S，也就是说，S=Ae模N。在为RSA给出了安全性假设的情况下，如果公钥d是已知的，则可以从S中计算出A，但是不能在给定了A和S的情况下计算出e。如果只给出了A，那么无法在不了解e的情况下计算出S。
4.4.2.6.4安全性实施变体
4.4.2.6.4.1长期秘密K的改变
在第4.4.2节描述的一个示例实施方式中，虽然使用了长期秘密K，但是举例来说，在某个时段之后，通过在OSPF与关联于SCWS的OP之间使用密钥交换方法，可以改变该秘密K。任何已知的密钥交换方法都是可以使用的。
K的改变可以在OPSF上执行，并且与SCWS相关联的OP不能阻止成功的OpenID协议过程。
在一个示例实施方式中，如果OPSF和OP在无状态模式中商定新的长期秘密K’，那么OP可以通过将函数f与新的密钥结合使用来计算签名密钥S’，即S’=f(A,K’)。然后，S’可被用于对断言消息进行签名，并且OPSF可以使用新的长期共享秘密K’来重新计算S’，从而核验断言消息上的签名。
在另一个示例实施方式中，如果在基于关联的模式中建立了新的秘密长期秘密K'，那么RP仍旧可以保持用于所述关联的旧秘密S。如果关联仍旧有效，并且RP没有加入与OPSF的关联步骤，那么RP有可能直接使用旧的关联句柄A，并且有可能预期来自OP且用已存储秘密S签名的断言消息。但是，OpenID规范允许OP将参数openid.invalidate（无效）handle包含在断言消息中。如果使用该参数并将其设置成旧的关联句柄A，那么RP会被迫返回到OP，以便像在无状态方案中那样执行签名核验。这样做可以允许与SCWS相关联的OP包含这个对新的长期共享秘密K’而言被设置成A的参数、以及使用了新创建的关联句柄A’的新签名秘密S’=f(A’,K’)。这样做有可能会使得RP上的句柄无效，并且RP可以与OPSF进行联系，以便实施签名核验。由于所述密钥交换，OPSF有可能已经具有K’，由此可以计算S’=f(A’,K’)，并且可以核验断言消息上的签名。但是，如果RP加入与OPSF相关联的新会话，那么OPSF也有可能使得句柄A无效，并且可以与RP使用新密钥K’来建立新配对A’,S’。
4.4.2.6.4.2用于K的散列链保证
在一个示例实施方式中，OPSF和关联于SCWS的OP有可能希望定期改变长期秘密K。基于该秘密K，这两个实体可以通过将（用密码保护的）散列函数h连续应用于K来执行散列链保证，由此将会产生一个链条：K0=h(K)，K1=h(K0)=h(h(K))，……，Kn=h(Kn-1)=hn(K)。如果可以安全建立初始秘密K，那么OP和OPSF可以独立计算该链条。然后，所使用的第一共享秘密可以是Kn。如果用于构建散列链的散列函数具有单向属性，那么所述值不会允许攻击者直接计算后续共享秘密Kn-1。攻击者不得不反转散列函数，以便推导出下一个秘密。这些秘密是由OPSF和本地OP以散列链的相反顺序使用的。为了进一步提高安全性，前进到散列链中的下一个值的处理、也就是OPSF和本地OP丢弃当前值并计算下一个值的处理可以遵循若干种策略，例如，该处理可以采用按月、按天、按会话等等的形式执行。
4.4.2.6.5重复使用AKAAV和秘密，以及从AKA证书构建散列链
在一个示例实施方式中，OPSF可以与MNO上的网络功能处于相同位置，其中所述网络功能可以允许OPSF检索来自HLR（归属位置寄存器）以及MNO的AuC（认证中心）的AKA认证矢量（AV）。OPSF可以检索AV，并且可以选择其中一个AV来质询与SCWS相关联的OP。通过使用该AV，OPSF和关联于SCWS的OP可以建立共享秘密CK，然后，该共享秘密CK可以用作OpenID的长期共享秘密K。在另一个示例实施方式中，不同于建立长期秘密，OP和OPSF可以建立散列链的保证，其值被用作OPSF与关联于SCWS的OP之间的共享秘密。这种处理可以是一种用于建立长期共享秘密的安全方式。
4.4.2.7强调所述改进的好处
本节旨在显示SCWS上的OP可以提供的好处，尤其是在该改进变体中提供的好处。
4.4.2.7.1标准的OpenID
图29示出的是标准的OpenID协议流程。通过使用已有的基于网络的OpenIDOP服务器（例如myopenid.com），可以运用标准的OpenID协议过程来从移动设备访问RP。
如图29所示，本地业务是不存在的，并且从空中网络卸载的唯一业务是发现处理以及RP与OP之间的关联建立处理。由于OP是网络服务，因此，介于用户/浏览器/设备与OP之间的所有通信全都经由空中接口。
空中传送通信是在965处和975处进行的，其中该通信是在MNO/空中网络上执行的，并且通常作为代表了MNO网络上的负载的数据业务（例如基于HTTP、IP的通信）。
在970处，业务会在固定线路的因特网上出现，并且可以使用现有的基础架构。
4.4.2.7.2OpenID/GBA
图30示出的是OpenID/GBA的业务流程。该图是从源于3GPPTR33.924v9.1.0第13页的图4-41.1中得到的。
如图30所示，不管在RP与MNO之间进行怎样的关联步骤，所有通信都在空中网络上进行。例如，980和985处的信号是通过空中传送通信传送的，该通信作为数据业务而在MNO/空中网络上进行，并且代表了MNO网络上的负载。与基于网络的OP相比，由于需要用于认证的附加步骤，因此，OpenID/GBA中的业务甚至更大，而这会给空中数据网络以及GBA认证所需要的后端服务、即BSF和NAF子系统造成负担。因此，空中网络业务将会增长，并且网络实体上的负载将会增大。
4.4.2.7.3简化的基于关联的通信
图31示出的是基于关联的通信模式的协议流程的另一个示例实施方式。如图30所示，空中传送业务可以卸载到本地设备上，从而减少空中接口网络业务。例如，通过执行该处理，可以允许认证业务处于本地，以使认证业务将空中接口网络或网络服务上的负担最小化。此外，发现和/或关联业务可以不经由空中接口网络发生，并且可以在固定线路的公共因特网上进行。
在990处，用户可以与浏览器之类的用户接口对接，并且可以访问RP，还可以使用OpenID来请求登录。在995处，RP和OP（MNO）可以基于OpenID标识来执行发现OP服务器的处理。在1000处，RP可以向OP传送关联请求。OP可以产生随机的唯一关联句柄A，并且可以计算密钥S。所述OP可以向RP传送关联响应。该关联响应可以包括关联句柄A和密钥S。RP可以存储密钥S和关联句柄A。
在1005处，RP可以向浏览器传送重定向。所述重定向可以将浏览器重定向到OP，并且可以将关联句柄A包含在请求参数中。OP可以与SCWS相关联。浏览器可以接收重定向，并且可以通过执行经过修改的本地DNS查找来映射到SCWS。在1010处，浏览器可以向OP传送本地认证请求。在1015处，认证可以在本地进行。例如在1020处，OP可以基于长期共享秘密钥K和关联句柄A来核认证书。此外，OP还可以计算密钥S，并且可以使用密钥S来计算签名。该签名可以用于对断言消息进行签名，和/或对返回URL、标识和/或模式之类的参数进行签名。
在1025处，OP可以向浏览器传送指示浏览器访问RP的重定向。该重定向可以包括关联句柄A和被签名的参数。在1030处，浏览器可以向RP传送请求，该请求可以包括来自OP且被签名的断言消息。RP可以使用密钥S来核验断言消息上的签名。然后，在1035处，RP可以允许浏览器显示登录页面，并且可以向浏览器提供针对服务的访问。
在一个示例实施方式中，假设在关联于SCWS的OP与MNO之间存在长期共享密钥。
如图31所示，1010、1015、1020和1025代表的是不会在MNO/空中网络上产生负载的本地通信。此外，由于这些通信可以在设备内部进行，因此，这些通信可以在其他（固定线路或非MNO）网络没有业务的情况下进行。
990、1005、1030和1035代表的是空中传送通信，该通信可以作为数据业务（例如基于HTTP、IP的通信）在MNO/空中网络上进行，并且可以代表MNO网络上的负载。
995和1000代表的是可以在固定线路因特网之类的固定线路上发生并且可以使用现有基础架构的业务。该通信不会增大MNO/空中接口网络上的负载。
图32示出的是基于关联的通信模式所具有的协议流程的另一个示例实施方式。如图32所示，空中传送业务可以卸载到本地设备，从而减少空中接口网络业务。例如，通过执行该处理，可以允许认证业务处于本地，以使认证业务将空中接口网络或网络服务的负担最小化。此外，发现和/或关联业务可以经由空中接口网络进行，并且可以在固定线路的公共因特网上进行。
在1040处，用户可以与浏览器之类的用户接口对接，并且可以访问RP，还可以使用OpenID来请求登录。在1045处，浏览器可以向RP传送HTTP消息，该HTTP消息可以包括OpenID标识URL。在1050处，RP和OP（MNO）可以基于OpenID标识来执行发现OP服务器。例如，RP可以向OP传送HTTP（S）获取标识页面消息，OP则可以使用OpenIDIDP服务器地址来做出响应。
在1055处，RP可以向OP传送关联请求。例如，RP可以向OP传送HTTP（S）传递。OP可以产生随机的唯一关联句柄A，并且可以计算秘密S。OP可以向RP传送关联响应。例如，OP可以向RP传送HTTP（S）传递。所述关联响应可以包括关联句柄A和秘密S。RP可以存储秘密S和关联句柄A。该RP可以创建现时和会话标识符。
在1060处，RP可以向浏览器传送重定向。例如，RP可以向浏览器传送HTTP重定向。所述重定向可以将浏览器重定向到OP，并且可以将关联句柄A包含在请求参数中。OP可以与SCWS相关联。浏览器可以接收重定向，并且可以通过执行经过修改的本地DNS查找来映射到SCWS。在1065处，浏览器可以向OP传送本地认证请求。例如，浏览器可以向OP传送包含了所述重定向中包含的参数的HTTP获取http://op.org/server。
在1070处，认证可以在本地进行。浏览器可以为用户呈现请求用户认证证书的认证页面。用户可以输入包含用户名和密码的认证证书。在1075处，OP可以基于长期共享秘密密钥K和关联句柄A来核认证书。此外，OP还可以计算秘密S，并且可以使用秘密S来计算签名。该签名可以用于对断言消息进行签名，和/或对诸如返回URL、标识和/或模式之类的参数进行签名。
在1080处，OP可以向浏览器传送指示浏览器访问RP的重定向。例如，OP可以向RP传送HTTP重定向。所述HTTP重定向可以包括关联句柄A和被签名的参数。在1085处，浏览器可以向RP传送请求，该请求可以包括来自OP且被签名的断言消息以及OP提供的参数。例如，浏览器可以向RP传送HTTP获取http://rp.org/return。RP可以使用秘密S来核验断言消息上的签名。然后，在1090处，RP可以允许浏览器显示登录页面，并且可以向浏览器提供针对服务的访问。例如，RP可以指示浏览器显示HTML页面。在1095处，浏览器向用户告知其在RP上登录。
在一个示例实施方式中，假设在关联于SCWS的OP与MNO之间存在长期共享密钥。
如图32所示，1040、1065、1070、1080和1095代表的是不会在MNO/空中网络上产生负载的本地通信。此外，由于这些通信可以在设备内部进行，因此，这些通信可以在其他（固定线路或非MNO）网络上没有业务的情况下进行。
1045、1060、1085和1090代表的是空中传送通信，该通信可以作为数据业务（例如基于HTTP、IP的通信）而在MNO/空中网络上进行，并且可以代表MNO网络上的负载。
1050和1055代表的是可以在固定线路因特网之类的固定线路上发生并且可以使用现有基础架构的业务。该通信不会增大MNO/空中接口网络上的负载。
图33示出的是基于关联的通信模式所具有的协议流程的另一个示例实施方式。如图33所示，空中传送业务可以卸载到本地设备，从而减少空中接口网络业务。例如，通过执行该处理，可以允许认证业务处于本地，以使认证业务将空中接口网络或网络服务的负担最小化。此外，发现和/或关联业务可以经由空中接口网络进行，并且可以在固定线路的公共因特网上进行。
在1100处，用户可以与浏览器之类的用户接口对接，并且可以访问RP，还可以使用OpenID来请求登录。在1105处，浏览器可以向RP传送可以包含OpenID标识URL的HTTP消息。在1110处，RP和OP（MNO）可以基于OpenID标识来执行发现OP服务器。例如，RP可以向OP传送HTTP（S）获取标识页面消息，OP可以使用OpenIDIDP服务器地址来做出响应。
在1115处，RP可以向OP传送关联请求。例如，RP可以向OP传送HTTP（S）传递。OP可以产生随机的唯一关联句柄A，并且可以计算秘密S。OP可以向RP传送关联响应。例如，OP可以向RP传送HTTP（S）传递。该关联响应可以包括关联句柄A和秘密S。RP可以存储秘密S和关联句柄A。该RP可以创建现时和会话标识符。
在1120处，RP可以向浏览器传送重定向。例如，RP可以向浏览器传送HTTP重定向。所述重定向可以将浏览器重定向到OP，并且可以将关联句柄A包含在请求参数中。OP可以与SCWS相关联。浏览器可以接收重定向，并且可以通过执行经过修改的本地DNS查找来映射到SCWS。在1125处，浏览器可以向OP传送本地认证请求。例如，浏览器可以向OP传送可以包含所述重定向中包含的参数的HTTP获取http://op.org/server。
在1130处，认证可以在本地进行。浏览器可以为用户呈现请求用户认证证书的认证页面。用户可以输入包含用户名和密码的认证证书。在1135处，OP可以基于长期共享秘密密钥K和关联句柄A来核认证书。此外，OP还可以计算秘密S，并且可以使用秘密S来计算签名。该签名可以用于对断言消息进行签名，和/或对返回URL、标识和/或模式之类的参数进行签名。
在1140处，OP可以向浏览器传送指示浏览器访问RP的重定向。例如，OP可以向RP传送HTTP重定向。该HTTP重定向可以包括关联句柄A和被签名的参数。在1145处，浏览器可以向RP传送请求，该请求可以包括来自OP且被签名的断言消息以及OP提供的参数。例如，浏览器可以向RP传送HTTP获取http://rp.org/return。RP可以使用秘密S来核验断言消息上的签名。然后，在1150处，RP可以允许浏览器显示登录页面，并且可以向浏览器提供针对服务的访问。例如，RP可以指示浏览器显示HTML页面。在1155处，浏览器向用户告知其在RP上登录。
在一个示例实施方式中，假设在关联于SCWS的OP与MNO之间存在长期共享密钥。
如图33所示，1100、1125、1130、1140和1155代表的是不会在MNO/空中网络上造成负担的本地通信。此外，由于这些通信可以在设备内部进行，因此，这些通信可以在其他（固定线路或非MNO）网络不发生业务的情况下进行。
1105、1120、1145和1150代表的是空中传送通信，该通信可作为数据业务（例如HTTP，基于IP的通信）而在MNO/空中网络上进行，并且可以代表MNO网络上的负载。
1110和1115代表的是可以在固定线路因特网之类的固定线路上发生并且可以使用现有基础架构的业务。该通信不会增大MNO/空中接口网络上的负载。
图34示出的是用于无状态模式的协议流程的另一个示例实施方式。
1160：用户可以访问RP网址，为了使用OpenID进行登录，他输入了其OpenID标识符，例如http://op.org/identity。
1165：浏览器可以向RP网址发送包含OpenID标识符的HTTP消息。
1170：RP可以使用基于HTTP/HTML的OpenID‘简单’发现处理，并且经由公共因特网来与OP-agg取得联系，从而在标识页面上检索OpenID标识符，例如HTTP获取http://op.org/identity。
1175：OP-agg可以接收请求，并且可以使用包含OPSF因特网地址的HTML页面来进行响应。例如，OP-agg可以通过包含下列地址来做出响应：
<linkrel=“openid.server”href＝http://op.org/server.cgi>。
OPSF可以像标准的OpenID标识供应方网络服务那样对RP进行操作。例如，OPSF能够按照RP的请求来核验断言消息上的签名（由本地OP发布）。根据需求，OPSF必须可以经由公共因特网到达，由此假设其具有DNS名称，例如可以经由http://op.org到达的op.org。由于外界不知道智能卡的IP地址，因此，OPOP-agg和OPSF的这种间接性可以用于通信。
OPSF的地址可以不同于OP-agg的地址。
1180：RP可以接收OPSF的地址，并且创建现时和会话标识符，例如nouce=123123，session=User。RP可以编译向OP告知应该在用户认证之后将浏览器重定向到哪一个URL的return_to参数。所述RP可以发布HTTP重定向，以便将浏览器重定向到OP服务器地址，其中所述重定向包括以下参数：
openid.mode=checkid_setup,
openid.identity=http://op.org/identity,
openid.return_to=http://rp.org/return.cgi?session=User&nonce=123123
1185：浏览器可以接收重定向，并且可以开放与RP在重定向消息中规定的URL相连的连接
1190：借助于经过修改而将OPSF的URL映射到SCWS本地IP地址的DNS查找表，例如，通过使用具有项http://op.org==127.0.0.1的主机文件，浏览器可以被重定向到与SCWS相关联的本地OP，并且发布包含了765处的参数的HTTP请求。
在设备上可以使用经过修改的本地DNS查找表，以使所述设备认为URLhttp://op.org位于SCWS的本地IP地址。浏览器可以开放与SCWS/本地OP的连接，而不是连接到OPSF（所述OPSF可以经由公共因特网而在URLhttp://op.org到达）。
1195：通过执行下列处理，可以确保将认证业务保持在本地，这些步骤并不是OpenID协议规范必需或规定的：
a.与SCWS相关联的OP可以显示本地认证页面
b.用户可以输入其认证证书，例如用户名和密码
c.与SCWS相关联的OP可以核认证书
1200：与SCWS相关联的OP可以创建唯一的随机关联句柄A。通过使用函数f，可以使用S=f(A,K)来计算断言消息的签名秘密，其中所述f应该是单向的，以使对于A的认识不会展现任何对于K的认识。在一个示例实施方式中，即便展现了S和A，也就是给出了S和A，f也不会展现任何关于K的知识，此外，对于函数g来说，在计算方面，对K=g(S,K)进行计算的处理是不可行的。
由于可能将A作为重定向消息中的参数的一部分展现给RP，因此可以假设RP不会在OpenID协议过程的无状态模式中获得对于S的认识。关联句柄A可以包含在重定向消息中。此外还可以假设，使用S签名的被签名的消息m不会向签名核验器展现任何关于K的信息（由于使用的是对称密钥签名，因此，签名核验器始终需要拥有S来核验签名，由此我们不要求该签名不展现S）。
在一个示例实施方式中，关联句柄可以被规定成是长为255个字符或更少的字串，并且可以只包括处于闭区间33-126中的ASCII字符（可打印的非空白字符）。
OPSF用于核验签名的秘密与关联于SCWS的OP用于产生签名的秘密可以是相同的。签名的新鲜度可以由下一个步骤中插入的RP现时来确保，并且该RP现时必须是签名的一部分。OpenID规范对签名秘密本身的新鲜度保持默契。OP负责确保秘密的密码强度，保持其秘密性，以及在需要时确保其新鲜度。OPSF和关联于SCWS的OP可以持续有限寿命或是用于该目的签名秘密的使用计数。
启用工具箱的本地OP可以使用CAT来主动与手持机通信，从而绕过SCWS。该消息可以依照标准的OTA（例如用于经由SMS-PP承载来发送OPSF的OTA）而被格式化。但是，这种处理有可能需要OPSF经由MNO的OTA系统来与所述卡进行通信。在另一个实施方式中，BIP网关可以提取工具箱消息的有效载荷，并且手持机可以使用TCP/IP将其发送到OPSF。这可能要求消息经由MNO的OTA服务器来传送。另外，SCWS声称只在所述卡不具有IP地址并且不支持TCP/IP的情况下使用BIP。因此，所预期的有可能是使用TCP/IP并借助SCWS来进行发送。
d.其他选项也是可以应用的，这些选项有可能在关联于SCWS的OP与OPSF之间产生共享秘密。此类方法的可行性有待下一步研究。
1205：与SCWS相关联的OP可以计算下列参数上的签名：return_to、标识以及模式。
1210：与SCWS相关联的OP可以向浏览器发送HTTP重定向消息，其中该消息包含了在1180处从RP接收的参数。此外还可以包括下列各项：
·openid.signed参数中的一系列被签名的参数
·openid.assoc_handle参数中的关联句柄A
·openid.sig参数中的签名（base64编码）。
在1212处，该消息可以用于将浏览器重定向到处于RP的return_toURL。
1215：浏览器可以将用户重定向到RP上的return_toURL。
1220：RP可以接收被签名的断言消息，并且在经由公共因特网且基于HTTP（S）的直接通信中加入与OPSF的核验过程。
1225：RP可以发布HTTP传递消息，该消息包含了在795处从与SCWS相关联的OP接收的参数。HTTP传递消息可以包括由与SCWS相关联的OP产生的关联句柄A。
1230：OPSF可以从参数列表中提取A，并且可以与关联于SCWS的OP使用具有相同输入的相同函数f，即OPSF计算f(A,K)=S，并且使用S作为共享秘密来核验从与SCWS相关联的OP接收的数据上的签名。
1235：如果签名核验成功，那么OPSF可以返回is_valid:真。
1240：对RP来说，现在可以将用户标识为http://op.org/identity。
1245：浏览器可以显示RP的HTML页面。
1250：用户可以在RP上作为http://op.org/identity登录。
如图34所示，1160、1190、1212、1215和1250代表的是不会在MNO/空中网络上产生负载的本地通信。此外，由于这些通信可以在设备内部进行，因此，这些通信可以在其他（固定线路或非MNO）网络未产生业务的情况下进行。
1165、1180、1220和1245代表的是空中传送通信，该通信可以作为数据业务（例如基于HTTP、IP的通信）而在MNO/空中网络上进行，并且可以代表MNO网络上的负载。
1170、1175、1225和1235代表的是可能在诸如固定线路的因特网之类的固定线路上出现并且可以使用现有基础架构的业务。该通信不会增大MNO/空中接口网络上的负载。
4.5方案和应用
本节论述的是先前章节中描述的方法和协议的附加实施方式。例如，本节通过显性列举了一些不同的方案扩展了以上概括，由此扩展了使用范例和方案的范围。
术语“智能卡”（SC）可以用于描述能够提供安全操作设施的任何类型的集成电路卡（IC）。对于可以使用SC来保持网络认证证书（例如GSM/UMTS）的移动设备中的特定用途来说，该用途可被称为UICC。开放移动联盟（OMA）定义的智能卡网络服务器（SCWS）应用并不局限于在UICC中使用，并且可被设想在其他任何智能卡上使用。因此，这里描述的实施方式很容易扩展到一般的SC，例如通过将OpenID与驻留在安全部件内部的OP实体结合使用来实施用户认证的实施方式。
此外，其他任何可以为安全性至关重要的方法提供相似接口和受保护运行的安全环境都可以是上述实施方式的实施目标。
4.5.1利益相关者模型
4.5.1.1MNO模型
在一个示例实施方式中，MNO可以充当全面的标识供应方。MNO可以托管作为网络服务的OP-gg以及OPSF发现和关联点实体，并且还可以向UICC提供OP应用和用户标识。
4.5.1.2第三方OP和MNO
在一个示例实施方式中，假设用户已经具有注册到第三方OP的现有OpenID标识符，例如myopenid.com。该OP可被称为第三方OP（3OP）。
MNO可以不再充当用户的服务供应者，而是可以传送数据，并且允许3OP在UICC上安装OP应用并将其与SCWS应用相关联。3OP有可能必须与MNO建立业务关系。MNO还可以为OP应用许可3OP远程管理权利。MNO可以向3OP收取服务的费用并产生收益。更进一步的细节是在下文中就兼容全球平台（GP）的卡的使用来描述的。
4.5.1.3非MNO，非移动
在非移动方案中可以使用一个示例实施方式。例如，OpenID标识供应方可以使用诸如银行发布的SC之类的一般SC来安装OP应用。举例来说，通过执行该处理，可以使用托管了NFC权证应用和OpenID认证OP应用的银行卡。可以假设先前不知道将会与SC通信的设备的类型。但是，如果给出了当前的SC规范，那么可以与SC建立借助USB的TCP/IP连接，其中举例来说，所述连接是借助本地链路、SC读取器、NFC通信接口等等建立的。SC可以配备能被外部终端到达的SCWS。
4.5.2拆分终端方案
本节描述的是这样的实施方式，其中包含了托管SCWS和OP应用的SC的设备可以不是与希望访问RP网站的设备相同的设备。在这些实施方式中，SC可被用作外部认证令牌。这些拆分终端实施方式可以与这里描述的不同利益相关者模型相结合。
4.5.2.1具有处于移动终端中的UICC的拆分终端
图34示出的是用于拆分终端的协议流程的示例实施方式。在一个示例实施方式中，用户可以拥有配备了UICC的移动设备，其上安装了SCWS和OP。用户可以使用与该移动设备不同的设备访问RP上的期望网页，其中该设备被称为浏览代理（BA）。当BA访问RP并提交OpenID标识符以进行登录时，RP可以将BA重定向到OP，即OP的URL。从RP到BA的HTTP重定向消息可以包括OP应用对断言消息上的签名进行计算所需要的必要信息。该消息的内容可以传递到移动设备以及SC上的OP。OP可以在移动设备上向用户显示认证页面，用户会授权并认证所述登录。OP可以对断言消息进行签名。然后，被签名的断言消息可以被送回RP，这个处理通常由RA完成。然后，RP可以核验该签名，并且用户/BA将会登录在RP上。
在另一个包含了BA与移动设备之间通信的示例实施方式中，举例来说，在两个实体之间可以借助蓝牙或WLAN来建立本地链路，并且可以将设备注册成是托管OP的设备。然后，浏览器可以经由本地链路来向移动设备发送重定向，移动设备则可以将这个重定向转发给OP/SCWS。然后，OP可以向用户要求其证书。用户可以在其移动设备上使用任何一种为了用户认证而实施的方法（例如密码、PIN、生物计量）来向OP进行认证。OP可以对断言消息进行签名，并且将其经由本地链路转发给BA。然后，BA可以使用这个消息来向RP进行认证。在该方案中，BA充当了RP与移动设备之间的MITM。由于用户有可能知道其发起了该OpenID会话，因此，他可以在他的移动设备上检测到非授权请求。
如图35所示，在1255处，BA可以访问RP，并且可以请求使用OpenID进行登录。在1260处，RP可以接收登录请求，并且可以基于OpenID标识来与OP（MNO）发起发现OP服务器的处理。在1265处，RP可以向OP（MNO）传送关联请求，OP（MNO）则可以传送关联响应。该关联响应可以包括关联句柄A和密钥S。在1270处，RP可以将浏览器重定向到与SCWS相关联的OP。所述RP请求可以将A包含在请求消息中。BA与用户可以建立本地链路。
在1275处，BA可以向与SCWS相关联的OP传送本地认证请求。在1280处，在关联于SCWS的OP与用户/移动设备之间可以建立本地认证处理。
在1285处，与SCWS相关联的OP可以将BA重定向到RP。该定向可以包括关联句柄，并且可以包括被签名的参数。在1290处，BA可以向RP传送请求。该请求可以包括来自与SCWS相关联的OP且被签名的断言消息。在1295处，RP可以允许BA显示登录页面。
4.5.2.2外部读卡器/NFC中的带有智能卡的拆分终端
在关于非移动SC部署的示例实施方式中，SC可以由基于网络的OP或另一个第三方（例如银行）发布。在这里可以应用与移动拆分终端范例中描述的步骤相似的步骤。然后，本地链路可以借助外部智能卡读取器或是借助附着于计算机的NFC（近场通信）终端来建立。该接口可以支持HTTP消息，并且该HTTP消息可被发送给在SC上实施的OP/SCWS。
4.6OpenID中的信任关系
4.6.1现有OpenID中的信任关系
图35示出的是OpenID中的信任关系。
4.6.1.1OpenID协议步骤1
如图36所示，在1300处，用户访问允许其在登录之后访问服务的RP网站。如果他决定使用OpenID登录，那么他会被重定向到其OP。用户必须信任恰当地执行了重定向并且不会遭遇网络钓鱼攻击的RP。此外，用户还相信供其在登录之后接收服务的RP，并且相信（出于隐私原因）所述RP不会展现与RP到第三方的用户交互。
用户提供的OpenID\标识符进入RP域，并且充当了用于为RP发现正确OP的手段、以及用于RP与用户之间交互的标识符。RP仅仅获悉该标识符，并且通过对其进行解析，RP知道了OP的地址。
根据OpenID规范，发现是可依赖方使用标识符来查找（“发现”）用于发起请求的必要信息的处理。OpenID认证具有三种执行发现的途径。
如果标识符是XRI,[XRIResolution（解析）2.0]（Wachob（瓦霍布）,G.、Reed（里德）,D.、ChasenL（查森勒）、Tan（谭）,W.以及S.Churchill（丘吉尔），“ExtensibleResourceIdentifier(XRI)ResolutionV2.0-CommitteeDraft02（扩展资源标识符（XRI）解析V2.0-委员会草案02）”），那么它会产生包含必要信息的XRDS文档。
应该指出的是，可依赖方可以利用CRI代理解析器，例如处于http://www.xri.net的XDI.org提供的解析器。这样做会消除RP在本地执行XRI解析的需要。
如果它是URL，那么首先应该尝试Yadis（雅迪斯）协议（Miller（米勒）,J.，“YadisSpecification1.0（雅迪斯规范1.0）”）[Yadis]。如果取得成功，则结果同样是XRDS文档。如果Yadis协议失败并且没有检索到有效的XRDS文档，或者在XRDS文档中没有发现服务元素（OpenID服务元素），则检索所述URL，并且应该尝试基于HTML的发现处理（基于HTML的发现）。
值得一提的是，发现步骤有可能为攻击者提供进入点。例如，攻击者可以使用DNS欺骗攻击来尝试直接攻击RP，以便以将RP重定向到受控于攻击者的伪造OP而并非真实OP的方式来暗中破坏发现步骤。虽然该主机是另一个主机，但由于域名相同，因此，RP仍旧认为它是用户的真实OP。与似乎处于OpenID规范的范围以外相对，该缺点存在于OpenID协议和保护的设计中。在可信OpenID文档中业已捕获到了这种威胁，并且其中论述了关于某些可能的缓解方法的暗示。
4.6.1.2OpenID协议步骤2
如图36所示，在1305处，一旦RP发现用户OP，则RP会与该OP建立关联，由此允许其安全地经由共享密钥保护信息来进行通信，用户标识符将会离开RP域并进入OP域。虽然OP会认定他实际托管了带有指定标识符的用户标识，但是OP还会获知该用户现在正在尝试访问哪一个站点。如果共享秘密的建立是不安全的（该标准只定义了能被MITM攻击的Diffie-Hellman），那么OP无法确保与之关联的RP与用户在其浏览器中看到的RP相同。
用户相信OP不会使用收集到的信息（例如用户访问过的站点和访问频率）来构建用户简档。此外，用户相信OP不会接受来自用户未访问过的站点的关联请求（例如攻击者对未知站点的隐藏登录尝试）。
RP相信OP的确会实际认证用户，以及为RP提供可靠的用户标识信息。在可以借助RP来收取RP服务费用的支付方案中，RP还相信OP会提供必要的手段来进行收费。例如，如果MNO在OpenID/GBA中充当OP，那么RP会将OP认定成是由允许借助用户电话账单来向其收费的MNO运行的。然后，RP相信MNO-OP会执行收费。
由于可以构建和设置任意的OP（例如那些不认证用户并且由此可能被垃圾邮件发送者滥用，从而为其提供一种简单机制来创建向论坛、博客等等兜售信息通用账号的OP），因此，RP有可能希望限制针对受限OP集合的访问。在OpenID协议中并没有规定这种OP白/黑名单方法，但在RP上可以实施该方法来防御恶性OP。
4.6.1.3OpenID协议步骤3
如图36所示，在1310处，用户被重定向到OP页面并执行认证。证书将会离开用户域并进入OP域。因此，用户与OP之间的接口必须受到保护以免窃听。在典型方案中，通过使用HTTP之上的HTTPS，可以提供很小的保护。但是，考虑到用户不会检查整个证书链，该处理并未防御带有有效证书的伪造OP。
用户相信OP不会滥用证书，也就是说，用户不会认为其OP是恶意的。恶意OP很容易即可代表其注册用户来访问所有服务。由于OP的损害会导致将用户证书立即暴露给所有网络服务，并且还会导致用户标识受损，因此，具有较大用户基础的大型OP成为了攻击者的主要目标。
作为认证阶段的结果，用户浏览器被来自OP的断言重定向到了RP，其中所述OP是用户为了使用其标识符而进行认证的OP。
用户标识受损尤其令人感到担忧，这是因为OpenID标识通常不但被用作了用于简化针对不同网络服务的访问的手段，而且还被用作了一种用于在多个站点上构建声望的手段。因此，一旦标识符被滥用，则很难恢复受好评的标识。
4.6.1.4OpenID协议步骤4
如图36所示，在1315处，通过使用来自OP的断言，用户被重定向到RP。RP获取足够信息来相信已经执行过认证的用户（和OP），并且相信该用户知道与标识符相关联的秘密。RP不会获得在用户与OP之间使用的认证方法的任何信息或保证。
4.6.2用于移动本地OP中的信任关系的实施方式
4.6.2.1概括
图37示出的是与本地OP的信任关系的示例实施方式。在一个示例实施方式中，如果OP成为用户的本地实体，那么OP和用户域可被认为是用虚线1340标识的单个域。
在1330处，用户可以执行认证，这样可以减小认证过程的网络负载。用户可以与为其提供更多控制的本地实体共享其私有数据。如果要构建关联，那么RP有可能需要直接与本地OP取得联系。该连接不是OpenID协议工作所必需的。RP与OP之间的通信还可以借助间接通信来执行，也就是借助于使用了用户浏览器的重定向。
但是，RP在本地OP中所具有的信任度取决于可以从来自OP的断言中推导得到的可靠信息量。通常，RP会接受每一个OP，但在需要安全性的应用中，RP可以限制针对一组OP或是具有指定属性的OP的访问。然后，OP必须为RP提供这些属性的信息。此类信息可以通过间接通信并从本地OP经由直接信道（例如关联信道）或者经由重定向消息中的附件传送。在另一个示例实施方式中，关于OP属性的这种断言（例如由可信赖的MNO发布）可以源于TTP。
在1325处，RP可以如1305中描述的那样继续进行处理（第0572段（即4.6.1.1节中最后一段））。在1335处，UE可以如1315中描述的那样继续进行处理（第0580段（即4.6.1.3节中最后一段））。在1320处，UE可以如1300中描述的那样继续执行处理（第0565段（即4.6.1节中第一段））。但在该方案中，如第0582段（即本节中第一段）所述，用户可以采用多种方式来执行本地认证，而不用在因特网上进行交互。
4.6.2.2与MNO的信任关系
图38示出的是与本地OP的信任关系的示例实施方式。如图38所示，由于MNO是在智能卡上运行的，因此它可以与OP具有直接联系。RP可以与MNO具有间接联系，但是在兼容标准的OpenID协议中，它们并不需要建立这种关系。RP可能需要与OP建立联系。出于若干种原因，例如借助于MNO的权证处理、标识的提升的信任等级等等，RP可能希望获取用户标识的附加信息。这种信任度可以基于RP在MNO中具有的信任度。
信任度可以从MNO经由OP传送到RP。在一个示例实施方式中，假设RP对MNO具有某个信任等级（例如通过MNO的声誉，类似于注册、服务以及合同协议的带外处理）。此外，可以假设RP可以在需要时与MNO的实体进行通信，并且该通信可以用恰当的手段保护（例如IPSEC、HTTPS）。此外还可以假设智能卡和MNO（的服务器）可能具有根据需要而以不同方式通信的手段。
在发现处理中可以包含MNO，由此可以通过为RP提供OP当前地址来允许RP与OP建立直接通信信道（关联）。该处理有可能将用户访问的服务暴露给MNO，由此允许其产生用户的追踪简档。如果使用了经由用户浏览器的间接处理，那么该发现处理可以不是必需的。
如果在OpenID协议中包含了MNO，那么MNO可以具有若干种作用。
4.6.2.2.1充当OP的（直接）信任度供应方的MNO
充当直接信任度供应方意味着MNO可以直接包含在OP与RP之间用于构建信任的处理中。这种直接包含可以即时向RP确保将OP断言的标识注册在了MNO上。如果MNO充当OP的直接信任度供应方，那么在OP、RP以及适当的服务或是MNO的现有服务组合之间可以使用若干种方法。
a）用于RP与MNO之间的直接连接的示例实施方式
在一个示例中，MNO可以提供能被RP到达的中心服务。RP不能与OP直接关联，而是经由MNO进行关联。用户浏览器可被重定向到本地OP。在认证之后，OP可以向MNO发送声明认证成功的消息。该消息可以用MNO发布给智能卡的密钥来签名。MNO可以核验该签名，附加自己的签名，然后将该消息转发给RP。RP可以接收两个消息：来自OP且表明用户已被认证的断言，以及来自MNO且表明有效OP已经执行了认证的消息。这些消息可以组合在来自MNO的单个消息中，以使所述消息包含表明认证执行成功的断言。
b）通过OP的间接通信的示例实施方式
在一个示例实施方式中，MNO可能不希望向RP提供这种外部服务；该通信可以间接地通过OP来传送。信任度可以直接从来自MNO的声明中得到，而RP与MNO之间的通信则可以经由OP执行。RP可以使用包含了现时的附加字段来将浏览器重定向到浏览器。然后，OP可以从请求中提取该字段，并且可以将其转发给MNO。MNO可以对其进行签名，然后，被签名的响应可以包含在从OP到RP的断言回答中。由于MNO可能对从已知OP接收的现时进行签名，因此，该处理还具有向MNO隐藏了被访问的服务的附加好处。如果将用户的真实标识泄露给了RP，那么该现时可被用作会话标识符，然后，所述会话标识符将会标识该用户。
c）用于组合方法的示例实施方式
在一个示例实施方式中，通信类型是可以组合的：当用户希望使用OpenID登录RP时，RP会与MNO进行联系，并且在OpenID协议的关联阶段中与MNO建立共享秘密。然后，RP可以预期OP在完成认证时将该秘密包含在断言消息中。对MNO来说，它可以选择使用新产生的签名密钥来为RP提供被签名的声明，其中该签名密钥是在MNO网络智能卡中使用GBA协议产生的。借助GBA协议，MNO可以与智能卡建立秘密，并且这两个实体可以签署相同声明。然后，OP可以将这个被签名的声明包含在发送给RP的断言消息中。RP可以对来自MNO且被签名的声明与断言消息中的声明进行比较。所述来自MNO的被签名的声明（或权证）可以根据需要而产生，或者可以在设备首次与MNO进行认证并且随后将其保存在本地的时候产生。当设备随后尝试连接到RP时，先前存储的被签名的声明可被递送给RP。
OpenID协议可以允许RP决定是与OP建立关联（由此建立共享秘密）还是使用无状态协议流程。OP则可以支持所有这两种工作模式。如果使用关联，则可以为每个RP和每个OP建立共享秘密。这意味着在MNO与用户设备上的OP之间预先共享的声明必须包含RP与MNO之间的这个最新秘密。签名密钥可以在设备-OP与MNO之间预先共享（例如借助GBA），然后，MNO和OP这二者会使用该签名密钥来对基于逐个会话的秘密/现时进行签名，其中该现时可以在RP与MNO之间确定并由MNO转发给OP。
4.6.2.2.2充当OP的（间接）信任度供应方的MNO
在一个示例实施方式中，MNO还可以充当OP的间接信任度供应方。同样，MNO不必牵涉到OpenID认证期间的通信过程中。在另一个示例实施方式中，MNO可以向智能卡发布证书和密钥材料，然后，所述证书和密钥材料可被用于对从OP到RP的断言消息中的字段进行签名。之后，RP可以核验向其确保OP源于可信任的MNO的签名和证书。所述证书核验可以在MNO没有进一步参与的情况下进行，例如由TTP执行。
4.6.2.2.3充当OP的信任度和软件供应方的MNO
在一个示例实施方式中，MNO可以远程下载并管理智能卡上的OP软件包。对一些解决方案、例如智能卡网络服务器（SCWS）来说，该管理可以借助HTTPS管理会话而在SCWS与MNO之间完成。MNO可以直接将用于传递信任度的秘密（例如证书，如经过认证的密钥）包含在OP发布的声明中。然后，RP可以从已认证秘密中推导出信任度。MNO甚至还可以将一组秘密包含在OP软件中，以便与不同的用户标识符结合使用。RP可以从MNO发布的OP软件证书中推导出信任度。
在一个示例实施方式中，GBA可以允许MNO与设备上的OP建立共享秘密。由于该秘密未必为RP所知，但是RP有可能已经与MNO建立了安全通信信道，因此，MNO可以在关联信道中将这个（GBA得出的）秘密转发给RP，以使RP可以自主核验OP断言声明，其中所述声明是用GBA导出的密钥签名的。
在另一个实施方式中，当在MNO与OP之间建立了GBA秘密之后，MNO可以从RP请求现时和RPID，然后使用所述现时和RPID来从其与OP之间的GBA秘密中建立仅用于该特定RP和该特定会话的进一步秘密。例如，通过执行这个处理，可以避免将GBA导出的秘密重新用于与RP的关联，以及避免将GBA导出的秘密暴露给RP。然后，MNO可以将这个RP和会话专用秘密转发给RP。与第一个选项中一样，RP随后能够基于该会话专用密钥来核验断言上的OP签名。
4.7全球平台智能卡上的实施方式
GPSC可以托管多个所谓的安全域（SD），其中所述安全域能使每一个SD代表利益相关者，并且能为该利益相关者存储密钥并且安装和个性化应用。主SD可以是属于卡发布者的发布者SD。SD可以采用层级结构来组织，并且SD可以具有在其层级内部管理内容的不同权限。发布者SD可以具有授权的管理（AM）权限，这意味着它具有卡的自主控制权，并且能在其层级中安装和删除SD。其他SD则只在驻留于卡上的独立层级时才被给予AM。如果SD处于相同层级，那么SD可以得到委托管理（DM）权限，其中该DM权限允许SD在其子层级中管理卡的内容。该SD执行的所有操作都可以由发布者用令牌授权，其中所述令牌由DMSD呈现给发布者SD，并由所述发布者SD进行检查。
驻留在不同SD中的GPSC的应用能够使用可信路径（TP）的概念来进行通信。TP可以是必须指定给应用的权限，其允许这些应用借助GP的开放API来交换命令。否则，应用在GPSC上是被分离的。
图39示出的是具有发布方SD的SD层级的示例实施方式。
图40示出的是具有DM的SD层级的示例实施方式。
4.7.2实施方式的实施选项
根据可以如何在SC上实施SCWS，可以启用不同的利益相关者模型。
4.7.2.1作为GP应用的SCWS的实施方式
图41示出的是作为GP应用的SCWS的示例实施方式。在一个示例实施方式中，SCWS可以在SC发布者拥有的特定SD中作为GP应用来实施，并且可以支持MNO模型和第三方OP模型以及非MNO模型。我们假设OP的应用逻辑可以作为不同的应用驻留在不同的SD中，并且由此可以被与拥有SCWS应用和域的实体不同的实体拥有和管理。这两个应用都可以使用可信路径能力来进行通信。第三方和卡发布者必须就用于实施该方案的业务联系达成一致，例如将正确的权限许可给SD和应用。
应用提供方（第三方OP）SD可以配备DM权限，并且可以管理OP应用。SCWS管理可以由卡发布者借助SCWS管理代理SD来执行，其中所述SD通常支持OTA管理能力，例如借助HTTM的RAM。如果APSD还支持SCP80协议，那么应用和内容可以是由第三方使用DM令牌管理的OTA。
4.7.2.2范例2：在卡的运行时间环境（RTE）中实施的SCWS
图42示出的是在卡的运行时间环境中实施的SCWS的示例实施方式。在一个示例实施方式中，由于对SCWS的访问不会通过GP框架暴露，因此，SCWS可以在卡的RTE中由SC制造商来实现，并且第三方应用无法与SCWS进行通信。因此，不能支持第三方OP的利益相关者模型。但是，支持MNO模型和非移动模型。
4.8SCWS之外的其他平台上的OP实施方式
4.8.1使用Java卡作为平台
在Java卡上可以安装Java运行时间环境，该环境允许跨越不同SIM卡（和厂家）的SIM卡应用的互操作性。
在一个示例实施方式中，Java卡平台可以用于允许MNO创建并向Java卡部署小应用程序OTA。
4.8.2使用嵌入式安全部件的实施方式
如上所述，在智能卡中可以实施属于用户或是受到用户某种程度的控制的设备中的嵌入式本地OP应用。随着嵌入式安全解决方案在移动设备中的日益扩展，有可能存在提供了不同安全属性的多个不同的运行环境。智能卡上的OP设计可以扩展至其他（嵌入式）安全部件，由此可以允许安全地执行代码以及安全地存储证书。此外，运行环境可能需要提供连至外部环境的通信信道，尤其是用于OP用户认证交互、OP浏览器通信（基于HTTP(s)）以及OP–RP关联和断言消息（也基于HTTP(s)）的信道。
在一个示例实施方式中，所使用的可以是移动电话内部已可用于为设备上的OP软件提供可信运行环境（TEE）的已有安全环境（例如信任区域等等）。
由于智能卡可以被视为处于MNO的控制之下，因此，智能卡可以代表MNO的关键资源。在实施嵌入式运行环境上的OP的过程中、尤其是MNO与本地OP建立共享秘密的实施方式中，MNO可能需要核验运行环境安全属性的装置。该装置可以包括但不局限于：
·执行运行环境的完整性测量的能力
·报告完整性量度的通信
·需要对设备运行环境进行（完整性）核验，由此将其转入可信运行环境（TEE）中
·用于从MNO网络到嵌入式TEE中的OP的下载/供应协议/处理
·TEE的通信能力；OP必须能与RP和用户（以及MNO）进行通信
在一些示例实施方式中（在智能卡上或TEE内部），MNO可以获得关于用户行为的附加信息（例如用户访问的RP、登录频率、用户行为等等）。在要求隐私的方案、例如在公司环境中，公司希望向MNO隐藏用户行为，并且较为有益的则是在很大程度上都不包含MNO。
在另一个示例实施方式中，如果使用了嵌入式安全特征来执行本地OP的实施方式，那么MNO不能包含在OpenID处理中。这样做可以允许用户自主建立、管理和保持处于其设备的TEE内部的OP装置。在该方案中，OP不能与MNO共享秘密，这是因为可以假设MNO在OP实施方式中可能缺乏信任度。但是，在用户与他的设备之间可以存在本地信任关系。用户可以信任所述OP实施方式不会向第三方泄露任何私有个人数据。由于MNO不能发布关于OP实施方式的断言，因此，隐私性的增加可能是以来自RP的OP信任度的降低为代价的。
4.8.3来自可信OpenID创新的概念集成
在一个示例实施方式中，OP可以在智能卡上实施。关于设备完整性的评定可被包含在内并且引入可供设备测量和报告完整性的需求。对于可以支持针对MNO的完整性核验/报告的设备来说，MNO首先可以检查设备完整性以及OP的安全/运行时间环境。然后，MNO可以为OP软件触发（远程）软件安装程序。此外，MNO可以为OP应用配备设备参考值。然后，OP可以对照这些参考值来检查在OpenID认证过程中报告的量度，并且如果顺利通过完整性检查，则可以允许所述认证。
虽然在上文中描述了采用特定组合的特征和元素，但是本领域普通技术人员将会了解，每一个特征既可以单独使用，也可以与其他特征和元素进行任何组合。此外，这里描述的方法可以在引入到计算机可读介质中并供计算机或处理器运行的计算机程序、软件或固件中实施。关于计算机可读介质的示例包括电信号（经由有线或无线连接传送）以及计算机可读存储介质。关于计算机可读介质的示例包括但不局限于只读存储器（ROM）、随机存取存储器（RAM）、寄存器、缓冲存储器、半导体存储设备、如内部硬盘和可移除磁盘之类的磁介质、磁光介质、以及如CD-ROM碟片和数字多用途碟片（DVD）之类的光介质。与软件相关联的处理器可以用于实施在WTRU、UE、终端、基站、RNC或任何主计算机中使用的射频收发信机。

Claims (44)

1.一种用于启用对试图接入来自第三方的服务的用户进行认证的用户设备，该用户设备包括：
用户接口，该用户接口被配置成：
使用单点登录安全协议与所述第三方进行通信，以代表所述用户来请求接入到由所述第三方提供的服务；以及
接收来自所述第三方的认证请求，其中该认证请求包括关联句柄；
以及
处理器，该处理器被配置成：
与标识供应方建立秘密；
在所述用户设备内执行对所述用户的本地认证；以及
使用所述秘密来产生被签名的断言，该被签名的断言用于用户认证，其中所述秘密被配置成使得所述第三方能够基于从所述标识供应方接收到的密钥来核验所述被签名的断言的真实性，以及允许所述用户接入由所述第三方提供的所述服务，
其中所述用户接口还被配置成向所述第三方传送所述被签名的断言和所述关联句柄。
2.根据权利要求1所述的用户设备，其中所述用户接口还被配置成接收来自所述第三方的指示，该指示表明所述第三方希望对所述用户进行认证。
3.根据权利要求1所述的用户设备，其中所述用户接口还被配置成接收来自所述第三方的重定向消息，该重定向消息被配置成指示所述用户接口对所述用户进行认证。
4.根据权利要求1所述的用户设备，其中所述用户接口还被配置成接收来自所述用户的用户证书。
5.根据权利要求1所述的用户设备，其中所述处理器是可信计算环境。
6.根据权利要求5所述的用户设备，其中所述用户接口整体或部分地由所述可信计算环境保护。
7.根据权利要求5所述的用户设备，其中当所述用户已被认证时，所述可信计算环境还被配置成向所述第三方传送认证响应。
8.根据权利要求5所述的用户设备，其中所述可信计算环境是下列中的一者：机器对机器(M2M)设备或智能卡。
9.根据权利要求8所述的用户设备，其中所述智能卡是下列中的一者：通用集成电路卡(UICC)、用户标识模块(SIM)、java卡、全球平台智能卡、或安全集成芯片卡(ICC)。
10.根据权利要求5所述的用户设备，其中所述可信计算环境使用智能卡网络服务器(SCWS)来被实施。
11.根据权利要求5所述的用户设备，其中所述可信计算环境与OpenID供应方共享秘密。
12.根据权利要求5所述的用户设备，其中所述可信计算环境还被配置成计算签名，并且将所述签名经由所述用户接口提供给所述第三方，以允许所述第三方核验所述可信计算环境的证书。
13.根据权利要求11所述的用户设备，其中所述可信计算环境还被配置成计算签名，并且将所述签名经由所述用户接口提供给所述OpenID供应方，以允许所述OpenID供应方核验所述可信计算环境的证书。
14.根据权利要求11所述的用户设备，其中所述可信计算环境还被配置成基于与所述OpenID供应方的共享秘密来计算签名，并且将所述签名经由所述用户接口提供给所述第三方，以允许所述第三方核验所述可信计算环境的证书。
15.根据权利要求11所述的用户设备，其中所述可信计算环境还被配置成基于与所述OpenID供应方的共享秘密来计算签名，并且将所述签名经由所述用户接口提供给所述OpenID供应方，以允许所述OpenID供应方核验所述可信计算环境的证书。
16.根据权利要求11所述的用户设备，其中所述可信计算环境还被配置成与所述OpenID供应方经由所述用户接口建立所述共享秘密。
17.根据权利要求16所述的用户设备，其中所述用户接口还被配置成接收来自所述第三方的包括所述关联句柄的认证请求，并且将所述关联句柄提供给所述可信计算环境。
18.根据权利要求16所述的用户设备，其中所述可信计算环境还被配置成基于与所述OpenID供应方的共享秘密来产生签名，并且产生包括所述签名和所述关联句柄的认证响应。
19.根据权利要求18所述的用户设备，其中所述用户接口还被配置成将由所述可信计算环境产生的所述认证响应提供给所述第三方。
20.根据权利要求1所述的用户设备，其中所述处理器还被配置成产生签名，并且接收来自OpenID供应方的签名断言消息。
21.根据权利要求20所述的用户设备，其中所述处理器还被配置成向所述第三方传送签名响应消息。
22.根据权利要求1所述的用户设备，其中所述用户接口和所述处理器处于相同设备上。
23.根据权利要求1所述的用户设备，其中所述用户接口和所述处理器处于分离的设备上。
24.根据权利要求1所述的用户设备，其中通过用密码或PIN码、生物计量标识、令牌或前述组合核验所述用户来对所述用户进行本地认证。
25.一种用于对试图接入来自第三方的服务的用户进行认证的方法，该方法包括：
经由用户接口接收来自所述第三方的指示，该指示表明所述第三方希望对所述用户进行认证，所述指示包括关联句柄；
与标识供应方建立秘密；
通过所述用户接口接收来自所述用户的用户证书；
使用所接收到的用户证书在本地对用户设备处的所述用户进行认证；
使用所述秘密产生被签名的断言，其中所述被签名的断言用于用户认证，并且其中所述秘密被配置成使得所述第三方能够基于从所述标识供应方接收到的密钥来核验所述被签名的断言的真实性；以及
将所述被签名的断言和所述关联句柄传送至所述第三方，以允许所述用户接入由所述第三方提供的所述服务。
26.根据权利要求25所述的方法，其中所述指示是重定向消息。
27.根据权利要求26所述的方法，其中所述重定向消息指示所述用户接口使用可信计算环境来对所述用户进行认证。
28.根据权利要求26所述的方法，其中对所述用户进行认证经由可信计算环境而被执行。
29.根据权利要求28的方法，其中所述可信计算环境是下列中的一者：机器对机器(M2M)设备或智能卡。
30.根据权利要求29的方法，其中所述智能卡是下列中的一者：通用集成电路卡(UICC)、用户标识模块(SIM)、java卡、全球平台智能卡、或安全集成芯片卡(ICC)。
31.根据权利要求25所述的方法，其中所述被签名的断言在所述用户已被认证时传送。
32.根据权利要求28所述的方法，其中使用所述可信计算环境对所述用户进行认证是通过使用安全网络服务器进行的。
33.根据权利要求25所述的方法，该方法还包括：共享与关联于移动网络运营商(MNO)的开放管理安全供应方的共享秘密。
34.根据权利要求25所述的方法，该方法还包括：共享与关联于移动网络运营商(MNO)的OpenID供应方的共享秘密。
35.根据权利要求28所述的方法，该方法还包括：经由所述用户接口建立与所述第三方的共享秘密。
36.根据权利要求35所述的方法，该方法还包括：基于所述共享秘密来产生签名，以及产生包括所述签名和所述关联句柄的认证响应。
37.根据权利要求36所述的方法，该方法还包括：接收来自所述第三方的签名断言消息。
38.根据权利要求37所述的方法，该方法还包括：向所述第三方传送签名响应消息。
39.根据权利要求28所述的方法，该方法还包括：计算签名，并且将所述签名经由所述用户接口提供给OpenID供应方，以允许所述OpenID供应方核验所述可信计算环境的证书。
40.根据权利要求39所述的方法，该方法还包括：经由所述用户接口与所述OpenID供应方建立共享秘密。
41.根据权利要求35所述的方法，该方法还包括：接收来自所述可信计算环境的关联句柄，并且将该关联句柄传送至OpenID供应方。
42.根据权利要求41所述的方法，该方法还包括：基于所述共享秘密来产生签名，并且产生包括所述签名和所述关联句柄的认证响应。
43.根据权利要求42所述的方法，该方法还包括：接收来自所述OpenID供应方的签名断言消息。
44.根据权利要求43所述的方法，该方法还包括：向所述OpenID供应方传送签名响应消息。
CN201180009229.6A 2010-02-09 2011-02-09 用于可信联合标识的方法和装置 Expired - Fee Related CN102783115B (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US30289010P 2010-02-09 2010-02-09
US61/302,890 2010-02-09
US39660210P 2010-05-28 2010-05-28
US61/396,602 2010-05-28
PCT/US2011/024200 WO2011100331A1 (en) 2010-02-09 2011-02-09 Method and apparatus for trusted federated identity

Publications (2)

Publication Number Publication Date
CN102783115A CN102783115A (zh) 2012-11-14
CN102783115B true CN102783115B (zh) 2016-08-03

Family

ID=43877206

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201180009229.6A Expired - Fee Related CN102783115B (zh) 2010-02-09 2011-02-09 用于可信联合标识的方法和装置

Country Status (7)

Country Link
US (1) US8533803B2 (zh)
EP (1) EP2534810B1 (zh)
JP (1) JP5540119B2 (zh)
KR (2) KR101684753B1 (zh)
CN (1) CN102783115B (zh)
TW (1) TWI514896B (zh)
WO (1) WO2011100331A1 (zh)

Families Citing this family (227)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6711554B1 (en) * 1999-12-30 2004-03-23 Lee Salzmann Method and system for managing and preparing documentation for real estate transactions
US8989705B1 (en) 2009-06-18 2015-03-24 Sprint Communications Company L.P. Secure placement of centralized media controller application in mobile access terminal
US8776214B1 (en) 2009-08-12 2014-07-08 Amazon Technologies, Inc. Authentication manager
CN102763111B (zh) 2010-01-22 2015-08-05 交互数字专利控股公司 用于可信联合身份管理和数据接入授权的方法和设备
US10977965B2 (en) 2010-01-29 2021-04-13 Avery Dennison Retail Information Services, Llc Smart sign box using electronic interactions
EP3133579B1 (en) 2010-01-29 2020-03-04 Avery Dennison Corporation Smart sign box using electronic interactions
US9215626B2 (en) * 2010-06-25 2015-12-15 Qualcomm Incorporated System, apparatus, and method for utilizing network access parameters in wireless communication systems
US8509431B2 (en) * 2010-09-20 2013-08-13 Interdigital Patent Holdings, Inc. Identity management on a wireless device
US9220051B2 (en) * 2010-11-08 2015-12-22 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for enabling DNS redirection in mobile telecommunication systems
IT1404159B1 (it) * 2010-12-30 2013-11-15 Incard Sa Metodo e sistema di controllo di una comunicazione tra una carta universale a circuito integrato ed una applicazione esterna
US20140068722A1 (en) * 2011-03-11 2014-03-06 CallSign, Inc. Personal identity control
EP3193523A1 (en) * 2011-04-01 2017-07-19 Telefonaktiebolaget LM Ericsson (publ) Methods and apparatuses for avoiding damage in network attacks
US9021552B2 (en) * 2011-04-05 2015-04-28 Sap Se User authentication for intermediate representational state transfer (REST) client via certificate authority
WO2012149219A2 (en) * 2011-04-26 2012-11-01 Apple Inc. Electronic access client distribution apparatus and methods
EP2696649A4 (en) * 2011-04-26 2014-09-03 Huawei Tech Co Ltd PROCESS, BASIC STATION AND SYSTEM FOR WIRELESS COMMUNICATION
CA2775206C (en) * 2011-04-27 2019-02-26 Perspecsys Inc. System and method of handling requests in a multi-homed reverse proxy
CN103503407B (zh) * 2011-04-28 2016-10-12 交互数字专利控股公司 用于多sso技术的sso框架
US8914876B2 (en) 2011-05-05 2014-12-16 Ebay Inc. System and method for transaction security enhancement
US8955078B2 (en) 2011-06-30 2015-02-10 Cable Television Laboratories, Inc. Zero sign-on authentication
US9767262B1 (en) 2011-07-29 2017-09-19 Amazon Technologies, Inc. Managing security credentials
US11444936B2 (en) 2011-07-29 2022-09-13 Amazon Technologies, Inc. Managing security credentials
US10362019B2 (en) 2011-07-29 2019-07-23 Amazon Technologies, Inc. Managing security credentials
US9258344B2 (en) * 2011-08-01 2016-02-09 Intel Corporation Multi-hop single sign-on (SSO) for identity provider (IdP) roaming/proxy
US8719571B2 (en) * 2011-08-25 2014-05-06 Netapp, Inc. Systems and methods for providing secure multicast intra-cluster communication
CN104025556B (zh) 2011-09-01 2018-08-10 艾利丹尼森公司 用于消费者追踪的设备、系统和方法
CN110061842B (zh) * 2011-09-30 2022-06-03 英特尔公司 带外远程认证
US9143910B2 (en) * 2011-09-30 2015-09-22 Blackberry Limited Method and system for remote wipe through voice mail
US8635684B2 (en) 2011-10-06 2014-01-21 Sap Ag Computer-implemented method for mobile authentication and corresponding computer system
EP2769502A4 (en) * 2011-10-18 2015-07-08 Intel Corp METHOD, SYSTEMS AND DEVICES FOR FACILITATING A CLIENT-BASED AUTHENTICATION
WO2013062394A1 (ko) * 2011-10-28 2013-05-02 삼성전자 주식회사 이동 통신 시스템에서 단일 사용 승인 방법 및 장치
CN103096311B (zh) * 2011-10-31 2018-11-09 中兴通讯股份有限公司 家庭基站安全接入的方法及系统
US8630908B2 (en) 2011-11-02 2014-01-14 Avery Dennison Corporation Distributed point of sale, electronic article surveillance, and product information system, apparatus and method
US9330245B2 (en) * 2011-12-01 2016-05-03 Dashlane SAS Cloud-based data backup and sync with secure local storage of access keys
US20130159195A1 (en) * 2011-12-16 2013-06-20 Rawllin International Inc. Authentication of devices
US9384339B2 (en) * 2012-01-13 2016-07-05 Telecommunication Systems, Inc. Authenticating cloud computing enabling secure services
US8527763B2 (en) * 2012-01-16 2013-09-03 Dell Products, Lp System and method for enabling seamless transfer of a secure session
KR101730459B1 (ko) * 2012-01-20 2017-04-26 인터디지탈 패튼 홀딩스, 인크 로컬 기능을 갖는 아이덴티티 관리
US8955065B2 (en) 2012-02-01 2015-02-10 Amazon Technologies, Inc. Recovery of managed security credentials
WO2013116319A1 (en) * 2012-02-01 2013-08-08 Amazon Technologies, Inc. Account management for multiple network sites
US8863250B2 (en) 2012-02-01 2014-10-14 Amazon Technologies, Inc. Logout from multiple network sites
US8935793B2 (en) * 2012-02-29 2015-01-13 The Mitre Corporation Hygienic charging station for mobile device security
US9137234B2 (en) 2012-03-23 2015-09-15 Cloudpath Networks, Inc. System and method for providing a certificate based on granted permissions
US20130254553A1 (en) * 2012-03-24 2013-09-26 Paul L. Greene Digital data authentication and security system
CN102761537B (zh) * 2012-03-29 2015-06-17 北京奇虎科技有限公司 一种基于客户端插件的授权认证方法及系统
US9083703B2 (en) 2012-03-29 2015-07-14 Lockheed Martin Corporation Mobile enterprise smartcard authentication
US8712407B1 (en) 2012-04-05 2014-04-29 Sprint Communications Company L.P. Multiple secure elements in mobile electronic device with near field communication capability
US9027102B2 (en) * 2012-05-11 2015-05-05 Sprint Communications Company L.P. Web server bypass of backend process on near field communications and secure element chips
US9094774B2 (en) 2012-05-14 2015-07-28 At&T Intellectual Property I, Lp Apparatus and methods for maintaining service continuity when transitioning between mobile network operators
US9148785B2 (en) 2012-05-16 2015-09-29 At&T Intellectual Property I, Lp Apparatus and methods for provisioning devices to utilize services of mobile network operators
US8862181B1 (en) 2012-05-29 2014-10-14 Sprint Communications Company L.P. Electronic purchase transaction trust infrastructure
US8973102B2 (en) * 2012-06-14 2015-03-03 Ebay Inc. Systems and methods for authenticating a user and device
US9473929B2 (en) 2012-06-19 2016-10-18 At&T Mobility Ii Llc Apparatus and methods for distributing credentials of mobile network operators
US8800015B2 (en) 2012-06-19 2014-08-05 At&T Mobility Ii, Llc Apparatus and methods for selecting services of mobile network operators
KR20130143263A (ko) * 2012-06-21 2013-12-31 에스케이플래닛 주식회사 트러스티드 플랫폼 기반의 개방형 아이디 인증 방법, 이를 위한 장치 및 시스템
US9282898B2 (en) 2012-06-25 2016-03-15 Sprint Communications Company L.P. End-to-end trusted communications infrastructure
US9066230B1 (en) 2012-06-27 2015-06-23 Sprint Communications Company L.P. Trusted policy and charging enforcement function
US8649770B1 (en) 2012-07-02 2014-02-11 Sprint Communications Company, L.P. Extended trusted security zone radio modem
US8667607B2 (en) 2012-07-24 2014-03-04 Sprint Communications Company L.P. Trusted security zone access to peripheral devices
US8863252B1 (en) 2012-07-25 2014-10-14 Sprint Communications Company L.P. Trusted access to third party applications systems and methods
US20140038526A1 (en) * 2012-08-03 2014-02-06 Louis C. ENNIS Mobile Social Media Platform and Devices
US9183412B2 (en) 2012-08-10 2015-11-10 Sprint Communications Company L.P. Systems and methods for provisioning and using multiple trusted security zones on an electronic device
US9015068B1 (en) 2012-08-25 2015-04-21 Sprint Communications Company L.P. Framework for real-time brokering of digital content delivery
US8954588B1 (en) 2012-08-25 2015-02-10 Sprint Communications Company L.P. Reservations in real-time brokering of digital content delivery
US9215180B1 (en) 2012-08-25 2015-12-15 Sprint Communications Company L.P. File retrieval in real-time brokering of digital content
US9113498B2 (en) * 2012-09-04 2015-08-18 Qualcomm Incorporated Apparatus and method with routing logic for communications between multiple baseband modems and a universal integrated circuit card
EP2771845B1 (en) 2012-09-10 2019-01-02 Avery Dennison Corporation Method for preventing unauthorized diversion of nfc tags
US8752140B1 (en) 2012-09-11 2014-06-10 Sprint Communications Company L.P. System and methods for trusted internet domain networking
US8955039B2 (en) * 2012-09-12 2015-02-10 Intel Corporation Mobile platform with sensor data security
US9178861B2 (en) 2012-10-16 2015-11-03 Guest Tek Interactive Entertainment Ltd. Off-site user access control
EP3214572B1 (en) 2012-10-18 2020-01-29 Avery Dennison Corporation System and apparatus for nfc security
US8931068B2 (en) * 2012-10-22 2015-01-06 Verizon Patent And Licensing Inc. Authentication process
US9177126B2 (en) * 2012-10-27 2015-11-03 Edward Curren System and method for human identity validation via a mobile device
KR101538424B1 (ko) * 2012-10-30 2015-07-22 주식회사 케이티 결제 및 원격 모니터링을 위한 사용자 단말
US8898769B2 (en) 2012-11-16 2014-11-25 At&T Intellectual Property I, Lp Methods for provisioning universal integrated circuit cards
US9767329B2 (en) 2012-11-19 2017-09-19 Avery Dennison Retail Information Services, Llc NFC tags with proximity detection
US8959331B2 (en) 2012-11-19 2015-02-17 At&T Intellectual Property I, Lp Systems for provisioning universal integrated circuit cards
US20140165172A1 (en) * 2012-12-12 2014-06-12 Rawstream System and method for authentication of devices for controlling network access
US20140189799A1 (en) * 2012-12-28 2014-07-03 Gemalto Sa Multi-factor authorization for authorizing a third-party application to use a resource
CN105191208B (zh) 2013-01-29 2018-12-07 黑莓有限公司 用于激活用户装置上的应用程序的方法
US9578664B1 (en) 2013-02-07 2017-02-21 Sprint Communications Company L.P. Trusted signaling in 3GPP interfaces in a network function virtualization wireless communication system
US9161227B1 (en) 2013-02-07 2015-10-13 Sprint Communications Company L.P. Trusted signaling in long term evolution (LTE) 4G wireless communication
US9300644B1 (en) * 2013-02-22 2016-03-29 Symantec Corporation Knowledge-based authentication based on tracked credential usage
US9104840B1 (en) 2013-03-05 2015-08-11 Sprint Communications Company L.P. Trusted security zone watermark
US9282098B1 (en) 2013-03-11 2016-03-08 Amazon Technologies, Inc. Proxy server-based network site account management
US9613208B1 (en) 2013-03-13 2017-04-04 Sprint Communications Company L.P. Trusted security zone enhanced with trusted hardware drivers
US8881977B1 (en) 2013-03-13 2014-11-11 Sprint Communications Company L.P. Point-of-sale and automated teller machine transactions using trusted mobile access device
US9049013B2 (en) 2013-03-14 2015-06-02 Sprint Communications Company L.P. Trusted security zone containers for the protection and confidentiality of trusted service manager data
US9049186B1 (en) 2013-03-14 2015-06-02 Sprint Communications Company L.P. Trusted security zone re-provisioning and re-use capability for refurbished mobile devices
US9191388B1 (en) 2013-03-15 2015-11-17 Sprint Communications Company L.P. Trusted security zone communication addressing on an electronic device
US9374363B1 (en) 2013-03-15 2016-06-21 Sprint Communications Company L.P. Restricting access of a portable communication device to confidential data or applications via a remote network based on event triggers generated by the portable communication device
US9325632B2 (en) * 2013-03-15 2016-04-26 International Business Machines Corporation Multi-tenancy support for enterprise social business computing
US9021585B1 (en) 2013-03-15 2015-04-28 Sprint Communications Company L.P. JTAG fuse vulnerability determination and protection using a trusted execution environment
US8984592B1 (en) 2013-03-15 2015-03-17 Sprint Communications Company L.P. Enablement of a trusted security zone authentication for remote mobile device management systems and methods
US9454723B1 (en) 2013-04-04 2016-09-27 Sprint Communications Company L.P. Radio frequency identity (RFID) chip electrically and communicatively coupled to motherboard of mobile communication device
US9171243B1 (en) 2013-04-04 2015-10-27 Sprint Communications Company L.P. System for managing a digest of biographical information stored in a radio frequency identity chip coupled to a mobile communication device
US9324016B1 (en) 2013-04-04 2016-04-26 Sprint Communications Company L.P. Digest of biographical information for an electronic device with static and dynamic portions
US9838869B1 (en) 2013-04-10 2017-12-05 Sprint Communications Company L.P. Delivering digital content to a mobile device via a digital rights clearing house
US9825923B2 (en) 2013-04-12 2017-11-21 Nokia Solutions And Networks Oy Secure radio information transfer over mobile radio bearer
US9443088B1 (en) 2013-04-15 2016-09-13 Sprint Communications Company L.P. Protection for multimedia files pre-downloaded to a mobile device
US9069952B1 (en) 2013-05-20 2015-06-30 Sprint Communications Company L.P. Method for enabling hardware assisted operating system region for safe execution of untrusted code using trusted transitional memory
WO2014193896A2 (en) * 2013-05-28 2014-12-04 Raytheon Company Message content ajudication based on security token
US9560519B1 (en) 2013-06-06 2017-01-31 Sprint Communications Company L.P. Mobile communication device profound identity brokering framework
US9178868B1 (en) 2013-06-24 2015-11-03 Google Inc. Persistent login support in a hybrid application with multilogin and push notifications
US9654473B2 (en) 2013-06-28 2017-05-16 Bmc Software, Inc. Authentication proxy agent
US9183606B1 (en) 2013-07-10 2015-11-10 Sprint Communications Company L.P. Trusted processing location within a graphics processing unit
US20150026772A1 (en) * 2013-07-16 2015-01-22 Samsung Electronics Co., Ltd. Media based authentication and authorization for secure services
CN105409185B (zh) * 2013-07-31 2018-12-21 诺基亚技术有限公司 一种本地通信侦听方法及装置
US9544153B1 (en) * 2013-08-07 2017-01-10 Google Inc. Compression of cryptographic chaining certificates
US9208339B1 (en) 2013-08-12 2015-12-08 Sprint Communications Company L.P. Verifying Applications in Virtual Environments Using a Trusted Security Zone
JP5485484B1 (ja) 2013-08-22 2014-05-07 楽天株式会社 情報処理装置、情報処理方法、プログラム、記憶媒体
US9036820B2 (en) 2013-09-11 2015-05-19 At&T Intellectual Property I, Lp System and methods for UICC-based secure communication
GB2518254B (en) * 2013-09-13 2020-12-16 Vodafone Ip Licensing Ltd Communicating with a machine to machine device
US9332433B1 (en) 2013-09-30 2016-05-03 Emc Corporation Distributing access and identification tokens in a mobile environment
US9124573B2 (en) 2013-10-04 2015-09-01 At&T Intellectual Property I, Lp Apparatus and method for managing use of secure tokens
US9208300B2 (en) 2013-10-23 2015-12-08 At&T Intellectual Property I, Lp Apparatus and method for secure authentication of a communication device
US9240994B2 (en) 2013-10-28 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for securely managing the accessibility to content and applications
US9185626B1 (en) 2013-10-29 2015-11-10 Sprint Communications Company L.P. Secure peer-to-peer call forking facilitated by trusted 3rd party voice server provisioning
US9240989B2 (en) 2013-11-01 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for secure over the air programming of a communication device
US9313660B2 (en) 2013-11-01 2016-04-12 At&T Intellectual Property I, Lp Apparatus and method for secure provisioning of a communication device
US9276932B2 (en) 2013-11-07 2016-03-01 International Business Machines Corporation Federated identity mapping using delegated authorization
US9191522B1 (en) 2013-11-08 2015-11-17 Sprint Communications Company L.P. Billing varied service based on tier
US10700856B2 (en) * 2013-11-19 2020-06-30 Network-1 Technologies, Inc. Key derivation for a module using an embedded universal integrated circuit card
US9161325B1 (en) 2013-11-20 2015-10-13 Sprint Communications Company L.P. Subscriber identity module virtualization
US9413759B2 (en) 2013-11-27 2016-08-09 At&T Intellectual Property I, Lp Apparatus and method for secure delivery of data from a communication device
US10475018B1 (en) 2013-11-29 2019-11-12 Amazon Technologies, Inc. Updating account data for multiple account providers
US9363736B2 (en) * 2013-12-16 2016-06-07 Qualcomm Incorporated Methods and apparatus for provisioning of credentials in network deployments
CN104735021B (zh) * 2013-12-18 2018-12-11 腾讯科技（深圳）有限公司 一种帐号登录方法、装置和系统
CN104754552B (zh) * 2013-12-25 2018-07-24 中国移动通信集团公司 一种可信执行环境tee初始化方法及设备
US9483249B2 (en) * 2014-01-06 2016-11-01 Apple Inc. On-board applet migration
US9436455B2 (en) 2014-01-06 2016-09-06 Apple Inc. Logging operating system updates of a secure element of an electronic device
US9118655B1 (en) 2014-01-24 2015-08-25 Sprint Communications Company L.P. Trusted display and transmission of digital ticket documentation
US20150215319A1 (en) * 2014-01-30 2015-07-30 Symantec Corporation Authentication sequencing based on normalized levels of assurance of identity services
AU2015218275B2 (en) 2014-02-14 2019-05-02 Intertrust Technologies Corporation Network security systems and methods
US9391982B1 (en) * 2014-02-27 2016-07-12 Cullen/Frost Bankers, Inc. Network authentication of multiple profile accesses from a single remote device
USD760756S1 (en) 2014-02-28 2016-07-05 Symantec Coporation Display screen with graphical user interface
US9509502B2 (en) 2014-03-13 2016-11-29 Intel Corporation Symmetric keying and chain of trust
US9521125B2 (en) 2014-03-13 2016-12-13 Intel Corporation Pseudonymous remote attestation utilizing a chain-of-trust
US9348997B2 (en) 2014-03-13 2016-05-24 Intel Corporation Symmetric keying and chain of trust
JP6201835B2 (ja) * 2014-03-14 2017-09-27 ソニー株式会社 情報処理装置、情報処理方法及びコンピュータプログラム
CN104954324B (zh) * 2014-03-26 2018-04-10 阿里巴巴集团控股有限公司 一种Session容灾方法及装置
US9226145B1 (en) 2014-03-28 2015-12-29 Sprint Communications Company L.P. Verification of mobile device integrity during activation
US9641512B2 (en) * 2014-04-10 2017-05-02 EMC IP Holding Company LLC Identity protocol translation gateway
US9713006B2 (en) 2014-05-01 2017-07-18 At&T Intellectual Property I, Lp Apparatus and method for managing security domains for a universal integrated circuit card
US9230085B1 (en) 2014-07-29 2016-01-05 Sprint Communications Company L.P. Network based temporary trust extension to a remote or mobile device enabled via specialized cloud services
US9934014B2 (en) 2014-08-22 2018-04-03 Apple Inc. Automatic purposed-application creation
TWI581598B (zh) * 2014-09-17 2017-05-01 國立成功大學 通訊認證方法
US9544395B2 (en) 2014-10-10 2017-01-10 At&T Intellectual Property I, L.P. Facilitating quality of service and security via functional classification of devices in networks
CN104283886B (zh) * 2014-10-14 2017-12-29 中国科学院信息工程研究所 一种基于智能终端本地认证的web安全访问的实现方法
CN104283885B (zh) * 2014-10-14 2017-07-28 中国科学院信息工程研究所 一种基于智能终端本地认证的多sp安全绑定的实现方法
CN105631678A (zh) * 2014-10-28 2016-06-01 杭州华三通信技术有限公司 部件防伪方法和装置
US9779232B1 (en) 2015-01-14 2017-10-03 Sprint Communications Company L.P. Trusted code generation and verification to prevent fraud from maleficent external devices that capture data
US10601809B2 (en) 2015-01-20 2020-03-24 Arris Enterprises Llc System and method for providing a certificate by way of a browser extension
US9838868B1 (en) 2015-01-26 2017-12-05 Sprint Communications Company L.P. Mated universal serial bus (USB) wireless dongles configured with destination addresses
US10637840B1 (en) * 2015-02-11 2020-04-28 Gustavo Andres Martinez System and methods to secure and display information transmitted between multiple platforms and multiple applications using the short message service (SMS), for registered users
US11171941B2 (en) * 2015-02-24 2021-11-09 Nelson A. Cicchitto Mobile device enabled desktop tethered and tetherless authentication
US11122034B2 (en) 2015-02-24 2021-09-14 Nelson A. Cicchitto Method and apparatus for an identity assurance score with ties to an ID-less and password-less authentication system
US10193700B2 (en) 2015-02-27 2019-01-29 Samsung Electronics Co., Ltd. Trust-zone-based end-to-end security
KR102303504B1 (ko) * 2015-03-25 2021-09-17 삼성전자 주식회사 무선 통신 시스템에서 단말의 프로파일 설치 방법 및 장치
WO2016153281A1 (ko) * 2015-03-25 2016-09-29 삼성전자 주식회사 무선 통신 시스템에서 프로파일을 다운로드 하는 방법 및 장치
CN106162574B (zh) * 2015-04-02 2020-08-04 成都鼎桥通信技术有限公司 集群系统中应用统一鉴权方法、服务器与终端
US9473945B1 (en) 2015-04-07 2016-10-18 Sprint Communications Company L.P. Infrastructure for secure short message transmission
US10637836B2 (en) 2015-07-02 2020-04-28 Convida Wireless, Llc Content security at service layer
US20170012990A1 (en) 2015-07-08 2017-01-12 International Business Machines Corporation Indirect user authentication
JP2017028418A (ja) * 2015-07-21 2017-02-02 富士通株式会社 無線機器、及び、無線機器の制御方法
CN106453196B (zh) * 2015-08-04 2020-01-07 中国移动通信集团公司 一种针对可信执行环境的密钥写入装置、系统及方法
US10846696B2 (en) * 2015-08-24 2020-11-24 Samsung Electronics Co., Ltd. Apparatus and method for trusted execution environment based secure payment transactions
US10699274B2 (en) 2015-08-24 2020-06-30 Samsung Electronics Co., Ltd. Apparatus and method for secure electronic payment
US9819679B1 (en) 2015-09-14 2017-11-14 Sprint Communications Company L.P. Hardware assisted provenance proof of named data networking associated to device data, addresses, services, and servers
US9825938B2 (en) 2015-10-13 2017-11-21 Cloudpath Networks, Inc. System and method for managing certificate based secure network access with a certificate having a buffer period prior to expiration
US10282719B1 (en) 2015-11-12 2019-05-07 Sprint Communications Company L.P. Secure and trusted device-based billing and charging process using privilege for network proxy authentication and audit
US9817992B1 (en) 2015-11-20 2017-11-14 Sprint Communications Company Lp. System and method for secure USIM wireless network access
WO2017102035A1 (en) * 2015-12-18 2017-06-22 Nokia Solutions And Networks Oy Trust based computing
US9985949B2 (en) 2016-01-25 2018-05-29 International Business Machines Corporation Secure assertion attribute for a federated log in
US10382424B2 (en) * 2016-01-26 2019-08-13 Redhat, Inc. Secret store for OAuth offline tokens
KR20170098105A (ko) * 2016-02-19 2017-08-29 삼성전자주식회사 인증 모듈을 갖는 전자 장치 및 인증 모듈의 동적 제어를 통한 사용자 인증 방법
US10230522B1 (en) 2016-03-24 2019-03-12 Amazon Technologies, Inc. Network access control
US20170289120A1 (en) * 2016-04-04 2017-10-05 Mastercard International Incorporated Systems and methods for authenticating user for secure data access using multi-party authentication system
CN105871869B (zh) * 2016-04-28 2018-11-23 湖南科技学院 移动社交网络中基于单项散列函数和伪身份匿名双向认证方法
WO2017192736A1 (en) * 2016-05-03 2017-11-09 Pegasus Media Security, Llc Methods and apparatus for device authentication and secure data exchange between a server application and a device
US10554722B2 (en) 2016-05-19 2020-02-04 Panasonic Avionics Corporation Methods and systems for secured remote browsing from a transportation vehicle
CN107438241A (zh) * 2016-05-27 2017-12-05 富泰华工业（深圳）有限公司 手机安全锁定系统及锁定方法
WO2018022104A1 (en) * 2016-07-29 2018-02-01 Visa International Service Association Multi-device authentication process and system utilizing cryptographic techniques
US10230710B2 (en) * 2016-08-04 2019-03-12 Visa International Service Association Token based network service among IoT applications
CA3026227A1 (en) 2016-08-30 2018-03-08 Visa International Service Association Biometric identification and verification among iot devices and applications
US10650621B1 (en) 2016-09-13 2020-05-12 Iocurrents, Inc. Interfacing with a vehicular controller area network
EP3321838B1 (en) * 2016-11-14 2019-07-17 Giesecke+Devrient Mobile Security GmbH Java card platform and applet security
US10320771B2 (en) * 2016-11-30 2019-06-11 Airwatch Llc Single sign-on framework for browser-based applications and native applications
US20180167383A1 (en) * 2016-12-12 2018-06-14 Qualcomm Incorporated Integration of password-less authentication systems with legacy identity federation
US9888385B1 (en) * 2016-12-19 2018-02-06 Kwangwoon University Industry-Academic Collaboration Foundation Method for subscriber authentication in cellular IoT device, IoT device for subscriber authentication, and base station apparatus for subscriber authentication
US10574648B2 (en) 2016-12-22 2020-02-25 Dashlane SAS Methods and systems for user authentication
CN110383755B (zh) 2017-01-05 2022-04-19 皇家飞利浦有限公司 网络设备和可信第三方设备
US10341864B2 (en) 2017-03-03 2019-07-02 Verizon Patent And Licensing Inc. Network-based device registration for content distribution platforms
US10805349B2 (en) 2017-03-29 2020-10-13 At&T Intellectual Property I, L.P. Method and system to secure and dynamically share IOT information cross multiple platforms in 5G network
US10432397B2 (en) 2017-05-03 2019-10-01 Dashlane SAS Master password reset in a zero-knowledge architecture
US10499249B1 (en) 2017-07-11 2019-12-03 Sprint Communications Company L.P. Data link layer trust signaling in communication network
US10848312B2 (en) 2017-11-14 2020-11-24 Dashlane SAS Zero-knowledge architecture between multiple systems
US10880291B2 (en) 2018-02-09 2020-12-29 Cisco Technology, Inc. Mobile identity for single sign-on (SSO) in enterprise networks
US10904004B2 (en) 2018-02-27 2021-01-26 Dashlane SAS User-session management in a zero-knowledge environment
EP3759638B1 (en) * 2018-04-05 2024-03-27 Google LLC Domain specific browser identifiers as replacement of browser cookies
US11664995B2 (en) * 2018-04-20 2023-05-30 Vishal Gupta Decentralized document and entity verification engine
GB2575016B (en) * 2018-06-13 2020-10-14 Arm Ip Ltd A technique for authenticating data transmitted over a cellular network
US10484770B1 (en) 2018-06-26 2019-11-19 Amazon Technologies, Inc. Display device with transverse planar microphone arrays
CN109088890A (zh) * 2018-10-18 2018-12-25 国网电子商务有限公司 一种身份认证方法、相关装置及系统
US11176230B2 (en) 2018-12-05 2021-11-16 Bank Of America Corporation Processing authentication requests to secured information systems based on user behavior profiles
US11036838B2 (en) 2018-12-05 2021-06-15 Bank Of America Corporation Processing authentication requests to secured information systems using machine-learned user-account behavior profiles
US11159510B2 (en) * 2018-12-05 2021-10-26 Bank Of America Corporation Utilizing federated user identifiers to enable secure information sharing
US11048793B2 (en) 2018-12-05 2021-06-29 Bank Of America Corporation Dynamically generating activity prompts to build and refine machine learning authentication models
US11316144B1 (en) 2018-12-13 2022-04-26 Amazon Technologies, Inc. Lithium-ion batteries with solid electrolyte membranes
US11356458B2 (en) 2019-03-15 2022-06-07 Mastercard International Incorporated Systems, methods, and computer program products for dual layer federated identity based access control
WO2020216445A1 (en) * 2019-04-25 2020-10-29 Telefonaktiebolaget Lm Ericsson (Publ) Trusted solutions for enabling user equipment belonging to a home network to access data communication services in a visited network
US11844014B2 (en) * 2019-04-27 2023-12-12 Nokia Technologies Oy Service authorization for indirect communication in a communication system
US11176274B2 (en) 2019-05-28 2021-11-16 International Business Machines Corporation Protecting user data
US10846383B2 (en) 2019-07-01 2020-11-24 Advanced New Technologies Co., Ltd. Applet-based account security protection method and system
US11729160B2 (en) * 2019-10-16 2023-08-15 Nutanix, Inc. System and method for selecting authentication methods for secure transport layer communication
US11516202B2 (en) * 2019-12-26 2022-11-29 Vmware, Inc. Single sign on (SSO) capability for services accessed through messages
EP4094401A4 (en) * 2020-02-28 2023-06-21 Samsung Electronics Co., Ltd. METHOD AND DEVICE FOR REMOTE ADMINISTRATION AND VERIFICATION OF A REMOTE ADMINISTRATION AUTHORITY
US11165586B1 (en) * 2020-10-30 2021-11-02 Capital One Services, Llc Call center web-based authentication using a contactless card
US11540202B2 (en) 2020-11-06 2022-12-27 Cisco Technology, Inc. Secure cloud edge interconnect point selection
CN112311805B (zh) * 2020-11-06 2022-04-12 支付宝(杭州)信息技术有限公司 基于可信执行环境的免登认证处理方法及装置
JP2023550622A (ja) * 2020-11-20 2023-12-04 華為技術有限公司 信頼できる端末を決定するための方法および関連装置
US11716316B2 (en) 2020-12-10 2023-08-01 Okta, Inc. Access to federated identities on a shared kiosk computing device
US20220207630A1 (en) * 2020-12-29 2022-06-30 Toby Michael Cohen System and method for authorizing transfer requests of physical locations
US20220224535A1 (en) * 2021-01-14 2022-07-14 Cloudentity, Inc. Dynamic authorization and access management
US11895106B2 (en) * 2021-01-28 2024-02-06 Oracle International Corporation Automatic sign-in upon account signup
US20230015789A1 (en) * 2021-07-08 2023-01-19 Vmware, Inc. Aggregation of user authorizations from different providers in a hybrid cloud environment
CN113946960A (zh) * 2021-10-19 2022-01-18 天津大学 一种基于空间划分的实用动态安全域边界生成系统及方法
US11941266B2 (en) 2021-10-20 2024-03-26 Samsung Electronics Co., Ltd. Resource isolation in computational storage devices

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5590199A (en) 1993-10-12 1996-12-31 The Mitre Corporation Electronic information network user authentication and authorization system
US20010045451A1 (en) * 2000-02-28 2001-11-29 Tan Warren Yung-Hang Method and system for token-based authentication
JP3943897B2 (ja) * 2001-10-30 2007-07-11 株式会社東芝 本人確認システム及び装置
US20060155993A1 (en) * 2003-02-21 2006-07-13 Axel Busboon Service provider anonymization in a single sign-on system
US8333317B2 (en) 2003-09-30 2012-12-18 Broadcom Corporation System and method for authenticating the proximity of a wireless token to a computing device
FI20050384A0 (fi) * 2005-04-14 2005-04-14 Nokia Corp Geneerisen todentamisarkkitehtuurin käyttö Internet-käytäntöavainten jakeluun matkaviestimissä
US7565536B2 (en) * 2005-09-02 2009-07-21 Gemalto Inc Method for secure delegation of trust from a security device to a host computer application for enabling secure access to a resource on the web
US9112705B2 (en) * 2006-02-15 2015-08-18 Nec Corporation ID system and program, and ID method
JP4819542B2 (ja) * 2006-03-24 2011-11-24 株式会社日立製作所 脆弱性検証付きのバイオメトリクス認証システムおよび方法
CN101444063B (zh) 2006-05-09 2013-02-06 交互数字技术公司 用于无线设备的安全时间功能
US20080024454A1 (en) * 2006-07-31 2008-01-31 Paul Everest Three-dimensional touch pad input device
US8275985B1 (en) * 2006-08-07 2012-09-25 Oracle America, Inc. Infrastructure to secure federated web services
US8707409B2 (en) * 2006-08-22 2014-04-22 Interdigital Technology Corporation Method and apparatus for providing trusted single sign-on access to applications and internet-based services
DE102007012749A1 (de) * 2007-03-16 2008-09-18 Siemens Ag Verfahren und System zur Bereitstellung von Diensten für Endgeräte
US20090013391A1 (en) * 2007-07-03 2009-01-08 Johannes Ernst Identification System and Method
JP4820342B2 (ja) * 2007-08-09 2011-11-24 日本電信電話株式会社 ユーザ認証方法、ユーザ認証装置、プログラム及び記録媒体
JP5132222B2 (ja) * 2007-08-13 2013-01-30 株式会社東芝 クライアント装置、サーバ装置及びプログラム
DE102007050836A1 (de) * 2007-10-24 2009-04-30 Giesecke & Devrient Gmbh Internet-Smart-Card
EP2106093A1 (en) * 2008-03-28 2009-09-30 British Telecommunications Public Limited Company Devolved authentication
US20110213959A1 (en) * 2008-11-10 2011-09-01 Nokia Siemens Networks Oy Methods, apparatuses, system and related computer program product for privacy-enhanced identity management
CN102272769A (zh) * 2008-12-30 2011-12-07 诺基亚西门子通信公司 服务访问控制
DE102009004490A1 (de) * 2009-01-09 2010-07-15 T-Mobile International Ag Verfahren und System zur Authentifizierung von Netzknoten eines Peer-to-Peer Netzwerks
US8875232B2 (en) * 2009-02-18 2014-10-28 Telefonaktiebolaget L M Ericsson (Publ) User authentication
US9490984B2 (en) * 2009-09-14 2016-11-08 Interdigital Patent Holdings, Inc. Method and apparatus for trusted authentication and logon

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Trust of User Using U-Key on Trusted Platform;Shuanghe peng 等;《ICSP2006 Proceedings》;20061116;全文 *

Also Published As

Publication number Publication date
KR20140107678A (ko) 2014-09-04
JP5540119B2 (ja) 2014-07-02
KR101684753B1 (ko) 2016-12-08
TWI514896B (zh) 2015-12-21
US20120072979A1 (en) 2012-03-22
JP2013519176A (ja) 2013-05-23
KR20120120955A (ko) 2012-11-02
EP2534810B1 (en) 2014-04-16
TW201216734A (en) 2012-04-16
US8533803B2 (en) 2013-09-10
WO2011100331A1 (en) 2011-08-18
EP2534810A1 (en) 2012-12-19
CN102783115A (zh) 2012-11-14

Similar Documents

Publication Publication Date Title
CN102783115B (zh) 用于可信联合标识的方法和装置
US8881257B2 (en) Method and apparatus for trusted federated identity management and data access authorization
US9185560B2 (en) Identity management on a wireless device
CN103503407B (zh) 用于多sso技术的sso框架
KR101556046B1 (ko) 통신 핸드오프 시나리오를 위한 인증 및 보안 채널 설정
CN105432103B (zh) 接入网络辅助引导自举
US9237142B2 (en) Client and server group SSO with local openID
KR101270323B1 (ko) 단일 서비스 사인 온을 제공하는 방법, 장치 및 컴퓨터 판독가능 저장 매체
US20160087957A1 (en) Multi-factor authentication to achieve required authentication assurance level
US20130227658A1 (en) Openid/local openid security
Hojjati et al. A blockchain-based authentication and key agreement (AKA) protocol for 5G networks
CN103460738A (zh) 用于使网络通信安全的系统和方法
CN103024735B (zh) 无卡终端的业务访问方法及设备
TW201225697A (en) Identity management on a wireless device
SCHMIDT et al. Efficient Application Single-Sign-On for Evolved Mobile Networks
WO2023223118A1 (en) Subscription identification in networks

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1175906

Country of ref document: HK

C14 Grant of patent or utility model
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20160803

Termination date: 20190209

CF01 Termination of patent right due to non-payment of annual fee