信任管理系统及方法.pdf

提出了用于帮助配置与网络服务、数字权利管理系统和/或其它应用一起使用的信任管理框架的系统和方法。用于配置信任管理框架的方法涉及向用户提供图形用户界面(GUI)，其提示用户以自相容的方式来定义信任管理框架的特定方面。在一个实施方式中，方法包括：提供提示用户定义角色的角色GUI；提示用户定义与该角色对应的服务的服务GUI；提示用户定义主体的主体GUI，包括将角色中的至少一个与主体相关联；以及呈现对被指定起节点作用的主体的角色绑定以及提示用户定义节点之间的相互作用的节点GUI。

1.  一种用于配置在网络环境中使用的信任管理框架的方法，该方法包括：
提供提示用户定义角色的角色图形用户界面；
提供提示用户定义对应于所述角色的服务的服务图形用户界面；
提供提示用户定义主体的主体图形用户界面，包括将角色中的至少一个与主体相关联；以及
提供节点图形用户界面，该节点图形用户界面呈现对被指定起节点作用的主体的角色绑定以及提示用户定义节点之间的相互作用。

2.  如权利要求1所述的方法，其中提供角色图形用户界面包括提供提示用户标识角色名称以及标识角色之间的相互作用的图形用户界面。

3.  如权利要求1所述的方法，其中提供角色图形用户界面包括提供提示用户标识角色名称以及标识何种角色能够调用何种角色的图形用户界面。

4.  如权利要求3所述的方法，其中所述角色图形用户界面在矩阵中呈现角色名称，其中请求者角色在所述矩阵的一个轴上，而响应者角色在所述矩阵的另一个轴上。

5.  如权利要求4所述的方法，其中节点之间的相互作用是通过标记在所述矩阵中的请求者角色和响应者角色之间的交叉点而被标识的。

6.  如权利要求5所述的方法，其中在请求者角色和响应者角色之间的交叉点处的标记指示被标记的请求者角色能够调用被标记的响应者角色。

7.  如权利要求6所述的方法，其中所述角色图形用户界面被配置为将每个被标识的角色名称放置在矩阵的每个轴上。

8.  如权利要求1所述的方法，其中提供角色图形用户界面包括提供提示用户标识角色名称且标识何种角色能够断言何种角色的图形用户界面。

9.  如权利要求1所述的方法，其中所述服务图形用户界面提示用户标识服务的名称以及标识与所述服务相关联的至少一个操作。

10.  如权利要求9所述的方法，其中标识与所述服务相关联的至少一个操作包括定义消息协议。

11.  如权利要求10所述的方法，其中定义消息协议包括下述中的至少一个：
指示消息的XML模式类型；
指示消息是否必须是完整性保护的；
指示消息是否必须是机密性的；
指示消息是否必须有时间戳；以及
指示消息是否必须包括现时。

12.  如权利要求10所述的方法，进一步包括提供提示用户定义用于与服务相关联的消息的模式类型的名称空间的名称空间图形用户界面。

13.  如权利要求9所述的方法，其中所述服务图形用户界面自动被填充了在角色图形用户界面中标识的角色，并且其中所述服务与角色相关联。

14.  如权利要求1所述的方法，其中所述主体图形用户界面提示用户标识主体名称以及用于每个主体的统一资源名称(URN)。

15.  如权利要求13所述的方法，其中所述主体图形用户界面提示用户标识每个主体是否被从外部源导入。

16.  如权利要求13所述的方法，其中所述主体图形用户界面提示用户标识与每个主体相关的凭证。

17.  如权利要求16所述的方法，其中所述主体图形用户界面提示用户根据下述中的至少一个来标识主体的凭证：
发布主体；
发布证书；
主体是否为属性发布者；以及
使用规范。

18.  如权利要求1所述的方法，其中所述节点图形用户界面根据客户角色绑定和服务角色绑定来呈现角色绑定。

19.  如权利要求18所述的方法，其中对于每个角色绑定，所述节点图形用户界面呈现下述中的至少一个：
角色断言；
服务类型的指示；
完整性证书的身份；
机密性证书的身份；
消息信任锚的身份；
属性信任锚的身份；以及
被信任的属性断言证书的身份。

20.  如权利要求4所述的方法，进一步包括查看被配置为请求者节点的客户角色绑定是否能调用被配置为响应者节点的相应服务绑定。

21.  如权利要求20所述的方法，其中所述节点图形用户界面呈现关于在节点之间定义的相互作用是否有效的指示。

22.  如权利要求1所述的方法，其中所述节点图形用户界面呈现提示用户标识两个节点之间的相互作用的节点相互作用表。

23.  如权利要求22所述的方法，其中通过标识请求者节点、请求者角色绑定、响应者节点以及响应者节点绑定而在节点相互作用表中表示相互作用。

24.  一种用于配置在网络环境中使用的信任管理框架的系统，该系统包括：
角色模块，提示用户定义角色；
服务模块，提示用户定义对应于所述角色的服务；
主体模块，提示用户定义主体，包括将角色中的至少一个与主体相关联；以及
节点模块，呈现对被指定起节点作用的主体的角色绑定以及提示用户定义节点之间的相互作用。

25.  如权利要求24所述的系统，其中所述角色模块提示用户标识角色名称以及标识何种角色能够调用何种角色。

26.  如权利要求24所述的系统，其中所述角色模块提示用户标识角色名称以及标识何种角色能够断言何种角色。

27.  如权利要求24所述的系统，其中所述服务模块提示用户标识服务的名称以及标识与所述服务相关联的至少一个操作。

28.  如权利要求27所述的系统，其中标识与服务相关联的至少一个操作包括定义消息协议，其中定义消息协议包括下述中的至少一个：
指示消息的XML模式类型；
指示消息是否必须是完整性保护的；
指示消息是否必须是机密性的；
指示消息是否必须有时间戳；以及
指示消息是否必须包括现时。

29.  如权利要求28所述的系统，进一步包括提供提示用户定义用于与服务相关联的消息的模式类型的名称空间的名称空间模块。

30.  如权利要求24所述的系统，其中所述服务模块自动给服务定义编辑器填充在角色图形用户界面中标识的角色，并且其中所述服务与角色相关联。

31.  如权利要求24所述的系统，其中所述角色模块被配置以检查被配置为请求者节点的客户角色绑定是否能够调用被配置为响应者节点的相应的服务绑定。

32.  如权利要求31所述的系统，其中所述节点模块呈现关于在节点之间定义的相互作用是否有效的指示。

33.  如权利要求24所述的系统，其中所述节点模块呈现提示用户标识两个节点之间的相互作用的节点相互作用表，其中通过标识请求者节点、请求者角色绑定、响应者节点以及响应者节点绑定来在节点相互作用表中表示相互作用，且其中所述节点模块被配置为呈现被标识的相互作用的有效性的指示。

34.  一种用于配置在网络环境中使用的信任管理框架的系统，该系统包括：
用于提示用户定义角色的装置；
用于提示用户定义对应于所述角色的服务的装置；
用于提示用户定义主体的装置，包括将角色中的至少一个与主体相关联；以及
用于呈现对被指定起节点作用的主体的角色绑定以及提示用户定义节点之间的相互作用的装置。

35.  一种包含用于配置信任管理框架的可执行指令的计算机可读介质，所述可执行指令包括以下指令：
提供提示用户定义角色的角色图形用户界面；
提供提示用户定义对应于所述角色的服务的服务图形用户界面；
提供提示用户定义主体的主体图形用户界面，包括将角色中的至少一个与主体相关联；以及
提供呈现对被指定起节点作用的主体的角色绑定以及提示用户定义节点之间的相互作用的节点图形用户界面。

信任管理系统及方法
技术领域
相关申请
本发明要求2006年8月11日提交的申请号为60/822,068的美国临时申请的权益，该申请通过引用被结合到本文中。
版权授权
本专利文件公开的部分包含受版权保护的资料。当其出现在专利和商标局专利文件或记录中时，该版权的所有者对专利文件或专利公开中的任何一个的复制再现都无异议，但是无论如何要以其它方式保留所有版权权利。
背景技术
随着网络和计算机安全越来越重要，对创建网络服务和其它应用而言设计以及实现稳健的信任管理框架(trust managementframework)已成为越来越重要的部分。然而相对而言，信任管理框架的设计和实现通常与依赖其的服务和应用的功能性无关，因此，这种服务或应用的设计者可能缺乏以有效、正确的方式设计和实现信任管理框架的专门知识。
信任管理可能需要各种构件(building block)的使用，例如密码学、公钥基础结构、数字证书(及其链接)、安全断言标记语言(security assertion markup language)(SAML)断言(例如定义角色)等等。一般而言，信任管理框架通常定义系统如何证实实体(entity)是它们自称的那个，以及确定实体仅被允许执行它们被授权执行的动作。配置自相容的(self-consistent)安全信任管理框架会是一项复杂的任务，因为在给定的系统中将通常存在具有重叠的角色和授权(authorization)的大量实体。
发明内容
介绍用于帮助配置与网络服务、数字权利管理系统(digitalrights management system)和/或其它应用一起使用的信任管理框架的系统和方法。例如，非限制地，这里所描述的系统和方法能用于帮助各种对使用技术(例如在共同转让的申请号为10/863,551(公开号为2005/0027871)(＂‘551申请＂)的美国专利申请中所描述的用于媒体编排网络环境(Networked Environment for MediaOrchestration)(NEMO)的服务编排技术、和/或在共同转让的申请号为11/583,693(公开号为2007/0180519)(＂‘693申请＂)的美国专利申请中所描述的用于设计和实现例如安全DRM系统的数字权利管理(“DRM”)技术)感兴趣的各种保管者(stakeholder)。‘551申请和‘693申请的全部内容被引用于本申请中以作参考。
在一个实施方式中，用于配置在网络环境中使用的信任管理框架的方法涉及为用户提供各种图形用户界面，以提示用户定义信任管理框架的特定方面。特别地，用于配置在网络环境中使用的信任管理框架的方法包括：提供提示用户定义角色的角色图形用户界面；提供提示用户定义对应于该角色的服务的服务图形用户界面；提供提示用户定义主体的主体图形用户界面，包括将角色中的至少一个与主体相关联；以及提供呈现对被指定起节点作用的主体的角色绑定以及提示用户定义节点之间的相互作用的节点图形用户界面。在一个实施方式中，该方法确保以自相容的方式配置信任管理框架。例如，在很多方面，配置图形用户界面为用户呈现了可从中进行选择的一组选项，为了确保自相容，这些选项被限制为唯一有效的选项，其中选择选项的有效性是基于先前的配置决定的(based on previous configurationdecisions)。
在一个实施方式中，用于配置在网络环境中使用的信任管理框架的系统包括：角色模块、服务模块、主体模块以及节点模块。角色模块提示用户定义角色。服务模块提示用户定义对应于该角色的服务。主体模块提示用户定义主体，包括将角色中的至少一个与主体相关联。节点模块呈现对被指定起节点作用的主体的角色绑定以及提示用户定义节点之间的相互作用。
结合以本发明主体工作的原理作为实例而示出的附图，从下列详细描述中，本发明的其它方面和优点将变得显而易见。
附图说明
通过结合附图参照下列详细的描述，将容易理解本发明，在附图中相同的标号表示相同的元素(element)，其中：
图1示出了用于配置信任管理框架的工作流程向导(workflowwizard)的实例。
图2图示了用于定义角色发布者(role issuer)的特定属性的角色GUI。
图3图示了用于定义角色调用者(invoker)的特定属性的角色GUI。
图4图示了名称空间配置编辑器。
图5图示了用于定义服务的服务GUI。
图6图示了用于定义主体(principal)及其凭证(credential)的主体GUI。
图7图示了用于定义扩展密钥用法的扩展密钥使用编辑器。
图8图示了用于定义节点的节点GUI。
图9图示了用于实践配置工具的实施方式的示例性计算机系统。
图10图示了图9的配置工具的放大图。
图11是根据一个实施方式用于配置信任管理框架的方法的流程图。
具体实施方式
下面将提供本发明主体工作的详细描述。虽然描述了若干个实施方式，但应该理解的是本发明主体工作并不局限于任何一个实施方式，但是作为替代包括多种选择、修改和等价物。另外，虽然在以下描述中为了提供本发明的透彻理解而阐述了多个特定细节，但是在不具有某些或全部这些细节情况下，能够实践某些实施方式。此外，为了清楚起见，将不详细描述相关领域中公知的特定技术资料以免不必要地使本发明主体工作不明确。
介绍用于帮助配置与网络服务、数字权利管理系统和/或其它应用一起使用的信任管理框架的系统和方法。例如，并非限制性地，这里所描述的系统和方法能用于帮助对使用技术(例如在‘551申请中所描述的用于媒体编排网络环境(NEMO)的服务编排技术、和/或在‘693申请中所描述的用于设计和实现例如安全DRM系统的数字权利管理技术)感兴趣的各种保管者(stakeholder)。应该理解这些系统和方法是新颖的，因为应用于其中的许多部件、系统和方法都是新颖的。
如在‘551申请中所详细描述的，信任管理可能需要各种构件的使用，诸如密码学、公钥基础结构、数字证书(及其链接)、安全断言标记语言(SAML)断言(例如定义角色)等等。一般而言，信任管理框架通常涉及定义系统如何证实实体是它们自称的那个，以及确定实体仅被允许执行其被授权执行的动作。通过定义自相容来确保安全信任管理框架可能是一项复杂的任务，因为在给定的系统中将通常存在具有重叠角色和授权的大量实体。
在优选的实施方式中，配置工具(在这里有时被简单地称作“工具”)被用于帮助配置与网络服务、数字权利管理系统、应用程序等等一起使用的信任管理框架。配置工具的实施方式在以直观的、图形形式来呈现复杂的网络(例如在‘551申请中所描述的那些和/或任何其它合适的网络)方面是有价值的，该图形形式使得更易于掌握各种系统元素之间的关系。
随着信任管理框架的配置，通过不断地为内部相容性而验证(validate)信任管理框架，并且通过以清晰的、计算机以及人可读的形式来获取配置，配置工具的实施方式能够帮助系统结构设计者。
配置工具的实施方式能提高系统实施者的生产率。从通过设计过程而产生的网络模型，配置工具可以被用来为所有NEMO主体自动产生所有的信任管理凭证。在一些实施方式中，配置工具也可以被用来为模型隐含的应用和服务产生具有桩代码(stub code)的基于Java的默认项目，从而能快速实行这样的实现，该实现能够执行由模型定义的NEMO节点之间的实时相互作用(live interaction)。从而，配置工具的实施方式能够帮助开发者快速获得工作基线功能性(working baseline functionality)，由此使得开发者能够专注于实施用于NEMO服务和消费者应用的业务逻辑，同时保持对信任管理发布(issue)的不可知，在缺乏配置工具的情况下，该信任管理发布可能会消耗大量的开发工作。
在一个实施方式中，配置工具包括信任管理编辑器，其通过信任管理框架的配置来引导用户。图1示出了工作流程向导对话10的一个实例，工作流程向导对话允许用户配置新的信任管理框架或修改现存的信任管理框架的配置。在图1所示的实例中，选择工作流程向导的“创建(Create)...”按钮12，从而将应用域配置编辑器(也指信任管理编辑器)呈现给用户。
在优选的实施方式中，信任管理编辑器包括四个主模块，其通过特定功能图形用户界面(GUI)被呈现给用户。特定功能GUI包括角色GUI(Roles GUI)、服务GUI(Services GUI)、主体GUI(PrincipalsGUI)和节点GUI(Nodes GUI)。将参考图2-图8来描述信任管理编辑器的实施方式。参考图2，信任管理编辑器包括工具栏14和特定功能标签20、22、24、26和28。工具栏提供对常见应用操作的访问，例如所述操作包括文件管理操作以及一些诸如名称空间(NS)和扩展密钥使用(XKU)操作的特定应用操作。特定功能标签用于开始(launch)特定功能GUI。特定功能GUI以及其相关的功能将在下面参考图2-图8来描述。
角色GUI
图2图示了显示角色GUI 30的信任管理编辑器的实施方式。角色GUI提示用户定义角色。在一个实施方式中，角色是给定同级(peer)与特定行为模式一起显示的一组服务。在该实施方式中，角色GUI包括两栏角色名称编辑器，左栏标记为“角色”栏，而右栏标记为“别名(Alias)”栏。该“角色”栏被配置为由角色名称的列表来填充，而该“别名”栏被配置为由对应的角色别名来填充。在优选的实施方式中，角色别名是可选的，并且如果定义了别名则该别名被用来以更简短的形式显示角色名称。在图2的实施方式中，定义了被标识为“叶(Leaf)”角色和“监控器(Monitor)”角色的角色。对于该实例，叶角色是只用于客户(client-only)的角色，其显示(expose)没有服务；而监控器角色是显示一个服务的角色，其将在下面更详细地描述。
在图2所示的实施方式中，角色GUI还包括发布者(Issuers)标签和调用者(Invokers)标签，当其被选择时，为用户呈现相应的发布者矩阵或调用者矩阵。图2图示了具有被选择的发布者矩阵32的角色GUI。该发布者矩阵被用来定义何种角色能够断言(assert)何种角色。在一个实施方式中，角色断言标识主体应该拥有何种角色“X”，以便有权将角色“Y”的角色断言发布给其它主体。例如，“X”对应于“发布者角色”，而“Y”对应于“主体角色(Subject Role)”。在图2的实施方式中，发布者矩阵包括在x-轴上的发布者角色以及在y-轴上的主体角色，并且该矩阵的每个轴自动由角色名称编辑器中定义的每个角色填充。通过标记发布者角色和主体角色之间的交叉点(intersection point)来标识角色之间的相互作用，在图2的实施方式中，在发布者角色和主体角色之间标记交叉点表明被标记的发布者角色能断言被标记的主体角色。也就是，为了断言在y-轴中所指示的主体角色，在发布者角色和主体角色之间的交叉处的标记定义了角色发行发布者应该具有在x-轴中指示的何种角色。应注意的是在图2所示的实施方式中，只有被定义的角色的子集碰巧对应于角色发布者；其它角色可以指由NEMO节点使用的角色，从而授权对各种NEMO服务的访问。在一个实施方式中，这是由于“角色”概念的超负荷(overloading)，导致两个单独的矩阵-“发布者”和“调用者”。后者描述了扮演不同角色的节点之间的相互作用(调用)。前者首先描述了这些角色如何被分配。有时角色具有两种功能。例如，具有角色“A”的服务可能将角色“B”断言发布给具有角色“C”的客户。在该实例中，发布者矩阵定义了{“A”，“B”}元组，表示角色“A”可以断言角色“B”。同时，“调用者”矩阵定义了{“C”，“A”}元组，意味着具有角色“C”的任何客户可以联系具有角色“A”的服务-最自然地是，以要求授权新的角色“B”的断言，以在给定的信任管理生态系统(ecosystem)中获得作为参与者的更多能力。
图3图示了具有所选择的调用者矩阵的角色GUI 30。调用者矩阵34被用于定义请求者(Requestor)角色和响应者(Responder)角色之间的关系。在图3的实施方式中，调用者矩阵包括y-轴上的请求者角色以及x-轴上的响应者角色，并且该矩阵的每个轴再次自动由在角色名称编辑器中定义的每个角色填充。通过标记请求者角色和响应者角色之间的交叉点来标识角色之间的相互作用，在图3的实施方式中，在请求者角色和响应者角色之间标记交叉点表明被标记的请求者角色能调用被标记的响应者角色。也就是，在请求者角色和响应者角色之间的交叉点处的标记定义了一个节点请求在x-轴中标识的何种角色，从而调用另一个节点上的服务，该另一个节点作用(act)于在y-轴中标识的角色中。在图3的实例中，选中的框(checked box)表示叶角色(请求者)能调用监控器角色(响应者)。
通过角色GUI 30，用户能够自由命名任何角色并且以任何方式定义角色之间的关系。如下所述，在发布者矩阵和调用者矩阵之间所指定的关系将被反应在随后的配置操作中。如通过矩阵图示地表示地那样，角色之间的关系的图形表示是使得信任管理工具为用户友好的特征之一。虽然角色GUI使用如图2和图3所示的发布者矩阵和调用者矩阵来图示地描述角色之间的关系，但是其它形式的表示也是可以的。
一旦角色被命名且角色关系被指定，就可以为角色配置服务。在一个实施方式中，在配置每个角色的服务之前，提示用户开始名称空间配置编辑器。该名称空间配置编辑器提示用户定义用于为服务及其操作而定义的所有请求和响应消息有效载荷(payload)的模式(schema)类型的名称空间。图4图示了通过按下在信任配置编辑器(见图2和图3)的工具栏上的“NS”按钮而开始的名称空间配置编辑器38的实施方式。在图4的实施方式中，名称空间配置编辑器包括“别名”、“名称空间(Namespace)”和“模式位置(Schema Location)”栏。该“别名”栏用于定义每个名称空间的别名，该“名称空间”栏用于定义XML模式的名称空间，而该“模式位置”栏用于定义用于相应的名称空间的模式的位置。一旦配置了名称空间，用户就通过选择“确定(OK)”按钮返回到活动(active)的特定功能GUI。
服务GUI
在一个实施方式中，在已经定义了角色和名称空间之后，选择服务标签22来开始服务GUI。图5图示了显示服务GUI40的信任管理编辑器的实施方式。服务GUI包括服务编辑器，其提示用户定义对应于经由角色GUI而定义的角色的服务。服务封装了对由响应者节点显示或提供的一组明确定义的功能性的表示。在一个实施方式中，服务GUI预先由经由角色GUI30先前定义的角色(例如，在图3中定义的“叶”和“监控器”角色)填充。用户可以对每个角色定义由具有相应角色的节点来显示的一组服务。注意，有些角色可能不具有相应的服务，因为他们既不是发布者角色也不是只用于客户的角色。在图5中示出的示范性的服务是“呈现(Presence)”服务，其功能是确保节点可用。应该注意的是，与角色相关联的服务的数量和类型是特定于应用的(application-specific)。与指定的服务相关联的软件代码被包含在特定于服务(service-specific)的软件模块中。例如，在‘551申请中描述了用于对等(peer-to-peer)相互作用的服务模块的开发。
每种服务可以具有一个或多个相应的操作，而每个操作可以具有可被定义的不同消息特征(messaging characteristic)。在图5的实施方式中，服务GUI 40提示用户定义与信任管理相关的特定消息特征。这些特征被按栏组织，用户可以在栏中作出特定规范(specifications)。在图5的服务GUI中呈现的特定消息特征是：
(a)“元素(Element)”字段-表示消息有效载荷的XML模式类型的XML元素类型；
(b)“完整性(Integrity)”复选框-消息是否必须是完整性保护的的指示(例如，数字签名的)；
(c)“机密性(Confidentiality)”复选框-消息是否必须是机密的指示(例如，加密的)；
(d)“时间戳(Timestamp)”复选框-消息是否必须有时间戳的指示；
(e)“现时(Nonce)”复选框-表示消息是否必须包括现时(一次数(number once))以保证其唯一性。
在图5的实施方式中，服务GUI 40使用文件夹和子文件夹以分层的方式来组织角色、相应的服务以及相应的操作，从而用图形来表示各种角色、相应的服务和相应的操作之间的关系。在角色、服务和操作以及相关联的消息特征之间的关系的图形表示是这样的特征之一，该特征使得信任管理编辑器比必须为每个新服务写服务相关代码并且通过配置代码行读取来解释(decipher)类似的关系和特征对用户更友好。
主体GUI
选择主体标签24以开始主体GUI。图6图示了显示主体GUI 50的信任管理编辑器的实施方式。在一个实施方式中，主体是具有唯一身份(identity)的实体。也就是，主体大致对应于单个身份的概念，但是该身份如何建立是特定于域的。例如，X.509证书和SAML断言具有它们被发送给其的“主题”的概念。主题名称(subject name)是那些凭证内容的一部分，并且其对于给定的主体来说应该是相同的。然而，其它凭证可以不具有主题，例如密钥。一旦任何私有凭证被泄露，该主体就会被冒充。
主体GUI 50提示用户定义信任管理框架的主体，包括将先前定义的角色中的至少一个与主体相关联，以及给主体提供适用于其在信任管理框架内有意使用的凭证。在图6的实施方式中，主体GUI包括主体名称编辑器和主体凭证编辑器。该主体名称编辑器包括“名称(Name)”栏、“URN”栏、“NEMO节点(NEMO Node)”栏和“导入(Imported)”栏。主体名称编辑器的栏提示用户标识下列用于每个主体的信息，其被定义为：
名称-短的、对用户友好的名称，其被用于工具中的别的地方以引用主体；
URN-统一资源名称(URN)，其在为/由相应的主体发布的凭证中使用；
Nemo节点-相应的主体是否为NEMO节点。如果该主体不是NEMO节点，则在一个实施方式中该主体仅为凭证发布者；
导入-相应的主体是否是待被定义且供应(provision)为设计系统或原有外部主体的一部分的内部主体，其凭证必须被导入且用于设计系统中。由于本实例是描述从无到有的整个信任管理框架的配置，所以在该实例中没有选中该框。
在一个实施方式中，主体名称编辑器可以包括提示用户标识主体将被复制多少次的栏。在进一步的实施方式中，主体名称表可以包括额外的复制信息，例如将被复制的主体的起始标识符(startingidentifier)。在主体将被复制的情况下，主体的URN将包括浮点字符(floating character)，以指示唯一标识符将被插入的位置。例如，如果主体将从ID＝1开始被复制100次，则每个主体将具有包括除了ID之外相同URN的URN，其中100个不同主体的ID范围为从1到100。该特征能被应用于生产多个类似装置的生产环境，其中每个装置要求不同的URN。
在图6的实例中，定义了主体“CA”、“RA”、“LeafNode(叶节点)”和“MonitorNode(监控器节点)”。在该实例中，主体CA被定义为起证书授权的作用，主体RA被定义为起角色断言授权的作用。例如，具有能签名于(sign)其它证书的一个或多个证书的任何主体是CA(对于X.509证书，其是密钥使用4-“证书签名(certificates signing)”)。具有能够数据签名(data signing)(密钥使用128-“数据签名”)的一个或多个证书并且(PLUS)该证书在该GUI中被标记为属性(attribute)发布者任何主体成为角色授权(Role Authority)(RA)。因此，主体从其凭证获得其能力。主体LeafNode被定义成执行叶角色，而主体MonitorNode被定义成执行监控器角色。
在一个实施方式中，在主体名称编辑器中定义的主体的凭证是经由主体凭证编辑器而定义的。在优选实施方式中，有两种凭证(证书和断言)，其中，例如证书将名称绑定到公钥，而断言将名称绑定到角色。在图6的实施方式中，主体GUI 50提示用户根据下列特征来标识主体的凭证：
发布主体(Issuing Principal)-从其来发布证书的主体
发布证书(Issuing Certificate)-从其来发布当前证书的证书的名称
属性发布者(Attribute Issuer)-证书是否能起到属性发布者的作用
使用(Usage)-表示能够使用何种证书(例如，用于X.509证书的标准枚举密钥使用)的代码值
值(Value)-为每个证书定义扩展密钥使用(extended keyusage)。例如，在一个实施方式中，值字段(field)可以是上下文相关的字段，为每种凭证类型触发具有更详细的信息的弹出式对话。对于证书，值字段可以提供类似于密钥使用、有效数据、XKU等等的信息。对于SAML断言，值字段可以包括所有属性名称及它们的值、有效间隔等等的列表。
供应(Provisioned)-指示主体是否初始供应有这些凭证，或在操作期间从字段中获得他们。
在一个实施方式中，为打算用作证书授权的每个主体提供具有用于证书发布(例如，使用＝证书发布)的密钥使用的至少一个证书。证书名称应该被选为短的用户友好的名称，用于在工具中的别处的引用。如果提前定义了一些角色发布规则，则打算用作角色发布者的每个主体都被提供有用于角色签名(role signing)(使用＝数据签名)以及零个或多个角色断言的至少一个证书。在一个实施方式中，被标识为NEMO节点的每个主体具有至少两个证书，一个用于数据签名，而另一个用于密钥加密，以分别支持消息完整性和机密性。
在优选的实施方式中，属性断言由属性填充。例如，断言对关于其主题(主体)的特定信息进行“断言(asserts)”。对断言的信任是基于对其签名者(signer)(断言发布者)的信任。属性断言由一个或多个属性组成。在一个实施方式中，每个属性具有名称以及零个或多个值。角色断言仅是具有单个属性“角色”以及一个或多个值(角色名称)的断言的简单情况。在一个实施方式中，默认所有属性和“角色”属性名称一起供给。在一个简化的实施方式中，这是在信任管理中扮演角色的唯一属性。在一个实施方式中，为了确保在配置过程中的自相容，主体凭证表被编程，从而仅允许作为有效的属性断言的先前定义的角色的选择。
参照图6的实例中的主体凭证表，主体“CA”具有一个被标识为“CA-Cert”的证书、被标识为“CA”的发布主体、被标识为“CA-Cert”的发布证书以及4的使用，其中4＝证书签名。主体“RA”具有一个被标识为“RA-Cert”的证书、被标识为“CA”的发布主体、被标识为“CA-Cert”的发布证书以及128的使用，其中128＝数据签名。主体“RA”也被标识为属性发布者。
主体“LeafNode”包括两个证书(“LeafNode-Cert”和“LeafNode-ConfidentialityCert”)以及一个断言(“LeafNode-LeafRole”)。证书“LeafNode-Cert”具有发布主体“CA”、发布证书“CA-Cert”和128的使用，而“LeafNode-ConfidentialityCert”具有发布主体“CA”、发布证书“CA-Cert”和32的使用，其中32＝加密。在一个示范性实施方式中，发布Cert(Issuing Cert)是任何具有密钥使用4(证书签名)的证书。相应地，发布主体是拥有至少一个发布证书的主体。断言“LeafNode-LeafRole”具有发布主体“RA”和先前定义的“叶”角色的属性。在一个实施方式中，在使用字段(usage field)中，用户仅被呈现以先前定义的角色作为有效选择选项。该特征有助于将用户引导到自相容且有效的配置。
在图6所示的实例中，主体“MonitorNode”包括两个证书(“MonitorNode-Cert”和“MonitorNode-ConfidentialityCert”)，以及一个断言(“MonitorNode-MonitorRole”)。证书“MonitorNode-Cert”具有发布主体“CA”、发布证书“CA-Cert”和使用128，而“MonitorNode-ConfidentialityCert”具有发布主体“CA”、发布证书“CA-Cert”和使用32。断言“MonitorNode-MonitorRole”具有发布主体“RA”和先前定义的“Monitor”角色的属性。
在一个实施方式中，使用扩展密钥编辑器定义扩展密钥使用，该扩展密钥编辑器是通过选择在信任配置编辑器的工具栏14中图示的“XKU”按钮而开始的。图7图示了包括“OID”栏和“Alias”栏的扩展密钥编辑器52的实施方式。OID栏定义了对扩展密钥使用有效的对象标识符(OID)。Alias栏定义了在工具中的别处使用的短的用户友好的别名。
返回参照图6，主体GUI 50的主体凭证表使用文件夹和子文件夹以分层的方式组织主体以及相应凭证(证书和断言)，以图示地呈现各种主体以及相应凭证之间的关系。此外，对每个主体图示地显示凭证的可配置的特征。主体和凭证之间关系的图形表示以及相关联的凭证特征使得信任管理编辑器比必须写程序代码来配置每个主体或通过配置代码行读取来解释类似的关系和特征要更用户友好。
在图6所示的实例中，以及尤其在主体GUI 50中，为了避免环形依赖(circular dependency)，例如A签名于B、B签名于C、C签名于A，主体的次序很重要。因此，根据以前创建的主体(以及由此其凭证)列表来填充可用于每个主体的证书的可用发布主体和发布证书的列表。
节点GUI
选择节点标签26来开始节点GUI。图8图示了显示节点GUI 60的信任管理编辑器的实施方式。节点是对系统框架中参与者的表示。节点可以作用于包括服务消费者和/或服务提供者的角色的多个角色下。节点也可以以包括消费型电子装置、诸如媒体播放器之类的软件代理、或诸如内容搜索引擎之类的虚拟服务、DRM许可提供者或内容锁装置(locker)在内的各种形式来实施。节点GUI呈现对被指定起节点(例如NEMO节点)作用的主体的角色绑定，以及提示用户定义节点之间的相互作用。在一个实施方式中，节点GUI包括节点定义表和节点相互作用编辑器。节点定义表以图形的方式呈现对在主体GUI50中被指定为NEMO节点的主体的角色绑定(参见图6)。在图8的实例中，基于参考图3而描述的在调用者矩阵中定义的角色关系，角色绑定被呈现为客户角色绑定或服务角色绑定。例如，对于给定节点，可用客户和/或服务绑定的列表可以是基于主体具有的一组SAML断言以及那些断言定义的角色的。反过来，在该实例中，能够在客户绑定中、在服务绑定中或在这两种绑定中使用的角色依赖于调用者矩阵(先前说过，在一个实施方式中，相同的角色能在调用者矩阵中被定义为“请求者”和“响应者”二者)。如在这里所使用的，术语“节点”通常指从事与其它节点相互作用的主体(例如，使用其凭证)。
此外，在优选的实施方式中，信任管理编辑器允许为特定角色配置节点，只要其相应的主体配置有相应的角色断言。这两个特征确保建立自相容配置。
在一个实施方式中，每个服务或客户角色绑定指主体的角色断言中的一个。一旦被例示，服务角色绑定就自动由用于为给定角色提前定义的每个服务的服务绑定来预先填充。在一个实施方式中，服务绑定能被修改，但是不能被移除或添加，因为那样会构成对反角色契约(contract)的违。如上面关于图5所描述的，服务GUI 40定义需要为作用于给定角色下的节点显示的服务。在一个实施方式中，一旦为角色“X”添加“服务角色绑定”，则对于在节点GUI 60下方的给定的节点，作出下列的断言：a)节点具有定义角色“X”的SAML断言(自动证实)；b)角色“X”在“调用者”矩阵中作为“响应者角色”至少提及一次(自动证实)；以及c)节点打算使用该SAML断言来为其它节点提供服务。在一个实施方式中，角色契约声称：通过接受服务角色“X”，节点必须为给定的角色“X”提供在服务GUI下定义的所有服务，而不仅仅是其子集。这可以通过自动填充用于给定角色“X”的所有服务绑定的固定列表，从而在节点GUI中执行。
在一个实施方式中，每个客户角色绑定自动由用于每个服务的客户绑定预填充，该每个服务应当能够由具有给定角色的客户调用。在一个实施方式中，角色绑定的预填充涉及：a)从调用者矩阵中，发现角色“X”是“请求者角色”的所有元组并且创建所有“响应者角色”的列表；b)从服务GUI 40中，为每个“响应者角色”取得服务列表；以及c)将所列的所有服务列表组合到一个大的列表中-这是所有客户绑定的列表。在一个实施方式中，没有如“客户契约”这样的事情。也就是，仅仅因为节点能作用于客户角色“X”下，不能意味着该节点必须联系该节点能够以给定的客户角色联系的所有服务。能够发布对给定类型的请求是一种能力，同时能够在任何时候响应于对给定类型的请求是一种义务。例如，客户能调用的角色(以及由此的服务)经由上面参考图3所描述的角色调用者矩阵34而定义。
在一个实施方式中，每个客户或服务绑定根据下列特征来定义：
角色断言(Role Assertion)-在主体GUI 50中标识的对应于角色断言的名称；
服务类型(Service type)-对于服务绑定，该字段标识所显示的服务的类型，然而对于客户绑定，该字段标识能够被给定客户所调用的服务；
整体性Cert(Integrity Cert)-用于消息签名的证书的名称；
机密性Cert(Confidentiality Cert)-用于消息加密的证书的名称；
消息TA(信任锚)(Messaging TA(Trust Anchor))-为证书授权主体之一而定义的信任锚证书，被用于验证用于消息签名和/或加密的同级的证书；
属性TA(信任锚)(Attribute TA(Trust Anchor))-为证书授权主体之一而定义的信任锚证书，被用于验证同级的角色签名证书；
信任AA(属性断言)Cert(Trusted AA(Attribute Assertion)Cert)-主体的证书，其被委托发布同级的角色。
在图8的实施方式中，节点GUI 60使用文件夹和子文件夹以分层的方式来组织节点、服务角色绑定和客户角色绑定，从而以图形呈现各种节点及其相应的角色绑定之间的关系。节点、服务角色绑定、客户角色绑定以及相关联的角色绑定特征之间的关系的图形呈现使得信任管理编辑器比必须通过配置代码行读取以解释类似的关系和特征要更用户友好。
除了列出所有的客户绑定和服务绑定之外，在节点GUI 60的一个实施例中为那些绑定中的每一个定义信任管理策略(policy)。每个客户或服务绑定定义：a)使用何种断言来证明一个的角色(自动从父母(parent)角色绑定继承的)；b)将何种证书用于消息签名；c)将何种证书用于消息加密；d)将何种信任锚证书用于验证与其(消息信任锚(Messaging Trust Anchor)或MTA)相互作用的其他节点的消息证书；e)将何种信任锚证书用于验证使角色断言签名证书(属性信任锚或ATA)；以及f)通过名称(信任属性授权或TAA)来确定谁是信任角色断言的签名者。在一个实施方式中，TAA是可选的。通常，只要能使用ATA来认证(authenticate)角色断言签名者TAA，则该TAA就被信任了。在一个实施方式中，节点GUI仅呈现有效的证书选择：加密和签名证书必须是给定主体中的那些(一个给定主体仅可使用其自身的证书来签名或加密其自身的消息)，并且它们必须具有相应的密钥使用(对于签名是128以及对于加密是32)。对于证书签名，MTA和ATA应该是具有密钥使用4的另一主体的任何证书。TAA应该是具有数据签名密钥使用128的任何证书，另外在“主体”GUI中被标记为“属性授权”。
在节点GUI 60底部的节点相互作用编辑器允许用户列举应当彼此调用的节点角色绑定对。在一个实施方式中，信任管理引擎检查在特定请求者节点的角色绑定下配置的每个客户绑定是否能调用在响应者节点的给定角色绑定下配置的相应服务绑定，其中“能调用”指为每个节点的绑定及其对应的信任管理策略而配置的凭证的兼容性(compatibility)。在一个实施方式中，如果列举的角色绑定对是无效的，则立即通知用户。在一个实施方式中，配置编辑器通过检查分配的凭证的兼容性来确定角色绑定对的有效性。例如，在一个实施方式中，为每个相互作用对{客户角色绑定A，服务角色绑定B}，证实以下各项：a)为绑定A而定义的消息信任锚(MTA)证书应该是在绑定B中使用的签名证书和加密证书两者的祖先(ancestor)-并且反之亦然；以及b)为绑定A而定义的属性信任锚(ATA)应该是在绑定B中使用的角色断言的签名者的祖先-并且反之亦然。在图8的实施方式中，在节点GUI中的配置状态窗口提供配置有效性的指示。如果该配置是无效的，则在该配置状态窗口中显示配置错误的指示。
再次参照图8的节点GU I60，当在该配置上工作时，可能通过选择XML标签28来观看在任何点处所创建的配置的基础(underlying)XML显示。当呈现的XML文件可编辑时，不推荐对其直接改变，因为这通常需要基础模式的知识。
一旦网络配置完成且配置状态窗口表明该配置是有效的，就完成了配置过程。该配置能被保存在本地文件系统中以备将来参考。这时，实施者能继续配置向导以便生成实施项目。
这里描述的配置工具简化了与网络服务、数字权利管理和/或其它应用一起使用的信任管理框架的配置。该信任管理框架的配置在一致性上持续有效并且能被保存以备将来参考。
图9图示了用于实践该配置工具的实施方式的示例性计算机系统70。该计算机系统包括输入/输出72、中央处理器(CPU)74、数据存储器76和系统存储器78。该输入/输出包括例如显示器和/或键盘。CPU包括本领域公知的常规的多功能处理器。数据存储器包括例如磁盘和/或光盘，和/或任何其它合适的存储装置。数据存储器可以是本领域公知的固定的或可移动的存储器。系统存储器可包括例如随机存取存储器(RAM)和只读存储器(ROM)的一些组合，在处理器执行指令过程中用于存储由CPU执行或使用的信息和指令，和/或用于存储临时变量或其它中间信息。在图9的实施方式中，系统存储器存储了操作系统80和上述配置工具82。然而，应该理解的是图9是为了说明目的而非限制性而提供的，并且具有附加部件和/或图9所示的一些合适的部件的子集的其他计算机系统也可以被使用。当然，在本领域中的技术人员将会认识到实际上能使用任何类型的计算系统，例如包括个人计算机和主机。
图10图示了来自图9的配置工具82的放大图。在图10所示的实例中，配置工具包括角色模块84、服务模块86、主体模块88和节点模块90。在一个实施方式中，每个模块包括用于执行对应于上述特定功能GUI的功能的可执行指令。配置工具还包括名称空间模块92和扩展密钥使用模块94。该名称空间模块包括用于实现前面参考图4所述的名称空间编辑器的可执行指令，扩展密钥使用模块包括用于实现前面参考图7所述的扩展密钥编辑器的可执行指令。
虽然特定功能GUI被描述为显示于单独的屏幕视图中，但是该特定功能GUI能同时以不同的组合而被呈现。此外，虽然提供了GUI的特定布局，但是其它布局也是可以的。
图11是根据一个实施方式来配置信任管理框架的方法的过程流程图。在方框1102处，提供了提示用户定义角色的角色GUI。在方框1104处，提供了提示用户定义对应于该角色的服务的服务GUI。在方框1106处，提供了提示用户定义主体的主体GUI，包括将角色中的至少一个与主体相关联。在方框1108处，提供了呈现对被指定起节点作用的主体的角色绑定以及提示用户定义节点之间的相互作用的节点GUI。
配置信任管理框架的过程可以包括配置新的信任管理框架或修改先前已配置的信任管理框架。
尽管为了清楚的目的详细描述了前面的内容，但显而易见的是在不离开其原则的情况下可以作出特定改变和修改。应当注意，存在许多可选择地方式来实现这里所描述的过程和装置二者。因此，本实施方式被认为是示例性的而非限制性的。