一种用户设备以及在用户设备中的方法与流程
本申请是申请日为2012年04月27日、申请号为201280020818.9、名称为“用于多sso技术的sso框架”的中国专利申请的分案申请。
相关申请的交叉引用
本申请要求2011年4月28日申请的序列号61/480,137的美国临时专利申请和2011年10月17日申请的序列号61/548,156美国临时专利申请的权益，申请的内容以引用的方式结合于此。
背景技术：
由于智能电话接入因特网服务的使用增加，移动用户安全要求随之增加。例如银行服务，针对娱乐事件的售票服务等可能需要完整、保密保护以及用户认证。这些要求可能以用户名、个人识别码(pin)以及密码的方式直接对用户施加认证负担。然而，用针对每一个的单独的用户提供的凭证处理许多账户可能潜在地在例如凭证疲劳(fatigue)方面给予用户过多的认证负担。如果用户试图通过使用易于记忆的凭证或跨多个域再使用相同的凭证来简化处理，那么用户可能产生安全弱点。
技术实现要素：
本发明内容用于以简要的形式介绍各种概念，其将在下述的具体实施方式中进一步被描述。本发明内容不意图确立所要求的主题的关键特征或必要特征，也不意图用来限制所要求的主题的范围。
在此公开通过统一的用户接口用于管理针对移动用户的多认证方法的统一框架，以及用于不同认证协议的协议层接口。统一的框架和协议层二者能够实现到终端用户的无缝认证服务。此外，还公开了涉及支持多服务提供方的多接入域的实施方式。
在此描述的实施方式可以提供全面的单点登录(sso)构架，其可以允许到用户的灵活的和/或无缝的经验。用户认证接口可以充当用户/应用实体(例如浏览器或非浏览器应用)和sso子系统之间的边界。在示例实施方式中，sso子系统可由移动网络运营方(mno)控制。sso子系统可以支持各种用户多因子凭证输入，例如生物计量、密码、pin和/或其他用户凭证输入。用户认证接口还可以提供用于改变认证强度等级(strengthlevel)。网络认证接口可以充当sso子系统和网络辅助认证技术或协议模块阵列之间的边界，该阵列可以允许在单个结构框架中提供多个sso机制。功能结构可以提供当与服务提供方(例如开放id(openid)信赖方)，认证时，将用户辅助认证从网络辅助认证(例如sso网络辅助认证)分离开来。
在示例实施方式中，用户设备(ue)可以包括被配置成与服务提供方通信以接入服务的用户应用。ue可以进一步包括多个网络辅助认证模块。每个网络辅助认证模块可以对应不同的网络辅助认证协议。例如网络辅助认证模块可以被配置成执行与服务提供方的网络辅助认证以接入服务。ue可以进一步包括单点登录(sso)子系统，sso子系统被配置成基于在ue和/或网络的用户辅助认证信息认证ue的用户。sso子系统可以进一步操作来选择多个网络辅助认证模块中的网络辅助认证模块，用于执行与服务提供方的网络辅助认证。sso子系统进一步可以被配置成执行用户辅助认证和基于一个或多个策略选择网络辅助认证模块。在另一示例实施方式中，ue可以检测服务提供方的一个或多个数据字段。响应于检测数据字段，ue的恳请者(supplicant)可以用对应的认证数据自动填充(populate)数据字段。
在此描述的系统、方法或手段的其他特征在下述具体实施方式和附图中提供。
附图说明
图1a是可以在其中实施一个或多个公开的实施方式的示例通信系统的系统图；
图1b是可在图1a中示出的通信系统中使用的示例无线发射/接收单元(wtru)的系统图；
图1c是可在图1a中示出的通信系统中使用的示例无线电接入网络和示例核心网的系统图；
图2示出了使用多sso技术的架构框架的示例实施方式；
图3a和图3b示出了用于sso框架架构的协议流的示例实施方式；
图4示出了使用多sso协议的架构框架的另一示例实施方式；
图5是根据实施实施方式使用gba互通的示例sso子系统的框图；
图6示出了包括用于方便使用多sso协议的可下载部件的架构框架示例实施方式；
图7显示了具有接口部件的sso系统的示例实施方式的框图；
图8示出了用于具有恳请者的sso框架架构的协议流程的示例实施方式；
图9显示了用于具有本地断言实体(lae)的sso框架架构的协议流的示例实施方式；
图10显示了用于具有集成的op的sso框架架构的协议流的示例实施方式；
图11显示了用于具有预取(pre-fetch)的sso框架架构的协议流程的示例实施方式；
图12显示了用于具有存储在服务提供方中的java小应用的sso框架架构的协议流的示例实施方式；
图13显示了用于具有缓存的java小应用的sso框架架构的协议流程的示例实施方式；
图14显示了用于具有联机(on-the-fly)供应(provision)的sso框架架构的协议流的示例实施方式；以及
图15显示了用于具有集成的工具箱的sso框架架构的协议流的示例实施方式。
具体实施方式
用户，例如移动用户，可能期望用于接入因特网服务的可用安全和/或无缝方式从而最小化甚至完全消除在凭证供应中的用户交互。在示例实施方式中，单点登录(sso)身份(identity)管理(idm)可以包括用于提供具有各种特性的sso实施的方式，在启用用于接入期望的服务的用户辅助和网络辅助认证时，通过该方式可以为用户提供这样简便的使用。用户辅助认证可以涉及使用来自用户的输入的认证。这样的用户输入可以是半自动(例如存储在浏览器中)或由用户输入。例如，用户辅助认证可以基于用户知道的参数(例如用户名，密码)和/或用户的特性(例如动态签名，虹膜扫描，指纹，或其他生物计量测量)。网络辅助认证可以涉及基于用户拥有的实体(例如包括加密密钥和协议的uicc)的用户认证。例如，网络辅助认证可以涉及通过网络运营方提供的用于网络接入的功能重新使用(例如通用引导(bootstrapping)架构(gba)协议)的用户的sso认证。例如，gba可以基于秘密密钥和协议的重新使用(例如在uicc中)生成sso认证，该协议可以提供到蜂窝网络和/或ims的接入。每个用户辅助认证输入和网络辅助认证输入可以称为认证因子。sso实施的各种特性可以包括，例如，具有无缝认证因子的sso，具有单个凭证组的sso，以及完整的sso。具有无缝认证因子的sso可以指在用户辅助认证成功之后自动进行(例如无用户交互)的网络辅助用户认证。具有单个凭证组的sso可以指用户可以使用单个凭证组(例如用于用户辅助认证)来与多服务提供方认证的实施。在示例实施方式中，单个凭证组可以在每次用户接入不同服务提供方时被提供。在使用完整的sso实施的示例实施方式中，用户可以被认证以接入服务提供方，并且随后获得对其他服务提供方的接入而无需立即再次认证。例如，完整的sso实施可以包括具有无缝认证因子的sso。
在此描述的用于通过统一的用户接口管理针对移动用户的一个或多个认证方法的统一框架，以及用于不同认证协议的协议层接口。统一框架和协议层二者可以实现到终端用户的无缝认证服务。此外，还描述了涉及支持多服务提供方的多接入域的实施方式。
在此描述的实施方式可以提供全面的sso架构，其可以允许到用户的灵活的和/或无缝的经验。用户认证接口可以充当用户/应用实体(例如浏览器或非浏览器应用)和sso子系统之间的边界。在示例实施方式中，sso子系统可由移动网络运营方(mno)控制。sso子系统可以支持各种用户多因子凭证输入，例如生物计量，密码，pin，和/或其他用户凭证输入。用户认证接口还可以提供改变认证强度等级。网络认证接口可以充当sso子系统和网络辅助认证技术或协议模块阵列之间的边界，该阵列可以允许在单个结构框架中提供多个sso机制。功能结构可以提供将用户辅助认证从网络辅助认证(例如sso网络辅助认证)分离开来。
sso子系统可以提供用户凭证的存储和/或处理，其中这样的存储可以在或不在可信计算环境(例如uicc，智能卡，或其他安全可信(trusted)环境)上，并可以提供多个安全等级。在可信计算环境上包括的存储可以支持用户凭证的重新使用。sso子系统充当在确定执行的安全等级和决定使用的sso协议中，执行外部利益相关者(stakeholder)(例如mno)的功能和/或策略的代理。从实施的立场，可能不划分任何sso功能位于安全可信环境(例如uicc，智能卡，或其他安全可信环境)上或下。
示例实施方式提供单独的、隔离(isolated)的sso客户端。在示例实施方式中，每个sso客户端服务不同的服务提供方，但在某种程度上同时允许多可用连接协议的基于策略的管理和/或由相同提供方提供的服务。
另一示例实施可以允许多个本地断言实体(lae)。lae可以指位于ue上的功能实体。例如，lae可以提供关于用户身份的可信断言和/或到远程实体的认证。在示例实施方式中，本地op可以指用于向rp提供开放id断言的lae的实例。每个lae可以在uicc上的接入技术特定域中实施，并且每个可以专用于一个隔离的域。相同接入技术可以在不同lae之间复用，或不同接入技术可以由lae一起使用。依据该实施，lae和sso客户端之间的关系可以是一对一或其中一个sso可以控制多个lae或由多个lae服务。
在此描述的实施方式可以便于在无线设备中认证协议的执行。例如，恳请者可以用来便于执行用于无线设备和网络实体的开放id认证处理，网络实体可以例如是信赖方(rp)或开放id身份提供方服务器(op)。根据示例实施方式，恳请者可以被实施为java小应用(applet)。恳请者可以实现用于认证方案(例如开放id认证)的网络辅助认证机制，非浏览器应用或浏览器应用原本不支持该认证机制。例如，恳请者可以与单点登录(sso)子系统对接，而sso子系统对接例如gba、aka、sip摘要(digest)以及eap-sim的网络辅助认证协议。给定在移动设备(例如智能电话平台)上可用的大范围的平台处理器架构、操作系统以及软件，恳请者可以提供到sso子系统的可以执行sso认证功能的网络认证接口。恳请者，例如，可以当与网络和/或接入层认证模块(例如gba模块，uicc)互操作时，使应用和/或浏览器便于自动和/或无缝认证。通过从rp和/或op下载恳请者部件(piece)，例如，恳请者可以在开放id认证协议期间无缝地提供设备特定软件。
在此描述的实施方式可以与例如开放id的联合认证协议一同工作，并且还可以例如与lae一同工作。例如，开放id可以绑定到网络辅助认证。在此描述的实施方式可以用来确定浏览器和/或非浏览器应用如何与接入层(例如uicc/非uicc)网络辅助认证机制通信。例如，恳请者和sso子系统可以提供与浏览器和/或非浏览器应用和网络辅助认证机制的自动和/或无缝操作。恳请者可以展示到sso子系统的统一接口并代表用户执行用于各种认证协议(gba、aka、eap-sim)的自动和/或无缝认证。可以下载的应用或组件，例如签名的java小应用，可以被下载(例如从rp和/或op)，并可以与不同非应用层和/或接入层认证协议一同工作。组件可以以统一的方式对接到sso子系统和浏览器/应用。
图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的一部分，所述ran104还可包括其他基站和/或网络元件(未示出)，例如基站控制器(bsc)、无线电网络控制器(rnc)、中继节点等等。基站114a和/或基站114b可被配置成在特定地理区域内传送和/或接收无线信号，所述特定地理区域可被称作小区(未示出)。所述小区可进一步划分为小区扇区。例如，与基站114a相关联的小区可划分为三个扇区。因而，在一个实施方式中，基站114a可包括三个收发信机，即小区的每个扇区使用一个收发信机。在另一个实施方式中，基站114a可使用多输入多输出(mimo)技术，并且因此可使用多个收发信机用于小区的每个扇区。
基站114a、114b可通过空中接口116与wtru102a、102b、102c、102d中一个或多个进行通信，所述空中接口116可以是任何适当的无线通信链路(例如，射频(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通信，所述基站114a可以使用基于蜂窝的无线电技术，以及与基站114b通信，所述基站114b可以使用ieee802无线电技术。
图1b是示例的wtru102的系统图。如图1b所示，wtru102可以包括处理器118、收发信机120、发射/接收元件122、扬声器/麦克风124、键盘126、显示器/触摸板128、不可移动存储器130、可移动存储器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可以被配置为传送和/或接收无线信号的任何组合。
此外，虽然发射/接收元件122在图1b中示出为单独的元件，但是wtru102可以包括任意数量的发射/接收元件122。更具体地说，wtru102可以使用mimo技术。因此，在一个实施方式中，wtru102可以包括通过空中接口116传送和接收无线信号的两个或更多个发射/接收元件122(例如，多个天线)。
收发信机120可以被配置为调制要由发射/接收元件122传送的信号，和解调由发射/接收元件122接收的信号。如上所述，wtru102可以具有多模式能力。因此，收发信机120可以包括使wtru102能够经由多个rat通信的多个收发信机，所述多个rat例如有utra和ieee802.11。
wtru102的处理器118可以耦合到下述设备，并且可以从下述设备接收用户输入数据，扬声器/麦克风124、键盘126和/或显示器/触摸板128(例如，液晶显示器(lcd)显示单元或有机发光二极管(oled)显示单元)。处理器118还可以输出用户数据到扬声器/麦克风124、键盘126和/或显示/触摸板128。此外，处理器118可以从任何类型的适当的存储器中访问信息，并且可以存储数据到所述存储器中，例如不可移动存储器130和/或可移动存储器132。不可移动存储器130可以包括随机存取存储器(ram)、只读存储器(rom)、硬盘或任何其他类型的存储器设备。可移动存储器132可以包括用户身份模块(sim)卡、记忆棒、安全数字(sd)存储卡等等。在其他的实施方式中，处理器118可以从物理上没有位于wtru102上(例如在服务器或家用计算机(未示出)上)的存储器中访问信息，并且可以将数据存储在所述存储器中。
处理器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可以包括一个或多个提供附加特性、功能和/或有线或无线连接的软件和/或硬件模块。例如，外围设备138可以包括加速计、电子罗盘、卫星收发信机、数字相机(用于图像或视频)、通用串行总线(usb)端口、振动设备、电视收发器、无绳耳机、
图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的上下文(context)，等等。
服务网关144还可连接到pdn网关146，所述pdn网关146可向wtru102a、102b、102c提供对例如因特网110的分组交换网的接入，以便于wtru102a、102b、102c和ip使能设备间的通信。
核心网106可便于与其它网络的通信。例如，核心网106可向wtru102a、102b、102c提供对例如pstn108的电路交换网的接入，以便于wtru102a、102b、102c和传统陆线通信设备间的通信。例如，核心网106可包括或可与用作核心网106和pstn108之间的接口的ip网关(例如，ip多媒体子系统(ims)服务器)通信。此外，核心网106还可向wtru102a、102b、102c提供对网络112的接入，所述网络112可包括由其它服务提供商拥有和/或操作的其它有线或无线网络。
图2示出了用于使用多sso协议和/或模块的架构框架的一个实施方式。如图2所示，sso子系统206可以与被配置成从服务提供方接入服务的应用(例如浏览器应用202和/或非浏览器应用204)通信。应用(浏览器应用202和/或非浏览器应用204)可以是用户与其交互的应用。使用浏览器应用202和/或非浏览器应用204，用户可以接入各种服务(例如网站，银行服务，针对娱乐事件的售票服务，和/或由服务提供方提供的其他服务)。
sso子系统206可以充当用于sso过程的集线器(hub)。在示例实施方式中，sso子系统206可以是运营方控制的。sso子系统206可以通过执行用户认证(例如用户辅助或网络辅助)充当网络网络代理。此外，sso子系统206可以执行后继产生和/或提交签名的或可信赖地用户身份断言和/或认证断言到服务提供方和/或身份提供方以用于网络辅助认证。sso子系统206的一些功能，例如安全存储和处理，可以在安全可信环境218中执行。
图2所示的构架可以将用户辅助认证经历与个体自足完备(self-contained)的网络辅助认证技术(例如也称为sso技术或sso协议或sso代理)合并，其中的一些可以使用网络辅助认证来执行用于认证和密钥交换的引导机制。例如，sso子系统206可以与多个认证模块208，210，212，214，和/或216通信，每个能够使用不同网络辅助认证协议执行与服务提供方的网络辅助认证。这些网络辅助认证模块208，210，212，214，和/或216可以用来基于预先安装的凭证，例如数字证书，共享主秘密，或任何其他使用不同被支持的认证方案的注册方法，提供到期望服务的安全用户接入。根据示例实施方式，认证模块可以包括开放id/sip摘要模块208，另一开放id模块210，开放id/gba模块212，开放id/isim模块214，和/或开放id/aka模块216。虽然如图2所示的每个网络辅助认证模块实施开放id网络辅助认证协议，但其他类型的网络辅助认证协议也可以或可替换地被实施。
网络辅助认证模块的一个或多个可以由给定服务提供方和/或身份提供方支持。每个网络辅助认证模块可以被配置成通过实施其对应认证协议，例如通过使用认证算法，来执行网络辅助认证。开放id/gba模块212，开放id/isim模块214，和/或开放id/aka模块216可以与安全可信环境218通信。安全可信环境218可以包括例如uicc，智能卡，或其他安全可信环境。在示例实施方式中，安全可信环境218可以是ue上基于硬件的实体，并可以负责安全存储敏感数据(例如加密密钥，订户凭证)和执行敏感功能的安全处理(例如加密计算)。
图2所示的组件的一个或多个可以驻在移动通信设备中。虽然图2示出所描述的构架中的功能性模块，但图2不意味着要求任何非应用功能在或不在安全可信环境218上。在此更详细地描述组件及其交互。虽然参照开放id协议描述认证，但相同的概念可以应用于其他认证协议，例如自由联盟。
用户可以使用应用(例如浏览器应用202和/或非浏览器应用204)来完成到服务提供方(例如信赖方(rp))(例如网络应用服务提供方)的初始访问。服务提供方(例如rp)可以接收用户标识(identification)，其例如可以是开放id用户标识符(identifier)。在开放id的情况下，在rp发起的发现之后用户可以被重定向(例如发现机制可以使用开放id提供方(op)身份来确定op的因特网地址)到基于网络的身份管理实体的，其例如可以是op。在示例实施方式中，op身份可以用来向rp提供op的因特网地址。接着可以开始认证过程。
sso子系统206可以提供用于实现与应用的通信的用户认证接口(用户在应用侧与该应用交互)以及用于网络辅助认证模块208，210，212，214，和/或216的网络认证接口。因此不同的应用(例如浏览器应用202和/或非浏览器应用204)可以基于用户输入提供输入到sso子系统206，或sso子系统可以向用户展示认证屏幕来实现与服务提供方的用户的网络辅助认证和/或与ue的本地用户辅助认证。不同的网络辅助认证模块210，212，214，和/或216(例如sso协议)可以被设计成与sso子系统206交互。策略管理还可以由sso子系统206执行。
sso子系统206认证结构可以具有两种类型的用户认证，用户辅助认证和网络辅助认证。这类型二者可被分离使得一个独立于另一个发生，但二者相互绑定(例如经由sso子系统产生的断言)并且互相交互(例如用户辅助认证可以触发网络辅助认证或反之亦然)。用户的用户辅助认证和从用户供应凭证到sso子系统206(用于用户辅助认证)可以独立地发生并可以从网络辅助认证协议解耦合。用户可以从网络辅助认证协议隔离(shield)。与单个用户凭证组可以独立于服务提供方的事实一起，这种透明可以导致针对用户的无缝sso经验。而且，两种认证类型可以提供通过其凭证，是它的生物计量，密码，pin，令牌，另一用户凭证，或它们的组合，用户要求的身份与uicc中保有的订户凭证或设备身份，例如imsi或impi，的绑定。与两种类型的认证的架构解耦合一起，这样的绑定可以通过充当中间层的sso子系统来实现。sso子系统可以通过自身或如在此所述的通过到较低层认证协议之一的调用(call)来执行加密绑定。
sso子系统206可以起到作为外部利益相关者(stakeholder)(例如mno)的网络辅助认证功能的代理的作用，并向外部利益相关者提供关于被供应的策略功能的信息。当用户发起到服务的接入(例如通过在web浏览器上键入url或启动应用)，可以发起用户辅助认证过程。例如，用户可以被请求来输入用户凭证，例如生物计量凭证和/或例如pin的密码。在示例实施方式中，移动通信设备可以具有接入设备本身的pin特征，其还可以是用户凭证信息的一部分。例如，ue的用户接口可以通过特定的接口向sso子系统206传达用户辅助认证凭证信息，被接入的服务(例如以weburl或激活的应用的形式)，和/或其他与将被使用的服务相关的信息。这样的传达可以基于提供的信息和供应的策略来激活sso子系统206内的功能来认证用户。例如来自用户辅助认证的参数可以被提供到网络辅助认证协议。这样的参数可以包括，例如用户辅助认证的信任等级，用户辅助认证的结果(例如通过或失败)，以及用户指派认证的时间。sso子系统206可以运行策略功能，其可以包括各种认证相关的参数，例如被认为足够用于被接入的服务的认证的信任(确信)等级和认证最少的新鲜度(freshness)(例如完成的时间)。例如用户可能希望使用银行服务，用于支付账单的目的。在这种情形下，供应的策略可以要求用户辅助认证的强形式(例如多因子)，并且被供应的策略可以需要只是在到导航用户到服务之前执行认证。如果对服务(例如电子邮件接入)期望低安全等级，则策略可以放松用户辅助认证要求。例如，pin可以用于具有低安全等级的用户辅助认证。在示例实施方式中，导出认证的策略可以由外部利益相关者和/或服务提供方执行。例如，策略功能可以在服务提供方(例如在网络上)，在ue(例如本地)，或二者的结合(例如分布式功能)被执行。
在示例实施方式中，sso子系统206遵照的策略可以确定什么sso认证协议(例如网络辅助认证模块208，210，212，214，和/或216)将被选择用于网络辅助认证。网络辅助认证模块的标准(例如sso认证协议)选择可以基于可用资源和将要接入的服务的安全要求。内部策略机制可以包括外部利益相关者(例如mno)提供的优选认证模块(例如sso协议)的优先化列表。一旦做出策略决定，sso子系统206可以提供用于向外部利益相关者(例如mno)传送哪个特定网络辅助认证模块已经被选择用于协议交换的机制。可替换地，sso子系统可以协商能力并对将被使用的认证模块达成一致。
图3a和图3b示出使用sso框架架构实施的协议的示例实施方式。在开放id的上下文中，sso子系统可以以安全的方式执行某些功能，其中的一些功能参考图3a和图3b中的调用流在此描述。
如图3a和3b所示，在314，可以执行用户辅助认证。例如，可以认证和处理用户凭证。用户凭证可以包括与用户302关联的唯一认证参数，例如用户pin，密码，用户标识符，生物计量信息，或摘要，和/或其他形式的用户辅助认证参数。用户302可以在设备304被本地认证，或与远程实体(例如外部利益相关者(例如mno)或身份提供方(idp)(例如开放id提供方312))结合被认证。
sso子系统308可以是在用户设备304上被配置成执行用户302的认证的本地实体。sso子系统308可以根据各种实施方式执行与或不与lae的认证。例如，图3a示出可以使sso子系统能够本地执行认证的示例供应协议流，如在此所述。一旦用户辅助认证完成，sso子系统308可以生成认证结果，例如认证断言，在316。认证断言可以包括数据，例如完成用户辅助认证的时间，以及认证的信任等级。信任等级可以指远程方可以在用户或ue的认证中置于的确信等级。用户辅助认证结果(例如通过或失败)可以安全和本地存储在设备304和/或与网络辅助认证协议一起使用。与用户辅助认证关联的其他参数也可以被存储和/或在网络辅助认证中使用。例如，这些参数可以包括认证的时间，认证的强度，和/或认证参数的类型。这些参数可以与认证结果一起存储或在网络辅助认证中使用。例如，sso子系统可以使用该信息中继认证数据到服务提供方，并且服务提供方可以确定认证数据是否足够用于提供到服务的用户接入。在314的用户辅助认证可以发生在任何时间，并且如基于各种认证策略(例如期望的安全强度)所建议的频繁或不频繁地发生。在示例实施方式中，如果存储了有效的用户辅助认证结果，sso子系统可以确定不需要执行用户等级认证。这样的情形可以允许用户接入多个服务提供方(例如rp)，无需在认证过程中的进一步的用户参入。例如如果策略针对特定服务提供方的特定服务的接入要求新的认证，则重新使用现有的认证信息可以不被允许。
在318，共享秘密密钥可以在rp310和op312之间建立。例如，用户的op登录请求，其可以包括用户提供的标识符，可以从应用306(例如浏览器或非浏览器应用)传递到rp310，这可以触发共享秘密密钥密钥的关联或建立。根据一个示例实施方式，登录请求可以在用户初始尝试接入基于网络的服务时被传递到rp310。基于接收的登录请求，可以执行关联，这可以建立op312和rp310之间的共享秘密密钥。在示例实施方式中，在320，密钥(例如从op312和rp310共享密钥导出的密钥和在网络辅助认证期间导出的密钥)和/或其他凭证可以供应给sso子系统308。供应的凭证可以用于如在此所述的与服务的进一步认证。
例如，网络辅助认证可以在供应之后执行，如图3b所示。例如，网络辅助认证可以遵循由rp310进行的至op312的重定向。重定向可以由应用306(例如浏览器应用或非浏览器应用)接收，其可以在321重定向消息到sso子系统308，用于选择网络辅助认证模块和/或协议。网络辅助认证模块/协议(例如sso协议)可以由sso子系统308经由策略实施选择和使用。这个过程可以包括引导和共享密钥建立，如在此进一步所述。
如图2所示，多个网络辅助认证协议方法可以由网络辅助认证模块(例如sso协议)族暗示。再次参考图3b，根据示例实施方式，开放id/sip摘要和/或开放id/gba可以被视为处理gba结构，并且使用第三代合作伙伴计划(3gpp)技术规范(ts)编号33.220(版本10)中指定的机制。在开放idgba中，uicc订户凭证可以用来引导将与网络共享的主会话密钥(例如表示ks)。网络辅助认证可以导致应用特定密钥ks_naf从ks导出并在op312和用户设备304之间共享。当与op312认证时，应用特定密钥可以由用户设备304用作密码。例如，它可以由用户设备304用作密码，如在3gpp技术规范(tr)编号33.924(版本9)中所述。
对于开放id/sip摘要，通过类似gba过程得到类似密钥结构。网络辅助认证的这个方法可以是基于非uicc的并且例如可以使用sip摘要凭证，而不是uicc凭证。一个开放id/sip摘要的示例实施方式在3gpptr33.914(版本11)中描述。
对于开放id/aka，网络辅助认证可以是基于非gba的，并且用户设备304和op312可以直接使用3gppaka来认证和共享密钥。开放id/aka的一个示例实施方式在3gppsa3的阿尔卡特-朗讯pcrs3-100757中描述。
对于常规的开放id，sso子系统308可以在网络辅助认证协议中提供接收到的用户凭证。
尽管开放id/gba、开放id/sip摘要以及开放id/aka可以具有结构差异，从网络归属订阅服务器(hss)接收到的一种类型或另一类型的认证向量(av)的应用可以是各协议的中心。此外，依赖于策略和期望的安全强度，用户的重新认证(用户辅助认证)可以在执行网络辅助认证时被执行。在示例实施方式中，在这样的网络认证期间，可以假设设备已经建立网络连接，并且网络辅助认证可以用来与服务提供方认证ue。
在网络辅助认证成功之后，sso子系统308可以向应用306提供网络辅助认证成功的指示。例如，sso子系统(例如经由lae)可以在322签名认证断言(例如身份断言)，并且在324发送断言消息到rp310。从sso子系统308到rp310的签名的断言消息可以指示认证成功，并可由sso子系统308用之前供应的凭证(例如在图3a中在320所示)自动地签名。网络辅助认证成功的通知可以在用户获得对在rp310的期望服务的接入之前执行。在认证过程(例如sso过程)的早期，已经执行关联来建立op312和rp310之间的共享秘密密钥。在一个示例实施方式中，断言消息可以用这个共享秘密密钥签名和/或是密钥的导出。一旦rp310和/或用户设备304(例如经由应用306)已经接收到网络辅助认证成功的指示，用户设备304(例如经由应用306)可以接入在rp310的服务，用户设备304登录到该rp310。
提供到rp310的断言消息可以指示到网络和到服务的认证完成以及在用户辅助认证中实施的用户要求的身份可以绑定到订户凭证，例如实施在网络辅助认证中的imsi或impi。例如，它可以是选择的sso功能的一部分，经由看见用户提供的凭证和基于uicc(或sip摘要)凭证之间的连接的机制执行绑定。断言消息可以包括指示绑定作为全部sso协议一部分的信息。而且，在示例实施方式中，断言消息可以提供认证强度或信任等级(例如低，中，高，非常高)。例如，断言消息中的低认证强度可以指示op312在断言的身份中具有很少或不具有信任(例如具有针对密码格式的最少规则的用户名/密码的自动插入)；中认证强度可以指示op312在断言的身份中具有一些信任(例如具有应用到密码的格式的规则用户名/密码的手动使用)；在断言消息中的高认证强度可以指示op312在断言的身份中具有高信任等级(例如使用生物计量或加密的网络接入令牌以及用户名/密码)；以及非常高认证强度可以指示op312在断言的身份中具有非常高的信任等级(例如生物计量和加密的令牌)。在示例实施方式中，“低”和“中”等级可以指示只使用用户凭证，而“高”和“非常高”等级可以要求进行网络辅助交互，并且要求更强形式的认证，例如生物计量和密码。
再次参照图2，图2示出示例性sso技术(协议)，其可以用于网络控制的引导和密钥建立。例如，开放id/isim214和开放id/aka216可以是基于uicc的，并且可以利用凭证，例如与网络共享的秘密，其可以安全地驻在uicc上。例如依据与网络共享的凭证，开放id/gba212可以是或可以不是基于uicc的。在示例实施方式中，开放id/sip摘要208可以不是基于uicc的。例如，可以提供常规的用户提供的开放id身份和密码。sso子系统的网络认证接口可以允许在单个架构框架中提供各种sso协议(例如图2中的模块208，210，212，214，216)。
根据示例实施方式，可以用两个认证类型绑定来验证用户。虽然用户验证可以参考开放id协议描述，但相同的概念可以应用到其他认证协议，例如自由联盟。例如，ue一通电，用户辅助认证可以发生。例如，用户可以提供用户辅助认证凭证(例如pin，生物计量)来获得对设备功能的接入。例如，用户可以提供pin来获得对iphone的接入。这样的认证机制可以在上电提供一次或在整个会话间歇地提供。认证用户的频率要求可以是策略驱动的。sso子系统可以验证用户提供的pin并且可以保存结果，其可以是断言的形式，确认pin已经被输入并被验证。这样的断言可以建立用户辅助认证。在用户辅助认证建立之后，用户可以试图登录服务提供方(例如rp)，该服务提供方例如可以通过定向web浏览器到rp网页来支持开放id协议。sso子系统可以检查用户辅助认证的状态，并且如果状态有效，可以向rp提供用户身份。rp可以执行开放id提供方(op)的发现，并且两个实体可以建立关联。这样的关联可以导致共享密钥。设备可以被重定向到lae，该lae可以是由sso子系统执行的在ue上的本地开放id代理功能。在示例实施方式中，由sso执行的策略(例如外部利益相关者的)可以要求执行强壮的网络辅助认证(例如gba，sip，aka)。可以选择认证模块(例如sso协议)。在认证协议中，这样的选择可以例如由sso子系统报告给mno。可以使用选择的网络辅助认证模块(例如sso协议)执行ue的认证。在示例实施方式中，选择的认证协议可以导致网络辅助认证功能和ue之间共享的应用特定密钥的引导。这样的密钥可以用来认证ue。
ue可以接收认证完成的指示，并且lae可以签名到rp的断言消息，指示已经发生强壮的认证。断言可以指示用户辅助认证(例如经由初始用户pin输入)和随后的网络辅助认证(例如经由选择的sso认证协议)之间的绑定。断言可以指示在此定义的认证信任等级中的一个。断言消息可以用通过本地sso代理(例如lae)和rp之间的关联建立的密钥来签名。rp和lae可以不直接通信，并且因而op服务功能(opsf)可以在网络上被产生以便于两个实体之间的通信。在示例实施方式中，opsf由rp经由公共因特网可达，好像rp是op一样，可以与这个opsf通信。本地sso(lae)代理可以通过opsf密钥分发机制获得关联密钥。opsf还可以支持关于源自lae的签名的断言的针对rp的签名验证。用户可以接着可以被无缝地定向到rp网页。在示例实施方式中，当用户后来希望接入不同的服务提供方时，sso子系统可以检查用户辅助认证结果是否已经存储以及这个认证是否仍然有效(例如根据本地存储的策略)。如果具有有效存储的结果，例如，sso子系统可以此时不执行用户辅助认证。新的服务提供方可以接着执行如在此所述的身份提供方的发现。因此，用户可以接入新的服务提供方而无需在ue输入凭证，并且用户可以不参与网络辅助认证。根据实施方式，这样的情形可以组成完整的sso实施。
在示例实施方式中，用户可以通过优选的服务和/或应用的注册接入优选的(例如附属的)服务。例如，web或其他在线应用服务提供方(如信赖方)可以使用服务提供商选择的idp注册到运营方的基于网络的sso系统。例如，支付交易提供商可以使用开放id来获得来自特殊idp的委托认证，其可以导致支付交易提供方成为附属的服务。注册可以由服务提供方(例如rp)，所选择的idp，运营方的sso系统，或服务的终端用户发起。进一步地，注册可以由接入网页的用户或驻在ue的sso子系统发起。例如，驻在ue的sso子系统可以变成“同步”到基于网络的sso子系统的数据库，并且从而变成知道注册的附属的服务和应用的列表和类型。
当没有明确选择sso协议时，rp可以被允许选择idp。根据示例实施方式，在idp的选择和将要使用的sso协议之间可以存在隐式(implicit)的关联。例如，rp可以选择特定idp，因为该idp可以支持特定sso协议，例如开放id。
用户接着可以使用ue接入sso(例如开放id)支持的基于web的应用服务。驻在ue的sso子系统可以符合运营方供应的策略，并可以选择注册的附属服务/应用和/或优选的服务/应用。驻在ue的sso子系统还可以在用户指示(例如经由在url中键入(typing))他或她的优选服务后，还可以拦截(介入(intervene))，并且可以用对应于相同服务的注册的、附属的版本的可替换服务的url转换或替换用户键入的url。这样的替换服务可以由相同的服务提供方提供，但可以根据优先的、附属的基础被展示和接入。例如，接入限于运营方服务的ue的用户，该运营方具有到前述服务/应用的前述基于注册的附属(例如，以及可以提供这样服务/应用的idp和rp)。
根据示例实施方式，在服务/应用的选择之后，ue可以代表用户以透明(transparent)和/或无缝的方式选择优选的接入网络辅助认证机制和合适的凭证。例如，ue可以在sso认证协议中指示所选择的接入网络辅助认证机制。网络可以识别所选择的优选接入网络辅助认证机制，并可以认证用户。一认证成功，可以发生sso操作的剩余部分(例如ue重定向到rp来获得服务)。
如在此所述，通过连接到作为运营方的sso系统的运营方的信任基础架构，订阅的附属的服务可以有效地获取由运营方提供的网络辅助认证强度。
更一般地，在此描述sso架构可以视为包括更正式的功能层级。例如，sso子系统可以管理一个或多个sso客户端(例如或本地sso代理)。如果下面的设备技术支持多服务提供方配置，那么多个sso客户端可以作为sso子系统中多服务管理器的子功能运行。这个一般化的架构可以提供用来支持具有潜在独立策略的多个服务的分离。
在这样框架中的每个sso客户端可以管理多个下属的(subordinate)子功能。例如，本地断言子功能可以由本地断言实体(lae)执行。lae可以涉及正式指定的执行本地断言的子功能。例如，依据实施，一个或多个lae可以由sso客户端控制。例如，配置可以涉及sso客户端-lae对(一对一)或一个客户端控制多个lae。在两者之一的配置中，sso客户端可以是控制实体。sso认证协议还可以在此称为sso技术。例如，sso客户端可以控制由所选择的sso认证协议实现的机制的处理。sso客户端可以管理策略执行动作，该策略执行动作可以确定使用哪个认证方法。例如，被应用的策略可以在例如mno的外部利益相关者的控制之下。
根据另一实施方式，ue可以支持多个sso客户端作为在多服务管理器中的子功能运行的实施。这样的实施可以视为环境中的功能，在该环境中不同服务提供方可以需要单独的、隔离的sso客户端专门服务这个特殊提供方，而同时允许由相同提供方提供的多个可用连接技术和服务的基于策略的管理。例如，me可以具有sso客户端a和sso客户端b，并且这些sso客户端的每一个可以被单独控制并且相互隔离。sso方面可以对提供方是特定的。
在一个示例实施方式中，与多个sso客户端一起，可以存在多个lae。例如，每个lae可以在ue上的接入技术特定域中实施。由于sso客户端隔离，每个隔离的域可以有一个lae。而且，例如，lae可以根据设备支持的可用接入技术被构建。相同的接入技术可以在不同的lae之间复用，或者不同接入技术可以由lae一起使用。因此，ue可以支持多lae。依据实施，例如lae和sso客户端之间的关系可以是一对一或一个sso客户端可以控制多个lae或由多个lae服务。
如在此所述，在sso子系统中执行的功能可以用各种方式配置。在ue中，例如，在基于uicc和基于非uicc(或可替换地安全环境)的架构之间可以存在划分。还可以在ue和mno网络之间存在功能的界限。下面是根据不同实施方式的一些可能配置。
加密aka功能可以驻在非uicc智能卡。这样的功能可以在例如g&d的msc的完全可编程非uicc智能卡上执行，并且与网络辅助认证(例如aka)类似，但该卡是可移动的并且在用户控制之下。加密功能可以驻在uicc上。这样的功能可以包括在uicc上实施的lae的基本(elementary)加密功能，例如，密钥导出和断言签名。功能可以类似于网络辅助认证(aka)。此外，可以实现绑定到imsi和用户注册到mno。
根据示例实施方式，lae功能可以驻在uicc或安全可信环境。例如，la可以是在智能卡web服务器(scws)或其他web浏览器应用上的开放id的完整实施。在示例实施方式中，网络辅助认证配置可以来绑定lae(例如本地断言)认证到任何形式的强壮网络辅助认证(例如本地开放id/gba)。强壮认证可以通过增加生物计量或类似本地认证应用到强壮本地用户辅助认证作为额外的因子。例如，任何形式的强壮本地认证可以与网络辅助认证结合并绑定到网络辅助认证。
图4示出了用于使用多sso协议和/或模块的架构框架的另一示例实施方式。如图4所示，ue402的sso子系统400可以与配置成从服务提供方接入服务(例如web服务406(例如rp))的应用(例如浏览器应用404)通信。sso子系统400可以提供针对用户的sso功能，并且可以产生对认证服务的自动化登录过程。例如，自动化特征可以包括可以向web服务406提供用户标识符和/或向身份提供方(例如开放id提供方(op)408)提供凭证而无需用户交互的功能。自动化的特征还可以是自动供应认证凭证给op408的认证方410，以及认证模块(例如认证方法)的自动选择和协商。根据示例实施方式，认证模块可以包括开放id/sip摘要模块418，开放id/gba模块412，eap/sim模块416，和/或开放id/aka模块414。例如，图5显示了示例环境，其中gba模块412由sso子系统400选择。虽然图4中示出的每个网络辅助认证模块可以实施开放id网络辅助认证协议，但还可以或可替换地实施其他类型的网络辅助认证协议。sso子系统400提供的自动化可以基于在无线设备(例如ue402)上存储的和例如op408供应的之前定义的策略被执行。这样的自动化可以由网络跟踪器(cookie)(例如存储在浏览器404中)，java小应用，存储表格数据的浏览器缓存等提供。在示例实施方式中，自动化可以被提供有刮削(scraping)功能，例如，其可以自动地检测要填的表格。
在使用java小应用的示例实施方式中，例如，自动化特征可以被结合到java小应用中，该java小应用可以在认证过程期间被下载。虽然在此讨论的自动化特征可以由java小应用实施，在此描述的实施方式不这样受到限制。在一些实施方式中，持续(persistent)特征(例如用户登录状况)可以不位于java小应用中，因为例如小应用可以从浏览器缓存中移除。此外，如在此所述，java小应用可以在协议运行过程中下载之后变得可用。利用java小应用的功能可以在小应用已经被下载到例如ue的设备之后被执行。如果例如java小应用在重定向到op之后从op下载，java小应用本身不可以提供刮削特征。
图6示出了包括用于便于使用多sso技术和/或模块的可下载组件的架构框架的示例实施方式。示例性可下载组件(例如恳请者622)可提供用于浏览器应用和/或非浏览器应用(例如应用604)到网络辅助模块，例如认证模块、协议和api(例如模块612，614，616，618，和620)的接口。在示例实施方式中，可下载组件(例如恳请者622)不绑定到在ue602上的完整sso子系统600的存在。例如，该组件(例如恳请者622)可以是独立的，在于它可以与或不与在无线设备(例如ue602)上的完整sso子系统特征一同使用。为了描述恳请者622的示例性特征的目的，图6显示了恳请者作为独立于sso子系统的组件，但是恳请者可以包含在sso子系统600中。此外，在此描述的实施方式可以包括具有或不具有sso子系统的子集的恳请者的变形。
在示例实施方式中，恳请者622可以用java小应用等实施。例如，java小应用可以在认证过程期间被下载并可以产生浏览器(或应用604)和在ue602中的网络辅助模块(例如gba模块612，aka模块614，eapsim616，sip摘要模块618，本地op模块620)之间的层。这样的层可以是软件层，其例如由于本地浏览器不支持一些认证机制，因此实现网络认证与认证模块对接。
恳请者622(例如java小应用)它可以独立于浏览器，在某种意义上是一旦被下载，其可以被执行并可以发布和/或处理http请求。例如，java小应用可以向op608发布请求来获取认证质询(challenge)。java小应用可以与认证模块(例如gba模块612，aka模块614，eapsim616，sip摘要模块618，lae模块)以及sso子系统对接。例如，ue602可以提供分层的接入，其中可以通过sso子系统600使得到认证模块的接入可用。sso子系统600和认证模块之间的网络认证接口可以用来便于认证。例如，java小应用可以发送来自身份提供方(例如op608)的质询到网络辅助认证模块，认证模块可以计算摘要响应，并且java小应用可以直接发送该响应到op608或经由浏览器发送该响应到op608。
如图6所示，虽然lae620还可以执行认证之外的功能，lae(例如本地op620)可以(例如由sso子系统600)被视为另一认证模块。因为例如lae可以包括比单纯认证方法更多的功能，因此关于lae的java小应用的作用可以不同于关于认证模块的java小应用的作用。例如，lae可能不计算认证响应，并且它可以积极地执行认证。结果，lae可以产生认证断言，该认证断言可以直接被发送到服务提供方，例如web服务606(例如rp)用于认证。关于lae，恳请者622(例如java小应用)可以实现从应用604(例如浏览器)到lae的通信。根据示例实施方式，sso子系统600可以包括例如由sim联盟标准化的开放移动api的软件中间件组件，并在该部件上构建。这样的软件中间件组件可以便于例如从用户/os级应用到sim卡应用的通信。
仍然参照图6中所示的示例性构架，恳请者622(例如签名的java小应用)可以经由浏览器被下载并且可以针对每个设备(ue602)类型被定制。恳请者可以针对不同设备类型，例如塞班(symbian)、ios、安卓等被定制。恳请者622可以实现从浏览器到sso子系统622的组件，例如gba模块612、aka应用614以及sip摘要认证方618的通信。恳请者622可由身份提供方的服务器(例如op服务器608)和/或web服务606(例如rp)提供。恳请者622可以提供用来执行自动和/或无缝用户认证的接口功能。在示例实施方式中，sso子系统600可以允许应用604(例如浏览器)与网络辅助认证模块612、614、616、618和620通信。恳请者622，例如，可以允许应用604(例如浏览器)使用sso子系统600的特征。例如，如果lae在ue602上可用，则恳请者622可以帮助lae620的发现以及到lae的连接。恳请者622可以将用户重定向到身份提供方的本地或远程的异体(例如lae或远程op608)并回到web服务606(例如rp)。恳请者622可以使sso子系统600能够作为认证模块使用，并且可以使能sso子系统600的lae部分(例如本地op620)的使用来直接生成签名的断言。sso子系统600可以预先装载在移动设备(例如ue602)中和/或经由其他机制下载到设备中。在示例实施方式中，当恳请者可以在用户每次访问web服务606(例如rp)时被重新装载时，sso子系统600可以跨服务持续。
在一个实施方式中，恳请者，例如图6中的恳请者622，可以被实施为java小应用等，并可以在受约束的操作环境(例如“沙箱”)中运行。这样的恳请者可以具有对系统资源的受限接入。在示例实施方式中，可以在认证已被执行之后(例如当浏览器离开服务网站时)卸载恳请者。参照图7，由于单点登录(sso)特征可以跨域不同服务之间的用户认证，sso功能的持续方面可以由sso子系统700的非恳请者部分提供。图7示出了具有sso子系统700的示例接口组件的图6的架构框架的示例实施方式。如图7所示，sso子系统可以包括恳请者，sso子系统700可以与各种组件，例如用户704、远程服务器708、生物计量单元710以及各种其他设备706对接。sso子系统700的恳请者部件的互通功能通过下面的示例描述。
仍然参照图7，恳请者一般可以没有对认证功能的直接接入，或者可以有对由lae(例如本地op620)提供的认证功能的接入。在这种情况下，使用网络辅助认证方法的一些认证请求可以经由sso子系统700调用。这样的调用可以包括到sso子系统700的恳请者的合适的授权和/或在先的确认(validation)(例如通过检查代码签名)。恳请者可以提供各种接口。例如，恳请者可以提供功能来通过提供到sso子系统700的接口选择用于特定服务提供方(例如rp)的标识符，实现认证过程的自动化。恳请者可以提供到sso子系统700的接口来提供用于与身份提供方(例如op608)认证的凭证。恳请者还可以提供到sso子系统700的接口(例如网络认证接口)用于网络辅助认证模块或机制的选择和/或协商。在一个示例实施方式中，恳请者可以提供替换重定向消息的功能，重定向消息例如为从web服务606(例如rp)到身份提供方(例如op608)的用于认证的重定向消息，以及在认证之后从web服务606到op608的重定向消息。
如上所述，sso子系统700可以提供用于用户辅助认证的用户认证接口(例如图6中的用户接口624)，并且可以通过这个接口执行用户辅助认证。用户认证接口可以由例如作为op恳请者功能一部分的op608提供，或可以是sso子系统700的持续功能的一部分。sso子系统700可以与身份提供方(例如op608)对接(例如通信)来收集关于用户辅助认证策略的信息。这样的关于策略的信息可以包括用户辅助认证参数，例如身份提供方或服务提供方要求的新鲜度(例如执行认证的时间)以及认证强度等级(例如生物计量或用户名/密码)。sso子系统还可以与op608对接以便于选择网络辅助认证模块和/或接口。在认证用户704和/或用户设备(ue)602成功之后，经由用户接口和/或使用所选择的网络辅助认证方法(例如gba模块612，aka模块614，eapsim616，sip摘要618)，sso子系统700可以设置针对时间段(例如有效时段)的用户认证的持续状态。一接收到重新认证请求(例如通过本地触发或通过网络)，sso子系统700可以重新认证用户704。在示例实施方式中，这样的重新认证可以向用户704提供无缝登录体验。
sso子系统700可以使用到在ue602外部的组件(例如其他设备706)的接口，例如，来获得来自经由无线接口连接到ue602的令牌的认证信息。sso子系统700可以建立到生物计量单元710或远程服务器708的用于认证的辅助通信信道。
图8是显示了认证流的流程图，该认证流触发恳请者(例如java小应用)的下载。图8中示出的示例性流可以在在此描述的sso框架架构中实施。虽然图中的示例实施方式使用开放id术语来描述，但示例性流可以应用到任何数量的单点登录安全协议，例如安全联盟。
参照图8，在808，ue802可以发送用户的op登录请求到rp804。登录请求可以包括用户提供的标识符，并可以传达到rp804，rp804可以在810触发rp804和op806之间的关联和/或共享秘密密钥的建立。网络辅助认证可以在810后被执行。例如，网络辅助认证可以遵照由rp804进行的到op806的重定向。重定向可以由ue802在步骤812接收。在814，ue可以发送请求到op806，用于使用恳请者认证。请求可以包括应用的身份，例如非浏览器应用的身份或ue802使用的浏览器代理的身份。在示例实施方式中，java小应用可以根据在请求中浏览器代理的类型被匹配。例如，多个和/或不同java小应用可以用于不同设备，使得可以根据ue802的各种组件，例如处理器、os和/或浏览器来选择java小应用。响应于该请求，在816，ue802可以从op806下载恳请者820(例如java小应用)。
java小应用可以由op806签名。用于java小应用的发布方证书可以由浏览器例如使用ue系统证书存储检查。例如，修改的系统或浏览器证书存储实施可以用存储在ue802的安全元件(例如uicc)上的证书/密钥检查java小应用的签名。java小应用可以包括决定与rp804使用哪个网络辅助认证模块800的逻辑。java小应用还可以包括向op806指示哪个认证模块/机制在ue802中可用的逻辑。在示例实施方式中，java小应用可以对一个单个认证模块800是特定的，并且op806可以选择向ue802提供哪个java小应用。在示例实施方式中，在814，http请求被发送。http请求可以包括浏览器代理，允许ue802的os被识别以及对应小应用的版本将由op806选择的并发送到ue802(在816)。
在818，网络辅助认证可以被执行。关于图3如在此所述，网络辅助认证可以遵照由rp804进行的到op806的重定向。重定向可以由恳请者820接收，该恳请者820可以重定向消息到sso子系统308用于选择网络辅助认证模块和/或协议(例如认证模块800)。网络辅助认证模块/协议(例如sso协议)可以由sso子系统经由策略实施选择和使用。这个过程可以包括引导和共享密钥建立，如在此进一步所述。
如图2、4、6和7所示，多个网络辅助认证协议模块可以由网络辅助认证模块(例如sso协议)族暗示。再次参照图8，在822，在818的来自认证的认证结果可以从恳请者820发送到op806。例如，认证结果可以包括在ue802和op806之间共享的应用特定密钥等。在网络辅助认证成功之后，op806可以向rp806提供网络辅助认证成功的指示。例如，op806在824可以签名身份断言并在824发送身份断言。签名的成功网络辅助认证通知可以在ue802获得对在rp804的期望服务的接入之前被执行。一旦rp804和/或ue802(例如经由应用)已经接收到网络辅助认证成功的指示，ue802(例如经由应用)可以登录到rp804(在826)并接入在rp804的服务(在828)。
图9显示了示例的实施方式，其中身份提供方的功能对于ue802被本地执行。例如，ue802可以包括sso子系统和lae(例如本地op900)。步骤808、810、814和816可以如关于图8所述的一样继续。在902和904，可以经由恳请者908和sso子系统900，以及sso子系统900和一个或多个认证模块800之间的交互产生签名的断言。ue802可以在906发送签名的断言到rp804。在rp接收到签名的断言后，ue802的用户可以能够接入由rp804提供的服务(在824)。图10示出了示例的实施方式，其中sso子系统在java小应用1002中实施。参照图10，sso子系统1002可以使用在uicc1000上的本地op加密执行网络辅助认证。在网络辅助认证成功之后，签名的断言被产生并被重定向到rp804。
如在此所述(例如图11到图15)，lae(例如本地op)可以集成在java小应用中或独立于java小应用。在可替换的示例实施方式中，开放id协议，例如，可以无需本地op组件而被实施。在这样的实施方式中，协议流程的第一部分可以对于具有lae的实施方式看上去相同或相似，但认证和/或断言生成可以通过ue和op之间的通信完成(例如如图16所示)。
图11示出了用于预取关联的协议流的示例实施方式。例如，关联可以被预取，其可以允许rp在来自用户的认证尝试之前获取关联(例如关联句柄和/或关联秘密)。这可以例如通过使用开放id的标识符选择模式被实施。rp可以不需要知道完整的开放id标识符url，但可以例如基于他们的op端点(endpoint)url预取用于一些已知的op的关联。参照图11，rp804可以在知道ue802的标识符之前在810得到关联。在812，例如通过使用预取的关联之一，rp804可以直接重定向ue802到op806。在这样的实施方式中，ue802可以从op806下载java小应用1100，其可以在ue802和op806之间的接口上产生业务量。在示例实施方式中，ue802到op806的接口可以是空中接口，但rp804和op806之间的接口可以是固定的互联网。
在预取步骤的示例实施方式中，java小应用可以由rp如图12所示存储。rp804可以接收由op806签名的一组java小应用1202。rp804可以用来自810的关联存储java小应用1202。当ue802希望在1204认证时，例如rp804可以在1206提供对应的java小应用1202到ue802。多个和/或不同java小应用可以用于不同的设备，例如，使得他们匹配非浏览器应用或浏览器代理的处理器和os。
根据示例实施方式，开放id库，例如可以外包至op。例如，op可以提供针对rp的api来处理针对rp的开放id特定操作。谷歌身份工具箱是示例实施，其可以一般化在ue上的rp的功能，并可以提供针对可以使用相同恳请者的多个rp的公共框架。rp可以请求api来发起开放id认证，并且api(由op提供或托管(host))可以返回将从rp发送到ue来发起ue认证的代码。此后，ue结果被发送回rp，rp可以验证认证结果(例如自行或在op的帮助下)。在示例实施方式中，关联的预取可以节约(减少)ue和op之间的通信，并可以实现离线情形。
图13示出了针对缓存的java小应用的协议流的另一实施方式。例如，java小应用1306等可以在例如智能电话的ue802上存储。在示例实施方式中，java小应用1306可以存储在来自之前运行的ue802的浏览器缓存中。在这样的实施方式中，可以调用存储的java小应用。例如，如果假设小应用在浏览器缓存中不可用，浏览器可能删除下载的java小应用而无需通知。例如当从相同的源(例如相同rp)调用小应用时，可以调用之前下载的java小应用。由op提供的api可以在1300返回代码，其发布到之前下载(以及缓存的)java小应用的调用。在1302，例如，到java小应用1306的调用被提供给rp804。在1304，调用被提供给ue802。在此描述的实施方式可以使用例如java脚本的可替换实施。
图14示出示例的实施方式，其中java小应用联机(onthefly)被供应。根据示例实施方式，浏览器可以不在缓存中存储java小应用。在这样的实施方式中，小应用1402可以由op806提供至rp804(在1400)，并且rp804可以在1404将小应用1402传送至ue802。由于http请求可以包括浏览器代理，ue802的os可以被识别，并且对应的小应用版本可以被发送到ue802。在此，rp804可以在针对op806的api调用1300中传递ue字符串(例如包括os和/或浏览器代理)到op806，例如来选择正确的java小应用版本。
如在此所述，各种实施方式可以使用开放id等来用浏览器应用接入服务。开放id可以基于http协议和/或java小应用可以实施java运行时间。在示例实施方式中，浏览器可以使用http协议和java运行时间环境二者。在此展示的开放id和/或其他概念的使用不限制为浏览器应用。如在此所述，各种实施方式可以使用非浏览器应用来实施开放id协议等。对于那些应用，可以应用相同的概念。具有非浏览器应用的实施方式可以提供支持下载和执行java小应用的接口和/或方法。虽然在此的描述可以针对各种协议流的描述使用术语浏览器，但流并不受到这样的限制并且包括非浏览器应用。
虽然各种实施方式描述为实施java小应用，但这样的实施方式不受到这样的限制。在此描述的java小应用代表用于组件(例如恳请者)下载的单个实施变型，该组件可以便于在服务接入应用(例如浏览器/非浏览器)和认证模块(例如op，本地op，gba，aka)之间的设备中的认证通信。例如，在此描述的实施方式可以由例如库或api的组件实施，其可以频外(outofband)装载或动态下载到无线设备。就应用可以知道如何处理组件(例如如何装载它，调用哪个功能)的意义而言，下载的组件(例如小应用，库)可以对应用是特定的。
谷歌身份工具箱(gitkit)可以提供多种能力和特征，其可以使rp功能的集成和/或实施能够简便。在网络侧，例如，通过包括网络侧恳请者功能首次展示(rollout)特征，rp功能可以由服务提供方进一步增强，用于采用开放id联合身份协议的简便化。在客户端侧，java脚本可以提供用来一般化恳请者功能的一些元件并将它们与gitkit对齐(align)，例如使用刮削来执行用户自动化的实施方式。
在此描述的各种实施方式可以将lae(例如本地op)的概念与谷歌身份工具箱结合，而保持遵从gitkit的用户提供的常规调用流。例如，在此描述的是本地op可以被调用以及浏览器可以被重定向到本地op的多种不同的方式。在示例实施方式中，重定向可以被应用到op的url，其中设备可以希望知道在哪里找到本地op。在另一实施方式中，由gitkitapi提供的网站可以提供到osapi的调用(例如经由java脚本)，该调用可以触发本地op认证过程，例如无需重定向浏览器到本地op。仍然在另一实施方式中，浏览器插件可以代替osapi被调用。
图15示出示例实施方式，其中gitkit1500可以与本地op900和java小应用1508结合。示例性结合步骤列在下面，但在此描述的实施方式不受到这样的限制，因为可以使用其他实施，例如包括满足非浏览器应用的那些实施。
参考图15，用户可以访问rp804和/或选择他的idp或输入他的电子邮件地址标识符。在一个实施方式中，标识符可以被预填入(例如使用现有的技术，例如浏览器存储的表格数据或cookies)，例如来提供认证过程的自动化，并标识符可以通过用户输入url到浏览器被触发。可以调用gitkit库功能“createauthurl(产生认证url)”。gitkit库可以执行idp发现。gitkit可以返回idp的授权端点url(例如op806的url)。java脚本微件(widget)可以弹出登录窗口，重定向用户到这个端点。这个弹出窗口中的重定向可以将用户带到在设备上运行的本地op实例。当结合到sim卡或其他其中执行本地op的加密功能的安全元件的接口时，本地op实例可以例如由提供http接口的应用和到浏览器的类web服务器能力组成。在可替换实施方式中，java脚本可以不使用重定向但可以能够调用osapi(在1502)以从脚本直接触发本地op认证。例如，如果本地op应用驻在sim卡上，java脚本可以潜在地调用osapi(例如sim联盟开放移动api)来直接与在智能卡上的本地op应用通信。其他实施方式可以不使用单纯的java脚本解决方案。在这些实施方式中，浏览器可以包括插件，其可以由java脚本调用来触发本地op认证。这个插件可以利用一些osapi，例如其可以提供用于os应用层和/或在安全元件上的本地op应用之间的通信的传输层逻辑。在其他实施方式中，gitkitapi可以在第一调用之后提供具有代码的rp，该代码可以允许下载java小应用到ue中。java小应用可以使用在此描述的本地op执行认证。实施方式可以预填入凭证(例如使用现有的技术，例如浏览器存储的表格数据，cookies等)来提供ue接收到本地op的重定向触发的认证过程的自动化。
在1102，用户可以被本地认证到本地op。本地op可以从网络中与op(sf)长期共享的秘密导出开放id签名秘密，并且使用关联句柄作为到密码导出功能的第二输入来产生针对开放id签名密钥。本地op/java脚本/插件可以产生签名的断言消息，并重定向浏览器到以前在rp产生的“continueurl(继续url)”，该“continueurl”已经由“createauthurl”gitkit库调用产生。rp可以接收签名的断言消息(在906)并在1510将它传递到gitkit库用于验证。gitkit1500可以使用“verifyassertion(验证断言)”api来与op(sf)的确认(validate)断言消息(在1512)。由于gitkit库可以由谷歌托管，gitkit库可以使用opsf用于签名验证。opsf可以返回身份信息(例如电子邮件，或其他例如由开放id的属性交换方法定义的属性)。如果账户/电子邮件已经存在，用户可以登录。如果没有，rp可以使用断言的电子邮件地址作为用户的不变的标识符来产生新的账户。额外的属性可以基于用属性交换机制接收到的信息自动填写。
作为额外的背景，gitkit协议流的概述可以在http://code.google.com/intl/de-de/apis/identitytoolkit/v1/openid.html找到。常规gitkit协议流可以总结如下。
用户可以访问rp网站并且可以点击他的idp的按钮。rp可以建立到gitkit服务api的调用，gitkit服务api转而可以执行发现步骤并返回调回(callback)url，rp可以必须建立该调回url来等待用户的返回，并且gitkit返回html代码，该html代码将被显示给用户以与idp认证。html代码可以包括到idp的认证url的重定向。这个代码还可以产生针对rp的相同用户接口。用户向他的idp进行认证。用户可以被重定向到在rp的调回url。rp可以使用在调回url接收到的参数(idp响应)来做出到gitkitapi的调用(验证断言)。gitkitapi可以验证idp响应并发送结果(验证的电子邮件+额外的属性)到rp。
gitkit可以通过提供rp在两个步骤中调用的至少两个api揭露开放id/oauth协议，如下面示出：
一个步骤可以包括createauthurlapi调用。这个api调用可以当用户在idp图标(例如gmail、yahoo按钮)上点击时或例如直接输入电子邮件地址时发生。gitkit后端可以例如根据开放id2.0协议执行idp发现。如果idp实际上使用oauth协议，那么gitkit可以直接使用预先定义的idp端点。最终结果可以是gitkit返回url(参数“authuri”)，其可以代表idp的授权端点，以及gitkit登录微件可以弹出登录窗口，该登录窗口可以重定向到这个端点。(这个步骤可以对应普通开放id协议的第一重定向，其中浏览器重定向到op。通过与本地op使用与之前相同的机制，在这个阶段，而是用户的浏览器可以被重定向到本地op)。当调用createauthurl，rp可以在“continueurl”(即调回url)中传递哪一个是在用户通过对应idp成功认证之后被重定向的url。“领域”(realm)可以是标识开放id的领域的可选参数，而“标识符”可以指定使用哪个idp。
另一步骤可以包括验证断言。在idp已成功认证用户之后，(这可以涉及实际的用户认证，如果使用本地op，用户认证可以本地完成)它可以重定向浏览器到url，该url在createauthurl的“continueurl”参数中被指定，该参数具有使用它的秘密密钥签名的用户的身份信息。根据实施方式，这可以与可以不被处理的二进制斑点(blob)类似，并且它可以被发送回gitkit用于确认。这可以是开放id中从op到rp的第二重定向。这可以与本地op使用。对调回url的http请求可以被rp后端中的gitkit客户端库捕获，并且客户端库可以用“requesturi”(idp返回的uri)和“postbody”(由idp签名的斑点)调用gitkit的验证断言api。gitkit后端可以使用开放协议确认idp响应，并且可以返回身份信息(例如如果使用了ax，还有与这个身份关联的属性)到rp的后端。这个步骤可以对应普通开放id的断言签名验证。这例如可以类似于开放id的无国籍(stateless)模式。gitkit库可以再次联系op(例如在网络中)来验证签名并请求额外的属性(例如电子邮件地址)。rp可以审查“verifiedemail(验证的电子邮件)”字段，并且做出相应的动作。例如，如果用这个电子邮件地址的账户有效，则用户可以登录，和/或java脚本微件可以关闭登录窗口，和/或重定向用户的浏览器到rp的主页。如果没有找到针对这个电子邮件的账户，rp可以例如用预填入的和不可编辑的电子邮件字段与针对所填入的账户的其他属性一起，重定向用户到账户产生页。
对于基于oauth的idp认证，rp可以使用相同或类似的调用，并得到从gitkit返回的相同或类似的响应。但gitkit可以在它的后端使用oauth协议与idp通信，并且做出正确的处理，例如交换接入令牌。gitkitapi端点接收针对gitkitapi调用的请求，认证用户(通常使用api密钥)，以及用正确的参数调用gitkit服务器。gitkit服务器可以联系对应的idp来完成开放id/oauth调用。
虽然在此描述的示例实施方式在开放id的上下文中执行，但上面描述的技术可以应用到任何数量的单点登录安全协议，例如自由联盟。此外，虽然与各种图一起描述各种实施方式，应当理解的是，其他类似的实施方式可以被使用，或者不背离各种实施方式的相同功能，对描述的实施方式作出修改和增加用于执行各种实施方式的相同功能。因此，实施方式应当不限于单个实施方式，但相反应当在根据所附权利要求的宽度和范围上解释。
此外上面以特定的组合描述了特征和元素，并且每个特征或元素可以单独的使用或与其他的特征和元素进行组合使用。应当理解的是，这里描述的任何或所有系统、方法以及处理可以用存储在计算机可读存储媒介上的计算机或处理器可读指令(例如程序代码、软件和/或固件)的方式实现。当指令由例如处理器的机器执行时，指令执行和/或实施在此描述的系统、方法和处理。具体地，以上描述的任何步骤、操作或功能可以用可执行指令的方式实施。计算机可读存储媒介包括实施在任何方法或技术中用于存储信息的易失性和非易失性，可移动和不可移动媒介。计算机可读存储媒介包括但不限于，ram，rom，eeprom，闪存或其他存储器技术，cdrom，数字通用盘(dvd)或其他光盘存储，磁带盒，磁带，磁盘存储或其他磁存储设备，或可以用来存储期望的信息以及可以由计算机或处理器接入的任何其他媒介。
- 还没有人留言评论。精彩留言会获得点赞！