Windows CardSpace 介绍
发布日期： 2007-06-06 | 更新日期： 2007-06-06
David Chappell
Chappell & Associates
适用于：
Windows CardSpace
Windows Vista
Windows XP
Windows Server 2003
摘要：本文介绍了一组代号为 CardSpace 的 Windows 新功能，该组功能提供了一种基于标准的解决方案，用于使用和管理不同的数字标识。
本页内容
 | 了解数字标识 |
| Windows CardSpace 提供了哪些功能 |
| 检查信息卡 |
| 与 Windows CardSpace 进行互操作 |
| Windows CardSpace 和其他 Microsoft 技术 |
| 结束语 |
| 更多参考资料 |
了解数字标识
您是谁？ 这个问题很简单，但答案却并不简单。 您的身份表示方法会因所到之处的不同而有所变化。 当您在机场的出入境通关口出示护照时，您的身份是某一国家的公民。 当您由于超速行驶而被警察拦截并出示自己的驾驶执照时，您的身份是居住在某一地区的合法司机。 当您使用信用卡在书店购买最畅销的小说时，您的身份是具有某一特定帐号的顾客。 不同的环境中需要使用不同的标识，每种标识的表示方法和所提供的信息均不尽相同。
（本文还包含指向英文网页的链接。）
在所有这些环境中，您可以通过一些便于理解的方法来确定自己的标识。 但在一个非常重要的环境，即网络环境中，标识的确定目前还比较混乱。 正如在现实环境中一样，我们都拥有多种数字标识，并以不同的方法表达它们。 但是，现在并没有一种统一的方法来处理这些数字标识。 相反，我们仍然在一个复杂、混乱且不安全的环境中苦苦挣扎。
然而，不同种类的数字标识始终是必不可少的，因为只凭单个标识不可能满足全部需求。 实际上，这些标识始终是由一些不同的源所提供的，因为只凭单个标识提供者同样不可能满足全部的需求。 这就意味着解决之道不是去强制要求使用一个数字标识系统，更合适的做法是寻找一致的方法来使用多个数字标识系统。 我们需要的是由多个主要用于处理标识的元系统所组成的系统。
需要通过合作来实现该标识元系统。 单个组织只凭一己之力不可能完成一个解决方案。 幸运的是，可以通过使用与供应商无关的通信标准来解决此问题。 这些标准基于 SOAP 和 XML，包括 WS-Security、WS-Trust、WS-MetadataExchange 和 WS-SecurityPolicy。 通过使用这些 Web 服务技术，可以定义一致的方法，来使用由任何源通过任何标识技术所创建的任何数字标识。
Microsoft 与其他公司通力协作，在定义此基于标准的标识元系统方面起着举足轻重的作用。 Microsoft 还在 Windows 中添加了新功能，从而帮助实现标识元系统。 任何 Windows 应用程序，包括诸如下一版的 Internet Explorer 等 Microsoft 技术产品，以及由其他方开发的应用程序，都可以通过 Windows CardSpace（最初代号为“InfoCard”）为用户提供一种通用的方法来使用数字标识。 CardSpace 作为 .NET Framework 3.0 的一部分，计划于 2007 年初发布，适用于 Windows Vista、Windows XP 和 Windows Server 2003。
Windows 是一种广泛使用的操作系统，因而 Cardspace 便成为实现标识元系统的重要部分。 除非其他组织也实现了此方案，否则该解决方案仍然无法成功实施。 因此，Microsoft 积极鼓励创建和使用能参与到标识元系统中的软件。 其目的是让相关人员可以在运行任何操作系统的任何机器上，就像当前在现实环境中使用标识那样，方便、有效和安全地使用数字标识。
介绍数字标识
同现实环境中的标识一样，数字标识也拥有各种形式和大小。 例如，您或许拥有一个 Yahoo 的电子邮件帐户，它通过电子邮件地址进行标识。 您可能还拥有诸如 Amazon 或 eBay 等各种商业组织的数字标识，以及诸如 MySpace.com 等站点的标识。这些组织和站点一般由您定义的用户名来标识。 在工作中，您可能还拥有雇主分配给您的数字标识，由您的网络登录信息进行标识。 此标识可能由某些目录服务进行维护，例如 Active Directory，并且通常只在公司网络范围内可用。
正如在现实环境中那样，我们有充分的理由在不同环境中使用不同的数字标识。 例如，通常需要将不同的信息与每个标识关联起来。 您使用的 Amazon 标识可以允许您访问信用卡号，而 MySpace.com 标识则不允许此操作。 每个标识的获取规则也不尽相同。 在 Amazon 获取数字标识比较容易， 只需创建一个用户名和密码即可。 从您的雇主那里获取数字标识可能有点困难，因为您至少需要得到运行公司网络的管理员的批准。
表示数字标识：安全令牌
尽管数字标识间存在差异，但它们都拥有一个重要的共性： 当在网络上传输数字标识时，每个标识都由某种安全令牌表示。 安全令牌其实是用于表达数字标识信息的一组字节。 如图 1 所示，此信息由一个或多个声明组成，每个声明包含此标识所传递的总信息的某一部分。 一个简单的安全令牌可能只包括一个含有用户名的声明，而稍复杂一点的安全令牌可能包括含有用户的名、姓、家庭住址及更多信息的多个声明。 某些数字标识的安全令牌可能还包括含有诸如信用卡号等敏感性信息的声明。
图
1.
安全令牌
大多数安全令牌都提供了某些信息，以证实这些声明确实属于提出这些声明的用户。 执行此操作的一个简单（且目前比较常用）的方法是将密码连同声明一起发送。 一个较为有效的方法是使用私有密钥对全部或部分声明进行数字签名，然后提供相应的公共密钥（可能包装在证书中）。 此外，表示数字标识的安全令牌通常还会提供某种证明，供令牌接收方验证此令牌确实代表拥有该标识的个人或组织。
每个安全令牌的基本理念都是相同的，即都是一个声明的集合，现今使用各种不同的格式来表示这些令牌。 最简单的例子是一个只用文本字符串表示的用户名，但较为复杂的格式，例如 X.509 证书和 Kerberos 票证也比较常见。 这些格式的设计都不允许传递一组任意的声明，尽管一些声明对于某些数字标识而言十分有用。 使用安全声明标记语言（SAML，一个由行业组织 OASIS 创建的标准）创建的令牌则允许执行此操作。 SAML 基于 XML，可以用于定义含有任何所需声明集的安全令牌。
一直以来，数字标识主要用于验证。 现今最为常见的安全令牌格式，如用户名、X.509 证书和 Kerberos 票证，就反映了这一点，因为这些安全令牌格式所包含的信息主要集中于验证标识方面。 但为什么数字标识不能像实际标识那样得到广泛应用呢？ 您钱夹中的每张卡都反映了某种标识，而且其上还带有某机构证实的有用信息。 例如，您的驾驶执照中包括您的姓名、年龄、或许还有您的照片和其他信息，这些都是经过某政府机构证实的信息。 表达此信息的数字标识有助于了解多方面的情况，例如证实您年满 21 周岁，或者您的确戴有眼镜。 类似地，您的每张信用卡上都带有卡号、过期日期及您的姓名。 正如这些卡在现实环境中很有用一样，为每张卡创建数字标识（用于生成带有正确声明的安全令牌）也非常有用。
尽管安全令牌一直以来只着重于传递验证信息，但有必要认识到数字标识的概念要比这宽泛得多。 例如，通常我们不会使用信用卡来验证自己的身份，但此标识所传递的信息（例如信用卡号）仍然是有价值的。 实际上，术语“安全令牌”本身就是用词不当，因为令牌可以包含与安全性无关的信息。 使用 SAML 或其他方法可以定义几乎包含任何所需信息的安全令牌。 数字标识目前在网络环境中已得到广泛应用，正如我们在现实环境中所使用的许多标识一样。
使用数字标识：
Windows CardSpace
和标识元系统
如果能对所有事物使用由单个安全令牌格式表示的单个数字标识，生活就简单多了。 然而在现实环境中我们拥有不同的标识，同理，在数字环境中我们也需要拥有不同的标识。 因此，所面临的挑战就是以一种既容易理解而又行之有效的方法来创建、使用和管理这些不同的数字标识。
这正是标识元系统所要解决的问题。 标识元系统不是通过创造另一种技术来创建和表示数字标识，而是提供了一致的方法来使用多个数字标识，无论这些数字标识使用的是何种安全令牌。 标识元系统使用任何人可以在任何平台上执行的标准协议，允许获取和使用任何种类的安全令牌以传递标识。
Windows CardSpace 为用户提供了一种选择标识和更多信息的方法，因此是标识元系统的重要组成部分。 本文介绍了 CardSpace 以及它如何适合标识元系统。 目的在于让您了解此技术所提供的功能及工作原理。 但请注意，这里的介绍基于系统的 Beta 版本。 通常，在技术的最终版本发布之前，某些内容可能会有所变动。
Windows CardSpace 提供了哪些功能
此技术有四个比较突出、也是最为重要的方面：
| • |
支持任何数字标识系统
|
| • |
一致的数字标识用户控件
|
| • |
替代基于密码的 Web 登录
|
| • |
提高了用户对远程应用程序标识的信任度
|
此部分介绍 CardSpace（作为标识元系统的一部分）如何提供这四方面的功能。
支持任何数字标识系统
我们使用的多个数字标识来自几个不同的源，而且其表示方法也是多样的。 换句话说，我们通常依赖于许多不同的数字标识系统，其中每个标识系统可能使用了一种不同的底层技术。 要从总体上考虑这种差异性，定义三个不同的角色会很有帮助：
| • |
用户 — 也称为主体，它是与数字标识关联的实体。 用户通常指人，但组织、应用程序、计算机和其他事物也可以拥有数字标识。
|
| • |
标识提供者 — 顾名思义，标识提供者是指 可以为用户提供数字标识的事物。 例如，对于雇主分配给您的数字标识，其标识提供者一般指诸如 Active Directory 之类的系统。 对于您所使用的 Amazon 数字标识，标识提供者实际上就是您，因为您自己定义了用户名和密码。 不同标识提供者所创建的数字标识可以包含不同的信息，并提供不同的用户真实身份保证级别。
|
| • |
依赖方 — 依赖方是一个应用程序，以某种方式依赖于数字标识。 依赖方将频繁使用标识（即组成该标识安全令牌的声明中包含的信息）来验证用户，然后作出授权决定，如允许该用户访问某些信息等。 依赖方也会使用该标识获得信用卡号，来验证不同时间或出于不同目的而进行访问的同一用户。 依赖方的典型示例包括 Internet 网站，如网上书店、拍卖站点，以及其他通过 Web 服务接受请求的所有应用程序。
|
给定这三个角色后，对于 Windows CardSpace 和标识元系统支持任何数字标识的方式就不难理解了。 图 2 显示了三个角色间的基本交互。
图
2.
用户、标识提供者和依赖方角色间的交互
如图 2 所示，用户可以依赖支持 CardSpace 的应用程序（例如 Web 浏览器）来访问几个依赖方中的任何一方。 还可以从一组标识提供者中进行选择，作为要显示给这些依赖方的数字标识源。 无论用户进行哪种选择，这三方间的基本信息交换都可分为以下三个步骤：
| • |
第一步，应用程序获取用户想要访问的依赖方的安全令牌要求。 此信息包含在依赖方的策略中，其中还包含了诸如依赖方将接受的安全令牌格式，以及这些令牌必须包含的声明等信息。
|
| • |
应用程序一旦拥有了此依赖方所需安全令牌的详细信息，就会将该信息传递给 CardSpace，并要求其从适当的标识提供者处请求令牌。
|
| • |
CardSpace 接收到此安全令牌后，随即会将其传给应用程序，然后再传给依赖方。
|
接下来，依赖方就可以使用此令牌验证用户或用于其他目的。
此高级视图说明了交换过程中最为重要的方面。 如下所示：
| • |
Windows CardSpace 和标识元系统对于从标识提供者处请求继而传递到依赖方的安全令牌格式完全不知。 事实上，CardSpace 甚至不知道此令牌所采用的格式。正是由于这个原因，CardSpace 可以通过任何类型的安全令牌（包括简单的用户名、X.509 证书、Kerberos 票证、SAML 令牌或其他类型）来使用任何数字标识系统。 这允许 CardSpace 和标识元系统与任何适当的数字标识技术结合使用。 还允许插入现在需要创建、也许会在将来问世的数字标识系统。
|
| • |
由标识元系统定义并由 CardSpace 实现的所有交换，都是使用已发布的开放协议来执行的。
|
在最基本的方案中，通过 WS-SecurityPolicy 描述依赖方策略，使用 WS-MetadataExchange 对策略进行检索，利用 WS-Trust 获得安全令牌，并使用 WS-Security 将该令牌传递给依赖方。实现上述所有操作的前提是，启用标识元系统中标识令牌安全交换所必需的 WS-* 协议已提交或即将提交给标准主体。
在 Web 浏览器与网站交互这种较简单（大概也比较普遍）的方案中，可以通过 HTML 表达依赖方策略，并且可使用 HTTPS 在该策略信息与站点之间以及安全令牌与站点之间进行交换。 虽然与标识提供者的交互仍要依赖于 WS-Trust，但网站不需要实现任何 WS-* 规范以充当依赖方角色。
在以上任意一种方案中，都不需要通过依赖方或标识提供者实施任何专用协议来使用 CardSpace。
如图 2 所示，只有当标识提供者和依赖方实现了标识元系统所使用的协议时，CardSpace 才有用。 虽然 Microsoft 致力于元系统定义的研究，并且已经创建了可以为 Windows 提供重要元系统组件的 Windows CardSpace，但没有其他组织的参与是不可能成功的。
一致的数字标识用户控件
通过标准协议获取和传输安全令牌确实非常有效。 然而,如果没有某种方法可供用户理解这些令牌所代表的数字标识并对其作出明智的决定，则系统将会瘫痪，呈现出无用的复杂状态。 因此，CardSpace 和标识元系统的主要目标之一，就是让包括从安全专员到您的父母在内的所有用户对数字标识的使用作出良好的决策。
为此，CardSpace 实现了一个直观的用户界面来使用数字标识。 图 3 显示了标识选择屏幕，这可能是此界面中最为重要的部分。
图
3. CardSpace
标识选择屏幕
如屏幕快照中所示，每个数字标识都显示为一个信息卡，有时还将其简写为 InfoCard（此技术代号的源）。 每张卡都代表一个用户有可能呈现给依赖方的数字标识。 屏幕快照上直观地显示了这些卡，且每张卡上还包含有关特定数字标识的信息。 此信息包括：为获取此标识的安全令牌所要联系的标识提供者、此标识提供者可以发行的令牌种类，以及确切来说这些令牌可以包含的声明。 （如本文稍后所述，每张信息卡事实上是由标识提供者创建的，然后安装在用户的计算机上。） 当用户选择某一特定卡时，实际上选择的是请求由特定标识提供者创建的带有特定声明集的特定安全令牌。 但是，这种技术上的复杂性被隐藏起来了，这样用户就可以随意去思考那些有意义的事情。 图 4（在图 2 的基础上略加引申）显示了用户的决定适合于该过程的哪一阶段。
图
4.
选择标识
如前文所述，该过程中首先应用程序要请求依赖方策略。 我们知道，该策略指出了此依赖方可以接受的安全令牌种类，以及这些令牌所必须包含的声明。 此信息返回并传递给 CardSpace 后，系统随即显示卡选择屏幕。 要为用户提供一致的体验，则应显示他们在此系统上所拥有的每张信息卡，就像打开钱夹时可以看到其中的每张卡一样。 但只有某些卡可以在任何情况下使用，因此，与安全令牌和声明关联的信息卡如果不符合此依赖方的要求，就会变暗，即用户无法进行提交操作。 用户单击某一特定卡后，CardSpace 随即会向此卡所关联的标识提供者发出请求（如前文所述）。 同样，标识提供者随后返回一个安全令牌，该令牌将传递给依赖方。
重要的是应该为用户提供一致的方法来选择数字标识，这主要有两方面的原因：
| • |
用户拥有一致的、可预测的方法来使用数字标识。 如果没有这样的方法，恐怕除了专家级用户外，其他用户一定会觉得结果令人困惑且是错误的。 为了使用 CardSpace 而创建的每个应用程序将以完全相同的机制来使用数字标识，并通过完全相同的界面将数字标识呈现给用户。
|
| • |
即使用户在安全技术知识方面存在差异也无所谓。 您无需考虑某一特定标识的安全令牌是使用 X.509 证书还是使用 SAML 或某种其他方法表达的。 CardSpace 通过为用户提供简单而直观的表示方法，确保用户可以避免面对这种不必要的复杂性。 所有事物都是根据与用户相联系的信息来表达的： 标识本身及其包含的信息。
|
为了确保更加安全，用户可以选择使用个人标识号 (PIN) 来保护个人信息卡，这样用户在使用信息卡之前必须输入该个人标识号。 并且为进一步阻止本地攻击，CardSpace 还为标识选择屏幕（用于选择卡片）创建了专用的 Windows 桌面。 这类似于隔离 Windows 登录屏幕所使用的机制，而且还阻止了其他本地运行的进程的攻击。
值得注意的是，为用户提供一致的机制，以便选择要使用的数字标识，这是标识元系统的实质所在。 本文主要介绍了 CardSpace（一种 Windows 技术），但要在其他操作系统上实现，则应提供相应的直观屏幕以进行卡片的选择。
替代基于密码的
Web
登录
现今 Internet 上最为常见的一种安全令牌就是用户名。 要证明一个用户名确实归您所有，最常见的方法就是提供与此用户名关联的密码。 虽然一般情况下由您自己选择用户名和密码，但有时您所访问的站点也会为您分配用户名和密码。 而这样的网站通常使用 SSL 与您的浏览器之间进行通信，所以此方法可以认为是非常安全的。 SSL 可以确保整个通信都经过加密，因此攻击者无法通过监听通信来窃取密码。
然而此类基于密码的方案比较容易受到另一种攻击： 网页仿冒。 攻击者通过发送欺骗性电子邮件，试图欺骗用户登录到一个假冒真实站点的站点上，从而使其暴露密码或者其他个人信息。 假如密码不是 Web 上的主要身份验证机制，则这种网页仿冒的威胁性会小一些，因为不存在可窃取的密码。 为实现此目的，并从整体上提高 Web 登录的安全性，CardSpace 允许使用一种更加强大的机制来替代基于密码的 Web 登录。
依赖方（例如网站）不通过密码来验证用户，而是使用安全令牌来验证用户。 例如，某公司提供了一系列的网站，它可能还会提供一个运行在某台机器上并可由任何客户访问的标识提供者，该标识提供者能够发行该系列中所有站点都可以接受的令牌。 此方法将密码的使用程度降到了最低，的确是一种可以同 CardSpace 一起使用的方法。 该方法仍只适用于特定的一组站点，因为没有单个的标识提供者可以被所有的网站接受以发行安全令牌。
那么如果由用户选择自己的用户名和密码，情况会如何？ 此方法目前在网站上已得到了非常广泛的应用，原因之一是因为其比较简单： 不需要第三方标识提供者。 该方法不提供过多有关用户真实身份的担保，因为站点无从知晓用户所提供的姓名是否真实。 对于使用此方法的站点而言，通常只需要在用户每次登录时识别该特定用户，而用户只需拥有唯一的数字标识，其中不一定含有任何真实信息。
简言之，问题在于： 依赖方希望接收由标识提供者创建的安全令牌，从而可以允许替代可能会被网页仿冒的基于密码的登录。 然而在大多数情况下，不存在能被广泛接受的第三方标识提供者来创建这些令牌。 但目的仅是识别由同一用户进行的多个访问，所以不需要使用复杂的数字标识。
为解决此问题，CardSpace 包括一个自发行标识提供者。 如图 5 所示，该自发行标识提供者在本地 Windows 系统上运行，并且像任何其他的标识提供者一样可以创建信息卡。 （事实上，为了区分外部标识提供者和自发行标识提供者类型，外部提供者通常称为托管标识提供者，而且它们创建的信息卡被称为托管卡。） 在图 5 所示的例子中，用户拥有三张从外部标识提供者处获取的信息卡，以及一张从自发行标识提供者处获取的信息卡。
图
5.
用户拥有来自自发行标识提供者的信息卡
由自发行标识提供者创建的信息卡可以只包含诸如用户名、通讯地址、电子邮件地址和电话号码等基本信息。 当用户选择将其中的一张信息卡提交给依赖方时，该用户系统上的自发行标识提供者会生成一个 SAML 令牌，其中包含用户在此卡中放置的信息。 自发行标识提供者还会生成一个公共/私有密钥对，使用私有密钥对安全令牌进行签名。 为了防止攻击者重新使用，令牌中包含了一个时间戳以及其他一些信息，使得它对于初始用户以外的任何人都没什么用处。 然后应用程序将此已签名的令牌连同其关联的公共密钥一起发送给依赖方。 依赖方可以使用此公共密钥验证安全令牌的数字签名，这样就确保了由正确的令牌所有者来呈现该令牌。 为阻止依赖方相互之间通过比较用户的公共密钥来跟踪用户活动，自发行标识提供者为使用此信息卡访问的每个依赖方都创建了一个不同的密钥对（尽管该细节对用户是隐藏的，用户只能看到一张该标识的信息卡）。
主要思想就是： 因为大多数标识提供者所发行的安全令牌均不使用密码，其中包括那些由 CardSpace 的自发行标识提供者创建的令牌，所以依赖方（包括网站和其他应用程序）可以使用这些令牌而非密码来验证用户。 如果站点不使用密码，则网页仿冒者就无法欺骗用户暴露这些密码。
网页仿冒是一个很严重的问题。 如果 Windows CardSpace 和标识元系统专注于减少此问题的发生，则当前的联机环境会得到明显改善。
提高了用户对
Web
应用程序标识的信任度
减少网站对基于密码登录的依赖性有助于减少网页仿冒情况的发生，但并不能彻底消除此问题。 如果用户受到欺骗访问了网页仿冒者的站点，则该站点可以接受该用户所提供的、自发行或其他方式的任何安全令牌，然后要求用户输入诸如信用卡号等信息。 网页仿冒者不会获得它所仿冒站点的用户密码，但毫无疑问可以获知其他一些有用的信息。
问题的根本在于用户不能区别真正的网站（比如说用户的银行）和网页仿冒者创建的仿冒站点。 二者可以显示相同的徽标及其他图形。 二者甚至还可以使用 SSL 来保护通信，因为网页仿冒者同样可以获取证书。 如果用户点击了网页仿冒者电子邮件中所提供的链接，他会发现自己连到了一个外观酷似银行站点的站点。 Internet Explorer 的右下角甚至还会显示小锁标记，表明该通信受 SSL 保护。
可通过以下两种方法解决此问题：
| • |
高度确认方法，网站使用此方法向用户验证其标识
|
| • |
一致性方法，用户使用此方法了解站点用于验证其标识的确认级别，然后对是否信任该站点作出正确的选择。
|
Windows CardSpace 和标识元系统解决了这两个问题。
第一个问题的解决，以及网站向用户验证其标识的方法的改进，均依赖于执行此操作所使用的证书的改进。 现今，网站通常使用 SSL 通信所用的证书来验证其标识。 情况多少有所改善，但 SSL 证书事实上只证实了给定站点拥有一个特定的 DNS 名称。 但并不能保证此 DNS 名称对应于该站点上所显示的信息。 网页仿冒者可以使用为他所拥有的 DNS 名称发行的证书，例如，保护与一个经过仔细加工看上去酷似银行的站点间进行通信。 因此，SSL 证书并不足以解决此问题。
为此，Microsoft 与同行业的其他公司进行合作，以创建一个新级别的证书。 该证书可包含比传统 SSL 证书更多的信息，其中包括证书所要发行到的组织的名称、位置和徽标。 此高度确认证书还将成为较权威的信息来源，这是因为证书的获取比较困难，需要与发行机构达成高度一致。 标识提供者以及依赖方都可以使用这种新的证书向 CardSpace 应用程序的用户验证其标识。
在上述两个问题中，通过创建高度确认证书可解决第一个问题。 但最终还是需要由用户来决定信任哪一个站点。 CardSpace 使得这种决定更加明确，它要求每位用户批准使用其想要访问的每个标识提供者和依赖方。 信息卡首次安装到用户系统上时，将出现一个屏幕，要求用户验证其想要接收的安全令牌，该安全令牌由发行此信息卡的标识提供者创建。 类似地，首次访问依赖方（例如网站）时，会出现一个屏幕，要求用户指明其是否希望向该依赖方发送数字标识信息。 图 6 显示了用户首次访问依赖方时所显示屏幕的示例：
图
6.
首次访问依赖方时所显示的屏幕
如示例所示，屏幕上可以包括标识经过批准的组织（例如 Overdue Media）的名称、位置、网站 URL 和徽标。 还可以包括已对此信息进行过验证的组织（例如 VeriSign）的名称和徽标。
为了帮助用户更好地作出决定，需要根据标识提供者或依赖方提供的证书种类相应地改变屏幕上所显示的内容。 如果提供了前文所述的高度确认证书，则屏幕会指出已经过验证的组织的名称、位置、网站 URL 和徽标，如图 6 所示。这可以向用户表明该组织是比较值得信任的。 如果只提供了 SSL 证书，则屏幕会指出授权了一个较低级别的信任。 而且，如果甚至提供了更弱的证书或者根本没有证书，则屏幕会指出没有任何证据可以表明该站点的真实身份。 其目的在于帮助用户作出明智的决定：允许哪些标识提供者为其提供数字标识，以及允许哪些依赖方接收这些数字标识。
所有这些都引出了一个严肃的问题： 这真的会对一般的 Windows 用户有所帮助吗？ 对于不了解分布式安全性的人（即不知道证书是什么，更不用说信任哪些证书颁发机构），他真能通过使用 CardSpace 作出更好的决定吗？ 最起码，为访问新的站点提供一致的、可预测的体验，应该会有所帮助。 在 CardSpace 上创建的每个应用程序（包括下一个版本的 Internet Explorer），都会要求用户明确同意使用其通过 CardSpace 访问的每个标识提供者和依赖方。 用户始终会看到相同的操作屏幕，而且这些屏幕可为用户提供指导，帮助用户确定可在多大程度上保证该站点的真实身份。 而且，用户只需在第一次访问某站点时作出是否要信任该站点的决定。 以后（甚至数月后）再访问该站点时，则不会再显示类似图 6 所示的屏幕。如果用户访问某个以前确实曾经访问过的站点时出现了该屏幕，很明显，这说明该用户由于某种原因受到欺骗而访问了仿冒的站点。
使用
Windows CardSpace
：示例情景
要准确了解 CardSpace 和标识元系统的使用方式，最直观的方法就是查看一些典型示例。 例如，回想一下在访问某个网上商店（如 Internet 书店）时发生了什么情况。 在最简单的情况下，不涉及到任何数字标识 — 任何人都可以浏览出售的书籍，而无需告诉销售商自己的身份。 但是，如果试图订购书籍的话，就需要提供数字标识登录。 现在，输入用户名和密码是最常见的方式，这两者都由自己提前设定。 如果该网上商店支持 CardSpace 和标识元系统，则还会提供另一个选项以供您进行身份验证： 使用信息卡。 为便于操作，该商店可能在其登录屏幕上配置一个特定按钮，可通过单击该按钮来使用信息卡登录，而无需输入用户名和密码。
单击此按钮将会让浏览器使用 CardSpace 来登录该站点。 通常会显示 CardSpace 选择屏幕，此时可以选择一张卡以作为日后登录该商店时验证身份之用。 虽然不要求全部如此，但在这种情况下所选择的信息卡很可能是由自发行标识提供者创建的 — 亦即您自己创建的信息卡。 因为所有站点此时需要做的就是将您标识为唯一的客户，因此这种简单形式的数字标识足以满足要求。 付款时，像平常那样在 Web 窗体中输入自己的信用卡信息和帐单邮寄地址即可。
上述简单示例中，CardSpace 提供了一种无需使用密码便可登录到网上商店的方法。 这种方法很有用，并且朝着 Internet 数字标识的方向迈进了一步。 但对于数字标识的众多用途而言，这仅仅是一个开始。 例如，在此示例的支付步骤中，还可以使用信息卡来将信用卡信息发送到该站点。 假设发行信用卡的公司提供了一个标识提供者，则可以利用此标识提供者请求一个与信用卡相对应的信息卡。 无需将信用卡信息输入 Web 窗体，站点会在支付屏幕上提供一个按钮，以便您提供信息卡。 单击此按钮，系统便会显示 CardSpace 选择屏幕，然后选择可用于支付该站点款项的信息卡。 单击其中的一张卡会使 CardSpace 联系该卡发行者的标识提供者，获取包含信用卡信息的安全令牌，然后将该令牌提供给网上商店。
正如本例所示，数字标识并不仅仅用来验证您的身份。 像您钱夹中各种卡所表示的物理标识一样，数字标识也可以用于付款或其他用途。 例如，假设您当地发行驾驶执照的组织提供了标识提供者。 那么现在，就可以使用该数字标识来验证发送到任何依赖方的个人信息。 例如在美国，客户必须证明他们已经年满 21 岁才能购买酒类饮料。 某个网上酒类商店可能要求其客户提供他们驾驶执照的 CardSpace 版本，其中就包括出生日期，或许还接受 CardSpace 版的信用卡来支付相关费用。
此驾驶执照标识提供者还可提供其他类型的信息卡。 例如，某些人可能希望在不透露自己姓名或其他标识信息的情况下，有办法证明他们已经年满 21 岁。 驾驶执照标识提供者知道您的年龄，因此可能会提供包含执照上所有内容的信息卡，也可能提供更简单的只包含年龄的信息卡。 对符合要求的人，标识提供者甚至可能提供这样一种信息卡：只包含一条您已经年满 21 岁的声明，而不会显示其他任何如年龄这一类潜在的敏感信息。 尽管被称为“数字标识”，但在标识特定用户时，却也没有要求其中必须包含该用户的所有信息。 大多情况下，需要的只是有一种方法来进行某个声明，例如已经年满 21 岁，所有信息皆由可信任的机构备份。
关于 Windows CardSpace 和标识元系统的其他用途，还有更多示例。 移动电话服务运营商也可以提供信息卡，使其用户能够将网上采购费用记入他们的电话帐单。 雇主可能会为其雇员提供多个数字标识，每种标识都具有自己的信息卡，以在公司网络上使用。 一个标识可用于正常访问，而另一个标识则可能除了证明此人为公司员工外不包含其他任何信息，而提供这样一个标识的唯一目的或许就是为了方便员工对公司管理提出匿名建议。 如同现实世界中的标识包含不同信息并具有不同用途一样，数字标识也可通过多种方式使用。 CardSpace 和标识元系统的目标是尽可能获得最广泛的应用。
检查信息卡
从用户的角度来看，信息卡是他（或她）可在其屏幕上看到的数字标识的可视化表现形式。 但是，对于 CardSpace 而言，信息卡实际上是存储在用户 Windows 计算机上的一个 XML 文档。 在这种情况下，重要的是了解获得信息卡的方式以及卡中所包含的内容。 本节将着重介绍此类相关问题。
如何获得信息卡
每个信息卡都由相应的标识提供者创建。 对于自发行标识提供者，CardSpace 提供了可让用户创建卡的图形工具。 对于其他标识提供者，通常运行于其他计算机之上，用户必须通过一些途径来获得合适的卡，如通过标识提供者的网站，或通过由标识提供者发送的电子邮件。 实现此操作的方式由每个标识提供者定义 — 没有硬性规定获得信息卡的方法。
无论采用哪种方法获得信息卡，即使由自发行标识提供者创建，都由发行卡的标识提供者进行了数字签名，并附带有标识提供者的认证。 此签名用于验证标识提供者的身份。 只要卡在用户的计算机上，双击该卡便会出现一个屏幕，允许用户将此卡安装到 CardSpace 标准存储区。 当用户必须批准标识提供者作为安全令牌的源时，情况也是这样，如前文所述（尽管由自发行标识提供者创建的信息卡不需要该批准）。 用户进行该操作后，便可使用该卡来请求安全令牌。
卡中包含的信息
信息卡的内容将以智能方式帮助用户选择数字标识。 利用这些内容，CardSpace 可使卡符合依赖方的要求，并从发行该卡的标识提供者处获取合适的安全令牌。 为了实现这两个目标，每个信息卡都会包含下列内容：
| • |
JPEG 或 GIF 文件，含有用户可在其屏幕上看到的信息卡图像，以及所显示的信息卡名称。
|
| • |
可从该标识提供者处请求的一个或多个类型的安全令牌，以及每个令牌可能包含的声明列表。 这样，CardSpace 可将依赖方策略与能够创建符合依赖方要求安全令牌的标识提供者进行匹配。
|
| • |
访问标识提供者上一个或多个端点请求安全令牌所需的 URL。
|
| • |
标识该标识提供者上可获得其策略的端点的 URL。 如下一节所述，此信息还会指示 CardSpace 应当怎样对发送给标识提供者的请求进行身份验证。
|
| • |
创建信息卡的日期和时间。
|
| • |
信息卡的 CardSpace 引用，是以 URI 形式指定的全局唯一标识符。 此标识符由发行信息卡的标识提供者创建，并且每一次使用信息卡请求安全令牌时，会将此标识符传回给该提供者。
|
同样重要的是应该注意信息卡中不包含的内容： 关于此标识的敏感数据。 例如，由信用卡公司创建的信息卡不会包含用户的信用卡号码。 尽管此类敏感信息可能作为声明出现在标识提供者创建的安全令牌中，但其始终是存储在标识提供者的系统中。 在安全令牌中发送此信息时，通常会加密以确保攻击者和 CardSpace 无法进行访问。 关键在于信息卡中从未包含此敏感信息，因此用户计算机上也从未存储此敏感信息。 但是，信息卡的拥有者也可以使用 CardSpace 来预览那些使用该卡创建的安全令牌中的信息。 当用户要求查看此信息时，将会从发行卡的标识提供者处提取此信息。 显示之后，接着会将该敏感信息从用户系统中删除。
信息卡的漫游
人们通常希望不同的计算机可以提供相同的数字标识。 有许多人在工作时使用一台计算机，在家中使用第二台计算机，而旅行时使用第三台计算机。 为了在这些不同的计算机之间进行漫游，CardSpace 提供了一种卡导出功能。 此选项允许使用外部存储媒体（如 USB 密钥）来保存信息卡副本。 然后可以将这些卡安装在其他计算机上，并允许用户以相同的方式请求来自标识提供者的安全令牌，无论是家用计算机、办公室计算机还是出门旅行时用的便携式计算机皆可。 为预防攻击，会使用从用户选择密码短语派生的密钥对导出的信息卡进行加密。 这就确保即使存储媒体丢失，也只有知道密码短语才可以解密存储媒体所包含的信息卡。
但有些情况并不适用这一解决方案。 例如，假设某人想要在网吧使用基于 CardSpace 的标识。 这样就需要将信息卡安装在公众场合的计算机系统上。 为了使用自管理标识提供者创建的现有标识，还需要安装同这些标识相关联的密钥。 但是把所有信息放到共享的公共计算机上不是什么好做法。 虽然 CardSpace 的第一个版本无法解决这一问题，但计划在不久的将来，可实现将 CardSpace 存储区和完整的自发行标识提供者全部安装到基于 USB 的硬件上。 一旦实现该目标，用户就能够将此设备插入计算机，然后直接从中请求安全令牌，而无需在使用的计算机上安装信息卡或密钥。
撤销信息卡
CardSpace 必须解决的另一个问题是撤销。 标识提供者向用户发行信息卡之后，如想撤销这张卡可以采取哪些措施呢？ 在最简单的情况下，标识提供者本身可能希望停止发行基于此卡的安全令牌。 使用此标识提供者可能还需要付费订购，而用户并未继续付款。 在这种情况下要撤销非常简单： 标识提供者只需停止接受使用此卡做出的对安全令牌的请求即可。 每个请求都带有唯一的 CardSpace 引用，因此标识提供者很容易就可以识别出使用已撤销信息卡发出的请求。
当用户想要撤销一张信息卡时，情况就会稍微复杂一些。 或许某个攻击者窃取了用户的便携式计算机，该计算机中安装了由外部标识提供者发行的信息卡。 正如我们前面提到的，可以为每个信息卡分配一个每次使用时都必须输入的 PIN。 如果这样做了，攻击者便无法使用窃取的卡，除非他/她也知道每张卡的 PIN。 此外，某些标识提供者可能要求用户在每次使用特定信息卡请求新的安全令牌时，都要输入密码或使用智能卡。 对于不具有其中任意一个保护措施的卡，用户将需要联系与其相应的标识提供者，并告知标识提供者不再接受这些卡。 同获取卡一样，要实现这种支持也没有任何标准机制。 每个标识提供者必须为其用户提供自己的程序来取消此信息卡，然后停止接受此卡做出的请求。
但是对于由自发行标识提供者创建的卡，该如何处理呢？ 就被盗窃的便携式计算机来说，连同这些卡的标识提供者也被盗窃了，因此没有办法告诉标识提供者停止接受请求。 这种情况非常类似于丢失密码，唯一的解决方案就是告知接受该密码的那些组织，密码丢失了。 如果信息卡连同创建它们的自发行标识提供者一起丢失了，则卡的拥有者将需要在每一个接受安全令牌（使用这些已丢失信息卡所创建）的依赖方手动取消他/她的帐户。 CardSpace 提供了卡历史记录功能，可记录卡在其中使用过的所有站点，因此被盗便携式计算机的拥有者可使用其信息卡的备份副本来确定需要联系哪些站点。
与 Windows CardSpace 进行互操作
Windows CardSpace 是 .NET Framework 3.0 的一部分，并且在其上构建的应用程序必须是 Windows 应用程序。 但是，将在其他平台和设备上实现与 CardSpace 兼容的标识选择器，并且标识提供者和依赖方不必是 Windows 应用程序。 本节将概述为了与采用 CardSpace 的 Windows 应用程序配合使用，标识提供者和依赖方需要怎么做。
创建标识提供者
可在任何操作系统上、使用任何开发平台来构建标识提供者。 无论以何种方式创建，每个标识提供者都必须满足四个条件，方可使用 CardSpace：
| • |
必须能创建同 Microsoft 定义的卡格式兼容的信息卡，并且必须提供一种方式来将这些卡提供给用户。
| ||||||||||
| • |
必须按照 WS-Trust 规范的定义来执行安全令牌服务 (STS)。 该规范基于 SOAP 定义了一种标准方式来请求特定类型的安全令牌，其中包含来自 STS 的特定声明。 每个标识提供者都必须至少执行一种 STS，但是 STS 能够以任何格式发行安全令牌 — 没有硬性规定要采用特定的令牌类型。 虽然不要求全部如此，但还是强烈建议标识提供者也支持由 Microsoft 为标识元系统定义的 WS-Trust 特定的扩展。
| ||||||||||
| • |
必须使用 WS-SecurityPolicy 来定义其策略，然后允许使用 WS-MetadataExchange 对该策略进行访问。 正如先前所述，每个信息卡都包含一个端点，可以通过这个端点来检索标识提供者的策略。 在图 2 和图 4 中忽略了此步骤，但在客户端应用程序通过标识提供者请求安全令牌之前，CardSpace 会首先要求标识提供者提供自己的策略。
| ||||||||||
| • |
必须在其策略中指明应如何对安全令牌的请求进行身份验证。 在 CardSpace 的第一个版本中，对标识提供者提供了四个选项来验证用户身份：
|
作为其策略的一部分，标识提供者还可以指示当用户针对某依赖方请求安全令牌时，必须提供该依赖方的标识。 默认情况下，请求令牌时，CardSpace 不会将依赖方的标识透露给标识提供者。 这样可保护用户隐私，因为这样可不让标识提供者知道用户想要使用此令牌访问哪个服务。 但某些标识提供者可能需要在发行请求的令牌之前了解依赖方的标识。 例如，一个 Kerberos 服务器需要知道客户端将访问的服务的标识，才能为该服务创建票证。 更常见的情况是，某个建立标识提供者来供自己网站使用的组织，可能只允许标识提供者发行用于那些自己网站的安全令牌 — 不允许任何不速之客为他们自己的目的来使用此标识提供者。
CardSpace 还定义了一些可在产生错误时发送的 SOAP 错误。 例如，访问一个标识提供者可能会生成一些错误，指明请求安全令牌时所引用的信息卡无效或已到期，或该标识提供者无法创建一个包含所请求声明的安全令牌。
创建依赖方
类似于标识提供者，可在任何操作系统上、使用任何开发平台来构建依赖方。 同样类似于标识提供者，依赖方也必须满足几个条件方可使用 CardSpace。 对依赖方的要求是：
| • |
必须能够接受安全令牌。 最常见的方法是执行 WS-Security，但网站还可以接受使用 HTTP 发送的令牌。
|
| • |
必须定义自身策略。 同样，应当选择使用 WS-SecurityPolicy 来定义其策略，然后允许使用 WS-MetadataExchange 对该策略进行访问。 网站也可以使用 HTML 描述其策略并使用 HTTP 传输。
|
| • |
必须提供证书。 对于执行 WS-* 规范的依赖方来说，可以使用 Microsoft 定义的 WS-Addressing 端点引用扩展来进行该操作。 通过将标识元素添加到 WS-Addressing EndpointReference，该扩展可提供一个标准方法来向客户端显示依赖方的证书。
|
依赖方可自由接受任何类型的安全令牌。 虽然不要求必须这样做，但许多依赖方会接受由 CardSpace 自发行标识提供者生成的安全令牌。 （Microsoft 定义了依赖方可放置在其策略中的特定值，以表示支持这些令牌。） 无论依赖方接受何种安全令牌，都可以随时将该信息映射到本地标识，比如，将一个 SAML 令牌转换到 Windows 安全标识符 (SID) 或 UNIX 用户标识符 (uid)。
同标识提供者一样，CardSpace 定义了一些在依赖方与 Web 服务交互期间，产生错误的情况下发送用的 SOAP 错误。 例如，访问依赖方可能会产生错误，指明安全令牌中的一个声明无效或请求的声明丢失。
Windows CardSpace 和其他 Microsoft 技术
同大多数的 Microsoft 新产品一样，CardSpace 将对 Windows 环境的其他部分产生影响。 受到这种新数字标识方法影响的最重要的技术是 Internet Explorer (IE)、Windows Communication Foundation (WCF)、Active Directory 和 Windows Live ID。本节将着重介绍每一个技术与 CardSpace 之间的联系。
Windows CardSpace
和
Internet Explorer
Microsoft Web 浏览器的下一个版本 Internet Explorer 7，将允许用户使用 CardSpace 来管理其数字标识。 因为 IE 是现今最广泛使用的访问 Internet 的工具，因此对于此新的标识技术而言是一个重要的应用程序。 在最常见的情况下，CardSpace 完全使用基于 SOAP 的协议进行通信。 但是，正如先前所述，网站还可通过使用 HTML 和 HTTP 来同 IE 7（以及可能同其他 Web 浏览器）进行交互。
图 7 显示了进行该操作的一个方法。
图
7. Windows CardSpace
和
Internet Explorer 7
|
1.
|
当浏览器用户在网站上访问一个受保护的页面时，例如网上商店上用于购买产品的页面，这一过程就会开始。 此时，网站会要求用户进行登录，因而该站点会将浏览器重定向到其登录页面。
|
|
2.
|
重定向操作会使站点向浏览器发送一个登录窗体。 利用该窗体，用户可像平时一样通过提供用户名和密码来登录到站点，但是如果该站点支持 CardSpace 登录，则传递窗体的页面还将包含一个特定 OBJECT 标记或 XHTML 语法。 此信息包含站点的策略，并且将使得浏览器向用户显示一个 Windows CardSpace 登录选项。
|
|
3.
|
如果用户选择该选项，则 IE 7 将执行由 OBJECT 标记或 XHTML 语法标识的代码，在登录过程中需要请求 CardSpace 的参与。
|
|
4.
|
随即将显示 CardSpace 屏幕，且用户可以选择一个标识。
|
|
5.
|
到目前为止，所有同该站点的通信都使用了 HTTP。 但是，用户选择了一个标识后，CardSpace 通常会使用 WS-Trust 联系相关的标识提供者，并获取安全令牌。
|
|
6.
|
然后作为登录过程的一部分，使用 HTTP POST 将此令牌发送到网站。
|
Web 应用程序便可使用此令牌验证用户身份或用于任何其他目的。
在这种情况下，标识提供者可能是在用户系统上本地运行的自发行标识提供者，也可能是一些外部提供者。 网站本身也能够提供自己的安全令牌服务，可用来生成由该站点使用的自定义令牌。 对于希望提供应用程序特定令牌或高流量的网站而言，此选项非常有用，因为它允许在专用服务器上进行大部分的验证工作。
另外更重要的一点是此过程中不存在任何特定于 IE 的内容。 任何操作系统上的任何浏览器都能以相同的方式使用标识元系统。 在 Windows 上，Microsoft 所提出的目标是允许任何应用程序（包括其他供应商的 Web 浏览器在内）通过 CardSpace 管理和使用数字标识。
Windows CardSpace
和
Windows Communication Foundation
Windows Communication Foundation 是即将推出的一款 Microsoft 平台，用于构建面向服务的应用程序。 WCF 可执行所有由 CardSpace 和标识元系统使用的能够互操作的协议，其中包括 WS-Security、WS-SecurityPolicy、WS-Trust 和 WS-MetadataExchange，并且 CardSpace 本身大部分也基于 WCF 而构建。 毫不奇怪，使用 WCF 来创建用作依赖方、标识提供者或 CardSpace 客户端的应用程序将很简单。
若要知道如何实现此目的，就需要了解一些有关 WCF 服务（执行操作）和 WCF 客户端（调用这些操作）的信息。 每个 WCF 服务都会显示一个或多个端点，通过这些端点可对该服务的操作进行访问。 每个 WCF 客户端都会指明想要与之进行通信的端点。 服务和客户端共同指定对端点的绑定，该绑定会定义将使用什么协议来传送 SOAP 消息、如何实现安全性等。 例如，名为 WsHttpBinding 的绑定指示应通过 HTTP（支持 WS-Security）发送 SOAP 消息，等等。 WCF 还可自动创建应用程序策略的可访问描述，使用 WS-SecurityPolicy 表示。
虽然没有要求必须如此，但大多数人还是倾向于使用 WCF，在支持 NET Framework 3.0 版本的 Windows 系统上实现标识提供者和依赖方的构建。 要创建标识提供者或依赖方，需要做的就是构建一个符合上节内容所列要求的 WCF 服务。 只要应用程序符合这些要求并选择了合适的 WCF 绑定，如 WsHttpBinding，就可以参与到 CardSpace 中。
但是，创建一个能够让用户以 CardSpace 来指定数字标识的 WCF 客户端应用程序，需要直接使用 CardSpace 软件。 提供了一个特殊的绑定来指示 WCF 应用程序应使用 CardSpace 进行身份验证。 如果 WCF 客户端为与之进行通信的端点指定此绑定（不管执行该端点的依赖方是否基于 WCF 而构建），将会在需要安全令牌时自动调用 CardSpace。 通常会显示 CardSpace 选择屏幕，让用户选择将要发送的数字标识。 CardSpace 将自动联系适当的标识提供者以获取安全令牌，然后将令牌插入 WCF 应用程序的传出请求。 开发人员仅需指定应使用正确的绑定，而 CardSpace 将完成剩余的全部操作。
Windows CardSpace
和
Active Directory
Active Directory 显然是标识提供者的重要备选者。 CardSpace 预定于 2007 年年初发布，而暂时还没有发布新版 Active Directory 的计划。 Microsoft 已经提出 Active Directory 最终将能够起到标识提供者的作用，但并未宣布该功能何时将会实现。
更直接的问题是 CardSpace 如何同 Active Directory 联合身份验证服务 (ADFS) 发生联系。 ADFS 现在就已可使用，而且初看起来与 CardSpace 极为类似。 但事实上，这两种技术完全不同。 CardSpace 会提供一个标识选择器和一个自发行标识提供者，二者都可在客户端计算机上运行。 ADFS 是一种基于服务器的软件，该软件允许某个组织通过 WS-Federation 连同其他组织，使用 Active Directory 来对其标识进行联合身份验证。 另一个重要的区别在于，如上一节所述使用 CardSpace 的浏览器起到了极为积极的作用，而使用 ADFS 的浏览器则没有这个意识完全处于被动状态。 当二者都涉及到标识时，CardSpace 和 ADFS 会执行完全不同的功能。
Windows CardSpace
和
Windows Live ID
Microsoft Windows Live ID 系统（以前称作 Passport），最初用来提供可供 Internet 上的任何站点使用的标准身份验证系统。 现在，从最初形式发展而来的网络主要包括由 Microsoft 本身运行的一些站点。 即使 Windows Live ID 现在一天能处理近十亿次登录，但事实很明显： 哪怕是一个像 Microsoft 这样大的组织，都不可能成为 Internet 上所有内容唯一的标识提供者。
CardSpace 和标识元系统具有非常多的标识及标识提供者的常规视图，代表了完全不同的方法。 Microsoft 已经表示将修改 Windows Live ID 使之起到标识提供者的作用，并且用户将能够通过 CardSpace 登录到他们的 Windows Live ID 帐户。 然而 CardSpace 与 Windows Live ID 不存在任何依赖关系，并且总有一天 Windows Live ID 提供的标识提供者将不会在标识元系统中起到任何特定的作用。
结束语
不可否认，标识元系统解决的问题以及所提供的解决方案都非常重要。 提供标准方法来使用各种数字标识，可让网络世界变得像现实世界一样方便和安全。 让用户控制在何种情况下使用何种标识，使人们可以直接负责使用其数字标识的方式。 使用包括自发行标识在内的数字标识，可减少对基于密码的 Web 登录的需求，同时增强用户对网站标识的信任度，还可减少困扰许多用户的网页仿冒攻击。
Windows CardSpace 是这些解决方案的关键部分。 要想实现上述美好目标，就需要为其他操作系统创建软件、构建标识提供者、提供依赖方和执行标准的 Web 服务协议，使元系统得以存在并实现互操作。 Microsoft 通过为 Windows 提供软件来履行其职责，但是只凭一己之力还无法完成标识元系统的伟大设想。 其他个人和组织也应该了解通过更有效使用数字标识将得到的益处，并且积极地参与进来。
尽管如此，CardSpace 仍就是用途广泛。 由于 CardSpace 底层的标识元系统是基于开放协议，因此可以在任何平台或设备上针对标识提供者、依赖方以及其他标识选择器构建与 CardSpace 相兼容的软件。 而且由于 CardSpace 显示的界面简单直观，因此可以断定任何 Windows 软件都能够使用 CardSpace。 基于所有上述事实，我们必须承认 Windows CardSpace 对于所有对数字标识感兴趣的人而言具有重要意义。
更多参考资料
文章
站点
博客
| • | |
| • |
--------------------------------------------------------------------------------
关于作者
David Chappell 是加利福尼亚州旧金山 Chappell & Associates 的负责人。 他通过讲演、撰稿和咨询，帮助全球的技术专业人员了解和使用企业软件，并制定更佳的决策。
秦韶华
扫一扫
900
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
