用于在计算机网络中管理对被保护资源的访问以及委托授权的方法

摘要

在方法中，使用者(100)向服务提供者(200)传送(s10)由所述使用者(100)代表被委托者(410)访问委托者(420)的被保护资源的授权请求，其中，所述使用者(100)是代表用户访问服务提供者(200)的软件应用或web站点，所述服务提供者(200)是提供对被保护资源的访问的软件应用或web站点。所述服务提供者(200)向控制器(300)传送(s20)该授权请求。请求令牌也被传送，该请求令牌是所述服务提供者(200)用来登记请求的授权的值。所述控制器(300)确定(s30)该请求的授权是否满足管控对委托者的被保护资源的访问的策略设置。如果符合，则所述服务提供者(200)准许所述请求令牌所登记的授权，并且包含所述请求令牌的第三消息被传送(s50)到所述使用者(100)。

说明书

技术领域

本发明涉及计算机或通信网络中对被保护资源的访问管理、访问此类资源 的授权委托以及此类资源的使用。具体来说，本发明涉及由物理实体执行的用 于执行这种访问管理和授权委托的方法，并且涉及配置用于此目的的物理实体 和计算机程序。本发明可特别地应用于使用计算机网络中与用户相关联的资源 的web服务环境中，其中资源分散在两个或更多web应用或web站点上并且其 中用户也可以是地理上分散的。

背景技术

在计算机或通信网络中，为了有利于一个用户或更普遍地为了有利于多个 用户，不同web站点或web应用可提供不同的服务。例如，一个web站点或 web应用可管理一个用户的电子邮件账户。另一个web站点或web应用可使能 照片的存储以便与该用户的社交网络中的成员共享这些照片。还有一个web站 点或web应用可作为一个书店来管理用户的书店账号。而再另外的web站点或 web应用可提供图像和照片的打印并将它们输送给用户。这些可能性是无穷的。

然而，web站点和web应用可希望能提供新的服务“which tie together  functionality from other sites”(Eran Hammer-Lahav，“Explaining OAuth”，2007年9 月5日，http://hueniverse.com/2007/09/explaining-oauth 2009年9月15日获取到， 这里称为参考文献[1])。例如，数码照片实验室打印web应用(如示例性的web 站点“printer.consumer.com”)可能想代表用户获取存储在数字图像托管web站 点(如示例性的站点“photos.container.com”)中的照片，其中该用户在该站点 具有一个账户，以便打印并输送这些照片给用户。

为了实现集成了来自不同web站点和web应用的被保护资源的web服务， 第一web站点或web应用，这里称为“使用者”，可请求用户提供他或她的证 书以便访问第二web站点或web应用，这里称为“服务提供者”(尽管使用者 也提供服务)。在上述例子中，使用者会是数码照片实验室打印web应用，服务 提供者会是数字图像托管web站点，以及被保护资源会是用户的私人照片。换 句话说，使用者可请求用户提供他或她的用户名和密码以便访问服务提供者。 然而，这暴露了用户的密码并且使得该密码能够被其它人使用来在服务提供者 内进行与该用户的账号相关联的任何动作(例如，“甚至改变你的密码并将你锁 在外(even change your password and lock you out)”，参考文献[1]，章节“What is it  For”)。

为了解决该问题，开发了OAuth协议(Atwood，M.等，″OAuth Core 1.0 Revision A″，2009年6月24日，http://oauth.net/core/1.0a 2009年9月15日获 取到，这里称为参考文献[2])。OAuth协议使得一个web站点或web应用(即 使用者)能够从另一个web站点或web应用(即服务提供者)访问被保护资源， 而不要求用户公开他们的服务提供者证书给使用者(参考文献[2]，摘要)。OAuth 协议可被认为是一个应用编程接口(API)访问委托协议。参考文献[1]章节 “What is it For”中解释的“贴身男仆钥匙类比(valet key analogy)”可帮助直观 地理解OAuth协议的目的。

在OAuth协议中，鉴权，即“用户准许访问他们的被保护资源而无需共享 他们的证书给使用者的过程”(参考文献[2]，“6.Authenticating with OAuth”)，工 作如下。

使用者从服务提供者获得未授权的请求令牌。使用者使用服务提供者的用 户授权URL(“URL”在这里表示“统一资源定位符”)经由用户的web浏览器 将用户指引到服务提供者。然后用户与服务提供者进行鉴权。换句话说，用户 登录到服务提供者的web站点。用户从不将他或她的服务提供者证书提供给使 用者。

然后，服务提供者向用户询问他或她是否同意使用者被准许访问被保护资 源。为此，服务提供者向用户展现与使用者想要访问的被保护资源有关的信息。 该信息包括请求访问的持续时间和访问类型(例如，复制、修改或删除被保护 资源)。例如，该信息可以展现在服务提供者web站点的网页上，以示例性的消 息形式，例如“web站点<使用者名>请求在接下来的1小时内访问你的私人照 片，你同意这种访问吗？”。然后用户准许或拒绝服务提供者的许可以代表用户 给使用者直观的访问。

如果用户同意，请求令牌被授权并且用户被指引回到使用者，这样通知使 用者请求令牌已被授权。然后授权的请求令牌被交换为访问令牌并且使用者可 以代表用户来访问被保护资源。如果用户拒绝许可，通知使用者请求令牌已被 废除。

使用OAuth协议的鉴权过程的例子展现在Eran Hammer-Lahav，″Beginner′s  Guide to OAuth-Part II：Protocol Workflow″，2007年10月15日， http://hueniverse.com/2007/10/beginners-guide-to-oauth-part-ii-protocol-workflow/2009年9月15日获取。

现在，一个新问题产生了。为了实现集成了来自不同web站点和web应用 的被保护资源的web服务，第一web站点或web应用(即“使用者”)可能希 望代表第一用户来访问来自第二web站点或web应用(即“服务提供者”)的 第二用户的被保护资源，其中第一用户和第二用户是不同的用户。

例如，第二用户应允许第一用户使用使用者来访问服务提供者以便访问与 第二用户相关的被保护资源，其中，使用者可以是数码照片实验室打印web应 用，服务提供者可以是数字图像托管web站点，被保护资源可以是第二用户的 私人照片。

专利申请US 2008/0066159A1涉及一种授权委托机制，包括维护者、第一 负责人和第二负责人(第[0007]、[0068]-[0078]段及图6)。所述维护者具有权利 准许能力。经由传递委托授权主张，将权利准许能力从维护者委托给负责人#1。

希望改进方法、物理实体和计算机程序以管理代表用户由这里称为使用者 的web站点或web应用对与这里被称为服务提供者的其它web站点或web应用 上的用户相关联的被保护资源的访问，同时考虑减少操作负担的需要以及以灵 活、安全和有效的方式解决更多情形的希望。

发明内容

为了满足或至少部分地满足这些目的，在独立权利要求中定义了方法、委 托辅助设备和计算机程序。在从属权利要求中定义了有利的实施例。

在一个实施例中，方法至少由使用者、服务提供者和控制器来执行。服务 提供者是被配置成提供对被保护资源的访问的软件应用和web站点中的至少一 个。使用者是被配置成代表用户访问服务提供者的软件应用和web站点中的至 少一个。所述方法包括由使用者向服务提供者传送第一消息，该第一消息表示 由代表第一用户(这里称为被委托者)的使用者从服务提供者访问第二用户(这 里称为委托者)的被保护资源的授权请求。所述方法还包括由服务提供者向控 制器传送第二消息，该第二消息表示由代表被委托者的使用者从服务提供者访 问委托者的被保护资源的授权请求。该第二消息包含一个请求令牌。该请求令 牌是服务提供者用来登记对访问被保护资源的请求的授权的值。所述方法还包 括由控制器确定第二消息所表示的请求的授权是否满足管控对委托者的被保护 资源的访问的策略设置；并且，如果确定请求的授权满足策略设置，则由服务 提供者准许由请求令牌所登记的授权，并由控制器和服务提供者中的至少一个 向使用者传送包含该请求令牌的第三消息。

控制器是一个或多个物理实体，其中可包括一个或多个计算机程序或硬件 电路单元以用于运行控制器的功能。例如，控制器可与一个或多个服务器计算 机或者一个或多个用户终端集成在一起。控制器被配置成接收包含请求令牌的 消息，即第二消息。该第二消息表示由代表被委托者的使用者从服务提供者访 问委托者的被保护资源的授权请求。控制器还被配置成检查(即，确定)第二 消息是否满足管控对委托者的被保护资源的访问的策略设置。换而言之，控制 器检查第二消息所表示的请求的授权是否满足管控对委托者的被保护资源的访 问的策略设置。

如果控制器确定请求的授权满足所述策略设置，则服务提供者被给予全权 以准许与请求令牌相关联的授权。然后服务提供者准许由该请求令牌所登记的 授权。可选地，在准许授权之前，服务提供者可执行关于由该请求令牌所登记 的授权是否安全和/或合法的进一步的确定，如果是，则服务提供者准许由该请 求令牌所登记的授权。

在授权被准许之后(即服务提供者和控制器都授权)，包含授权的请求令牌 的第三消息由控制器或服务提供者或他们两个传送给使用者。然后使用者可代 表被委托者从服务提供者访问与委托者相关联的被保护资源。因此，集成了委 托者的被保护资源的服务能够由使用者提供以有益于被委托者，其中被委托者 能够获得任何的服务输出。该方法也有益于委托者，委托者能够方便地与被委 托者或代表被委托者工作的使用者共享他或她的被保护资源，而无需发布及由 此暴露他或她的证书。

换而言之，一方面，控制器作为委托者的委托辅助设备。它辅助委托者管 理对授权或阻止对他或她的被保护资源的访问的职权委托。另一方面，控制器 还作为被委托者的委托辅助设备。它辅助被委托者获得访问委托者的被保护资 源的授权。

管控对委托者的被保护资源的访问的策略设置(也称为策略规则或保密设 置)在实施之前由控制器建立。如果第二消息不满足策略设置，则控制器不对 服务提供者给予全权以允许对被保护资源的访问。当第二消息以及第二消息所 表示的请求的授权不满足策略设置时，控制器和服务提供者实施访问拒绝而无 需委托者在接收到第二消息时进行干预。在一些实施例中，如果控制器请求委 托者这样做，例如，当面对特殊的请求授权时，即仅基于控制器中现有的策略 设置不能拒绝或允许的请求授权，则委托者在接收到第二消息时进行干预。

换而言之，给予控制器机会以截听并评估每个请求的授权，并且，根据由 该消息所表示的请求的授权的类型和其请求令牌(即，以每个请求为基础)，控 制器决定接受还是拒绝该请求的授权。基于从消息中提取或收集的关于如果请 求令牌被授权会或者可能发生什么的信息，控制器作出确定，即决定。

这使委托者解脱了在接收到消息时需要与服务提供者进行交互。

因此，该方法通过减少用户的操作负担从而显著地改进和促进了计算机或 通信网络中的隐私管理。出于用户观点的隐私管理是存在于用户或有益于用户 的控制中的任务，其中的控制是指控制哪个被保护资源能够或不能被代表其它 用户(即被委托者)的指定使用者访问以及如何访问，其中被保护资源由服务 提供者存储、提供或者可从服务提供者访问，并且与用户(即委托者)相关联。 隐私管理还包括对用户的被保护资源的适当处理，与用户的偏好一致，例如关 于其执行与用户的被保护资源相关的操作。

除了减轻用户的操作负担，该方法还降低了人为错误的风险，所述人为错 误会包括用户(即委托者)无心地准许了对某些被保护资源的访问。

消息是一个或多个信息单元，能够在通信信道或网络上传送并且如果必要 的话能够携带请求令牌和相关参数，如果有的话。该消息也被称为请求或者可 表示一个请求。

用户是其身份能够被鉴权的一个人或一群人，或者是其身份能够被鉴权的 物理实体，例如用户终端或用户设备。换而言之，当这里使用术语“用户”时 (或者术语“被委托者”或“委托者”)，其可以是指实际的最终用户(即人或 一群人)以及可以附上身份的用户终端或用户设备中的任一个或者两者。此外， 如果用户终端能够使用多种身份(例如与不同的用户偏好相关联)来操作，则 用户终端可据此操作的每个身份可对应于本发明上下文中的一个用户。

因此，术语“用户”(或者术语“被委托者”或“委托者”)这里适当的情 况下也包含用户设备或用户终端(或者分别是被委托者的设备或被委托者的终 端，或者委托者的设备或委托者的终端)。例如，如果要求与用户交互，则用户 设备可被配置好以便执行该交互而无需人干预。这特别表明了为什么术语“用 户”通常指作为人或一群人的用户和由特定的人使用的用户设备中的任一个或 者两者。

被保护资源是与一个用户的身份或与一组用户相关联的一组身份有关的数 据，或者是与一个用户的身份或与一组用户相关联的一组身份有关的服务。被 保护资源的例子包括私人照片、在线地址簿中的联系人、在线日程中的条目、 在线社交网络中的好友列表、书签列表、存储于在线社交网络账户中的喜爱的 歌曲列表、最近从在线商店中购买的货物列表、在服务器或博客上保存或发布 数据的可能性等等。被保护资源可包括被保护的社会信息。

如上所述，对被保护资源的访问或使用可存在于服务的使用中。在该上下 文中，服务的提供是一个技术和经济活动，其例如可导致出售的实体货物的所 有权、计算机配置的技术特性的修改等。该服务可以是web服务。

本发明可用于基于web的社交网络服务，但是不局限于此。同样地，本发 明可采用从OAuth协议导出或扩展OAuth协议的协议，但是不局限于此。本发 明可应用于其它上下文中并采用其它协议。

在一个实施例中，本发明还包括，在使用者或服务提供者传送第一消息的 步骤之前，由被委托者控制的软件应用和物理装置中的至少一个传送涉及代表 被委托者的使用者从服务提供者访问委托者的被保护资源的服务请求给使用 者。

在一个实施例中，该方法是这样的，由使用者向服务提供者传送第一消息 的步骤包括使用者通过由被委托者控制的软件应用和物理装置中的至少一个向 服务提供者传送第一消息。

在一个实施例中，该方法还包括，在控制器确定第二消息所表示的请求的 授权是否满足管控对委托者的被保护资源的访问的策略设置的步骤和由服务提 供者准许由请求令牌所登记的授权的步骤之间，以及如果确定请求的授权满足 策略设置，则从控制器向服务提供者传送指示由第二消息所表示的请求授权能 够被接受的消息。该消息给予服务提供者全权以便准予(即授权)该请求的授 权。

在一个实施例中，该方法还包括，在由服务提供者准许请求令牌所登记的 授权的步骤和由控制器和服务提供者中的至少一个传送包含该请求令牌的第三 消息给使用者的步骤之间，从服务提供者向控制器传送包含该请求令牌的消息， 针对该请求令牌授权被准许。

在一个实施例中，该方法是这样的，向使用者传送包含该请求令牌的第三 消息从控制器执行。

在一个实施例中，该方法是这样的，控制器包括代表被委托者运行的委托 辅助设备，以及代表委托者运行的委托辅助设备，其中委托辅助设备是软件应 用和物理装置中的至少一个。

在一个实施例中，该方法是这样的，由控制器确定第二消息所表示的请求 的授权是否满足管控对委托者的被保护资源的访问的策略设置包括从第二消息 中提取以下信息中的至少一个：(i)有关该请求的授权所始发自的使用者的信 息；(ii)有关被委托者的信息，其中使用者代表该被委托者请求访问委托者的 被保护资源的授权；(iii)有关被保护资源的信息，其中通过请求令牌请求对被 保护资源上的一个或多个操作予以授权；(iv)有关一个或多个操作的信息，其 中通过请求令牌请求对一个或多个操作予以授权；确定提取的信息是否满足策 略设置。从该消息中提取信息可包括解析该消息。

该实施例实现了控制器(作为委托者)在隐私管理方面对在第二消息中包 含的请求令牌的重要性的有效控制，达到可从包含请求令牌的第二消息中推断 出来的程度。如果从消息中提取的信息不满足为委托者或由委托者事先设置的 策略设置，则不对服务提供者给予准许请求的授权的全权。

控制器对第二消息的检查可涉及请求令牌所始发自的使用者的特征或身 份，其中一些使用者或者一类或一组使用者可能被认为是不可靠的。控制器对 第二消息的检查还可涉及被委托者的特征或身份，代表该被委托者，已创建由 第二消息所表示的请求的授权，其中一些被委托者或者一类或一组被委托者可 能被认为是不可靠的。

假如有关被保护资源的信息能够从第二消息中获得或提取(因为该消息中 包含标识此类被保护资源的参数或者因为从该消息的一个或多个特征中可能导 出与请求的授权相关的被保护的类型或被保护资源的标识)，其中通过该第二消 息请求对被保护资源上的一个或多个操作予以授权，控制器对第二消息的检查 可包括提取这种有关被保护资源的信息。例如，如果第二消息对应于与特定被 保护资源或被保护资源类型相关的请求的授权，例如敏感信息(如，银行明细)， 则服务提供者可被阻止准许请求令牌所登记的授权。

在一个实施例中，有关被保护资源的信息可从第二消息中获得或提取，其 中通过该请求令牌来请求对被保护资源上的一个或多个操作予以授权。

假如有关一个或多个操作的信息可从第二消息中获得或提取，其中通过请 求令牌请求对一个或多个操作予以授权，检查第二消息的步骤可包括确定被请 求授权的操作的此类特性是否满足策略设置。

在一个实施例中，有关操作的信息可从第二消息中获得或提取，其中通过 请求令牌来请求对操作予以授权。

本发明还涉及一种包括接收机、确定器和传送机的委托辅助设备。该接收 机被配置用于从另一个委托辅助设备接收消息，这里称为请求消息，其表示了 代表这里称为被委托者的第一用户的使用者从服务提供者访问这里称为委托者 的第二用户的被保护资源的授权请求。该请求消息包含一个请求令牌。在该上 下文中，服务提供者是被配置成提供对被保护资源的访问的软件应用和web站 点中的至少一个。使用者是被配置成代表用户访问服务提供者的软件应用和web 站点中的至少一个。请求令牌是服务提供者用来登记访问被保护资源的请求授 权的值。确定器被配置用于确定该请求消息所表示的请求授权是否满足管控对 委托者的被保护资源的访问的策略设置。传送机被配置用于，如果请求的授权 满足策略设置，则向服务提供者传送指示该请求消息所表示的请求的授权能够 被准许的响应消息。换而言之，传送机被配置用于，如果确定请求的授权满足 策略设置，则给予服务提供者全权以准许该请求的授权。

在一个实施例中，所述委托辅助设备是这样的，确定器包括提取器和子确 定器。所述提取器被配置用于从所述请求消息中提取至少一个下述信息(i)与 该请求的授权所始发自的使用者有关的信息；(ii)有关被委托者的信息，其中 使用者代表该被委托者请求访问委托者的被保护资源的授权；(iii)有关被保护 资源的信息，其中通过请求令牌请求对被保护资源上的一个或多个操作予以授 权；(iv)有关一个或多个操作的信息，其中通过请求令牌请求对一个或多个操 作予以授权。所述子确定器被配置用于确定提取的信息是否满足策略设置。

本发明还涉及一种包含指令的计算机程序，指令被配置成当在计算机或上 述控制器上运行时，使得服务器或计算机作为以上所定义的委托辅助设备来操 作。本发明还涉及包含这种计算机程序的计算机程序产品或计算机可读介质。

附图说明

下面将结合附图描述本发明的实施例，其中：

图1是本发明一个实施例中的方法的示意消息图；

图2是本发明一个实施例中的方法的示意消息图，其中，在控制器确定授 权请求可被接受之后，从控制器向服务提供者传送消息以允许服务提供者准许 该授权并且其中传送包含授权的请求令牌的第三消息的步骤从控制器执行；

图3是本发明一个实施例中的方法的示意消息图，其中，在使用者传送第 一消息给服务提供者之前，使用者从被委托者接收使用该使用者的请求；

图4是本发明一个实施例中的方法的示意消息图，其中，从使用者发送给 服务提供者的第一消息通过被授权委托者传送；

图5是本发明一个实施例中的方法的示意消息图，由服务提供者发送给控 制器的第二消息通过使用者传送；

图6是本发明另一个实施例中的方法的示意消息图；

图7是本发明一个实施例中的方法的示意消息图，其中，控制器包括被委 托者的委托辅助设备和委托者的委托辅助设备；

图8-12是本发明另一些实施例的示意消息图；

图13是图12中示出的方法的一部分的示意消息图；

图14是本发明一个实施例中的方法的流程图；

图15是示意性地示出了本发明一个实施例中的委托者的委托辅助设备；

图16和17是为解释了本发明相对于现有技术所解决的问题和提供的优点 而示出的方法消息图。

具体实施方式

下面将结合具体实施例描述本发明。这些具体实施例用于为技术人员提供 更好的理解，而并不旨在以任何方式限制附带的权利要求所定义的本发明的范 围。

图1是本发明一个实施例中的方法的示意消息图。图1所示的方法由使用 者100、服务提供者200和控制器300来执行。

使用者100试图代表被委托者410(图1中未示出)访问可从服务提供者 200访问的委托者420(图1中未示出)的被保护资源。为此，使用者100向服 务提供者传送s10第一消息。该第一消息表示或包括了表示访问委托者420的 被保护资源的授权请求的计算机可读信息。服务提供者200接收从使用者100 始发的第一消息。在使用者100和服务提供者200之间，可存在中间物理实体， 第一消息可通过该中间物理实体来传送(图1中未示出，但可以参见图4的例 子)。

第一消息表示或包括计算机可读信息，该计算机可读信息表示了使用者 100代表被委托者410从服务提供者200访问委托者420的被保护资源的授权请 求。服务提供者200从第一消息检测授权请求须首先通过为委托者420工作的 控制器300的批准。然后，服务提供者200为接收到的授权请求分配请求令牌。 在该上下文中，请求令牌是标识对被保护资源的访问请求的一个值。

服务提供者200创建包含现阶段未授权的请求令牌的第二消息，并将该第 二消息传送s20到控制器300。控制器300是负责检查对于所有委托者的授权请 求的控制器或者可以是与特定委托者420或特定的一组委托者420相关联的控 制器。在后一情况中，服务提供者200能够从第一消息中获取足够的信息来定 位控制器300，该控制器300负责评估第一消息涉及的对委托者420的被保护资 源的访问的请求授权。

除了请求令牌之外，第二消息可包括伴随请求令牌的多种附加信息或参数， 如，请求令牌所登记的请求授权始发自的使用者100的标识、代表其创建请求 的授权的被委托者410、来自使用者100的请求授权的主题的被保护资源和/或 与被保护资源相关的使用者100请求被授权的操作。

第二消息可以是一个分组、HTTP请求或任何其它适当格式化的信号以携 带请求令牌。

然后，控制器300确定s30接收的第二消息是否符合管控对委托者420的 被保护资源的访问的策略设置。

策略设置存储在控制器300中或者可由控制器300访问，并且涉及与委托 者420相关的被保护资源，其中控制器300为该委托者420工作。策略设置可 由委托者420预先设置。备选地或另外的，当启动为委托者420工作的控制器 300时可默认设置隐私设置。隐私设置的更新可由委托者420、被授权配置控制 器300的第三方或他们两者来执行。

例如，委托者420(即作为委托者420的用户，或者换句话说，具有委托 者420的角色的用户)可预先设置策略设置，其中，控制器300使用策略设置 来指示第一特定使用者100，如“doesntcareaboutprivacy.com”及 “sellsyourprivatedatato3rdparties.com”，没有被授权访问委托者的任何被保护资 源，而不管怎样的资源及对资源执行的操作。委托者420还可以指示来自另一 个特定使用者100(如“careaboutprivacy.com”)的消息中的请求授权应当仅在 被保护资源例如是银行明细或社会保障号码的情况下被拒绝，而不管怎样的对 资源执行的操作，或者在被请求授权的操作在于一些被保护资源的删除操作的 情况下被拒绝。

委托者420还可以预先设置策略设置，其中，控制器300使用策略设置来 指示在代表第一特定被委托者410工作时的使用者100没有被授权访问委托者 的任何被保护资源，而不管怎样的资源及请求对资源执行的操作。例如，委托 者420还可指示当代表其它特定被委托者410工作时的使用者100应当仅在如 果被保护资源不是银行明细或社会保障号码的情况下被授权访问委托者的被保 护资源或者仅在如果请求被授权的操作不在于一些被保护资源的删除操作的情 况下，才被授权。

控制器300对授权请求的拒绝操作可包括删除第二消息、将第二消息的细 节记录在控制器300中以用于后续评定，以及通知使用者100和/或服务提供者 200请求未授权。发送给使用者100和/或服务提供者200的信息可包括请求被 拒绝的详细原因。

如果控制器300确定s30第二消息所表示的请求授权满足管控对委托者420 的被保护资源的访问的策略设置，则控制器300给予服务提供者200全权以授 权请求的授权和相关联的请求令牌。然后服务提供者200准许s40请求令牌所 登记的授权。然后，向使用者100传送s50包括授权的请求令牌的第三消息， 该授权的请求令牌向使用者100指示授权请求已被控制器300和服务提供者200 两者批准。

接收到授权的请求令牌时，使用者100使用该请求令牌来代表被委托者410 从服务提供者200访问委托者420的被保护资源(图1未示出)。

在图1中，步骤s40相关联的虚线指示请求的授权的批准和准许操作由服 务提供者200和控制器300一起执行。仅当控制器300允许服务提供者200这 样做时服务提供者200才准许请求的授权。此外，即使控制器300批准请求的 授权，如果请求的授权被认为是不安全的或非法的，服务提供者200可仍决定 不批准该请求的授权。如果服务提供者200决定拒绝该请求的授权，服务提供 者200还可以在接收之前阻塞第一消息，这样没有第二消息被发送到控制器 300，减少了交换消息的数量。

图1中与步骤s50相关联的虚线说明了这样一个事实：向使用者100传送 包含授权的请求令牌的第三消息的步骤可由服务提供者200或控制器300来执 行。

该方法为终端用户提供了用户友好及有效的解决方法以管理他们分散在多 个网络实体中的被保护资源的隐私方面。同时，该方法最小化实现影响。为了 对他们想要许可的对他们的被保护资源的使用设置限制，作为委托者420的用 户不需要经历存储有关其的被保护资源的每个单个服务提供者200。在控制器 300中设置策略设置对于解决来自许多服务提供者200的授权请求来说是足够 的。另外，作为委托者420的用户很少被打扰及询问准许还是拒绝使用者100 代表被委托者410访问被保护资源的授权请求。

在一个实施例中，由服务提供者200传送s20的第二消息包括多于一个的 请求令牌并且表示一个或多个使用者100的多于一个的请求授权。控制器300 检查第二消息以与策略设置进行比较，并且控制器300可仅接受满足策略设置 的请求授权。控制器300可相应地通知服务提供者200。

图2是本发明一个实施例中的方法的示意消息图，与图1中示出的实施例 的区别在于，在图2中，控制器300在确定s30是否接受请求的授权之后，如 果确定步骤s30的结果是肯定的，则通过向服务提供者200发送s32消息来请求 s32服务提供者200准许该授权并且对相关联的请求令牌进行授权。步骤s32中 发送的消息指示控制器300批准请求的授权。

之后，服务提供者200准许s40该授权并且向控制器300传送s45授权的 请求令牌。然后控制器300向使用者100传送包含该授权的请求令牌的第三消 息，使用者100随后可使用该授权的请求令牌来从服务提供者200访问委托者 420的被保护资源。

虽然没有在图2中示出，但在确定步骤s30结果为拒绝请求的授权的情况 下，控制器300可通知服务提供者200基于为或由委托者420设置的策略设置， 与请求令牌相关联的请求授权在控制器300侧已被拒绝。

图3是本发明一个实施例中的方法的示意消息图，与图2中示出的实施例 的区别在于，在图3中，在由使用者100向服务提供者300发送s10第一消息 中的授权请求之前，被委托者410请求s5使用由使用者100提供的服务，其中 该服务利用了从服务提供者200可访问的委托者420的被保护资源。换句话说， 被委托者410调用s5使用者服务或应用100，该服务或应用要求访问在服务提 供者200中托管的委托者的被保护资源。步骤s5可包括，但不限制于，从web 浏览器调用URL。

因此，图3示出了一种被委托者发起的方法。在其它实施例中，不是直接 基于从被委托者410接收的请求，而是出于使用者100自己的主动，使用者100 可向服务提供者200发送授权请求。例如，被委托者410可在使用者100中设 置特定的委托者420被认为是朋友。基于该信息，使用者100可向服务提供者 200发送s10授权请求以获得委托者420的生日。如果该授权请求被服务提供者 200和控制器300允许，则使用者100可在委托者420生日之前的几天或几星期 向被委托者410发送提醒消息。

还是在同一个例子中，使用者100还可基于其自己的主动向另一个服务提 供者200，如在线书店(或者作为多个在线书店的多个服务提供者200)，发送 s10授权请求，以便找到哪些书是委托者420最近购买的或者哪些类型的书是委 托者420通常感兴趣的。如果该授权请求被服务提供者200和作为委托者420 的控制器300所允许，则使用者100可以在委托者420生日之前几天或几星期 为被委托者410提供有关建议的给委托者420的生日礼物的信息。

图4是本发明一个实施例中的方法的示意消息图，与图3中示出的实施例 的区别在于，在图4中，一旦使用者100接收到s5被委托者410使用使用者100 的服务的请求，使用者100就通过被委托者410向服务提供者200发送s10第 一消息(即从服务提供者200使用委托者420的资源的授权请求)。

在一个实施例中，由使用者100通过被委托者410向服务提供者200发送 s10第一消息可包括，将被委托者410的web浏览器重定向到服务提供者200 的网页，例如根据OAuth协议(参见参考文献[2]，“6.Authenticating with  OAuth”)。由使用者100发起的重定向机制也可包括给被委托者410一个机会以 阻止使用者100向服务提供者200发送授权请求。这允许了被委托者410控制 使用者100和服务提供者200之间通信的发生。

例如，被委托者410可能希望避免或限制使用者100代表被委托者410与 一些服务提供者200之间的通信。

图5是本发明一个实施例中的方法的示意消息图，与图3中示出的实施例 的区别在于，在图5中，从服务提供者200发送到控制300的第二消息通过使 用者100来发送。因此，使用者100接收服务提供者200为其授权请求分配的 未授权的请求令牌。

图6是本发明一个实施例中的方法的示意消息图，组合了图4和图5中示 出的实施例。也就是，由使用者100发送s10给服务提供者200的第一消息通 过被委托者410来发送s10。此外，由服务提供者200发送s20到控制器300的 第二消息通过使用者100来发送s20。该实施例组合了图4和图5中实施例的优 点。

图7是本发明一个实施例中的方法的示意消息图，与图3中示出的实施例 的区别如下。控制器300包括被委托者410的委托辅助设备310和委托者420 的委托辅助设备320。被委托者的委托辅助设备310和委托者的委托辅助设备 320一起形成控制器300或形成控制器300的一部分(因为控制器300可能包括 为其它用户工作的委托辅助设备)。被委托者的委托辅助设备310为被委托者 410工作以便支持对被委托者410的委托的管理。被委托者的委托辅助设备310 可以与被委托者410的web浏览器并行运行。

委托者的委托辅助设备320为委托者420工作，并且可与委托者的浏览器 并行运行。在一个实施例中，被委托者的委托辅助设备310和委托者的委托辅 助设备320中的至少一个托管在一个服务器上。在该实施例中，在该服务器上 托管的委托辅助设备的操作不依赖于该委托辅助设备为其工作的用户是否启动 他或她的浏览器。

服务提供者200向被委托者的委托辅助设备310发送s20授权请求和第二 消息。然后，被委托者的委托辅助设备310将该授权请求转发s25给委托者的 委托辅助设备320。可进行鉴权s28。之后，委托者的委托辅助设备320确定s30 是否接受该授权请求。

如果委托者的委托辅助设备320接受该授权请求，关于授权请求已被接受 的信息被传送s32a到被委托者的委托辅助设备310，被委托者的委托辅助设备 310将该信息转发s32b给服务提供者200。然后，服务提供者200准许s40该授 权并且具有授权的请求令牌的第三信息被传送s50到使用者100。因此，使用者 100可使用服务提供者200所托管的委托者420的被保护资源。

被委托者的委托辅助设备310辅助被委托者410获得授权委托以允许被委 托者410和代表其工作的任何使用者100访问从服务提供者200可访问的委托 者420的被保护资源。被委托者的委托辅助设备310的功能包括检查从服务提 供者接收到的授权请求是否满足为被委托者410设置的与代表被委托者410发 送的授权请求相关的策略设置。

委托者的委托辅助设备320辅助委托者420准许或拒绝与被委托者410或 为被委托者工作的任何使用者访问从服务提供者200可访问的委托者420的被 保护资源相关的授权请求。

换句话说，被委托者的委托辅助设备310被给予一次截听包含未授权的请 求令牌的第二消息的机会。被委托者的委托辅助设备310准备其发送s25给委 托者的委托辅助设备320的授权委托请求。该请求包含未授权的请求令牌以及 与托管与该请求相关的被保护资源的服务提供者200有关的信息。该请求还可 包含与请求的授权相关的被保护资源、请求访问被保护资源的使用者100以及 使用者100代表其工作的被委托者410有关的信息。

当接收到来自被委托者的委托辅助设备310的消息时，委托者的委托辅助 设备320可决定对被委托者410进行鉴权。被委托者的标识可以在从委托者的 委托辅助设备310接收的消息中接收到或者通过其它方式建立。

图8是本发明一个实施例中的方法的示意消息图，与图7中示出的实施例 的区别如下。在确定s30是否接受授权请求之后以及在决定接受它之后，委托 者的委托辅助设备320将该授权直接发送s32到服务提供者200。实际上，在该 阶段被委托者的委托辅助设备310的干涉不再是必要的。然而要求委托者的委 托辅助设备320有服务提供者200的地址。

图9是本发明一个实施例中的方法的示意消息图，与图8中示出的实施例 的区别如下。在准许s40该授权以及对请求令牌授权之后，服务提供者200将 授权的令牌发送s45给委托者的委托辅助设备320。然后委托者的委托辅助设备 320向使用者100传送s50包含该授权的令牌的第三消息。

该实施例给了委托者的委托辅助设备320机会来进一步限制与授权的请求 令牌相关联的准许的授权，例如加强对其使用的限制，如有效时间帧等。

图10是本发明一个实施例中的方法的示意消息图，与图8中示出的实施例 的区别如下。在准许s40该授权之后，服务提供者200向被委托者的委托辅助 设备310发送s45授权的请求令牌。因此被委托者的委托辅助设备310可记录 该信息以用于统计的目的或诸如此类，然后向使用者100传送s50包含该授权 的请求令牌的第三消息。然后使用者100可以用该授权的令牌从服务提供者200 访问委托者420的被保护资源。

图11是本发明一个实施例中的方法的示意消息图，与图8中示出的实施例 的区别如下。在准许s40该授权以及发布授权的令牌之后，服务提供者200向 委托者的委托辅助设备320发送s45授权的请求令牌。然后委托者的委托辅助 设备320向被委托者的委托辅助设备310发送s50a包含该授权的请求的第三消 息，被委托者的委托辅助设备310将其转发s50b给使用者100。该实施例组合 了图9和图10中示出的实施例的优点。

图12是本发明一个实施例中的方法的示意消息图。现在将结合图12和13 描述允许基于被委托者的发起从委托者420对被委托者410进行授权委托的该 实施例。

被委托者410调用s5使用者服务或应用100，该服务或应用要求访问在服 务提供者200中托管或者可从其中访问的委托者420的被保护资源，其中服务 提供者200也称为“容器”(图12中标记：“s5：使用使用者”)。该步骤s5可包 括从web浏览器调用URL，但不限于此。

使用者100以第一消息响应s10该调用(“s10：取得(资源，使用者)”)。 这种消息包括或表示对在服务提供者200中托管或者可从其中访问的委托者的 被保护资源的请求。第一消息通过被委托者410来发送s10，例如通过被委托者 的web浏览器重定向第一消息。

服务提供者200接收该第一消息并评估该对被保护资源的请求。如果在该 阶段服务提供者200还没有授权该请求，则服务提供者200以包含具有未授权 请求令牌的授权请求的第二消息响应s20(“s20：未授权请求令牌”)。该未授权 请求令牌可以涉及或者可以不涉及特定的被保护资源、被委托者410或使用者 100。这取决于服务提供者实现。

被委托者的委托辅助设备310(“DA(被委托者一侧)”，其中DA代表委 托辅助设备)截听包含未授权请求令牌的第二消息。被委托者的委托辅助设备 310准备其发送s25给委托者的委托辅助设备320的授权委托请求(“s25：授权 (令牌，容器，被委托者，资源，使用者)”)。该请求包含未授权的请求令牌以 及与托管该请求的被保护资源的服务提供者200有关的信息。该请求还可包含 与请求授权的被保护资源、请求访问被保护资源的使用者100以及调用使用者 100的被委托者410有关的信息。

当接收到该消息时，委托者的委托辅助设备320可决定对被委托者410进 行鉴权(“s28：鉴权过程”)。被委托者的标识可以在来自被委托者的委托辅助 设备310的消息中接收到或者能够通过其它方式建立。

完成前面的过程之后，委托者的委托辅助设备320开始决定过程(“s30： 决定过程”)。决定过程的目标是决定拒绝该授权委托还是准许它。

作为决定过程s30的一部分，委托者的委托辅助设备320向服务提供者200 发送s32授权请求，其中服务提供设备300托管未授权请求令牌涉及的被保护 资源或者提供对其的访问，如图13所示(“s32：授权请求(令牌)”)。服务提 供者200执行的特定授权过程s40依赖于服务提供者的实现(“s40：授权过程”)。

作为成功的授权过程的结果，服务提供者200向委托者的委托辅助设备320 发送s45授权的请求令牌(“s45：授权的请求令牌”)。该请求令牌将允许被委托 者410或者代表该被委托者410工作的使用者获得对在服务提供者200中托管 的被保护资源的访问。该请求令牌还可包括对其使用的限制，如有效时间帧， 使用的使用者应用或其它。

另外，服务提供者200可向委托者的委托辅助设备320提供有关请求访问 被保护资源的使用者100的信息或者有关被保护资源本身的信息(“s46：附加 信息”)。

有利地，在决定过程s30中的任何时间，委托者的委托辅助设备320可决 定向委托者420请求更多的信息以便合并于该决定过程(“s31：交互服务”)。 该交互过程可以采用在委托者的委托辅助设备320和委托者420之间交换消息 的方式。

此外，决定过程s30也可考虑委托者420之前声明的更多信息，如管控授 权委托的策略或诸如此类。委托者的委托辅助设备320可使用任何计算机实现 的过程来获取、存储及实施委托者的偏好，例如包括查询存储委托者的策略的 数据库，解析表示该请求的消息，对消息值和存储的策略进行比较等。

完成决定过程之后，委托者的委托辅助设备320准许或拒绝该授权委托。

如果决定过程s30的结果是拒绝，则委托者的委托辅助设备320以一个未 授权消息响应来自被委托者的委托辅助设备310的消息(“s53，s55：未授权请 求令牌”)。被委托者的委托辅助设备310可将该消息重定向到使用者100。

如果决定过程s30的结果是准许，则委托者的委托辅助设备320通过向被 委托者的委托辅助设备310发送包含在步骤s45中从服务提供者200接收的授 权请求令牌的消息对来自被委托者的委托辅助设备310的消息进行响应(“s52， s54：授权请求令牌”)。被委托者的委托辅助设备310将该授权请求令牌发送回 使用者100。使用者100使用该授权请求令牌获得代表被委托者410对被保护资 源的访问(“s60：取得(资源，授权令牌)”)。

图12和13所示出的实施例的明显优点在于消息交换被简化，因为委托者 的委托辅助设备320由于之前从被委托者的委托辅助设备310接收了消息(在 步骤25中)从而得知了其地址。此外，由于授权的请求令牌是通过被委托者的 委托辅助设备310从委托者的委托辅助设备320发送到使用者100，所以被委托 者的委托辅助设备310能够跟踪其开始的授权请求以及该过程的结果。

在一个实施例中，被委托者的委托辅助设备310与被委托者的浏览器并行 运行。如果委托者420是在线的，同样应用于委托者的委托辅助设备320。在一 个子实施例中，被委托者的委托辅助设备310以浏览器插件的形式与被委托者 的浏览器并行运行。在一个子实施例中，委托者的委托辅助设备320以浏览器 插件的形式与委托者的浏览器并行运行。在另一个实施例中，第三方(如移动 运营商)作为委托者辅助设备的角色并且使用一个代理来捕获寻址到其订户的 授权消息。

图14是本发明一个实施例中的方法中的确定步骤s30的流程图。在该实施 例中，由控制器300确定第二消息所表示的请求的授权是否满足策略设置的步 骤s30包括一个提取步骤s301和一个确定步骤s302。

提取步骤s301包括从第二消息中提取至少一个以下信息：有关请求的授权 所始发自的使用者100的信息；有关被委托者410的信息，其中使用者100代 表该被委托者请求访问委托者420的被保护资源；有关被保护资源的信息，其 中通过请求令牌请求对被保护资源上的一个或多个操作予以授权；以及有关一 个或多个操作的信息，其中通过请求令牌请求对一个或多个操作予以授权。确 定步骤s302包括确定提取的信息是否满足策略设置。

从消息中提取信息的子步骤s301可包括解析该消息。

图15示意性地示出了本发明一个实施例中的委托辅助设备320以及其的一 些组成单元。委托辅助设备320包括配置用于接收来自另一个委托辅助设备的 请求的接收机25(该请求对应于上述的第二消息)。委托辅助设备320还包括配 置用于确定请求的授权是否满足管控对被保护资源的访问的策略设置的确定器 30。策略设置可存储在委托辅助设备320中或者也可存储在委托辅助设备320 可访问的数据库或存储器单元中。如果委托辅助设备320确定该请求的授权不 符合策略设置，则通知服务提供者200请求的授权不能被准许。确定器30还可 包括提取器301，配置用于从该请求消息中提取至少一个以下信息：(i)有关请 求的授权所始发自的使用者100的信息；(ii)有关被委托者410的信息，其中 使用者100代表该被委托者请求访问委托者420的被保护资源；(iii)有关被保 护资源的信息，其中通过请求令牌请求对被保护资源上的一个或多个操作予以 授权；以及(iv)有关一个或多个操作的信息，其中通过请求令牌请求对一个或 多个操作予以授权。该确定器30还可包括配置用于确定提取的信息是否满足策 略设置的子确定器302。此外，委托辅助设备320还可包括用于向服务提供者传 送响应消息的传送机32。

下面将描述本发明的一个实施例中在控制器100中由用户或用户终端对隐 私设置(也称为“策略设置”)的管理。

用户(作为委托者)希望设置隐私偏好以管控对他或她的被保护资源的使 用和发布。控制器300可向用户显示不同的选项并且允许他或她配置不同的参 数，如被保护资源能够被访问的条件，即使用或发布。当完成时，控制器300 存储最终的策略设置。然后，无论何时使用者100代表另一个用户(潜在的被 委托者)要求授权对被保护资源的访问，控制器100实施该用户的偏好，即策 略设置。

用户从能够设置与对他们被保护资源的访问有关的他们的偏好中获益。为 此，用户在控制器300中设置隐私偏好，然后控制器300实施这些隐私偏好。

参与策略设置的定义的变量可包括：请求者、被委托者、资源、操作和许 可。如果用户(委托者)不是控制器300的唯一用户，则可能需要在策略设置 中明确声明该用户(委托者)。

请求者可以是试图获得对用户的被保护资源的访问的任何使用者100。

被委托者可以是使用者100代表其试图获得对用户的被保护资源的访问的 任何被委托者410。

资源可以是策略设置规则所涉及的被保护资源的标识符。

操作值可以是任何使用者100能够请求的操作，例如，它们可以是“查询”、 “创建”和“删除”。然而，本发明的实施例不限制于任何数量或类型的可以是 策略设置规则的主题的操作。

许可可以设置为“准许”、“拒绝”或者“问我”(当该用户，即委托者，偏 好基于每个调用的基础来决定；这能够通过ad-hoc交互服务来实施，如浏览器 中的弹出，基于SMS的授权等)。

可以为用户提供机会来通过不同的方式表达他们的隐私偏好。首先，用户 可以从多个预先定义的隐私策略中选择一个并将其与一个被保护资源相关联。 这些预先定义的隐私策略可以用自然语言来描述，这样不是技术人员的用户能 够理解它们。该自然语言描述被映射到以隐私策略表达语言描述的具体策略实 现。这些策略是分等级的，这样用户可以容易地比较它们并选择出更适合他们 需要的策略。该方案从模型的简单性和实用性中获益，因为用户不需要处理策 略细节。

用户也可以被允许定义隐私策略的每个细节。虽然该方案在用户偏好的描 述上提供了很大的灵活性，但可能在实用性上导致一些风险。仅高级用户可以 理解(且可能希望知道)策略的意思。这可以作为高级选项来提供。

在一个实施例中，该方法还包括从至少一个服务提供者200获得有关被保 护资源的信息的步骤，其中被保护资源与至少一个服务提供者200中的用户身 份相关联。这使得用户能够获得对从服务提供者200可访问的被保护资源的认 识。这改进了隐私管理如何能够被执行。

在该实施例的子实施例中，控制器300(作为用户的委托辅助设备)能够 获得的有关与至少一个服务提供者200中的用户身份相关联的被保护资源的信 息包括有关与至少一个服务提供者200中的用户身份相关联的被保护资源的使 用的信息。

因此，在该情况下，控制器300不仅仅作为用户的委托辅助设备，还具有 附加的记载能力。该实施例使用户能够通过控制器300(作为用户的委托辅助设 备)获得对其身份所关联的被保护资源的动态认识。因此，控制器300可在这 个方面作为用户的中央控制点。

在用户能够如何以及何时获得信息的意义上，即当在至少一个时间段中， 被保护资源被哪些使用者以及代表哪些用户(即，哪些被委托者)所使用，可 获得的认识可以是动态的。用户(即委托者)因此能够收集有关对他们的被保 护资源的使用的信息。然后，用户可基于该知识决定是否修改控制器中的策略 设置。使用历史的获取可在从用户接收到表达请求时由控制器执行。备选地， 基于与用户的初始交互或基于默认设置，控制器可配置成获取与用户身份相关 联的被保护资源的使用历史。

身份，更具体的用户的身份，是用户特征中的一个，其标识用户或者以一 些方式映射到该用户来对其进行标识。

使用信息可特别的包括有关以下一个或多个项的信息：被保护资源的类型， 对被保护资源的访问的时间戳，访问、已经访问、使用或已经使用身份资源的 使用者的标识符，以及被委托者的标识符，其中使用者代表该被委托者访问、 已经访问、使用或已经使用被保护资源。

在一个实施例中，该方法还包括记录信息，这里称为历史信息，其有关接 收到的第二消息以及第二消息所表示的请求授权是否被确定为满足策略设置。 然后，该方法包括使该历史信息对用户或其用户终端可用的步骤。

在一个实施例中，该方法另外由能够与控制器300通信的用户终端来执行， 并且该方法还包括由用户终端在控制器300中设置策略设置。

为了进一步说明和理解本发明所解决的一些技术问题，图16和17解释了 用于提供对用户数据的访问的两个方法，即分别是AuthSub API(参见Google 网站，“Accounts API AuthSub for Web Application”，2010年2月17日从 http://code.google.com/apis/accounts/docs/AuthSub.html获取)以及ClientLogin(参 见Google网站，“Accounts API，ClientLogin for Installed Applications”，2010年2 月17日从http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html获 取)。

考虑AuthSubAPI，让我们使用一个用户实例来参考图16说明其是如何工 作的。让我们考虑一个Web 2.0应用来购买电影票。同时，该web应用也访问 用户的Google日程数据以个人化其提供(offer)。该用户实例可如下：

(i)简(Jane)(图16右侧示出的，“用户”)访问该电影票web应用(图 16左侧示出的，“Web应用”)，询问这星期适合她当前日程的可看电影。

(ii)该web应用将简重定向到Google账户(Google Accounts)，以使得 Jane被鉴权(使用她的Google证书)以及确认该web应用可访问她的Google 日程信息(图16中的步骤1、2)。

(iii)简鉴权并同意(图16中的步骤3)。

(iv)简被重新定向回到web应用，web应用接收能够用于之后查询简的 Google日程的令牌(图16中的步骤4)。

(vi)web应用从简的Google日程中获得信息(图16中的步骤5、6)。

(vii)然后web应用呈现可看的电影列表，但仅仅是那些适合这星期简的 日程的电影(个性化)(图16中没有示出)。

因此，如图16所示，可以是基于HTTP重定向的协议被用来将用户重定向 到Google账户(Google Accounts)，证书不共享给web应用，并且当用户鉴权 (及隐含的授权)时，令牌被获取。然而，不支持委托者将授权委托给被委托 者的情形。

当涉及到ClientLogin时，可使用有细微差别的例子：可将存储在用户Google 日程(个人的)中的信息与他或她的公司日程的信息一起显示的企业电子邮件 客户端。该用户实例会工作如下，如图17所示：

(i)约翰(John)打开他的膝上型计算机中的企业电子邮件客户端，请求 该电子邮件客户端显示约翰的日程(结合了来自约翰的Google日程的个人信息 以及来自约翰的公司日程的职业信息)。

(ii)该电子邮件客户端请求约翰提供他的Google证书。约翰供应他的证 书(图17中的步骤1)。

(iii)该电子邮件客户端使用这种信息联系Google账户(图17中的步骤2)。

(iv)Google账户对约翰进行鉴权，提供能够由该电子邮件客户端用来之 后访问Google中约翰的日程的令牌(图17中的步骤7)。可选地，Google账户 可用CAPTCHA来应答(图17中的步骤3到6)。

(v)该电子邮件客户端使用该令牌访问约翰的Google日程，获取约翰的 日程信息(图17中的步骤8)。

(vi)该电子邮件客户端显示约翰的组合日程信息。

因此，如图17所示，该应用处理用户的证书并且为他们供应Google账户 服务。这允许使用者模拟该用户，因此，这应当被避免。

本发明提出并试图部分或全部地避免这些问题。因此，本发明的一些优点 如下：

委托者的证书没有发布给使用者100使用。被保护资源的所有者，即委托 者420，不要求公开用于访问服务提供者200的委托者420的证书。

此外，不需要信任的使用者100和服务提供者200之间的联合关系。使用 者100和服务提供者200可运行在不同的计算机上并且处于不同的管理域。不 要求服务提供者200预先与使用者100和/或被委托者410建立信任关系。本发 明的方法不要求被委托者410和使用者100之间、使用者100和服务提供者200 之间或者被委托者410和服务提供者200之间的信任关系，仅要求委托者420 和服务提供者200之间的信任关系，如上所解释的。也就是，委托者420必须 信任服务提供者200不会准许委托者420没有批准的授权。

更进一步的，授权可基于每个被委托者的请求而被准许，接着是被委托者 发起的流程。

更进一步的，本发明的方法基于之前声明的规则允许执行有关授权委托的 自动决定。该方法还可允许与被保护资源所有者(即委托者420)之间的在线交 互。

根据本发明包括控制器、服务提供者、使用者、委托辅助设备和用户终端 的物理实体可包括或存储包含指令的计算机程序，这样，当在物理实体上运行 计算机程序时，根据本发明实施例的步骤和流程可被执行。本发明还涉及根据 本发明执行方法的此类计算机程序，以及涉及存储根据本发明执行方法的计算 机程序的任何计算机可读介质。

这里使用诸如“接收机”、“确定器”、“提取器”、“子确定器”和“传送机” 这些术语，不对这些单元可如何分布以及单元可如何聚集进行限制。也就是， 这些单元的组成部分可分布在不同软件或硬件组件或装置中以带来想要的功 能。多个不同的单元也可聚集在一起以提供想要的功能性。

任何一个上述涉及的控制器的单元可用硬件、软件、现场可编程门阵列 (FPGA)、专用集成电路(ASIC)、固件或诸如此类来实现。同样适用于用户 终端、使用者和服务提供者。

在本发明的另外实施例中，上述的接收机、确定器、提取器、子确定器和传送 机中的任何一个可分别被接收部件、确定部件、提取部件、子确定部件和传送部件 所替换，或者分别被接收单元、确定单元、提取单元、子确定单元和传送单元所替 换以执行接收机、确定器、提取器、子确定器和传送机的功能。

在本发明的另外实施例中，上述步骤中的任何一个可以使用计算机可读指 令来实现，例如以计算机可理解的流程、方法或诸如此类的形式，以任何类型 的计算机语言，和/或以在固件、集成电路或诸如此类上的嵌入软件的形式。

虽然基于详细的实施例对本发明进行了描述，但是这些详细实施例仅用于 为技术人员提供更好的理解，并不意图限制本发明的范围。本发明的范围更确 切地由所附带的权利要求来定义。