Creating Managed Cards

Download sample

A managed card is an information card issued by an Identity Provider. The managed card contains:

  • Details about the entity that issues the card, such as:

  • Card Name

  • Certificate

  • Security Token Service (STS) and Metadata Exchange (MEX) endpoints

  • An image displayed on the card

  • The list of claims about the user that the Identity Provider corroborates.

  • Details about how the user authenticates with the STS of the Identity Provider to have the information card populated with the required claim values. This authentication factor can be in the form of a certificate, a Kerberos token, a self-issued card or, in certain cases, a username and password pair.


    To create cards for use with CardSpace, the Identity Provider must generate a signed XML file that contains the card data. This information card is named with a .crd file extension.

To work with this sample, Web site configuration is necessary. The configuration is done using the installation batch file provided in the sample folder:


For more information about installation of the Web site, and some troubleshooting tips, see Installing CardSpace Sample Certificates.

Compiling the Card Writer

The source code for the Card Writer is found in the CardWriter Folder (in C#).


The source code for the Card Writer is found in the CardWriter Folder (in VB.NET):


Load the project file (CardWriter.csproj) in Visual Studio 2005 and compile it or use msbuild from the command line (where you unpacked the sample).

msbuild /nologo /v:quiet CardWriter\CardWriter.csproj

This compiles the Card Writer into the \bin folder, which can now be run from the command line.

    ManagedCardWriter carddetails.ini [outputfilename.crd]

Using the Card Writer

The card writer uses an .INI file as the input for generating a .CRD file.

bin\cardwriter.exe SampleCards\FabrikamUP.ini
Reading card config from
   <install path >\FabrikamUP.ini
Card written to
   <install path>\SampleCards\FabrikamUP.crd


The output card is placed in the same directory as the source .ini file.

Understanding the data in a CardSpace Card

Inside the source .ini file there are several sections that contain data that can be modified to generate cards for a specific purpose.

Type of card sample


Using the card creator, each card can use one type of authentication to authenticate with the Identity Provider’s STS. The card type may be one of UserNamePassword, KerberosAuth, SelfIssuedAuth, or SmartCard.

Card Details Sample

Name=My Card (U/P backed)

In the details section, there are four required fields.


The display name of the card that the user sees. The user can modify the name after it is imported into their Identity Selector.


This is the ID of the card. Importing cards with the same ID prompts the user about replacing the older card with the newer one. Cards should keep the ID consistent between revisions of their schema.


Each new version of the same card should get an incremented version number.


The image the user sees on the card when it is imported into their Identity Selector. This cannot be changed by the user.

Issuer Details Sample


In the issuer section, there are four required fields.


The endpoint URL of the Identity Provider STS.


The MEX endpoint for the STS. In CardSpace, HTTPS is required for the MEX endpoint.


The URL for the location of the privacy policy of the Identity Provider.


The location of the certificate, whose public key, is used to sign the card file. This should be in the format location/store name/common name (for example,localmachine/My/ or a path to a .pfx file that contains the certificate and private key. If the .pfx file is password protected, you must also put a CertificatePassword= field in the .ini file.

Claims Details Sample

2=   3=

In the claims section, individual claim URIs are listed that the Identity Provider supports. Use of the standard set of claim URIs requires no additional information, whereas using custom claim URIs requires a section for each custom claim.

Custom Claim URI Details Sample

     display=My Super Claim
     description=A claim for all to see

Each custom claim URI must detail the display name and the description for each claim created. These are displayed to the user in the CardSpace Identity Selector.

Token Types Supported Sample


The Identity Provider declares the types of the tokens that the STS supports. These are listed as URNs in the Token Types section. Each URN is put on a separate line, with an index number as the field name (such as, 1,2,3…).

Token Details Sample

[Token Details]

The Identity Provider can decide whether to issue tokens to any relying party or may require the relying party to state who they are when requesting the identity.


In this section, any credential hint information can be listed and encoded into the card. For different authentication types, there are different possible requirements:

  • For Self-issued card authentication, the value is the PPID claim from the card, as given to the Identity Provider, using their certificate.

         Hint=Enter your username and password
  • For Username/Password authentication, the value is the username (and is optional), that is displayed for the user.

         Hint=Enter your username and password
  • For Certificate Authentication, you must identify the certificate by one of three methods:

    • The thumbprint of the certificate.

    • A reference to the certificate in its store in the format location/store name/common name (currentUser/My/FrankLee)

    • The hash of the certificate itself.

Certificate Sample

     Hint=Insert your smartcard now

Viewing the Generated Card

The .crd format is an XML document that contains the preceding information. It is used by the Identity Provider to express all those in concise form and it is used by the user for importing the card into their collection.

In this example assume that an Identity Provider is issuing a card that certifies membership in an auto club, and that gives access services or discounts at a variety of Web sites.

The Signature

The root element of the .crd file is an enveloping signature.

<Signature xmlns="">
    <CanonicalizationMethod Algorithm="" />
    <SignatureMethod Algorithm="" />
    <Reference URI="#_Object_InfoCard">
        <Transform Algorithm="" />
      <DigestMethod Algorithm="" />
  <Object Id="_Object_InfoCard">

This ensures that once the card has been issued, it should be protected from tampering. This is accomplished with the use of the signature. Additionally, it gives the cryptographic certainty that it is really issued by the auto club, as it shows off usage of the private key.

The two X509Certificate elements contain the certificate of the identity provider (the auto club) and the certificate of the Certifying Authority that issued the certificate to the auto club.

After the signature, there is an element called InformationCard, which contains the actual metadata of the card. The following example shows the XML elements of the card.

<InformationCard xml:lang="en-us" xmlns="">
      <InformationCardReference />
      <CardName />
      <CardImage />
      <Issuer />
      <IssuerName />
      <IssuerInformation />
      <TimeIssued />
      <TimeExpires />
      <TokenServiceList />
      <SupportedTokenTypeList />
      <SupportedClaimTypeList />
      <PrivacyNoticeAt />

<InformationCardReference> contains the card ID and the version; used in subsequent import operations so that cards can be updated or overwritten.


<CardName> contains the cosmetic card name, which the user is allowed to modify after the import.

<CardName>My Card</CardName>

<CardImage> contains a base64-encoded image that the Identity Provider can select the appearance they prefer. This is encoded inside the card and not referenced in a URL to ensure the provider of the brand consistency without depending on the client’s capability of resolving links.

<CardImage MimeType="image/jpeg">

<Issuer> represents the URI of the STS—the address to which the Request Security Token (RST) messages are sent every time the managed card is used. <IssuerName> is the cosmetic name associated to it.


<IssuerInformation>, new to .NET Framework 3.5 , contains name-value pairs that allow Identity Providers to bundle ad-hoc information about themselves (for example, how to contact technical support or customer service) into managed cards for display by the client's Information Card Selector.

         <EntryName>Cash Machine Location</EntryName>
         <EntryName>Customer Support</EntryName>

<TimeIssued> and <TimeExpires> contain the time of the issuing operation and the card expiration date, respectively. The expiration date should be regarded as a ‘this-metadata-contract-supported-until’ date, and not an account expiration date, which should be handled as account data at the STS.


<TokenServiceList> contains a list of <TokenService> elements that are the data for obtaining the STS metadata, contacting it securely and for authenticating incoming requests.

          <EndpointReference >
            <Address />
            <Metadata />
            <Identity />
          <UserCredential />

<EndpointReference> is a WS-Addressing endpoint reference, which contains again the STS endpoint; the Metadata section contains the address of the WS-MetadataExchange endpoint.

<EndpointReference xmlns="">
          <Metadata xmlns=""
           <wsx:MetadataSection >
                 <Address xmlns="">

<Identity> contains the certificate associated to the STS, typically the same as the one used in the initial signature.

    <Identity xmlns="">
      <KeyInfo xmlns="">

The <UserCredential> element changes depending on the type of authentication:

  • For Information Cards backed by a personal card, the <PrivatePersonalIdentifier> element is used to store the PPID.

                </ SelfIssuedCredential >
  • For a Certificate backed card, the element <X509V3Credential> is used by managed card; the <KeyIdentifier> element contains the hash of the smartcard’s certificate. The <DisplayCredentialHint> element is the prompt that the user receives before displaying the smartcard.

              <X509Data xmlns="">
             </ X509Data >
  • The <UsernamePasswordCredential> holds the default user name for the card for Username/Password backed cards.

            Enter your username and password

The <SupportedTokenTypeList> contains a list of <TokenType> elements that detail the list of token types the STS supports.

    <TokenType xmlns="">

The <SupportedClaimTypeList> contains the list of claims that are supported by the card. Single claims are described by the <SupportedClaimType> element, whose elements are self-explanatory (DisplayTag and Description). The example uses predefined claim URIs available in the self-issued set as well as custom claim URIs, such as

        <DisplayTag>Given Name</DisplayTag>
        <Description>Given Name</Description>
          <DisplayTag>Last Name</DisplayTag>
          <Description>Last Name</Description>
    <SupportedClaimType Uri="">
         <DisplayTag>Email Address</DisplayTag>
         <Description>Email Address</Description>
    <SupportedClaimType Uri="">
          <DisplayTag>My Super Claim</DisplayTag>
          <Description>A claim for all to see</Description>

The privacy policy URL is found in the <PrivacyNotice> element:


Custom Faults

When there is a failure involving a user's managed card authentication credential, identity providers (beginning with .NET Framework 3.5) may throw a standard SOAP fault containing a reason for the error. The CardSpace Information Card Selector will display the fault's reason field in a multi-line edit control in its authentication window. Users may, for example, be directed to steps for troubleshooting or receiving support.


CardSpace cannot guarantee that the fault's message will be non-sensitive; therefore, the message will not be logged to the client's event log.


  • Managed Card - An information card issued by an Identity Provider. The information card contains metadata about the Security Token Server and the claims the Identity Provider supports.

  • Identity Provider - The identity provider issues digital identities to users, which contain claims of data about the user.

  • Security Token Service (STS) - The Security Token Service exchanges one token for another. The STS grants a token with claims based on the users’ authentication with the server. Essentially, the server that hands out digital identity information to the user.

See Also

Other Resources

Installing CardSpace Sample Certificates

Footer image

© 2007 Microsoft Corporation. All rights reserved.