I just assume (= hope) that it will be a common scenario in the future that identity providers set up a web page where you somehow register and in turn get a managed card to import into CardSpace.

After you imported the card you can use it to login to applications and services that accept cards from that particular identity provider. Under the covers, CardSpace will then contact the STS to obtain a token for the relying party. To get this token you have to somehow authenticate with the STS.

A CardSpace STS currently supports four credential types

• Username/password
• Certificates
• Kerberos
• Self issued cards

Each authentication type has its use.

• Username/password supports any key/value pair type of authentication, e.g. also CC# and security code.
• Kerberos enables single-sign on in Kerberos realms
• Self issued cards enable single sign on with self asserted information (but probably verified by the identity provider)
• Certificates (my favourite) enable very strong authentication and especially when combined with smart cards multiple factors

You can also strengthen the protection of the cards with an additional pin that you have to enter, every time you use them.

When you want to build your own STS for CardSpace you have to make a choice which authentication type(s) you want to support. While reading the The Identity Selector Interop Profile about using self issued cards, I came across this:

<quote>

5.4. Self-issued Token Credential

When the identity provider requires a self-issued token as the credential type, the following credential descriptor format MUST be used in the information card to specify the required credential.

Syntax:

<ic:UserCredential>
  <ic:SelfIssuedCredential>
    <ic:PrivatePersonalIdentifier> xs:base64Binary </ic:PrivatePersonalIdentifier>
  </ic:SelfIssuedCredential>
</ic:UserCredential>

The following describes the attributes and elements listed in the schema outlined above:

…/ic:SelfIssuedCredential

This element indicates that a self-issued token credential is needed.

…/ic:SelfIssuedCredential/ic:PrivatePersonalIdentifier

This required element provides the value of the PPID claim asserted in the self-issued token used previously to register with the IP/STS (see Section 8.5.14). Furthermore, the actual security policy of the IP/STS (expressed in its WSDL) MUST include the sp:IssuedToken assertion requiring a self-issued token with exactly one claim, namely, the PPID.

</quote>

This means that you have to embed the PPID of the self issued card inside a managed card to make the connection between these two cards. In a recent post I told you that PPIDs are generated dynamically based on the application identity.

Now this implies that from a CardSpace point of view the web site issuing the managed card and the STS (usually a separate web service) need to have the same identity. Otherwise the PPIDs would get calculated differently and CardSpace could not associate the SIC with the managed card.

This means that essentially the web site and the STS have to use the same server certificate. And both of them need read access to the private key.

Now to me it sounds a little bit dangerous when a flaw in one application can compromise the identity of another. And especially an identity provider should have rock solid security.

Just another reason to factor out at least the token decryption code in the web interface. I wrote about that here and provided a service that allows doing that here.

Another approach could be to use EV certificates. That would allow having separate certs for the web app and the STS and still the PPID would get calculated correctly (given the O, L, S, C fields in the certificate match). I have not tried that but will once I can afford them ;)

Sometimes it is really funny how such a small detail can completely change your overall architecture…and sometime you find out the hard way…