What you always wanted to know about Microsoft Cardspace - Part 2

  • Articolo

Q: Can a card be marked as "not exportable"?
A: No this is not possible at the moment. After a card has been installed in the card-selector the card can always be exported using the standard facilities of the card selector. This allows easy tranportation of cards and use of the cards on several devices/PCs. If the security requirements of an identity provider or a relying party demand that the card should not be usable on another device the provider can issue the card with a certificate as the token credential type. This certificate can either be a soft or a hard certificate. In case of a soft certificate it will be installed into the local certificate store and this certificate can be marked as non exportable. This ensures that the mnanaged card, although it can be exported and imported, can only be used on the device where the certificate has been installed.

Q: Can an identity provider create a managed card which uses the self issued toke credential type and the corresponding self issued card remotely and automatically?
A: Well while it may be possible to create those cards at all at the identity provider it cannot be done automatically. The reason for this is that the self issued card is encrypted by the Self-issued Identity Provider (SIP) where the card is transferred in a transportable format in a two step process:

  1. Transformation of card metadata and/or claim information ito a pre-encryption format.
  2. Transformation of the pre-encryption into a post-encryption format using key derived from a user provided password.

However this cannot be done automatically as the SIP does not provide a API to automate this process.
Another reason that this is not possible is that this may be a major violation of one of the basic principles of the Cardspace identity metasystem. Remember, unlike a managed card, a self issued card does contain the private claim information. The identity provider first of all needs the data and the consent of the user to use this data for the creation of a self issued card and then the further process does raise three issues where the user may loose control.

  1. The user needs to specify a password or the provider needs to compute a password (PIN) to protect the cardspace store which means the password could become potentially unsafe.

  2. The card needs to be imported into the card-selector. However during import the card-selector does not display the claim information carried by the card for verification before importing. So there are chances that there are claim informations stored on the card which are wrong or which have been altered

    Import Wizard ProcessImport Wizard Process 1

     

  3. In order to create a managed card which uses the self-issued token credential type the private personal identifier (PPID) needs to available to create the managed card. The PPID however uniquely identifies a card towards a specific relying party and the PPID is generated using a relying party identifier (PR Identifier) and a card id. So in order to generate this PPID the card has virtually to be used once on behalf of the user.

While it is probably a good idea to provide the user a card which can be used with the least possible efforts by the user (e.g. install a certificate, create a self-issued card for as authentication instance for a managed card etc.). It is probably not a good idea to create both cards altogether through a identity provider.

Q: Will it be possible for an identity provider to display custom error messages in the card-selector?
A: Yes this is definitely something planned for the selector component available with the .Net Framework 3.5. The identity provider can then simply return a SOAP Fault element with a message. The message can even be localized however it is only possible to display plain text messages. More information regarding this can be found in the cardspace blog here.

Comments