使用别名的身份和验证系统的制作方法
专利名称：使用别名的身份和验证系统的制作方法
使用别名的身份和验证系统
背景技术：
对于用户和商业之类来说，因特网不断地变得越来越有价值。越来越多的人将因特网用于每天的任务，从购物、银行业务和付帐单到消费媒体和娱乐。电子商务正伴随在因特网上商业递送更多服务和内容、在线通信和合作以及为用户创造新的途径来彼此联络而不断发展。目前，用户能够从包括计算机、移动和智能电话、游戏控制台和其他具有网络连通性的设备的多种多样的平台集合中访问在线资源。当访问一些站点和服务时，用户需要被验证以使得互动是合适的并且没有在某些方面被误用。例如，尝试访问在线银行帐号的用户需要被验证以证明该用户就是他所声明的用户(即拥有帐户或被授权访问该帐户的合法银行客户)。另一个例子是，除其它原因以外，社交网站的用户需要被验证以防止仿冒者获得对用户页面的访问并贴出恶意或伪造的内容。验证通常涉及输入被称为“证书”以证明他的或她的身份的用户ID(或登录ID、帐号名、用户名等)以及密码或个人标识号码(“PIN”)的用户。虽然一些验证系统提供了令人满意的性能，但当前的系统并不能满足在线社区的所有需求。例如，用户既想使得他们在线设计的身份的灵活性，又要一种简单的方法来维护他们的身份的安全性而不需要使用经常是很长的密码列表(这将增加不安全的体验，例如跨多个网站上的重用帐号名和密码)。提供本背景技术来介绍以下概述和详细描述的简要上下文。本背景技术不旨在帮助确定所要求保护的主题的范围，也不旨在被看作将所要求保护的主题限于解决以上所提出的问题或缺点中的任一个或全部的实现。
发明内容
一种身份和验证平台利用了一种数据模型，该数据模型能够将诸如电子邮件地址、移动电话号码、昵称、游戏ID和其他用户ID等多个身份用作别名，所述别名是一个主帐号名的唯一的子身份。用户可以使用验证证书的通用集或主帐号的证书来访问该平台所支持的别名并使用别名来设计多个不同的在线身份。该平台进一步被配置为将所述别名展现给各个客户机应用程序和因特网可访问的站点与服务，例如电子邮件、即时消息、媒体共享、游戏和社交网络等等，以便能够实现各种使用别名的使用场景。在各种说明性示例中，支持别名使用的网站和服务依靠身份和验证服务以为网站和服务的用户提供验证(统称为“依靠服务”)。依靠服务可以与运行在web浏览器上的应用程序(即“瘦客户机”应用程序)或更多特征丰富的客户机应用程序(即“胖客户机”应用程序)结合起来操作，以提供广泛范围的使用别名的使用场景。例如，用户可以登录到依靠服务，并使用他们的主帐号名和密码或使用别名和相同的主帐号密码来验证用户。可以集中地管理多个电子邮件帐号(其中每个电子邮件帐号用不同的别名标识用户)，以便用户能够登录到验证的主电子邮件帐号，并随后接收定址到不同电子邮件别名的电子邮件消息。并且，依靠服务的用户可以通过使用这样的用户的别名来找到其他用户。 可以将使用事件计划服务生成的邀请定址到，例如用户的别名，但仍然递送到该用户的主帐号。或者，游戏玩家可以通过在线游戏服务上的别名来查找并找到另一玩家的简档。为用户提供用于使用别名管理他们在线身份的工具。用户具有创建、更新和删除别名并管理在各种服务中如何使用它们的能力。用户还可以设置与他们的别名相关联的一个或多个属性，以限制在别名和主帐号名之间的关联在服务上公开的范围。这使得用户能够在任何期望的时候维护隐私，同时仍然能够享受别名所提供的益处。有利地，本身份和验证平台是在各种各样的服务上可扩展并可缩放的，这些服务是可由不相关的服务提供者操作的(例如电子邮件别名可以被应用到使用由不同的提供者主持的不同的域的电子邮件帐号)。该平台为用户提供了一种便捷和安全方法来使用和展现别名以管理在在线社区中如何察觉他们，同时控制何时且如何能联系他们以及在期望的时候保护他们的隐私。提供本概述是为了以简化的形式介绍将在以下详细描述中进一步描述的一些概念。本概述不旨在标识出所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。
图1示出一种说明性在线服务环境，在其中，在客户机设备处的用户可以与依靠支持别名的身份和验证服务的在线站点和服务互动；图2示出可以与别名一起使用的站点和服务的说明性集；图3示出了可以在客户机设备上运行的说明性的瘦客户机应用程序和胖客户机应用程序；图4示出说明性的别名数据模型；图5示出可以与主帐号名相关联的别名的说明性集；图6示出可以与别名相关联的属性的说明性集；图7示出了由API(应用编程接口)展现给客户机应用程序和依靠服务的方法的说明性集；图8示出第一说明性使用场景，其中，用户可以使用瘦客户机应用程序用别名登录到服务；图9示出第二说明性使用场景，其中，用户可以使用胖客户机应用程序用别名登录到服务；图10示出第三说明性使用场景，其中，用户可以接收发送给多个不同电子邮件别名的电子邮件消息；以及图11示出第四说明性使用场景，其中，可通过别名由其他用户联络用户。各附图中相同的附图标记指示相同的元素。除非另外指明，否则各元素不是按比例绘制的。
具体实施例方式计算机用户经常维护不同的身份以用于不同的在线站点和服务。单个用户可以使用各种标识符，例如电子邮件地址、昵称、用户名、移动电话号码、游戏名字或ID和其他构造，在不同的时间和不同的设置中来反映用户在线身份。因此，例如，用户可以使用基于现有的网络服务利用移动电话号码，基于现有的网络服务例如可与移动电话一起操作的即时消息(“IM”)。另外，用户可以用用户名登录在线社交网站并在登录飞行常客帐号时使用电子邮件地址。用户可以发现维护多个分散的身份是麻烦的。例如，因为越来越多的站点和服务要求帐号创建来使用它们，不同的帐号名和密码的扩散会导致用户的“密码疲劳”。对于这些用户而言，记住他们的密码是很困难的，这将导致用户在多个站点和服务上重用相同的证书。这种体验不仅造成了易于盗窃和身份欺骗，而且用户也失去了如何将他们自己呈现给在线社区的灵活性。用户经常想要以不同的身份代表他们自己的能力，因为这允许他们使他们的身份适应于特定的在线上下文，并且在一些情况中，将该能力扩展到其他用户以联络他们。然而，在大多数的在线服务上，用户典型地仅被允许具有与给定帐号相关联的单个身份。尽管存在多个昵称可以与一个帐号相关联的现有服务，它们目前都被限制在涉及组讨论的在线服务，并且这些昵称在该组之外就不能使用。昵称也不能用于登录主帐号。这些限制使得那些想要具有丰富的在线社交互动的用户感到灰心。本身份和验证系统使用户受益，并解决了当前在线环境的限制。该系统为用户提供了一种简单的方法来使用别名管理他们的在线身份，以控制何时和如何联络他们。现在转向附图，图1示出说明性在线服务环境100，其中，在各个客户机设备IU1, 2...N处的用户IOS1,"可以在诸如因特网120等网络上与各种在线站点和服务进行互动。客户机设备112可以采用各种形状因素并被配置为具有不同的能力和资源。在这个示例中， 客户机设备112包括桌面PC IU1、膝上PC 1122、移动设备1123(例如智能电话、移动电话等)、以及视频游戏控制台11 。然而，要强调的是，这些设备旨在是说明性的，并且还可以满足特定实现的需求所需要的那样来使用其他类型的设备。将在线站点和服务配置为依靠服务122来提供身份和验证。因此，在线站点和服务被称为“依靠服务”，并且由图1中的附图标记115来统一地标识。客户机设备112、依靠服务115以及身份和验证服务典型地使用HTTP (超文本传输协议)来通信。在一些实现中，依靠服务115以及身份和验证服务122中的一个或多个可以由相同的实体来操作。然而，这并不是一种要求，因为，依靠服务提供者也可以将用户验证委派给操作身份和验证服务122的无联系的第三方提供者。依靠服务115可以包括可由一个或多个服务提供者操作的广泛的各种不同的服务。图2示出了可以在一些实现中使用的特定依靠服务的说明性示例。这些示例旨在进行说明，在每个应用中并不需要使用在图2中示出的所有示例，并且在给定的实现中可以使用没有示出的其他服务。说明性的依靠服务115包括支持下述项的服务即时消息206i ； 桌面电子邮件20 ；个人网页20 ；主机电子邮件20 ；在线文件存储和/或共享20 ；媒体内容(例如图片、音频或视频)共享20 ；网络论坛和/或讨论组2067 ；博客(即网页博客)20 ；事件计划20 ；或社交网络2061(|。提供不是如上所列出的但却依靠身份和验证服务122的服务的网站也可被使用(如由图2中的附图标记20 所统一标识的)。为了向使用别名的用户105提供特别的体验，客户机设备112(图1)通过安装在该设备上并在其上运行的客户机应用程序与依靠服务115(以及身份和验证服务122)互动。如图3所示，客户机设备(如由桌面PC 11 所代表)可以运行包括瘦客户机应用程
6序30A,2...n和胖客户机应用程序306^两者的各种客户机应用程序。虽然在图2中示出了 N个胖客户机应用程序和瘦客户机应用程序，在给定客户机设备112上使用的特定类型和数目的应用程序可以随实现和客户机设备的能力而变化。例如，移动设备可以不运行与 PC和游戏控制器相比那样多的客户机应用程序，而其所运行的那些应用程序可以适应于该移动设备所支持的更加约束资源的运行时环境。瘦客户机应用程序302典型地是那些可以使用web浏览器，例如在PC上的微软因特网浏览器 和移动设备的因特网浏览器移动版，来实现的应用程序。瘦客户机应用程序通常以浏览器支持的语言，例如HTML(超文本标记语言)和XML(可扩展标记语言)，来编码并执行如脚本和ActiveX控件的特征。胖客户机应用程序306典型地由使用诸如PC上的Win32等编程环境的独立应用程序来实现。胖客户机应用程序通常包括例如桌面电子邮件、博客和IM客户端的应用程序，这些应用程序与作为瘦客户机实现的类似的应用程序相比典型地为本地数据存储提供了更加丰富的特征集和更好的灵活性。在一些实现中，可以使用客户机侧别名接口 315(即本地安装的API)向胖客户机应用程序306展现别名功能性。然而，这样的接口 315并不需要在所有实现中使用，并且一些胖客户机应用程序306可以被配置为通过调用经由所述身份和验证服务122所支持的API (应用编程接口)所展现的方法来直接与别名服务对接，如将在下面结合图7所述的文本中更详细描述。身份和验证服务122 (图1)被安排为在灵活的数据模型下将别名展现给依靠服务 115和客户机应用程序302和306，所述数据模型支持广泛范围的别名使用场景(这些使用场景中的一些在图8-11中被示出并将结合文本进行描述)。图4示出说明性的别名数据模型400，它提供了别名是主帐号的子身份(如附图标记415所指示)。由身份和验证服务 122提供该主帐号。例如，身份和验证服务122可以作为微软的Windows Live ID 服务的一部分来实现，这样，该主帐号包括Windows Live ID，例如电子邮件地址(例如“userOlive. C0m”、“User@h0tmail.C0m”等)，用户使用它来访问各种在线服务，所述服务包括微软公司提供的这些服务以及第三方提供的服务。在替换安排中，主帐号可以被依靠服务115中的一个的提供者所支持。无论谁是主帐号提供者，一般而言，依靠服务115将(例如通过适当范围的服务合同)同意给定的用户105将能够访问所有的依靠服务115并且由身份和验证服务122使用该主帐号和其关联的别名来验证。别名数据模型400进一步提供别名可以包括各种类型的标识020)。如图5所示， 用户(由用户105!代表性指示)可以有资格使用与主帐号名512(即userihotmail. com) 相关联的一个或多个别名505。别名说明性地包括，但不是必须局限于，电子邮件地址505” 昵称50 、移动电话号码50 以及在微软公司的)(b0X LIVE 在线游戏服务的情况下被称为“玩家标签”50 的游戏玩家简档名字。这些特定类型的标识是说明性的，并且如特定应用所要求可以使用其他的类型。电子邮件地址别名5051可以包括来自不同域的电子邮件地址，并且可以被不同的和/或不相关的依靠服务提供者所支持。昵称别名50 和玩家标签别名50 是在域中的名字，虽然该域自身并不会展现给用户105。例如，虽然，出于系统跟踪该别名的起源的目的，昵称别名包括(例如“nickname@domain.com”)的域，但用户105所使用和看到的别名仅是简单的“nickname”。
回看图4，数据模型400提供了所有的别名505在服务环境100中都是唯一的025)，并且每个别名都与一个固定的标识符(430)相关联，所述标识符在此称为 “AUID”(别名唯一标识符)。模型下的唯一性确保了用户105可以声明使用别名的专有权， 并且与该别名明确关联。并且通过成为固定的(即决不被改变或重分配)，AUID使得系统数据与别名相关联并被跟踪，这样，可以在用户105决定以任何方式更新或修改别名的情况下维护服务的连续性。例如，如下将详细描述，用户105可以希望基于使用别名的询问限制主帐号名的展现。这种限制可以关联于AUID，这样，如果改变了别名的名字(例如从 "Nicknamel"变为“Nickname〗”)，还可以对新别名的名字维持有关隐私的用户的偏好。数据模型400还提供了别名可以具有属性(435)，这些属性形成了用于定义用户 105的身份的核心。一个示例性的属性集600在图6中被示出。在这个示例中的属性包括IsEmail (是电子邮件)(如附图标记605所指示)IsMobile (610)(是移动电话)IsGamertag (615)(是玩家标签)IsNickname (620)(是昵称)IsVerified(625)(是被证明的)IsPrivate (630)(是私有的)Context (635)(上下文)注意，并不是所有的上面示出的属性都必须在任意给定的实现中都被使用。属性IsEmail 605、IsMobile 610、IsGamertag 615 以及 IsNickname 620 分别被用于标识别名类型。这种标识可以用于使得依靠服务115以及身份和验证服务122以合适于别名类型的方式来使用这些别名。被设计用于向电子邮件别名递送的消息，被用于向移动电话号码别名发送时，例如由于消息协议的变化以及设备特性例如现实和呈现能力的差异，将必定不会有效率地工作。当电子邮件地址被用作别名并且该电子邮件地址由与身份和验证服务122的提供者无关的依靠服务115所提供时，IsVerified属性625是典型地可应用的。在这种情况，服务122需要在允许别名与主帐号相关联并由依靠服务115使用之前证明该别名的有效性。当电子邮件别名的用户已经证明他或她拥有该电子邮件地址时可以为该电子邮件别名设置IsVerified属性标志。否则，当未被证明时由服务122来跟踪该电子邮件别名，这将典型地限制了其中可以使用未被证明的别名的使用场景。例如，如果使用未被证明的别名(即该别名的IsVerified属性标志未设置)来从事件计划服务20 发送邀请给被邀请者，那么，被邀请者将不能接受该邀请，直到被邀请者可以示出该别名属于被邀请者并对其具有权限。未被证明的电子邮件别名通过一种方法获取证明，在该方法中，身份和验证服务122发送单独的定址到该未被证明的电子邮件别名的电子邮件。来自服务122的电子邮件包括包含确认令牌的确认链路。当点击链路时，将打开一个网页，被邀请者可以登录到该网页，由此证明在对该电子邮件别名的合法收件箱处接收了确认电子邮件。确认还可以用于用作别名的移动电话号码。包含代码的SMS(短消息服务)消息可以被发送给移动电话号码别名。用户可以转到使用例如PC或该电话上的移动浏览器建立的网页，并将来自SMS消息的代码输入由该站点提供的用户界面，由此用身份和验证服务122证明该移动电话号码别名。IsPrivate属性630提供了一个展现别名505和主帐号名512之间的关系的别名用户的偏好的指示。如果设置了 IsPrivate属性标志，那么，身份和验证服务122将不会对来自调用者的查询展现任意别名505之下的主帐号名512。这样，IsPrivate属性630的使用使得用户能够允许或阻止某个人或某个服务查找与别名相关联的主帐号名。在一些实现中，也支持反向情况，其中用户可以允许或阻止对与主帐号名相关联的所有别名或别名的所选子集的查找。Context属性6；35可被用于指示使用别名的上下文。例如，Context属性6；35可以指示使用了哪些特定的依靠服务115或哪些特定的依靠服务115与给定别名505相关联。当实现某些使用场景或服务特征时，其他依靠服务115可以随后使用这种上下文。例如，可以标记在第一依靠服务内部创建的电子邮件别名的Context属性635，即Context = servicel。随后，第二依靠服务可以检查该Context属性并发现该电子邮件别名还没有与第二服务一起使用。随后可以通知用户有关将该电子邮件别名与第二依靠服务一起使用的选项。Context属性635的其他使用可以包括向用户105显示哪些别名与哪些依靠服务115 一起被使用，或基于使用率分类别名。如在图7中所示，别名数据模型400可以用于定义各种方法700，这些方法可以由身份和验证服务122通过API 704展现给来自依靠服务115和应用程序302和306的远程调用(分别由附图标记710和714所指示)。方法700示例性包括Create Alias (创建别名)(如附图标记TOO1所指示)Delete Alias (删除别名)(7002)Rename Alias (重命名别名)(7003)Update Alias (更新别名)(7004)GetAliasesForAccount (获得帐户的别名)(7005)GetAccountForAliases (获得别名的帐户)(7006)当调用Create Alias方法TOO1时，将创建与主帐号名相关联的别名并设置初始的属性集600。如果在创建别名时提供了确认令牌，那么，将设置属性IsVerified 625，这样， 所创建的别名505是经证明的别名。Delete Alias方法7002和Rename Alias方法7003分别允许从系统中删除别名和重命名别名。如果用户105重命名别名505，如上所述，其属性和与其相关联的任意其他数据将使用固定的标识符(例如AUID)被持久保存。调用者可以调用Update Alias方法7004来改变与别名相关联的属性600。例如，可以切换IsPrivate 属性630以使得隐私有效或无效。现在转到图8-11，示出了使用别名的几个示例性使用场景。需要强调，这些使用场景旨在突出本系统能够实现的各种服务特征和用户体验，并不是要意图以任意方式来限制其可应用的范围。图8示出用户(代表性地示为用户105)可以使用在桌面客户机设备11 上运行的瘦客户机应用程序302用别名登录到依靠服务115的示例性使用场景800。虽然在该示例中使用了桌面客户机设备112”但该使用场景对于图1所示的其他客户机设备也是类似的，并将在附加的文本中描述。所述场景在当用户尝试使用由瘦客户机应用程序302所实现的web浏览器访问依靠服务115时开始(如附图标记810所指示)。
依靠服务115将返回含有登录链接的页面(820)。当用户IOS1点击该链接时，重定向该用户到身份和验证服务122(830)以代表依靠服务115执行对该用户的验证。身份和验证服务122呈现一个登录对话框，通过该对话框，用户可以登录。虽然用户IOS1具有使用该用户的主帐号名和密码进行登录的选项，但在本场景中，该用户用别名和密码进行登录(840)。典型地，出于为用户IOS1提供方便的考虑，对于所有该用户的别名，密码都将是与主帐号名相关联的相同密码。然而，并不要求用户使用公用的密码。身份和验证服务122使用提供的别名和密码来验证该用户IOS1，并将验证令牌返回给客户机(850)。验证令牌将包括加密形式的数据，所述数据包括与别名相关联的主帐号名、密码和AUID。身份和验证服务122随后重定向该用户105!到依靠服务115(860)。 使用在身份和验证服务122和依靠服务115预先共享的密钥，依靠服务115可以从传递自客户机的验证令牌中提取并解密数据，由此，向用户IOS1显示受保护的内容或提供个性化服务(870)。由于验证令牌包括主帐号的验证证书，用别名登录到依靠服务115通过验证下层的主帐号来对用户IOS1进行验证。这种特征确保了用户105访问合适的内容和个性 (personalization)，因为，依靠服务115将总是识别该主帐号名。图9示出用户IOS1H用在桌面客户机设备11 上运行的胖客户机应用程序306用别名登录到依靠服务115的示例性使用场景900。这个使用场景与使用瘦客户机应用程序的场景800相类似，但在实现细节上不同。该场景在当用户IOS1尝试通过应用程序306访问依靠服务115时开始(如由附图标记910所指示)。向用户IOS1呈现一个登录UI(用户界面)。用户用别名和密码登录该UI，并且所捕获的证书被发送给身份和验证服务122(920)。 在一些实现中，客户机侧的别名界面315，在图3中示出并将在附加文本中描述，可被配置为将API展现给胖客户机应用程序以启动捕获和发送功能。身份和验证服务122使用该别名验证该用户1051;并将验证票据返回给客户机 (930)，该验证票据包括加密形式的数据，所述数据包括与别名相关联的主帐号名、密码和 AUID。胖客户机应用程序306可以使用所述数据来请求来自依靠服务115的一个或多个服务票据(940)。以与上述场景800相类似的方式，验证票据包括主帐号名的事实使得依靠服务能合适地标识用户IOS1，即使该用户以别名登录。随后，依靠服务返回合适的服务票据 (950)。胖客户机应用程序306接着通过将先前步骤所接收的服务票据传递给依靠服务来从该依靠服务请求受保护和/或个性化的内容和服务(960)。依靠服务115响应于所述请求将内容或服务提供给用户105J970)。图10示出第三说明性使用场景1000，其中，用户可以接收发送给多个不同电子邮件别名的电子邮件消息。在该示例中，桌面客户机11 处的用户105i使用瘦客户机应用程序302与依靠服务115互动，在该场景中该依靠服务115包括主持的电子邮件服务。用户 IOS1请求访问依靠服务115的一个特征(1010)，该特征允许电子邮件消息定址给要统一检索的多个不同的别名。依靠服务115将返回含有登录链接的页面(1020)。当用户IOS1点击该链接时， 重定向该用户到身份和验证服务122(1030)以代表依靠服务115执行对该用户IOS1的验证。身份和验证服务122呈现一个登录对话框，通过该对话框，用户IOS1用别名和密码登录(1040)。
10
身份和验证服务122使用提供的别名和密码来验证该用户IOS1，并将验证令牌返回给客户机(1050)。验证令牌将包括加密形式的数据，所述数据包括与别名相关联的主帐号名、密码和AUID。另外，验证令牌将包含HasAliases (具有别名)字段。(注意，对于胖客户机应用程序306，HasAliases字段还被移入来自身份和验证服务122的响应的HTTP头部)。该HasAliases字段包括指示对该别名的最后的改变的时间戳(例如创建别名、重命名别名、更新其属性的时间等)。身份和验证服务122重定向该用户IOS1到依靠服务115(1060)。依靠服务 115可以从传递自客户机的包括主帐号名的验证令牌中提取数据。当依靠服务115从验证令牌中读取HasAliases字段时，它可以调用通过别名API 704(图7)所展现的 GetAliasesForAccount 方法(1070)。身份和验证服务122响应于来自依靠服务的API调用返回用户IOS1与主帐号名相关联的一别名列表(1080)。随后，依靠服务115可以将所有定址到各个电子邮件别名的电子邮件提供给用户105^1090)。电子邮件别名可以由依靠服务115缓存，直到 HasAliases字段中的时间戳指示该别名已经被改变。那时，依靠服务115可以做出另一个 GetAliasesR)rAccount调用以获取经更新的别名列表。图11示出第四说明性使用场景1100，其中，可通过别名由其他用户联络用户。在运行瘦客户机应用程序302的膝上客户机设备11 的用户10 与在此场景中包括事件计划服务的依靠服务115进行互动。用户10 希望将对事件的邀请发送给另一用户IOS1 (相应地，出于使得描述清楚的目的，后面的用户10 将被称为“主机”，而用户被称为 “被邀请者”)该场景在主机与依靠服务115互动以创建定址到被邀请者的电子邮件别名的邀请时开始(1110)。依靠服务115调用GetAccountForAliases方法(1120)，该方法通过别名API 704被展现并将在邀请中命名的电子邮件别名作为该方法的一个参数传递。身份和验证服务122返回与被邀请者的电子邮件别名相关联的主帐号名(1130)。然而，如果设置了电子邮件别名的IsPrivate属性(指示被邀请者IOS1不希望展现下层帐号名给来自别名的查找)，那么身份和验证服务122将不会响应于API调用返回主帐号名。假设，别名没有被设置为私有，依靠服务115将把邀请索引到从 GetAccounti^rAliases调用返回的主帐号名。例如通过电子邮件来给出通知，这样，被邀请者可以登录以获得邀请(1140)。被邀请者可以点击通知中的链接以被重定向到身份和验证服务122(1150)并使用用户主帐号名和密码或别名和密码来登录(1160)。身份和验证服务122使用提供的证书来验证该被邀请者，并将验证令牌返回给客户机(1170)。验证令牌将包括数据，所述数据包括与别名相关联的主帐号名、密码和AUID。 身份和验证服务122随后重定向该用户被邀请者到依靠服务115(1180)。随后，依靠服务 115可以响应于来自验证令牌的数据提供事件邀请(1190)。在上述场景中，事件邀请被发送到被邀请者的电子邮件地址。在替换的场景中，如果事件邀请被发送给不是别名的电子邮件地址，那么所述通知可以为被邀请者提供一个将电子邮件地址作为登录到使用主帐号名和密码的服务时的经证明的电子邮件别名加入的选项。尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述具体特征或动作。相反，上述具体特征和动作是作为实现权利要求的示例形式公开的。
权利要求
1.一种用于通过使用一个或多个别名(505)来向服务(122)标识用户(105)的方法， 所述方法包括下述步骤使用别名数据模型G00)，通过该别名数据模型将所述一个或多个别名(50 作为主帐号(512)的唯一的子身份来维护；展现用于操作所述一个或多个别名(505)的方法(700)；以及当所述用户(105)使用所述一个或多个别名(505)中的一个登录到所述服务(122)时向所述主帐号(512)验证该用户(105)。
2.如权利要求1所述的方法，其特征在于，所展现的方法包括创建别名、删除别名或重命名别名中的至少一个。
3.如权利要求1所述的方法，其特征在于，包括将一个或多个属性与别名关联的进一步的步骤。
4.如权利要求3所述的方法，其特征在于，所展现的方法包括更新与所述别名关联的属性。
5.如权利要求3所述的方法，其特征在于，与所述别名关联的属性提供下述至少一项 a)标识所述别名是否被证明，b)标识所述别名是否是私有的，c)标识所述别名的类型，或 d)提供所述别名的上下文。
6.如权利要求1所述的方法，其特征在于，所述别名数据模型允许从电子邮件地址、昵称、玩家标签或移动电话号码之中选择出所述一个或多个别名。
7.如权利要求1所述的方法，其特征在于，所述别名数据模型提供了与所述一个或多个别名的每个相关联的固定的标识符。
8.一个或多个计算机可读存储媒体，包括由放置在电子设备上的一个或多个处理器执行时履行一种用于操作API (704)的方法的指令，所述方法包括下述步骤配置所述API (704)来向调用者(710、714)展现用于操作与主帐号(512)相关联的别名(505)的方法(700)，所述别名(505)在别名数据模型(400)下作为所述主帐号(512)的子身份被安排；在API (704)处接收请求与所述主帐号(512)相关联的别名列表(1070)；以及将所述别名列表响应地返回给所述调用者(1080)。
9.如权利要求8所述的一个或多个计算机可读存储媒体，其特征在于，所述调用者是依靠服务，所述依靠服务被安排为依靠用于下述项的API方法a)使用别名验证所述依靠服务的用户，b)接收与所述主帐号相关联的别名列表，或c)接收与别名相关联的主帐号的标识。
10.如权利要求8所述的一个或多个计算机可读存储媒体，其特征在于，所述数据模型进一步提供了所述别名是唯一的并使用固定的标识符来标识。
11.如权利要求8所述的一个或多个计算机可读存储媒体，其特征在于，所述数据模型进一步提供了所述别名具有一个或多个相关联的属性，这些属性提供了下述至少一项a) 标识所述别名是否被证明，b)标识所述别名是否是私有的，c)标识所述别名的类型，或d) 提供所述别名的上下文。
12.如权利要求11所述的一个或多个计算机可读存储媒体，其特征在于，所述方法还包括下述步骤在API接收请求与别名相关联的所述主帐号的调用，并且如果所述一个或多个属性没有指示该别名是私有的，则将所述主帐号的标识返回给所述调用者。
13.如权利要求11所述的一个或多个计算机可读存储媒体，其特征在于，所述方法进一步包括包含下述至少一项的步骤a)响应于对创建别名的API的调用来创建所述别名， b)响应于对删除别名的API的调用来删除所述别名，c)响应于对重命名别名的API的调用来重命名所述别名，或d)改变与别名相关联的所述属性。
14.如权利要求13所述的一个或多个计算机可读存储媒体，其特征在于，如果当创建所述别名时提供了验证令牌，则将所述别名作为经证明的别名来创建。
15.如权利要求14所述的一个或多个计算机可读存储媒体，其特征在于，所述验证令牌进一步包括下述数据a)指示所述主帐号具有一个或多个关联的别名的数据，以及b)包括指示别名最后被改变的时间的时间戳的数据。
全文摘要
一种身份和验证平台(122)利用了一种数据模型(400)，该数据模型能够将多个身份例如电子邮件地址、移动电话号码、昵称、游戏ID和其他用户ID用作别名(505)，所述别名是一个主帐号名(512)的唯一的子身份。用户(105)可以使用平台(122)所支持的别名(505)来使用主帐号(512)的验证证书设计多个不同的在线身份。该平台(122)进一步被配置为将所述别名(505)展现给各个客户机应用程序和因特网可访问的站点与服务(206)，例如电子邮件、即时消息、媒体共享、游戏和社交网络等等，以便能够实现各种使用别名(505)的使用场景。
文档编号G06Q20/00GK102171712SQ200980139829
公开日2011年8月31日 申请日期2009年9月18日 优先权日2008年10月3日
发明者L·C·艾尔斯, N·马哈帕特洛, R·陈, W-Q·M·郭 申请人:微软公司
使用别名的身份和验证系统
背景技术：
对于用户和商业之类来说，因特网不断地变得越来越有价值。越来越多的人将因特网用于每天的任务，从购物、银行业务和付帐单到消费媒体和娱乐。电子商务正伴随在因特网上商业递送更多服务和内容、在线通信和合作以及为用户创造新的途径来彼此联络而不断发展。目前，用户能够从包括计算机、移动和智能电话、游戏控制台和其他具有网络连通性的设备的多种多样的平台集合中访问在线资源。当访问一些站点和服务时，用户需要被验证以使得互动是合适的并且没有在某些方面被误用。例如，尝试访问在线银行帐号的用户需要被验证以证明该用户就是他所声明的用户(即拥有帐户或被授权访问该帐户的合法银行客户)。另一个例子是，除其它原因以外，社交网站的用户需要被验证以防止仿冒者获得对用户页面的访问并贴出恶意或伪造的内容。验证通常涉及输入被称为“证书”以证明他的或她的身份的用户ID(或登录ID、帐号名、用户名等)以及密码或个人标识号码(“PIN”)的用户。虽然一些验证系统提供了令人满意的性能，但当前的系统并不能满足在线社区的所有需求。例如，用户既想使得他们在线设计的身份的灵活性，又要一种简单的方法来维护他们的身份的安全性而不需要使用经常是很长的密码列表(这将增加不安全的体验，例如跨多个网站上的重用帐号名和密码)。提供本背景技术来介绍以下概述和详细描述的简要上下文。本背景技术不旨在帮助确定所要求保护的主题的范围，也不旨在被看作将所要求保护的主题限于解决以上所提出的问题或缺点中的任一个或全部的实现。
发明内容
一种身份和验证平台利用了一种数据模型，该数据模型能够将诸如电子邮件地址、移动电话号码、昵称、游戏ID和其他用户ID等多个身份用作别名，所述别名是一个主帐号名的唯一的子身份。用户可以使用验证证书的通用集或主帐号的证书来访问该平台所支持的别名并使用别名来设计多个不同的在线身份。该平台进一步被配置为将所述别名展现给各个客户机应用程序和因特网可访问的站点与服务，例如电子邮件、即时消息、媒体共享、游戏和社交网络等等，以便能够实现各种使用别名的使用场景。在各种说明性示例中，支持别名使用的网站和服务依靠身份和验证服务以为网站和服务的用户提供验证(统称为“依靠服务”)。依靠服务可以与运行在web浏览器上的应用程序(即“瘦客户机”应用程序)或更多特征丰富的客户机应用程序(即“胖客户机”应用程序)结合起来操作，以提供广泛范围的使用别名的使用场景。例如，用户可以登录到依靠服务，并使用他们的主帐号名和密码或使用别名和相同的主帐号密码来验证用户。可以集中地管理多个电子邮件帐号(其中每个电子邮件帐号用不同的别名标识用户)，以便用户能够登录到验证的主电子邮件帐号，并随后接收定址到不同电子邮件别名的电子邮件消息。并且，依靠服务的用户可以通过使用这样的用户的别名来找到其他用户。 可以将使用事件计划服务生成的邀请定址到，例如用户的别名，但仍然递送到该用户的主帐号。或者，游戏玩家可以通过在线游戏服务上的别名来查找并找到另一玩家的简档。为用户提供用于使用别名管理他们在线身份的工具。用户具有创建、更新和删除别名并管理在各种服务中如何使用它们的能力。用户还可以设置与他们的别名相关联的一个或多个属性，以限制在别名和主帐号名之间的关联在服务上公开的范围。这使得用户能够在任何期望的时候维护隐私，同时仍然能够享受别名所提供的益处。有利地，本身份和验证平台是在各种各样的服务上可扩展并可缩放的，这些服务是可由不相关的服务提供者操作的(例如电子邮件别名可以被应用到使用由不同的提供者主持的不同的域的电子邮件帐号)。该平台为用户提供了一种便捷和安全方法来使用和展现别名以管理在在线社区中如何察觉他们，同时控制何时且如何能联系他们以及在期望的时候保护他们的隐私。提供本概述是为了以简化的形式介绍将在以下详细描述中进一步描述的一些概念。本概述不旨在标识出所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。
图1示出一种说明性在线服务环境，在其中，在客户机设备处的用户可以与依靠支持别名的身份和验证服务的在线站点和服务互动；图2示出可以与别名一起使用的站点和服务的说明性集；图3示出了可以在客户机设备上运行的说明性的瘦客户机应用程序和胖客户机应用程序；图4示出说明性的别名数据模型；图5示出可以与主帐号名相关联的别名的说明性集；图6示出可以与别名相关联的属性的说明性集；图7示出了由API(应用编程接口)展现给客户机应用程序和依靠服务的方法的说明性集；图8示出第一说明性使用场景，其中，用户可以使用瘦客户机应用程序用别名登录到服务；图9示出第二说明性使用场景，其中，用户可以使用胖客户机应用程序用别名登录到服务；图10示出第三说明性使用场景，其中，用户可以接收发送给多个不同电子邮件别名的电子邮件消息；以及图11示出第四说明性使用场景，其中，可通过别名由其他用户联络用户。各附图中相同的附图标记指示相同的元素。除非另外指明，否则各元素不是按比例绘制的。
具体实施例方式计算机用户经常维护不同的身份以用于不同的在线站点和服务。单个用户可以使用各种标识符，例如电子邮件地址、昵称、用户名、移动电话号码、游戏名字或ID和其他构造，在不同的时间和不同的设置中来反映用户在线身份。因此，例如，用户可以使用基于现有的网络服务利用移动电话号码，基于现有的网络服务例如可与移动电话一起操作的即时消息(“IM”)。另外，用户可以用用户名登录在线社交网站并在登录飞行常客帐号时使用电子邮件地址。用户可以发现维护多个分散的身份是麻烦的。例如，因为越来越多的站点和服务要求帐号创建来使用它们，不同的帐号名和密码的扩散会导致用户的“密码疲劳”。对于这些用户而言，记住他们的密码是很困难的，这将导致用户在多个站点和服务上重用相同的证书。这种体验不仅造成了易于盗窃和身份欺骗，而且用户也失去了如何将他们自己呈现给在线社区的灵活性。用户经常想要以不同的身份代表他们自己的能力，因为这允许他们使他们的身份适应于特定的在线上下文，并且在一些情况中，将该能力扩展到其他用户以联络他们。然而，在大多数的在线服务上，用户典型地仅被允许具有与给定帐号相关联的单个身份。尽管存在多个昵称可以与一个帐号相关联的现有服务，它们目前都被限制在涉及组讨论的在线服务，并且这些昵称在该组之外就不能使用。昵称也不能用于登录主帐号。这些限制使得那些想要具有丰富的在线社交互动的用户感到灰心。本身份和验证系统使用户受益，并解决了当前在线环境的限制。该系统为用户提供了一种简单的方法来使用别名管理他们的在线身份，以控制何时和如何联络他们。现在转向附图，图1示出说明性在线服务环境100，其中，在各个客户机设备IU1, 2...N处的用户IOS1,"可以在诸如因特网120等网络上与各种在线站点和服务进行互动。客户机设备112可以采用各种形状因素并被配置为具有不同的能力和资源。在这个示例中， 客户机设备112包括桌面PC IU1、膝上PC 1122、移动设备1123(例如智能电话、移动电话等)、以及视频游戏控制台11 。然而，要强调的是，这些设备旨在是说明性的，并且还可以满足特定实现的需求所需要的那样来使用其他类型的设备。将在线站点和服务配置为依靠服务122来提供身份和验证。因此，在线站点和服务被称为“依靠服务”，并且由图1中的附图标记115来统一地标识。客户机设备112、依靠服务115以及身份和验证服务典型地使用HTTP (超文本传输协议)来通信。在一些实现中，依靠服务115以及身份和验证服务122中的一个或多个可以由相同的实体来操作。然而，这并不是一种要求，因为，依靠服务提供者也可以将用户验证委派给操作身份和验证服务122的无联系的第三方提供者。依靠服务115可以包括可由一个或多个服务提供者操作的广泛的各种不同的服务。图2示出了可以在一些实现中使用的特定依靠服务的说明性示例。这些示例旨在进行说明，在每个应用中并不需要使用在图2中示出的所有示例，并且在给定的实现中可以使用没有示出的其他服务。说明性的依靠服务115包括支持下述项的服务即时消息206i ； 桌面电子邮件20 ；个人网页20 ；主机电子邮件20 ；在线文件存储和/或共享20 ；媒体内容(例如图片、音频或视频)共享20 ；网络论坛和/或讨论组2067 ；博客(即网页博客)20 ；事件计划20 ；或社交网络2061(|。提供不是如上所列出的但却依靠身份和验证服务122的服务的网站也可被使用(如由图2中的附图标记20 所统一标识的)。为了向使用别名的用户105提供特别的体验，客户机设备112(图1)通过安装在该设备上并在其上运行的客户机应用程序与依靠服务115(以及身份和验证服务122)互动。如图3所示，客户机设备(如由桌面PC 11 所代表)可以运行包括瘦客户机应用程
6序30A,2...n和胖客户机应用程序306^两者的各种客户机应用程序。虽然在图2中示出了 N个胖客户机应用程序和瘦客户机应用程序，在给定客户机设备112上使用的特定类型和数目的应用程序可以随实现和客户机设备的能力而变化。例如，移动设备可以不运行与 PC和游戏控制器相比那样多的客户机应用程序，而其所运行的那些应用程序可以适应于该移动设备所支持的更加约束资源的运行时环境。瘦客户机应用程序302典型地是那些可以使用web浏览器，例如在PC上的微软因特网浏览器 和移动设备的因特网浏览器移动版，来实现的应用程序。瘦客户机应用程序通常以浏览器支持的语言，例如HTML(超文本标记语言)和XML(可扩展标记语言)，来编码并执行如脚本和ActiveX控件的特征。胖客户机应用程序306典型地由使用诸如PC上的Win32等编程环境的独立应用程序来实现。胖客户机应用程序通常包括例如桌面电子邮件、博客和IM客户端的应用程序，这些应用程序与作为瘦客户机实现的类似的应用程序相比典型地为本地数据存储提供了更加丰富的特征集和更好的灵活性。在一些实现中，可以使用客户机侧别名接口 315(即本地安装的API)向胖客户机应用程序306展现别名功能性。然而，这样的接口 315并不需要在所有实现中使用，并且一些胖客户机应用程序306可以被配置为通过调用经由所述身份和验证服务122所支持的API (应用编程接口)所展现的方法来直接与别名服务对接，如将在下面结合图7所述的文本中更详细描述。身份和验证服务122 (图1)被安排为在灵活的数据模型下将别名展现给依靠服务 115和客户机应用程序302和306，所述数据模型支持广泛范围的别名使用场景(这些使用场景中的一些在图8-11中被示出并将结合文本进行描述)。图4示出说明性的别名数据模型400，它提供了别名是主帐号的子身份(如附图标记415所指示)。由身份和验证服务 122提供该主帐号。例如，身份和验证服务122可以作为微软的Windows Live ID 服务的一部分来实现，这样，该主帐号包括Windows Live ID，例如电子邮件地址(例如“userOlive. C0m”、“User@h0tmail.C0m”等)，用户使用它来访问各种在线服务，所述服务包括微软公司提供的这些服务以及第三方提供的服务。在替换安排中，主帐号可以被依靠服务115中的一个的提供者所支持。无论谁是主帐号提供者，一般而言，依靠服务115将(例如通过适当范围的服务合同)同意给定的用户105将能够访问所有的依靠服务115并且由身份和验证服务122使用该主帐号和其关联的别名来验证。别名数据模型400进一步提供别名可以包括各种类型的标识020)。如图5所示， 用户(由用户105!代表性指示)可以有资格使用与主帐号名512(即userihotmail. com) 相关联的一个或多个别名505。别名说明性地包括，但不是必须局限于，电子邮件地址505” 昵称50 、移动电话号码50 以及在微软公司的)(b0X LIVE 在线游戏服务的情况下被称为“玩家标签”50 的游戏玩家简档名字。这些特定类型的标识是说明性的，并且如特定应用所要求可以使用其他的类型。电子邮件地址别名5051可以包括来自不同域的电子邮件地址，并且可以被不同的和/或不相关的依靠服务提供者所支持。昵称别名50 和玩家标签别名50 是在域中的名字，虽然该域自身并不会展现给用户105。例如，虽然，出于系统跟踪该别名的起源的目的，昵称别名包括(例如“nickname@domain.com”)的域，但用户105所使用和看到的别名仅是简单的“nickname”。
回看图4，数据模型400提供了所有的别名505在服务环境100中都是唯一的025)，并且每个别名都与一个固定的标识符(430)相关联，所述标识符在此称为 “AUID”(别名唯一标识符)。模型下的唯一性确保了用户105可以声明使用别名的专有权， 并且与该别名明确关联。并且通过成为固定的(即决不被改变或重分配)，AUID使得系统数据与别名相关联并被跟踪，这样，可以在用户105决定以任何方式更新或修改别名的情况下维护服务的连续性。例如，如下将详细描述，用户105可以希望基于使用别名的询问限制主帐号名的展现。这种限制可以关联于AUID，这样，如果改变了别名的名字(例如从 "Nicknamel"变为“Nickname〗”)，还可以对新别名的名字维持有关隐私的用户的偏好。数据模型400还提供了别名可以具有属性(435)，这些属性形成了用于定义用户 105的身份的核心。一个示例性的属性集600在图6中被示出。在这个示例中的属性包括IsEmail (是电子邮件)(如附图标记605所指示)IsMobile (610)(是移动电话)IsGamertag (615)(是玩家标签)IsNickname (620)(是昵称)IsVerified(625)(是被证明的)IsPrivate (630)(是私有的)Context (635)(上下文)注意，并不是所有的上面示出的属性都必须在任意给定的实现中都被使用。属性IsEmail 605、IsMobile 610、IsGamertag 615 以及 IsNickname 620 分别被用于标识别名类型。这种标识可以用于使得依靠服务115以及身份和验证服务122以合适于别名类型的方式来使用这些别名。被设计用于向电子邮件别名递送的消息，被用于向移动电话号码别名发送时，例如由于消息协议的变化以及设备特性例如现实和呈现能力的差异，将必定不会有效率地工作。当电子邮件地址被用作别名并且该电子邮件地址由与身份和验证服务122的提供者无关的依靠服务115所提供时，IsVerified属性625是典型地可应用的。在这种情况，服务122需要在允许别名与主帐号相关联并由依靠服务115使用之前证明该别名的有效性。当电子邮件别名的用户已经证明他或她拥有该电子邮件地址时可以为该电子邮件别名设置IsVerified属性标志。否则，当未被证明时由服务122来跟踪该电子邮件别名，这将典型地限制了其中可以使用未被证明的别名的使用场景。例如，如果使用未被证明的别名(即该别名的IsVerified属性标志未设置)来从事件计划服务20 发送邀请给被邀请者，那么，被邀请者将不能接受该邀请，直到被邀请者可以示出该别名属于被邀请者并对其具有权限。未被证明的电子邮件别名通过一种方法获取证明，在该方法中，身份和验证服务122发送单独的定址到该未被证明的电子邮件别名的电子邮件。来自服务122的电子邮件包括包含确认令牌的确认链路。当点击链路时，将打开一个网页，被邀请者可以登录到该网页，由此证明在对该电子邮件别名的合法收件箱处接收了确认电子邮件。确认还可以用于用作别名的移动电话号码。包含代码的SMS(短消息服务)消息可以被发送给移动电话号码别名。用户可以转到使用例如PC或该电话上的移动浏览器建立的网页，并将来自SMS消息的代码输入由该站点提供的用户界面，由此用身份和验证服务122证明该移动电话号码别名。IsPrivate属性630提供了一个展现别名505和主帐号名512之间的关系的别名用户的偏好的指示。如果设置了 IsPrivate属性标志，那么，身份和验证服务122将不会对来自调用者的查询展现任意别名505之下的主帐号名512。这样，IsPrivate属性630的使用使得用户能够允许或阻止某个人或某个服务查找与别名相关联的主帐号名。在一些实现中，也支持反向情况，其中用户可以允许或阻止对与主帐号名相关联的所有别名或别名的所选子集的查找。Context属性6；35可被用于指示使用别名的上下文。例如，Context属性6；35可以指示使用了哪些特定的依靠服务115或哪些特定的依靠服务115与给定别名505相关联。当实现某些使用场景或服务特征时，其他依靠服务115可以随后使用这种上下文。例如，可以标记在第一依靠服务内部创建的电子邮件别名的Context属性635，即Context = servicel。随后，第二依靠服务可以检查该Context属性并发现该电子邮件别名还没有与第二服务一起使用。随后可以通知用户有关将该电子邮件别名与第二依靠服务一起使用的选项。Context属性635的其他使用可以包括向用户105显示哪些别名与哪些依靠服务115 一起被使用，或基于使用率分类别名。如在图7中所示，别名数据模型400可以用于定义各种方法700，这些方法可以由身份和验证服务122通过API 704展现给来自依靠服务115和应用程序302和306的远程调用(分别由附图标记710和714所指示)。方法700示例性包括Create Alias (创建别名)(如附图标记TOO1所指示)Delete Alias (删除别名)(7002)Rename Alias (重命名别名)(7003)Update Alias (更新别名)(7004)GetAliasesForAccount (获得帐户的别名)(7005)GetAccountForAliases (获得别名的帐户)(7006)当调用Create Alias方法TOO1时，将创建与主帐号名相关联的别名并设置初始的属性集600。如果在创建别名时提供了确认令牌，那么，将设置属性IsVerified 625，这样， 所创建的别名505是经证明的别名。Delete Alias方法7002和Rename Alias方法7003分别允许从系统中删除别名和重命名别名。如果用户105重命名别名505，如上所述，其属性和与其相关联的任意其他数据将使用固定的标识符(例如AUID)被持久保存。调用者可以调用Update Alias方法7004来改变与别名相关联的属性600。例如，可以切换IsPrivate 属性630以使得隐私有效或无效。现在转到图8-11，示出了使用别名的几个示例性使用场景。需要强调，这些使用场景旨在突出本系统能够实现的各种服务特征和用户体验，并不是要意图以任意方式来限制其可应用的范围。图8示出用户(代表性地示为用户105)可以使用在桌面客户机设备11 上运行的瘦客户机应用程序302用别名登录到依靠服务115的示例性使用场景800。虽然在该示例中使用了桌面客户机设备112”但该使用场景对于图1所示的其他客户机设备也是类似的，并将在附加的文本中描述。所述场景在当用户尝试使用由瘦客户机应用程序302所实现的web浏览器访问依靠服务115时开始(如附图标记810所指示)。
依靠服务115将返回含有登录链接的页面(820)。当用户IOS1点击该链接时，重定向该用户到身份和验证服务122(830)以代表依靠服务115执行对该用户的验证。身份和验证服务122呈现一个登录对话框，通过该对话框，用户可以登录。虽然用户IOS1具有使用该用户的主帐号名和密码进行登录的选项，但在本场景中，该用户用别名和密码进行登录(840)。典型地，出于为用户IOS1提供方便的考虑，对于所有该用户的别名，密码都将是与主帐号名相关联的相同密码。然而，并不要求用户使用公用的密码。身份和验证服务122使用提供的别名和密码来验证该用户IOS1，并将验证令牌返回给客户机(850)。验证令牌将包括加密形式的数据，所述数据包括与别名相关联的主帐号名、密码和AUID。身份和验证服务122随后重定向该用户105!到依靠服务115(860)。 使用在身份和验证服务122和依靠服务115预先共享的密钥，依靠服务115可以从传递自客户机的验证令牌中提取并解密数据，由此，向用户IOS1显示受保护的内容或提供个性化服务(870)。由于验证令牌包括主帐号的验证证书，用别名登录到依靠服务115通过验证下层的主帐号来对用户IOS1进行验证。这种特征确保了用户105访问合适的内容和个性 (personalization)，因为，依靠服务115将总是识别该主帐号名。图9示出用户IOS1H用在桌面客户机设备11 上运行的胖客户机应用程序306用别名登录到依靠服务115的示例性使用场景900。这个使用场景与使用瘦客户机应用程序的场景800相类似，但在实现细节上不同。该场景在当用户IOS1尝试通过应用程序306访问依靠服务115时开始(如由附图标记910所指示)。向用户IOS1呈现一个登录UI(用户界面)。用户用别名和密码登录该UI，并且所捕获的证书被发送给身份和验证服务122(920)。 在一些实现中，客户机侧的别名界面315，在图3中示出并将在附加文本中描述，可被配置为将API展现给胖客户机应用程序以启动捕获和发送功能。身份和验证服务122使用该别名验证该用户1051;并将验证票据返回给客户机 (930)，该验证票据包括加密形式的数据，所述数据包括与别名相关联的主帐号名、密码和 AUID。胖客户机应用程序306可以使用所述数据来请求来自依靠服务115的一个或多个服务票据(940)。以与上述场景800相类似的方式，验证票据包括主帐号名的事实使得依靠服务能合适地标识用户IOS1，即使该用户以别名登录。随后，依靠服务返回合适的服务票据 (950)。胖客户机应用程序306接着通过将先前步骤所接收的服务票据传递给依靠服务来从该依靠服务请求受保护和/或个性化的内容和服务(960)。依靠服务115响应于所述请求将内容或服务提供给用户105J970)。图10示出第三说明性使用场景1000，其中，用户可以接收发送给多个不同电子邮件别名的电子邮件消息。在该示例中，桌面客户机11 处的用户105i使用瘦客户机应用程序302与依靠服务115互动，在该场景中该依靠服务115包括主持的电子邮件服务。用户 IOS1请求访问依靠服务115的一个特征(1010)，该特征允许电子邮件消息定址给要统一检索的多个不同的别名。依靠服务115将返回含有登录链接的页面(1020)。当用户IOS1点击该链接时， 重定向该用户到身份和验证服务122(1030)以代表依靠服务115执行对该用户IOS1的验证。身份和验证服务122呈现一个登录对话框，通过该对话框，用户IOS1用别名和密码登录(1040)。
10
身份和验证服务122使用提供的别名和密码来验证该用户IOS1，并将验证令牌返回给客户机(1050)。验证令牌将包括加密形式的数据，所述数据包括与别名相关联的主帐号名、密码和AUID。另外，验证令牌将包含HasAliases (具有别名)字段。(注意，对于胖客户机应用程序306，HasAliases字段还被移入来自身份和验证服务122的响应的HTTP头部)。该HasAliases字段包括指示对该别名的最后的改变的时间戳(例如创建别名、重命名别名、更新其属性的时间等)。身份和验证服务122重定向该用户IOS1到依靠服务115(1060)。依靠服务 115可以从传递自客户机的包括主帐号名的验证令牌中提取数据。当依靠服务115从验证令牌中读取HasAliases字段时，它可以调用通过别名API 704(图7)所展现的 GetAliasesForAccount 方法(1070)。身份和验证服务122响应于来自依靠服务的API调用返回用户IOS1与主帐号名相关联的一别名列表(1080)。随后，依靠服务115可以将所有定址到各个电子邮件别名的电子邮件提供给用户105^1090)。电子邮件别名可以由依靠服务115缓存，直到 HasAliases字段中的时间戳指示该别名已经被改变。那时，依靠服务115可以做出另一个 GetAliasesR)rAccount调用以获取经更新的别名列表。图11示出第四说明性使用场景1100，其中，可通过别名由其他用户联络用户。在运行瘦客户机应用程序302的膝上客户机设备11 的用户10 与在此场景中包括事件计划服务的依靠服务115进行互动。用户10 希望将对事件的邀请发送给另一用户IOS1 (相应地，出于使得描述清楚的目的，后面的用户10 将被称为“主机”，而用户被称为 “被邀请者”)该场景在主机与依靠服务115互动以创建定址到被邀请者的电子邮件别名的邀请时开始(1110)。依靠服务115调用GetAccountForAliases方法(1120)，该方法通过别名API 704被展现并将在邀请中命名的电子邮件别名作为该方法的一个参数传递。身份和验证服务122返回与被邀请者的电子邮件别名相关联的主帐号名(1130)。然而，如果设置了电子邮件别名的IsPrivate属性(指示被邀请者IOS1不希望展现下层帐号名给来自别名的查找)，那么身份和验证服务122将不会响应于API调用返回主帐号名。假设，别名没有被设置为私有，依靠服务115将把邀请索引到从 GetAccounti^rAliases调用返回的主帐号名。例如通过电子邮件来给出通知，这样，被邀请者可以登录以获得邀请(1140)。被邀请者可以点击通知中的链接以被重定向到身份和验证服务122(1150)并使用用户主帐号名和密码或别名和密码来登录(1160)。身份和验证服务122使用提供的证书来验证该被邀请者，并将验证令牌返回给客户机(1170)。验证令牌将包括数据，所述数据包括与别名相关联的主帐号名、密码和AUID。 身份和验证服务122随后重定向该用户被邀请者到依靠服务115(1180)。随后，依靠服务 115可以响应于来自验证令牌的数据提供事件邀请(1190)。在上述场景中，事件邀请被发送到被邀请者的电子邮件地址。在替换的场景中，如果事件邀请被发送给不是别名的电子邮件地址，那么所述通知可以为被邀请者提供一个将电子邮件地址作为登录到使用主帐号名和密码的服务时的经证明的电子邮件别名加入的选项。尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述具体特征或动作。相反，上述具体特征和动作是作为实现权利要求的示例形式公开的。
权利要求
1.一种用于通过使用一个或多个别名(505)来向服务(122)标识用户(105)的方法， 所述方法包括下述步骤使用别名数据模型G00)，通过该别名数据模型将所述一个或多个别名(50 作为主帐号(512)的唯一的子身份来维护；展现用于操作所述一个或多个别名(505)的方法(700)；以及当所述用户(105)使用所述一个或多个别名(505)中的一个登录到所述服务(122)时向所述主帐号(512)验证该用户(105)。
2.如权利要求1所述的方法，其特征在于，所展现的方法包括创建别名、删除别名或重命名别名中的至少一个。
3.如权利要求1所述的方法，其特征在于，包括将一个或多个属性与别名关联的进一步的步骤。
4.如权利要求3所述的方法，其特征在于，所展现的方法包括更新与所述别名关联的属性。
5.如权利要求3所述的方法，其特征在于，与所述别名关联的属性提供下述至少一项 a)标识所述别名是否被证明，b)标识所述别名是否是私有的，c)标识所述别名的类型，或 d)提供所述别名的上下文。
6.如权利要求1所述的方法，其特征在于，所述别名数据模型允许从电子邮件地址、昵称、玩家标签或移动电话号码之中选择出所述一个或多个别名。
7.如权利要求1所述的方法，其特征在于，所述别名数据模型提供了与所述一个或多个别名的每个相关联的固定的标识符。
8.一个或多个计算机可读存储媒体，包括由放置在电子设备上的一个或多个处理器执行时履行一种用于操作API (704)的方法的指令，所述方法包括下述步骤配置所述API (704)来向调用者(710、714)展现用于操作与主帐号(512)相关联的别名(505)的方法(700)，所述别名(505)在别名数据模型(400)下作为所述主帐号(512)的子身份被安排；在API (704)处接收请求与所述主帐号(512)相关联的别名列表(1070)；以及将所述别名列表响应地返回给所述调用者(1080)。
9.如权利要求8所述的一个或多个计算机可读存储媒体，其特征在于，所述调用者是依靠服务，所述依靠服务被安排为依靠用于下述项的API方法a)使用别名验证所述依靠服务的用户，b)接收与所述主帐号相关联的别名列表，或c)接收与别名相关联的主帐号的标识。
10.如权利要求8所述的一个或多个计算机可读存储媒体，其特征在于，所述数据模型进一步提供了所述别名是唯一的并使用固定的标识符来标识。
11.如权利要求8所述的一个或多个计算机可读存储媒体，其特征在于，所述数据模型进一步提供了所述别名具有一个或多个相关联的属性，这些属性提供了下述至少一项a) 标识所述别名是否被证明，b)标识所述别名是否是私有的，c)标识所述别名的类型，或d) 提供所述别名的上下文。
12.如权利要求11所述的一个或多个计算机可读存储媒体，其特征在于，所述方法还包括下述步骤在API接收请求与别名相关联的所述主帐号的调用，并且如果所述一个或多个属性没有指示该别名是私有的，则将所述主帐号的标识返回给所述调用者。
13.如权利要求11所述的一个或多个计算机可读存储媒体，其特征在于，所述方法进一步包括包含下述至少一项的步骤a)响应于对创建别名的API的调用来创建所述别名， b)响应于对删除别名的API的调用来删除所述别名，c)响应于对重命名别名的API的调用来重命名所述别名，或d)改变与别名相关联的所述属性。
14.如权利要求13所述的一个或多个计算机可读存储媒体，其特征在于，如果当创建所述别名时提供了验证令牌，则将所述别名作为经证明的别名来创建。
15.如权利要求14所述的一个或多个计算机可读存储媒体，其特征在于，所述验证令牌进一步包括下述数据a)指示所述主帐号具有一个或多个关联的别名的数据，以及b)包括指示别名最后被改变的时间的时间戳的数据。
全文摘要
一种身份和验证平台(122)利用了一种数据模型(400)，该数据模型能够将多个身份例如电子邮件地址、移动电话号码、昵称、游戏ID和其他用户ID用作别名(505)，所述别名是一个主帐号名(512)的唯一的子身份。用户(105)可以使用平台(122)所支持的别名(505)来使用主帐号(512)的验证证书设计多个不同的在线身份。该平台(122)进一步被配置为将所述别名(505)展现给各个客户机应用程序和因特网可访问的站点与服务(206)，例如电子邮件、即时消息、媒体共享、游戏和社交网络等等，以便能够实现各种使用别名(505)的使用场景。
文档编号G06Q20/00GK102171712SQ200980139829
公开日2011年8月31日 申请日期2009年9月18日 优先权日2008年10月3日
发明者L·C·艾尔斯, N·马哈帕特洛, R·陈, W-Q·M·郭 申请人:微软公司
最新回复(0)