Using InfoCards With DACS

Contents

• Introduction
• A Concise Overview of InfoCards
• DACS Authentication
• Self-Issued InfoCards
• Using Self-Issued InfoCards for DACS Authentication
• Demonstration 1: Self-Issued InfoCards
• Managed InfoCards
• Using Managed InfoCards for DACS Authentication
• Demonstration 2: Managed InfoCards
• InfoCards and DACS: the Future
• Notes
• Links

Introduction

September, 2014 Update:
In early 2011, Microsoft announced that it would not support CardSpace (aka, Infocards and Information Cards) starting with Windows 8. As CardSpace has been the most widely available identity selector for using Information Cards, and other projects related to Infocards and CardSpace have folded, future releases of DACS will likely deprecate and eventually remove support for Information Cards. See:

• On the Demise of CardSpace;
• Open Cardspace opportunity;
• Personal Reflections on the CardSpace Journey;
• From CardSpace to Verified Claims;
• Change will come: the present is untenable;
• The Clay Feet of Giants?; RIP, Windows CardSpace. Hello, U-Prove; and
• U-Prove.

The remainder of this document, and support for Infocards within DACS, are no longer being actively maintained. You may find that other Infocard and CardSpace related projects have been terminated and that their web pages are out of date or no longer available.

Note:
InfoCard support in DACS is relatively new. Elements of the design and implementation, including data formats, may be changed incompatibly. This document continues to be revised; the latest version is available here. Footnotes are indicated by a ^*** symbol.

This article describes a project that was initiated in early 2009 to investigate Information Card technology and how DACS might use it in its repertoire of authentication methods. Support for Information Cards (InfoCards) in DACS, developed and demonstrated by DSS as part of this project, offers a flexible and feature-rich platform from which a better understanding of them can be gained and the technology evaluated. The project described here was completed in August, 2009.

We begin with an overview of InfoCards. Readers are referred to cited material for background information and additional detail. Following a brief description of DACS authentication, we take a close look at the two types of InfoCards, how they work and ways in which each might be integrated with DACS to supply new authentication methods or supplement existing ones. Initial implementations that support Managed InfoCards and Self-Issued InfoCards are described. Instructions for demonstrations of DACS-based authentication that use InfoCards are supplied. The document concludes with some thoughts about future directions and links to additional information.

An objective of the project was to produce a prototype implementation to support creation of Self-Issued InfoCards and Managed InfoCards, validation of the secure tokens produced from these InfoCards, and extraction of claim information from the secure tokens. While these InfoCards can be used for DACS authentication, many other applications are possible. No Identity Selector component was written - any Identity Selector that conforms to the specification should interoperate with the DACS implementation, although only Windows Cardspace is officially supported at present. The prototype has been integrated with the DACS code base and documentation, and will appear in release 1.4.23 of DACS, although it will remain limited in various respects, including partial or missing functionality. The degree to which InfoCard support will be carried forward and refined in future releases of DACS depends primarily on the feedback and support that DSS receives from DACS users.

The article is not intended to be a comprehensive treatment of Information Cards, but rather an investigation of them from the standpoint of DACS; unlike most writings on InfoCards, this is not a Windows-centric position and it is intended to neither promote nor denigrate InfoCards. The likely audience of this article are those with some experience implementing or deploying web-based authentication who would like to understand how they can apply Information Cards. This document assumes some familiarity with DACS and its authentication capabilities. Visit dacs.dss.ca for an overview of DACS and complete technical documentation for the latest release, including the latest revision of this document.

Corrections and suggestions for improvement are welcome.

A Concise Overview of InfoCards

Information Cards (also InfoCards, I-Cards, or i-cards) are "personal digital identities that people can use online". More precisely, an InfoCard is a graphical representation of a digital object that a user can employ to request cryptographically secure tokens, containing specific information, from a provider associated with the InfoCard. An Identity Selector is client software that provides the user interface to InfoCards, managing their creation, storage, review, update, deletion, import/export, and selection. Windows CardSpace [1, 2] is Microsoft's Identity Selector for the Identity Metasystem. It is currently available with Windows XP (with .NET Framework 3.0 and successors), Windows Server 2003, Windows Vista, and Windows 7 (on Windows XP, the InfoCard management utility is found in the Control Panel folder). Other Identity Selectors have also been written, such as Bandit, Higgins, and Azigo (apparently defunct) ^***.

One of the main goals of the Identity Metasystem is to put the release of identity information under the direct control of computer users while at the same time respecting the right of a server or application to indicate what information it requires.

There are three roles within the Identity Metasystem:

1. Identity Providers, which issue digital identities; these identities might be issued by businesses, governments, and organizations (these are represented by Managed Information Cards or Managed InfoCards), or an individual may create his or her own digital identities, called Self-Issued Identities and are represented by Self-Issued Information Cards (or Self-Issued InfoCards or Personal Information Cards).
2. Relying Parties (or Service Providers), which require identities; these are servers or other online services that rely on identities that have been issued by Identity Providers (IPs or IdPs).
3. Subjects, which are the individuals (and other entities) that are referred to by digital identities.

Based on the Identity Selector Interoperability Profile (ISIP) 1.5 (or 1.0), identities are represented and requested using claims (attributes). In the case of Self-Issued InfoCards, the claims are filled in by the user and limited to "phone book" kinds of information (name, address, phone numbers, email address, date of birth, gender). Custom claim types are also allowed by the InfoCard format; CardSpace does not allow the format of its Self-Issued InfoCard to be modified, however. Managed InfoCards may have arbitrary claims. An InfoCard also includes a software-generated Private Personal Identifier (PPID) that uniquely identifies a subject to a particular Relying Party (RP) and which is different for that subject for each Relying Party (that is, if an InfoCard is used with Relying Party R1 more than once, the same PPID will be given to R1 each time; if that InfoCard is also used with Relying Party R2, a PPID different than the one sent to R1 will be sent, although it will be the same PPID each time).

When an InfoCard-enabled server or application (a Relying Party) requires claims about the user:

1. The Relying Party produces a web page containing an OBJECT element that uses parameters (via the PARAM element) requiredClaims and optionalClaims to list mandatory and optional claims, respectively; both parameters are optional and consist of a space-separated list of claim types^***. Newer releases of Microsoft's Internet Explorer browser understand the HTML OBJECT tag and start the user's Identity Selector interface^***. Extensions exist to enable Firefox [3, 4, 5] and Safari browsers to invoke an Identity Selector.

   This simplified HTML fragment illustrates a form that a Relying Party might embed in a web page to enable sign-on; when activated by a user, InfoCard-based authentication will be initiated in a suitably enabled browser, which will execute the user's Identity Selector interface so that an InfoCard can be selected by the user and causes a token to be generated and submitted to the Relying Party:

   <form name="login_form" method="post" action="/cgi-bin/infocard_login">
   <table>
   <tr>
   <td>
    <img src="ic_image.jpg" onClick="login_form.submit()"/>
   <object type="application/x-informationCard" name="xmlToken">
    <param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion">
    <param name="issuer" value="http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self">
    <param name="requiredClaims"
           value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier">
   </object>
   </td>
   </tr>
   
   <tr>
   <td><input type="submit" name="infocard_login" value="Login"/></td>
   <td></td>
   </tr>
   </table>
   </form>
   

   By convention, the parameter named xmlToken provides the security token. The issuer parameter in the example specifies that a Self-Issued InfoCard is needed and the tokenType asks for a SAML token. All parameters are optional.
2. The user agent interacts with the Identity Selector to display all of the user's stored identities (InfoCards) that could satisfy the request.
3. The user may select an identity from among the listed InfoCards, causing the Identity Selector to contact the issuer of the identity to obtain a digitally signed XML security token from an associated Secure Token Service (also called a Security Token Service, IP/STS, or STS) that contains the requested information; in the case of a self-issued identity, this may effectively be the Identity Selector itself, which can include an internal Simple Identity Provider (SIP). Although the technology can be used to manage the exchange of any kind of security token, a Self-Issued InfoCard must use the SAML format. Where communication between the Identity Selector and Relying Party occurs over https, the token is encrypted by the Identity Selector with a randomly generated symmetric key, which in turn is encrypted using the Relying Party's public key, which is taken from its X.509 certificate [6, 7].
4. The Relying Party decrypts (if necessary) and validates the returned token, and then extracts the claim values.

DACS Authentication

DACS presents a modular, composable, and run-time configurable authentication framework. The DACS distribution currently includes over a dozen different authentication methods. New authentication methods are relatively easy to add, configure, and test, making DACS well-suited as a testbed for their evaluation and deployment.

Although DACS is primarily used to control access to assets based on who is requesting access, it is not necessary to authorize access predicated on the identity of the requester. When the identity is important, a DACS administrator assumes the responsibility of configuring user authentication appropriately to meet the security requirements of his jurisdiction and federation. The suitability of a given authentication method must be weighed on a case-by-case basis. The large selection of available authentication modules is in part due to a desire to leverage existing accounts for use with DACS, but also to allow each administrator to select authentication methods and styles with desirable security and practicality characteristics for given use cases.

For example, in some situations it is necessary to determine, with confidence, that a user is a particular individual, known a priori to a given site (e.g., the user is "Bobo Sample, Employee #123"). In other situations, it is entirely sufficient only to recognize an essentially anonymous user as that same individual each time he or she logs in. All that the latter situation requires is a unique digital identity at the given site.

Communication between users and DACS, and within DACS, usually is done over network connections that are made secure using the Secure Socket Layer Protocol (SSL) or Transport Layer Security Protocol (TLS) [SSL, TLS]

The vast majority of web-based systems employ username/password type authentication - figures of 81% to 99% have been claimed^*** - and therefore these methods are well-supported by DACS. Despite their popularity, a well-known drawback is that most users select poor passwords^***. Just as significantly, users typically employ the same password with more than one account^*** (the proliferation of accounts and their passwords is a different but related problem). This implies that if an attacker is able to obtain a user's password, whether through guessing, theft of a password file or log file, malware (such as keystroke logging), active or passive eavesdropping (e.g., a man-in-the-middle attack), spoofing (such as through phishing), or other means, it is likely that the password can be readily used by the attacker to gain access to the user's accounts at other sites. Have you ever accidentally typed a password for a different account when signing on to a web site? What do you suppose the site did with that invalid password?

Because of these weaknesses, the importance of authentication methods that do not require the user to merely submit a password to a Relying Party should not be underestimated. In addition to Information Cards, DACS provides other password-free authentication methods, such as SSL client certificates, grid-based one-time passwords, hardware tokens, and OPIE supplied via PAM.

Self-Issued InfoCards

For the Subject, a Self-Issued InfoCard is, by itself, primarily a convenience - it facilitates "one-click sign-on" and the ability to efficiently resubmit commonly requested information. For an InfoCard-enabled server, it is essentially no different than employing a web-based form for user sign-on because:

• A Relying Party can specify required and optional claims, and a user may decline to provide all claims or any optional claims^***. Self-issued claims are presented by CardSpace as labeled fields with editable values.
• The standard format of a Self-Issued InfoCard does not include a prescribed password field, or even an "account name" or "username" field. It is limited to "phone book" types of fields, such as address, phone numbers, and such.
• The claims contained within a Self-Issued InfoCard are not verified in any way on behalf of Relying Parties; that is, a user is free to specify any input for any field, providing it is syntactically valid according to the Identity Selector Interoperability Profile. Therefore, a Relying Party that receives a token obtained from a Self-Issued InfoCard cannot assume that any of the information that is provided about the Subject is accurate, including the Subject's name, address (location), and email address. Furthermore, two or more different users can each generate almost identical InfoCards, differing only in their PPIDs.
• A Self-Issued InfoCard may be freely edited by its owner, even after creation or use, (subject to schema conformance, although almost all claims are represented as simple character strings), and an owner may create two or more virtually identical Self-Issued InfoCards; with CardSpace at least, a user may provide semantically invalid claim values for most fields (such as an illegal email address).

Any user can create multiple Self-Issued InfoCards, which may be identical except for their PPIDs. If PPIDs are used to map users to their accounts at a server or application, it is possible for many PPIDs to map to the same individual. This complicates account management. Because a Self-Issued InfoCard may be deleted by its owner at any time, depending on how servers and applications use InfoCards, this may mean that a user can effectively delete an account without the site's knowledge since the PPID for a deleted InfoCard will no longer map to any individual. Furthermore, Self-Issued InfoCards may easily be shared by multiple users on the same computer, and they can be freely duplicated.

Because of these characteristics, in general, a Self-Issued InfoCard is by itself unsuitable for secure authentication purposes. They may be appropriate in situations with weak security requirements, or where no access protection is required.

Use cases for Self-Issued InfoCards within DACS might be categorized as follows:

1. Account-less operation
   This usage class does not use InfoCards for authentication purposes, and therefore access is essentially anonymous. Rather, no server-side account exists and the information provided by an InfoCard is used only for gathering possibly inaccurate site visitation data, such as for a "guest book", or for immediate processing (such as to send a copy of the document currently displayed in the user's browser to the email address found in the submitted InfoCard).
2. User-driven account creation
   A user-driven account is a "self-service" account that is created automatically, typically without restriction and without an a priori association between the user and the site. The PPID is effectively used as the account identifier. Abandoned or lost accounts on the server or application side are not an issue, perhaps they have a limited lifetime or are automatically deleted for inactivity. Having registered his InfoCard, a user may subsequently identify himself to the site and sign on simply by resubmitting the InfoCard. Deleting the InfoCard loses access to the account. Although this usage class is also essentially anonymous, it allows users to be recognized at a site with a "one-click sign-on". An appropriate use is to allow users to set preferences that can be remembered by the site between visits (e.g., preferred language).
3. User-driven account creation with verification
   This usage class, which is an enhancement of the previous one, applies an additional registration step to confirm that some or all of the information submitted through an InfoCard is "correct", although the "true" identity of the user might not be revealed to the site. A common method is to send a confirmation message to the purported email address; to activate the account, a user must send a reply from that email address or invoke a special URL provided within the confirmation message. Alternatively, a telephone-based confirmation method might be applied. The confirmed information may be used as the account name instead of the PPID, or for account recovery. By using an InfoCard field (other than the PPID) as the account name, for instance a verified email address, it is easier to allow a user to associate a new InfoCard with the account, or use multiple InfoCards. Different users may put the same email address in their InfoCards, however, so it might be necessary for site to enforce their uniqueness, or to use the pair consisting of the PPID and the email address as the account name.
4. User-driven account creation with password
   This usage class corresponds to the password-based authentication method that is commonly used by e-commerce sites. During the registration step, the user is required to select a suitable password in addition to an InfoCard. To sign on, the user must provide the registered InfoCard and password. The password gives the site a level of confidence that the user who created the account is logging in, although it may not know who that user is. The password helps to protect against different users submitting the same InfoCard; this might happen if they share a computer, for example. In essence, the PPID acts as the username. This class may also use the confirmation step described previously.

   If the password can be added to an InfoCard, it can be submitted automatically, otherwise an obvious disadvantage of this usage class is that a user must type it into a sign-on form. Requiring a user to enter a password during each sign-on defeats one of the goals of InfoCards, however (see Password Card).

   A site willing to bend the rules for using InfoCards in exchange for user convenience might consider some alternatives. The user's password could be submitted by using (or misusing) an unused field in an InfoCard (e.g., as the "web page" claim type); doing so would print the password during InfoCard display and editing, however. A method of providing the password indirectly could be developed (e.g., by adopting the convention that the web page claim type is a URL that the Relying Party can use to securely fetch the password). A variation of the preceding approach would have the site provide a new registrant with a unique secret that the user is instructed to add to his InfoCard; for example, he might be required to replace the surname field in the initially submitted InfoCard with the specified string, which the site might consider to be a password or merely an account identifier; subsequent logins to the site, using the modified InfoCard, would be automatic. This would result in a site-specific Self-Issued InfoCard - one that should only be sent to a particular site - and the user must take care to select the correct InfoCard during sign-on. A user can assign a distinct name and image with each InfoCard and the Identity Selector can help to avoid errors, however.

   It is arguable whether any of these unconventional approaches are better or worse than having a user type a password, and perhaps writing it down.

5. Site-moderated account creation
   In this category, an InfoCard is associated with an existing account, and whatever authentication method used to gain access to the account is retained. Consequently, either the original sign-on method or the InfoCard can be used to log in to the site. Use of the InfoCard depends on the underlying account being in good standing and the mapping between the InfoCard and the account being valid. Modification or deletion of the mapping can be done by the user after signing on using the normal authentication method.

An additional use case category is to use Self-Issued InfoCards to strengthen another authentication method, effectively introducing an additional authentication factor. In addition to processing a Self-Issued InfoCard as previously described, an HTML FORM element that submits a security token to DACS could require additional authentication material; for example, a one-time password from a hardware token might be required. This can yield a multi-factor authentication method.

Note that for the same reason secure systems do not store plaintext passwords, a Relying Party must not store PPIDs in a form that could make them useful to an attacker.

Although each usage class outlined above has advantages and disadvantages, and different implementation demands, all but the last either have significant security or usage weaknesses that make them appropriate only for applications with very weak authentication requirements.

Using Self-Issued InfoCards for DACS Authentication

In view of the preceding analysis, and the typical usage of and support for authentication methods within DACS, this section outlines how Self-Issued InfoCards can best be used by DACS. The goal is to provide DACS administrators with flexible options for using Self-Issued InfoCards to provide a simplified user sign-on method with well-understood security implications and minimal administrative requirements.

Briefly, the recommended approach allows an authorized user, already having a suitable account (DACS identity) at a jurisdiction, to associate a Self-Issued InfoCard of his or her choice with the account. After an authenticated user successfully self-registers an InfoCard at a jurisdiction, the user can later click on the jurisdiction's InfoCard logo and be automatically authenticated, provided the normal authentication conditions are satisfied (i.e., the associated account is enabled, the identity's access has not been revoked, no errors occur, and so on). As before, a user may sign on using an existing authentication method. Use of this capability is optional at any jurisdiction, and a jurisdiction is free to impose whatever restrictions it deems necessary.

There are three main variants of the method. The first two require a new Self-Issued InfoCard user to be authenticated at the time the InfoCard is registered; i.e., the user must already have a DACS identity. After registration, the InfoCard will be associated with that identity. The third variant relaxes the requirement that the user be authenticated at InfoCard registration time.

Variant 1: Inherited Identity With Linked Accounts

In the first variant, the registered InfoCard is "linked" to a pre-existing account and may only be used as long as the pre-existing account is valid and enabled. The purpose of this is to simplify administration and recovery of an InfoCard account; if a user deletes or loses her InfoCard, if it becomes invalid for any reason, or if she needs to register a different card, she need only sign on using the linked authentication method and register a different InfoCard. The procedure is simple and no administrative intervention is required. An account suitable for this linkage is one in which DACS can test for the existence of the account without having to submit the user's password or any additional information. Currently available authentication methods that are suitable are Apache-based accounts (local_apache_authenticate), DACS-based accounts (local_passwd_authenticate), DACS-based accounts without passwords (local_simple_authenticate), and Unix-based accounts (local_unix_authenticate).

Variant 2: Inherited Identity Without Linked Accounts

In the second variant, it is not necessary for the pre-existing account to continue to exist and be valid after InfoCard registration. This allows any DACS authentication method (including the InfoCard method itself) to be used to "bootstrap" an InfoCard-based account. For example, an administrator might generate an rlink (or other type of temporary account) for the jurisdiction's InfoCard registration page and then send the URL (or temporary username/password) that it creates to a user via email. Having received the message, the user signs on, visits the registration page, and then registers his InfoCard, linking it to the DACS identity established at sign-on time. In this variant, the identity that the DACS administrator selects for the registrant is essentially a username (most likely generated randomly from a large identifier space) and the password is the InfoCard's PPID. Unlike the first variant, account management is left to the DACS administrator, however, because the user may not have an alternate authentication method at his disposal if he needs to register a different InfoCard; this can result in an accumulation of unusable accounts.

Variant 3: Self-Asserted Identity

The third variant does not require the user to be signed on at the time of InfoCard registration. Instead, a field of the submitted InfoCard, probably the email address or possibly the web page URL, is used as the DACS identity to associate with the InfoCard. While somewhat simpler from the user's perspective, because there is no alternate authentication method involved in the registration process, this variant is inherently weaker than the others. For some applications, however, this may not be a concern. Or, if the email address field is used as the identity, an email confirmation step may be undertaken before account creation to ensure that the user is actually associated with the email address (recall that just as when a user is required to enter an email address in an HTML FORM element, an InfoCard user is free to claim any email address, even someone else's or a non-existent or invalid address). Control over a web page URL may be similarly proven, for example by being requested to add a specified comment to it. In this variant, the email address (or web page URL) is essentially a username and the password is the InfoCard's PPID.

This variant has some disadvantages over the others. First, if the user changes the email address in her InfoCard, or if is deleted or becomes unusable, the user must repeat the registration process; the previous account will continue to exist but will be unusable. Second, some valid email addresses are not valid DACS usernames; unless the DACS administrator configures an appropriate mapping, these email addresses cannot be used for this purpose. Third, DACS does not provide any assistance for email address confirmation processing because of the complexity of doing it properly in the general case (system dependencies, managing outstanding registration applications, error handling, possibility of abuse and spam, etc.), so a DACS administrator must develop the procedures required to support this work flow out of the building blocks provided by DACS.

Discussion

The security of the new authentication mechanism hinges on the uniqueness and secrecy of an InfoCard's unique PPID, as well as the negligible probability that an attacker can guess it. This is ensured by the InfoCard specification, secure communication between the parties (which might be provided by SSL-based communication between a user's browser and a DACS-enabled web server, for instance), and secure storage of InfoCards, both in their digital wallets and in the mappings maintained by DACS. An inherent weakness of InfoCards is that they are not necessarily PIN-protected, so any user of a computer with access to an InfoCard may use it; Relying Parties are not told whether a submitted InfoCard was PIN-protected [Bohren]. If the user account requires a sign-on password, then the card store is encrypted with it. Also, a Self-Issued InfoCard may be easily duplicated and shared.

Note that the InfoCard model is also applicable in situations in which no Relying Party certificate is available (i.e., web sites that use the http scheme). InfoCard issuers can prohibit the use of cards at Relying Parties that are not identified by a certificate. The Identity Selector Interoperability Profile "highly recommends" using extended validation X.509 certificates, as opposed to regular SSL server certificates, to identify the organization associated with the Relying Party. It is important to understand that in exchange for giving up SSL, important security features are lost, including confidentiality and protection against man-in-the-middle, spoofing, and replay attacks. Regardless of whether https is used, the token that is returned to a Relying Party is digitally signed, to protect against alteration and to authenticate the signer, and dated, to offer resistance against replay attacks. To maintain a secure environment, DACS generally requires that the https scheme be used over all untrusted communication channels.

As an example of the content and relative complexity of a SAML token, the following token was sent to a Relying Party (DACS, in this case) from CardSpace over http. Text has been elided and it has been formatted for clarity.

<?xml version="1.0" encoding="UTF-8"?>
<saml:Assertion
    xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
    AssertionID="SamlSecurityToken-64ada613-1618-4035-aada-b9d1b62bc967"
    IssueInstant="2008-12-03T02:37:19.037Z"
    Issuer="http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self"
    MajorVersion="1"
    MinorVersion="1">
  <saml:Conditions
      NotBefore="2008-12-03T02:37:19.037Z"
      NotOnOrAfter="2008-12-03T03:37:19.037Z">
    <saml:AudienceRestrictionCondition>
      <saml:Audience>http://bsd6.dss.ca/cardspace.html</saml:Audience>
    </saml:AudienceRestrictionCondition>
  </saml:Conditions>
  <saml:AttributeStatement>
    <saml:Subject>
      <saml:SubjectConfirmation>
        <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Attribute
        AttributeName="givenname"
        AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims">
      <saml:AttributeValue>Tarah</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute
        AttributeName="privatepersonalidentifier"
        AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims">
      <saml:AttributeValue>gEHi+NbJ36Pc+INz8Q9W+Fzo+IKrluSDIZQVAIHBfjU=</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
  <Signature
      xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      <CanonicalizationMethod
          Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></CanonicalizationMethod>
      <SignatureMethod
          Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></SignatureMethod>
      <Reference
          URI="#SamlSecurityToken-64ada613-1618-4035-aada-b9d1b62bc967">
        <Transforms>
          <Transform
              Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform>
          <Transform
              Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform>
        </Transforms>
        <DigestMethod
            Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
        <DigestValue>BDErLaLIpItueux3zx6rG4GWImU=</DigestValue>
      </Reference>
    </SignedInfo>
    <SignatureValue>GCO1d/kum90NwnogOunIuZ1atnGAb21kxA0Wl/+HLncejYGwXe7L/cHQdvCftKuxz1fNCF7FRg8rposltvZxXRMCD2Xw==
    </SignatureValue>
    <KeyInfo>
      <KeyValue>
        <RSAKeyValue>
          <Modulus>u917ypU/KJ9Fe9USUSA3jaTIGF4lfKv6bxTHLrAoFjPXI9DAdG3Qt6ibMW6nicwZ8Jd8kIX3+1TPHbVtsw==
          </Modulus>
          <Exponent>AQAB</Exponent>
        </RSAKeyValue>
      </KeyValue>
    </KeyInfo></Signature>
</saml:Assertion>

The following encrypted SAML token, also with text elided and reformatted for clarity, was sent to a Relying Party (DACS, in this case) from CardSpace over https:

<?xml version="1.0" encoding="UTF-8"?>
<enc:EncryptedData
    xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
    Type="http://www.w3.org/2001/04/xmlenc#Element">
  <enc:EncryptionMethod
      Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"></enc:EncryptionMethod>
  <KeyInfo
      xmlns="http://www.w3.org/2000/09/xmldsig#">
    <e:EncryptedKey
        xmlns:e="http://www.w3.org/2001/04/xmlenc#">
      <e:EncryptionMethod
          Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
        <DigestMethod
            Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
      </e:EncryptionMethod>
      <KeyInfo>
        <o:SecurityTokenReference
            xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
          <o:KeyIdentifier
              EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
              ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1">yemfw</o:KeyIdentifier>
        </o:SecurityTokenReference>
      </KeyInfo>
      <e:CipherData>
        <e:CipherValue>H6mGix81dVcoSc3uxTrJEtKuVAkVv7ZMCz7KRRvZwsgjz0STdoL4P7f5CrUL8/iLSgdZ/o+Xv0Xz+pmptat3ctofkAA
        </e:CipherValue>
      </e:CipherData></e:EncryptedKey></KeyInfo>
  <enc:CipherData>
    <enc:CipherValue>xox4t+TH1FTx4fiLGUB/nc1jFSQmKd/4OKnxTcf3JkGzx+u2uMFspIYlR9w
    </enc:CipherValue>
  </enc:CipherData>
</enc:EncryptedData>

The following describes the "pre-authenticated" use case for Self-Issued InfoCard registration and usage in more detail:

1. A jurisdiction creates a DACS-wrapped InfoCard registration page; only authenticated users with access to the page may register and use a Self-Issued InfoCard. The page describes its purpose and presents instructions on how to proceed with registration and how the user's InfoCard can be used to sign on after successful registration. The same page is used by a user who has already registered but wants to register a different InfoCard. (A possible future extension is to allow a user to register multiple InfoCards.)
2. By clicking on a "Register" button, the user engages in a dialogue with his Identity Selector and chooses an InfoCard to be associated with the jurisdiction. This may be an existing InfoCard, or one created by the user specifically to sign on at the jurisdiction.
3. If the user's interaction with his Identity Selector is successful, a registration form is submitted to the jurisdiction, running a DACS-wrapped registration application (with the same authorization constraints as the registration page) that processes the user's request for Self-Issued InfoCard registration. The application creates a mapping from the InfoCard's PPID to the user's current DACS identity (which must be relative to the jurisdiction at which registration occurs). If a mapping already exists, it is replaced by a new mapping.
4. A DACS utility similar to the dacspasswd(1) command is provided to allow an administrator at the jurisdiction to perform maintenance operations on the InfoCard mappings. Mappings can be listed, deleted, enabled, disabled, and so on.
5. The jurisdiction will provide an InfoCard sign-on logo, placing it either on an existing authentication page or on a new page created specially for the purpose. When a user submits his registered InfoCard to the jurisdiction, dacs_authenticate(8) validates the mapping, according to the configuration found in dacs.conf, and create new credentials for the associated identity, which are returned to the user without any additional interaction.
6. The method for obtaining roles that are associated with the DACS identity, if any, must be configured as a separate step in the authentication procedure in the usual way.
7. All subsequent DACS interactions, including sign off, are the same as if any other DACS authentication method had been used.

DACS credentials include an attribute that describes the authentication method that was used to establish the identity named therein. Access control rules can therefore test whether authentication was based on a Self-Issued InfoCard, and any jurisdiction is free to reject these credentials.

Implementation

The prototype implementation involves a new DACS authentication module (local_infocard_authenticate), extensions to DACS configuration processing so that an administrator can specify how the new authentication module is used, and minor modifications to the format of DACS credentials (unfortunately, these modified credentials will not interoperate with earlier releases of DACS). A new DACS web service, dacs_infocard, creates or updates the mapping between a valid InfoCard and a DACS identity. A new utility command, dacsinfocard, is used by an administrator to manage InfoCard-based accounts. Similar in purpose to dacspasswd(1), it is also capable of parsing, validating, and extracting information from an InfoCard token, allowing custom account registration and authentication procedures to be developed based on InfoCards.

To support authentication via Self-Issued InfoCards, the section of dacs.conf for the demo jurisdiction INFOCARDS includes the following directives:

VFS "[infocards]dacs-kwv-fs:/usr/local/dacs/federations/dss.ca/INFOCARDS/infocards?field_sep=:"
INFOCARD_DIGEST             "SHA256"
INFOCARD_USERNAME_SELECTOR  "credentials"

<Auth id="passwd">
  URL     "local_passwd_authenticate"
  STYLE   "pass"
  CONTROL "sufficient"
</Auth>

<Auth id="infocard">
  URL     "local_infocard_authenticate"
  STYLE   "infocard"
  CONTROL "sufficient"
</Auth>

The current version of the prototype performs all of the required or recommended validity tests on a SAML token (such as verifying the digital signature) and includes infrastructure to do the remaining one (tracking the usage of each token to protect against replay attacks). These security measures require a variety of "heavyweight" supporting technologies, including Canonical XML, Exclusive XML Canonicalization, XML Signature Syntax and Processing (for RSA-based signatures), XPath, and others. To avoid a substantial and ultimately unnecessary implementation effort, libxml2 and xmlsec1 libraries are used; both are released under the MIT open source license.

A token sent to a Relying Party over https is encrypted using XML Encryption Syntax and Processing, using the public key taken from the Relying Party's X.509 v3 certificate. The Relying Party must decrypt the token, validate its message structure (e.g., as a SAML token), protect against token replay attacks, validate message conditions (checking that its validity period is still in effect, taking clock skew into account, and verifying that this Relying Party is the intended recipient of the token), validating the digital signature, and checking that the required information fields are present and valid.

The design and implementation of the prototype are subject to change.

Demonstration 1: Self-Issued InfoCards

A micro-site has been created to demonstrate a prototype implementation of DACS authentication using Self-Issued InfoCards. Instructions are provided there. SSL is used in the demonstration. The prototype does not verify that the linked account exists and is enabled; a production version might do so, however. Ignore any security warnings from your browser when you first visit the demo site. Review the information at the beginning of the page.

Begin the demonstration by creating a Self-Issued InfoCard on one of the supported platforms, or use an existing Self-Issued InfoCard if you have one. It does not matter what information you put in your InfoCard, except that you must provide an email address. Next, using a browser that supports InfoCards on one of the supported platforms, visit the demonstration home page and proceed to the Self-Issued InfoCard demo.

Managed InfoCards

From the user's perspective, Self-Issued InfoCards and Managed InfoCards are used at a Relying Party (e.g., to sign on) in essentially the same ways, and the average user may not recognize which type she is working with. There are, however, some important differences:

• Rather than being created and populated by the user, Managed InfoCards are obtained from an Identity Provider (IdPs), over a secure channel, and imported by the user into her Identity Selector.
• The user is not able to modify a Managed InfoCard; she may only add, replace, delete, or select it (CardSpace automatically replaces an older instance of a Managed InfoCard with an updated one).
• An Identity Provider may provide an image for an Identity Selector to display to represent the Managed InfoCard. The image may include a readily recognized logo, trademark, etc. to facilitate rapid identification and selection of the card by a user.
• The structure of the SAML tokens that a Relying Party can receive from the two types of InfoCard are quite different in several important respects, and whereas the former tokens are created by a user-managed Simple Identity Provider (SIP) as the Security Token Service (STS), the latter are created by a third-party managed one. Although it may not be a common use case, an individual can provide her own Managed InfoCard.

• Managed InfoCards specify one or more IP/STS endpoint references in a prioritized list. Each endpoint reference indicates how an Identity Selector contacts an IP/STS and the Security Policy that determines how the Identity Selector must authenticate itself to the IP/STS If an Identity Selector is unable to successfully complete its request for security token operation (RST) with one endpoint, it will try the next endpoint in the ordered list^***. The Identity Selector may request a "Display Token" from the IP/STS, which is a representation of the claims carried by the security token that can be displayed to the user; before the token is submitted to the Relying Party, the Identity Selector can display the claims that will be sent with the token, giving the user the opportunity to abort the transaction or select a different InfoCard. CardSpace initiates this operation when either the "Retrieve" or "Send" buttons are pressed. This authentication step, which must be secured either by SSL or message-level security, prevents a stolen Managed InfoCard from being immediately useful to an attacker. It is the Identity Provider that chooses the authentication method to be used by specifying one of four supported "credential types" in the Managed InfoCard:

  • UsernamePasswordCredential
    A configurable prompt is displayed and the user is required to provide a username and password (a username may be embedded in the Managed InfoCard). This username and password could be the same as for an existing account of the user's or it could be for a new account created specifically for this purpose. An empty password is allowed. This form of authentication obviously foils one-click sign-on; other methods of Identity Selector authentication can be chosen that do not require prompting, so user interaction is not mandatory.
  • X509V3Credential
    An X.509 client certificate, which was previously registered with the IP/STS, is submitted to the IP/STS. The certificate used for this might be one sent automatically by https when the user launches the Identity Selector or it might be stored on hardware-based smart card. Self-signed SSL certificates (which may be created using OpenSSL) can be used. These Managed InfoCards are sometimes said to be "backed by a certificate" or "backed by a smartcard".
  • SelfIssuedCredential
    This method requires that a Self-Issued InfoCard previously registered with the STS must exist in the user's card store. If this InfoCard is found in the user's card store, then the Identity Selector for the Managed InfoCard will not prompt for authentication unless that Self-Issued InfoCard is locked with a password.
  • KerberosV5Credential
    A Kerberos V5 service ticket for the IP/STS is required.

  The specification allows new methods to be added, although of course they must be understood by the Identity Selector.

  Additional authorization methods, such as DACS access control rules, may be useful.

Although it is possible to achieve, the primary benefit of Managed InfoCard is not necessarily to facilitate convenient "one-click sign-on", as it is for Self-Issued InfoCards. Rather, they provide a secure, distributed mechanism for Identity Providers to supply arbitrary information to Relying Parties in a user-centric fashion. From both an architectural and implementation standpoint, whereas Self-Issued InfoCards give simpler though constrained access to InfoCard technology, Managed InfoCards expose highly flexible, configurable, and versatile mechanisms for user-centric information sharing.

It is possible to create a Managed InfoCard that has the same claims as a Self-Managed InfoCard. In essence, a Self-Managed InfoCard is only a simplification or special instance of a Managed InfoCard rather than being fundamentally different.

Discussion

Here are some additional points about Managed InfoCards:

• The credential material used in the authentication step is not visible to the Relying Party; it only has access to the resulting token, if approved by the user, and containing only those optional claims released by the user^***. Recall that SSL is not required between the user's browser and the Relying Party.
• A Managed InfoCard, which is generally not administered by the user, can be revoked by its Identity Provider at any time.
• The claims returned to a Relying Party need not be static (e.g., it could return an "Age" claim).
• For privacy reasons, the identity of the Relying Party is not automatically revealed to an Identity Provider, although an Identity Provider may request it.
• An STS may return a security token in any format requested by the Relying Party that the STS understands. The Identity Selector Interoperability Profile specifies that SAML tokens must be used with Self-Issued InfoCards. A specification for an OpenID token type is being developed, and Managed InfoCard demonstrations sometimes use an ad hoc (custom) token format.

A user's authentication procedure via a Managed InfoCard can be simplified, enriched (e.g., user preferences might be specified), and made more secure, but these advantages come at the expense of having to administer Managed InfoCards at the Identity Provider and distribute them to users over secure communication channels. While the two types of InfoCard are used at the Relying Party's server in mostly the same ways, there are some differences:

• The Identity Provider may customize the format of the Managed InfoCards by adding claims, and increase accessibility to configurable token generation options and parameters while maintaining security; that is, while the contents of a Self-Issued InfoCards are constrained but in the hands of the user, the contents of a Managed InfoCard are under the control of the Identity Provider, within the limits of the Managed InfoCard schema. At selection time, a user is still able to decide whether a Managed InfoCard should be used by a given Relying Party and whether optional claims should be passed to it.
• Because the "payload" of a Managed InfoCard token can be customized, it can contain any information that can simplify server-side software and its administration at a Relying Party, since that information is maintained at the Identity Provider. There is no limitation to identity-related claims (such as a username) and user characteristics and preferences (such as preferred language) - a Managed InfoCard may include any text-oriented attribute information.
• If its Security Token Service cannot be accessed by the Identity Selector, a Managed InfoCard cannot be used. A Managed InfoCard can specify an ordered list of STSs, however, and they need not require the same authentication method.

Users will tend to have one Managed InfoCard for each site or organization (or group of cooperating sites or organizations) that supports them. As more Relying Parties accept Managed InfoCards from a given Identity Provider and understand and honour claims produced by it, the more value users can derive from those InfoCards, however.

With CardSpace, a Managed InfoCard can be installed by the user from a capable browser by simply following a link, which may be associated with an illustrative icon. Alternatively, from the CardSpace user agent, a Managed InfoCard can be imported and installed from a file; they are transferred to the user from the Identity Provider in a signed file with the conventional extension ".crd".

InfoCard selection is triggered by a Relying Party in nearly the same way for both types. The user's Identity Selector is called by the browser. The user's selection of a Managed InfoCard causes the user's Identity Selector to contact the Identity Provider associated with the InfoCard to acquire a token. The token is submitted by the Identity Selector according to the Relying Party's HTML FORM element.

One proposed use case for Managed InfoCards is for credit card payments. In this scenario, a credit card company or bank is the Identity Provider, and a merchant is the Relying Party. Wanting to complete a purchase at the merchant's web site, a user might select an icon on a web page that causes her browser to trigger her Identity Selector. Choosing the "Pay by FoozleCard" Managed InfoCard, her Identity Selector will contact the Identity Provider associated with the InfoCard (i.e., a server operated by her bank or credit card company) to request a token. The token, which might contain identifying information and credit card details, is then submitted to the Relying Party to complete the transaction.

It is important to recognize that a Managed InfoCard's Identity Provider can be administered by a Relying Party; for instance, a DACS jurisdiction could act as both the Identity Provider for its Managed InfoCards and the Relying Party during user authentication based on its Managed InfoCards. Or, a DACS federation might run a central Identity Provider for its users, with any InfoCard-enabled jurisdiction able to function as a Relying Party.

Though differing in many architectural and structural details, Managed InfoCards (or perhaps more accurately, their tokens) are conceptually similar to X.509 client certificates [RFC 5280, SSL]. Both are formally described, cryptographically secured, extensible digital objects that can be used to represent an identity within a framework of trust. One notable difference between the two is that InfoCards (both Self-Issued and Managed) are primarily intended for interactive use (although apparently non-interactive use via delegation is not disallowed). Importantly, the CardSpace Identity Selector presents a much more user-friendly interface to InfoCards than do the popular browsers for X.509 client certificates; use of client certificates is effectively limited to sophisticated users, although automatic installation of a client certificate from a web page is possible. It is not necessary to use an SSL connection between the user and the Relying Party with InfoCards; this is not the case for client certificates.

DACS includes an authentication method for X.509 client certificates used with SSL. Self-signed certificates may be used for this purpose. DACS does not currently offer any assistance with respect to creating client certificates, but this procedure could be partially or completely automated (a user submits a request for an X.509 client certificate and the certificate is loaded into the user's browser by returning the certificate to the browser as the MIME type application/x-x509-user-cert).

Using Managed InfoCards for DACS Authentication

Because they address many of the deficiencies of Self-Issued InfoCards, Managed InfoCards are a more suitable basis for secure authentication methods. Where a Relying Party administers its Identity Provider, it can create a Managed InfoCard for a specific individual and verify the integrity and validity of the InfoCard token when it is submitted for authentication purposes.

As with many authentication methods, an apparent drawback of Managed InfoCards is that either they provide only one authentication factor ("something you have") or their use necessarily involves user interaction. If demonstration of its possession is sufficient to authenticate, therefore, anyone who gains access to a Managed InfoCard, such as by copying it or stealing the storage device or laptop where it is stored, can then use it to assume the corresponding identity. For this reason a Managed InfoCard should always be password protected. Another drawback of Managed InfoCards with respect to security is that they are easily copied and shared (techniques to ameliorate this problem, such as restricting a Managed InfoCard to being used from certain IP addresses, tend to have their own problems). There is no way for a Relying Party to know what security methods were applied during the sequence of events that preceded submission of the token.

The use cases for Managed InfoCards by DACS, where it provides IP/STS functionality, might fall into three general categories:

1. Minimally interactive sign-on, SAML token
   By using either the X509V3Credential or SelfIssuedCredential authentication methods with a Managed InfoCard, interaction with the user can be minimized. The former method requires the user to obtain and install an X.509 client certificate on his system (or to present a credential embedded within a smart card) and then register it with the Identity Provider at the time the InfoCard is requested; this can be a self-signed certificate. The latter method requires the user to create a Self-Issued InfoCard and register it with the Identity Provider (and save it as long as the Managed InfoCard is required). In practice, several user actions may be required to authenticate in addition to selecting the appropriate Managed InfoCard, but this use case provides maximum convenience for the user. Unfortunately, the preparations necessary for either of these methods are likely beyond the capabilities of many users or will be felt to be too inconvenient by them.
2. Username/password authentication, SAML security token
   There are at least two possible sub-cases: leveraging users' existing account information or creating a new kind of account. In the former, an existing DACS identity that is associated with a non-online, password-based authentication method (such as Unix accounts, Windows NTLM-based accounts, LDAP-based accounts, basic Apache accounts, CAS-based accounts, and others) can have a Managed InfoCard "tied" to it. The user would be required to provide this username/password to authenticate to the IP/STS. The InfoCard includes appropriate prompting text (e.g., "Please enter your Unix password") and a specification of the DACS authentication procedure that is required for this user. DACS, acting as the Identity Provider for its Managed InfoCards, invokes the specified authentication module with the username and password given by the user and returns a SAML security token if authentication succeeds. When it receives a valid security token from the Identity Selector, DACS knows that the user must have already been successfully authenticated and it can issue new credentials. This sub-case maintains many of the advantages of InfoCards (anti-phishing characteristics, common look and feel at authentication time, customizable claims, and so on), but having to enter the username/password of an existing account negates the convenience factor promised by InfoCards.

   As an alternative, a new account type could be created for this purpose. A user with multiple Managed InfoCards (having the same IP/STS) would use the same username/password regardless of which InfoCard he selected. Despite that advantage, this alternative contributes towards the proliferation of accounts and seems like a step in the wrong direction. It is possible to support a fixed password string, including no password string at all.

3. Strengthening authentication by requiring a Managed InfoCard as an additional authentication factor
   In addition to processing a Managed InfoCard as described in a previous use case, an HTML FORM element that submits a security token to DACS could require additional authentication material; for example, a one-time password from a hardware token might be required. This would result in a multi-factor authentication method.
4. Custom security tokens
   Instead of using a SAML security token, DACS could use a light-weight token of its own design in conjunction with one of the previously described approaches. Since DACS should offer support for both Self-Issued InfoCards and Managed InfoCards, however, and since the former requires the Relying Party to understand SAML security tokens (and this has already been implemented for DACS), custom security tokens will not be considered until further investigation can justify the extra implementation effort.
5. Cross-federation authentication
   DACS includes several mechanisms to allow a user that can authenticate outside of his federation to obtain DACS credentials. This is a natural application of Managed InfoCards. If a user has a Managed InfoCard issued by another DACS federation or a non-DACS system (an Identity Provider), a DACS jurisdiction, acting as a Relying Party, can import an identity if it has a trust relationship with the Identity Provider. Similarly, other federations or systems may be willing to recognize a Managed InfoCard issued by DACS for user authentication.

In summary, authentication based on Managed InfoCards requires:

• Creation of a Managed InfoCard, by an Identity Provider, configured for the particular user.
• Acquisition and installation of the new InfoCard by the user (e.g., by following a link using a CardSpace-enabled web browser).
• Construction of a sign-on form at a Relying Party that will cause a security token to be submitted from the user's selected Managed InfoCard.
• Creation of an IP/STS endpoint, published in a Managed InfoCard, that will accept https requests for a security token (assuming either the username/password authentication method or the X.509 client certificate method is used by the Identity Selector), validate the authentication material accompanying the request, and respond with a security token or an error indication.
• Creation of a web-based service that returns DACS credentials when a valid security token is submitted to it.

Implementation

An early goal of the project was to make use of existing implementations as much as possible. But it proved surprisingly challenging to find an implementation of an IP/STS that:

• is open source with DACS-compatible open source licensing;
• handles Managed InfoCards (not just Self-Issued InfoCards);
• is neither a toy nor experimental (i.e., it is well-written, non-buggy, and documented code that is modular, complete, configurable, and includes adequate instructions in English);
• relative to the DACS distribution, does not depend on a burdensome amount of additional third-party software and does not require third-party software that is difficult to build or configure;
• is not bundled or integrated with excess or redundant functionality (i.e., it is not part of a larger authentication services package; a pure IP/STS package would be ideal);
• like DACS, is available for multiple Unix-type platforms or is platform independent;
• conforms to Identity Selector Interoperability Profile 1.5 instead of the older, obsolete version;
• implements an IP/STS that supports more than one authentication method (e.g., UsernamePasswordCredential is common, but X509V3Credential is less so);
• is not too difficult to integrate with DACS (e.g., it can easily be modified to work with DACS run-time configuration); and
• appears to have some degree of continuing development and support behind it.

Following a lengthy search, several candidates were considered:

• InformationCard-C, which implements support for Self-Issued InfoCards (C, New BSD License).
• simpleSAMLphp, which supplies InfoCard generation and IP/STS functionality (PHP plus extensions, GNU Lesser General Public License).
• Shibboleth, a web-based single sign-on system that can issue and use Managed InfoCards (C++ and Java, Apache 2.0 license).
• cardspaceauthn, an authentication module for OpenSSO, Sun's open Web access management project (Java, Common Development and Distribution License (CDDL)).
• A demonstration, by Rob Richards (PHP, BSD-style license).
• Carillon STS, written by Dave Coombs of Carillon Information Security Inc (PHP, GNU General Public License).
• SharpSTS (C#, Microsoft Public License (MS-Pl)).
• Higgins, The Bandit Project, DigitalMe (Java, Eclipse Public License).

After careful evaluation and testing, no single implementation was found to be suitable for use by DACS. Instead, code from various implementations was combined, rewritten, and customized to develop an initial prototype that consisted of four main components:

1. a web service and command-line utility for administering both Self-Issued InfoCards and Managed InfoCards, and supplying Relying Party functionality,
2. an Identity Provider application to create Managed InfoCards,
3. a WS-MetadataExchange responder web service (MEX), and
4. a secure token generator web service for the IP/STS.

Debugging this prototype was unusually difficult, due to the complexity of the layered protocols involved and the interactions among the components, and because CardSpace and the Windows SIP/STS often log very little useful information when an error occurs, making it very difficult to determine precisely what went wrong during a multi-step operation.

Once the initial prototype was functional, it was used to bootstrap native DACS implementations of the four components. Together with new DACS administrative and configuration capabilities, a completely new, integrated implementation of InfoCard support was created for DACS in ISO C99 C/C++ with GNU extensions. Currently standing at more than 10,000 lines of code and using over 31 configuration directives and variables, it is by far the largest and most complicated authentication module in the collection of some 14 DACS modules. Low-level support for Identity Provider authentication using UsernamePasswordCredential, X509V3Credential, and SelfIssuedCredential was written, and component configuration was harmonized with the DACS run-time configuration mechanism. Support for Managed InfoCards was added after Self-Managed InfoCard support by extending the prototypes (the DACS authentication module local_infocard_authenticate, the DACS web service dacs_infocard, and the dacsinfocard command) and adding new Identity Provider and Security Token Service functionality.

To the best of our knowledge, there is no comparable open source licensed implementation.

Managed InfoCard functionality is provided by the following components:

dacs_managed_infocard(8)

This web service creates a new Managed InfoCard, which may be downloaded directly to the user's Identity Selector; in an alternative mode, the card is written to an access controlled file to which the user is given a link. It has a "self serve" mode of operation, where a user can request a Managed InfoCard associated with the DACS identity sent with the request, and another mode where a privileged user can request a Managed InfoCard for a specified identity. In the simplest case, a new card has only two claims - the corresponding DACS identity and a PPID - and can be used for authentication via local_infocard_authenticate. Other claim management possibilities are available, however, including one in which dacs_managed_infocard may be configured to call a custom web service that is responsible for creating a record of the card and defining claims that are associated with it.

dacs_mex(8)

This is the WS-MetadataExchange responder.

dacs_sts(8)

This is an implementation of the Security Token Service. It is responsible for returning a secure token containing the claim values requested by the Relying Party. If a custom web service was used to define the Managed InfoCard's claims, another custom web service is called to obtain the claim values, otherwise only the default claim values (DACS identity and PPID) are available.

local_infocard_authenticate

This DACS authentication module, which acts on behalf of a Relying Party, is given a secure token. If the token is valid and contains a DACS identity (or DACS username, relative to the current jurisdiction), it returns successfully with the authenticated identity.

dacs_infocard(8)

This web service can be used by a Relying Party to validate a secure token or extract claim values from it.

Related configuration directives can be found in dacs.conf(5). Instructions for enabling InfoCard functionality at build-time are given in dacs.install(7).

In the prototype, Managed InfoCards are used as follows:

1. A user with an existing account authenticates himself to DACS and visits a Managed InfoCard registration page - access to this page is restricted to users authenticated by this jurisdiction. Although not currently supported by the prototype, authentication using an X.509 client certificate could be used and the X509V3Credential authentication method could then be used between the Identity Selector and the IP/STS.
2. Continuing, the user submits an HTML FORM to dacs_managed_infocard, to request a Managed InfoCard. After some validity checks, DACS, acting as the Identity Provider for the InfoCard, creates a registration record and generates a new Managed InfoCard.
3. If registration is successful, a new Managed InfoCard is returned to the user's browser as the MIME type application/x-informationCard, which causes the user's InfoCard-capable web browser to start his Identity Selector to store the new InfoCard.
4. The Managed InfoCard can now be used. The user may sign on at the DACS jurisdiction that registered his InfoCard, with DACS now acting as the Relying Party, by selecting a labeled link/icon on a sign-on page, which causes an HTML form to be submitted. This causes his InfoCard-capable web browser to start his Identity Selector. When a previously-registered Managed InfoCard is selected:
   1. dacs_mex is called by the Identity Selector to obtain endpoint metadata.
   2. dacs_sts is called by the Identity Selector to obtain a secure token containing claims requested by the Relying Party (specifically, a DACS identity). The UsernamePasswordCredential authentication method is used between the Identity Selector and the IP/STS. If authentication is correct, dacs_sts responds with a SAML token. The user's Identity Selector prompts the user to approve the claims encapsulated within the security token; the transaction can be approved or aborted.
   3. dacs_authenticate is invoked (because the HTML form was submitted) and is passed the secure token and other arguments required to authenticate the owner of the card in the current jurisdiction. It validates the token and the account associated with the Managed InfoCard. Either DACS credentials are returned or an error indication, and post-authentication processing is performed in the usual way.

As set out in the project requirements, development and testing was mainly performed on a Windows XP Professional SP2 platform using CardSpace as the Identity Selector.

To act as an IP/STS for Managed InfoCards, the section of dacs.conf for the demo jurisdiction INFOCARDS includes the following directives:

VFS "[infocards]dacs-kwv-fs:/usr/local/dacs/federations/dss.ca/INFOCARDS/infocards?field_sep=:"

INFOCARD_DIGEST    "SHA256"
INFOCARD_AUDIENCE "host dacs.dss.ca"
INFOCARD_AUDIENCE "prefix https://dacs.dss.ca/infocard-demo"
INFOCARD_AUDIENCE "regex/i dacs.dss.ca"
INFOCARD_MEX_URL "https://dacs.dss.ca/infocard-demo/cgi-bin/dacs/dacs_mex"
INFOCARD_TOKEN_ISSUER "https://dacs.dss.ca"
INFOCARD_ISSUER_INFO_ENTRY "ALabel:AValue!"
INFOCARD_STS_URL "https://dacs.dss.ca/infocard-demo/cgi-bin/dacs/dacs_sts"
INFOCARD_STS_AUTH_TYPE "passwd"
INFOCARD_IP_PRIVACY_URL "http://dacs.dss.ca/infocard-demo/managed_privacy.txt"
INFOCARD_STS_KEYFILE "/usr/local/apache2/conf/ssl.key/dacs.dss.ca.key"
INFOCARD_STS_CERTFILE "/usr/local/apache2/conf/ssl.crt/dacs.dss.ca.crt"
INFOCARD_STS_CACERTFILE "/usr/local/apache2/conf/ssl.crt/root.dacs.dss.ca.crt"
INFOCARD_STS_PASSWORD_METHOD "ignore"
INFOCARD_CARD_IMAGEDIR "/usr/local/apache2/dacs/htdocs/infocard-demo/managed_card_images"
INFOCARD_CARD_OUTPUTDIR "/usr/local/apache2/dacs/htdocs/infocard-demo/managed_cards"

INFOCARD_CARDID_BASE_URL "https://dacs.dss.ca/infocards/managed_cards"
INFOCARD_CARDID_SUFFIX "identity"

INFOCARD_CARD_DEFS_URL "https://infocards.dss.ca/cgi-bin/dacs/nfis_demo_card_defs.php"
INFOCARD_CARD_FILL_URL "https://infocards.dss.ca/cgi-bin/dacs/nfis_demo_fill_claims.php"

EVAL ${Conf::infocard_sts_title} = "DACS Managed InfoCard IP/STS"
EVAL ${Conf::infocard_card_image_passwd} = "dacs_username_password_credential.png"
EVAL ${Conf::infocard_sts_username_password_prompt_fmt} = "No password is required.  Click 'OK' to continue."

<Auth id="infocard">
STYLE "infocard"
URL "local_infocard_authenticate"
CONTROL "sufficient"
</Auth>

In this configuration, the InfoCard claims are defined, stored, and filled at another jurisdiction running on a different host.

The dacs_infocard(8) web service or dacsinfocard(1) command can be used to disable or delete an InfoCard registration, temporarily or permanently revoking use of the InfoCard for authentication. The general purpose DACS access control features may also be applied to InfoCards in various ways.

The design and implementation of the prototype are subject to change, and the prototype will be extended as the capabilities of Managed InfoCards with respect to DACS are better understood. Additional configuration directives and command line flags will no doubt need to be introduced for registering and generating Managed InfoCards, and accepting them for authentication.

Demonstration 2: Managed InfoCards

A micro-site has been created to demonstrate a prototype implementation of DACS authentication using a Managed InfoCards. The current version of the demonstration lets you create a Managed InfoCard that is associated with any of several identities at the demo jurisdiction. These Managed InfoCards are defined and "filled" by two custom web services. Only two claims (attributes): dacs_identity, which is the DACS identity of the user requesting a new card (relative to the jurisdiction running dacs_managed_infocard), and a PPID. After the card has been added to your Identity Selector, you can authenticate at the jurisdiction as the identity registered with the card. Instructions are provided on the web page.

Because the UsernamePasswordCredential authentication method is used between the Identity Selector and the IP/STS, you will be prompted for a username and password by your Identity Selector (presumably CardSpace) when you select a Managed InfoCard for authentication. The prompt should indicate that no password is actually required; simply click on "OK".

The demonstration may be temporarily unavailable from time to time due to development, testing, or system maintenance.

InfoCards and DACS: the Future

Microsoft began promoting Information Cards and CardSpace in 2005/2006 and continues to refine the technology with its new Geneva Framework, now called Windows Identity Foundation (for example, by improving support for the X.509 credential). Identity Metasystem Interoperability (IMI) version 1.0 was recently approved as an OASIS Standard. To date, however, few web sites have adopted InfoCards for sign-on, other than by developers for demonstration purposes [11, 12]. As another gauge of its popularity, searches for jobs linked to the terms "InfoCards", "CardSpace", or "Information Cards" return very few matches at this writing. Likewise, searches for books that match any of those terms also return a very small number of hits.

Information Cards offer important advantages over other authentication and identity (claim) distribution technologies, for users, implementors, identity providers, and relying parties. It does, however, face some challenges:

• Because CardSpace is available free of charge for recent editions of the ubiquitous Windows operating system, it is likely to be the Identity Selector that most people first see. But the current implementation is unattractive, slow and clunky to use, and interaction with it is unpleasant - it does not make a good first impression. On several occasions it was observed to crash on Windows XP. Unfortunately, there are few serious alternatives to it; even if CardSpace were better, this might be perceived as a bad omen. Users of Windows XP, of which there are still a great many, must download and install CardSpace, an inconvenience barrier that many of them will avoid.
• The freely-available Identity Selector add-ons that are available for Firefox and other browsers (which currently make up approximately 33% of all browser users) are not updated frequently; this apparent lack of support sends the wrong message to anyone concerned about the viability of the technology. Also, because they are an add-on to browsers other than Internet Explorer rather than an integrated feature, Information Cards are effectively unavailable to naive users, arguably the very users that could benefit most from them. It seems that there is no general, run-time method available for a browser other than Internet Explorer to determine whether an Identity Selector is present. All together, these leave the impression that Information Cards are a "Microsoft/Windows thing"; though partially true, this perception will cause some to reject the technology out of hand.
• For implementors, technical documentation (primarily the Identity Selector Interoperability Profile specification and related documents) is incomplete and poorly organized - it is necessary to hunt for information in an assortment of documents, forums, blogs, and examples. Implementation is challenging. As mentioned earlier, error logging on Windows is sometimes unhelpful, which increases the level of difficulty for developers of interoperable third-party software. The authors of the Information Card specification (Microsoft, effectively) should be circumspect about extending the functionality and complexity of the specification (and CardSpace), and should instead focus on simplifying it wherever possible. DACS support for Managed InfoCards tries hard to make utilization of the technology as easy as possible, and though there is no doubt room for improvement, an inherently steep learning curve remains.

Randall Stross says in his New York Times article Goodbye, Passwords. You Aren't a Good Defense (9-Aug-2008):

We won't make much progress on information cards in the near future, however, because of wasted energy and attention devoted to a large distraction, the OpenID initiative.

Commenting on Stross's article (11-Aug-2008), Kim Cameron, Microsoft's Chief Architect of Identity, had some conciliatory comments. As mentioned earlier, some work has been done towards interoperation of OpenID with InfoCard; this is not universally welcomed (for example, OpenID Infocards: Painful or Promising?).

Are Information Cards a leading-edge technology that will blossom and gain widespread adoption, will it merely obtain a niche following, or has it already become another dead end that at best might offer instructive lessons to the developers of future authentication technologies? Regardless, it offers some interesting benefits and fits in well with DACS's "Swiss army knife" approach to authentication, albeit at the cost of higher complexity and larger implementation effort than any other DACS authentication method.

There is a wide gap between a prototype implementation that can demonstrate a new technology and production-quality software, but DSS intends to include a secure and usable initial version of InfoCard support in release 1.4.23 of DACS. The extent to which InfoCard support will be maintained and improved in subsequent releases depends on the up-take of InfoCards in general and how much interest is expressed in the new capabilities by DACS users. There are many ways in which the implementation can be enhanced and extended, and many avenues for experimentation. The stability of the InfoCard specification (and its supporting technologies) is also an important factor in determining how much effort is required to maintain InfoCard support within DACS.

Notes

1. Contrary to the specification, CardSpace appears to always demand at least one URI in the requiredClaims parameter value. With respect to cases not addressed by the specification: 1) if a claim appears in both the required list and the optional list, CardSpace considers the claim to be required; 2) additional occurrences of a given claim within either list are ignored; and 3) if an IP/STS returns a claim that does not appear in either list, CardSpace treats it as if it were required.
2. It allows more than one OBJECT element within a submitted FORM element; CardSpace will be invoked multiple times.
3. It is not clear whether it is policy retrieval processing or token service processing that follows this sequence, or whether different Identity Selectors might implement this differently.
4. With CardSpace, inclusion of optional claims uses an all-or-nothing control rather than a more selective per-claim control.
5. Azigo's terms of service limit the use of their software and services to "US citizens over 13" and require creation of an account. These unfortunate constraints make official support of Azigo by DACS impossible.
6. A 2009 survey of European companies in IT services, consulting, insurance and utilities industries with over 500 employees reported that 99% use username/passwords for remote access, although other methods may also be supported.
7. It is standard practice for sites to allow users to select their password. Unlike passwords, usernames are generally not considered to be secret and are often based on a user's name or email address. A minority of sites impose minimal "password hygiene" requirements. The PASSWORD_AUDIT directive provides a mechanism by which a DACS administrator can identify weak user passwords that pass through any password-based DACS authentication module, and the PASSWORD_CONSTRAINTS directive can be used to impose restrictions on user passwords associated with native DACS accounts that are password-based.
8. A study in 2000 suggests that 70% of people do not use a unique password for each web site. A 2003 study revealed that 65% of workers use the same password for different applications or services. And in 2010, it was reported that 73% of web users use their bank password at other web sites.

Links

The following external links provide supplemental material. Note that a large amount of older material about InfoCards remains available, and while still useful, it is sometimes based on earlier versions of CardSpace or the Identity Selector Interoperability Profile.

Also see Understanding Windows CardSpace: an Introduction to the Concepts and Challenges of Digital Identities by Vittorio Bertocci, Garrett Serack, and Caleb Baker, Addison-Wesley, ISBN 0321496841, 2008.

1. Identity Selector Interoperability Profile 1.5
2. The Information Card Foundation
3. Open Identity Exchange (OIX)
4. A Guide to Using the Identity Selector Interoperability Profile V1.5 within Web Applications and Browsers (July, 2008)
5. Identity Selector Interoperability Profile specification and companion guides (August, 2008)
6. RFC 3275 XML-Signature Syntax and Processing (March, 2002) and XML-Signature Syntax and Processing (W3C Recommendation, February, 2002)
7. XML Encryption Syntax and Processing (August, 2002)
8. Canonical XML (March, 2001), RFC 3076 (March, 2001)
9. Exclusive XML Canonicalization (July, 2002), RFC 3741 (March, 2004)
10. Patterns for Supporting Information Cards at Web Sites: Personal Cards for Sign-up and Sign-In (August, 2007)
11. Introducing Windows CardSpace (April, 2006)
12. Design Rationale behind the Identity Metasystem Architecture (January, 2006)
13. Identity Metasystem Interoperability, Version 1.0, Editors Draft 03 (November, 2008) [also see OASIS Identity Metasystem Interoperability (IMI) TC]
14. OSIS: Open Source Identity Systems
15. OASIS Security Services (SAML)
16. Infocard support in simpleSAMLphp
17. Cardspace Managed Card and STS Test Harness
18. thinktecture STS Starter Kit
19. A Service to Prove You Are Really You, Saul Hansell, The New York Times, 23-May-09.
20. Technology Leaders Favor Online ID Card Over Passwords
21. Detecting Information Card Support
22. Microsoft Identity Lab (Relying Party Page)
23. Linkage with CardSpace in Auditing Mode, Kim Cameron, 5-Aug-07
24. Geneva Team Blog
25. WSO2 Identity Server (Java, Apache 2.0 license)
26. PayPal's plans for a single consumer identity
27. Yahoo, PayPal and others to enable Americans to participate in law making

© Copyright 2009-2014 DSS Distributed Systems Software, Inc. All rights reserved. All trademarks, icons, logos, and product names used in this article are the property of their respective owners.