I said I would write up my understanding of PPIDs (privatepersonalidentifier) and how it works with CardSpace. Here is my attempt at it.
When a card (either managed or unmanaged) is created in CardSpace, a "master key" is associated with the card. The master key is simply random bits - entropy. The master key has several purposes: 1) it is used to generate a public/private key pair for the card, and 2) it is used in the generation of a PPID for the card whenever one is requested.
A card's PPID is "site-specific." It is computed as needed. It will be different for every relying party the card is selected for. When a relying party requests PPID in its claims, CardSpace uses the subject name in the certficate presented by the relying party to construct the PPID. More precisely, the identifier is computed as a function of the organization name ("O") and any optional location ("L", "S", "C", and "DC") attributes present in the subject name of the certificate.
To enable an STS that supports the PPID claim to be able to always produce a consistent claim value, Windows CardSpace includes the extension element ic:ClientPseudonym/ic:PPID in the RST request, illustrated below:
<wst:RequestSecurityToken>
<ic:ClientPseudonym>
<ic:PPID>MIIEZzCCA9CgAwIBAgIQEmtJZc0=</ic:PPID>
</ic:ClientPseudonym>
...
</wst:RequestSecurityToken>
The <ic:PPID> element contains the result of applying a hash function to a relying party identity and optional user-supplied entropy to produce an opaque, yet consistent, reference for the relying party. This value must be used as the basis for generating a PPID claim that is sent back to the RP in the security token. The STS may use this value as is or as an input seed to a custom function to derive a value for the PPID claim.
Using An Unmanaged (Self-Issued) Card As The Authentication Method For a Managed Card
A managed card may specify one of four authentication methods - or types of user credentials - for authenticating to the IdP. These are: 1) Username/password, 2) Kerberos v5 Credential, 3) Smartcard based X.509 Certificate Credential, and 4) Self-issued Token Credential. When a card is selected, the appropriate authentication materials are sent to the STS in the RST. For username/password, the user will be prompted to enter a username and password before sending the RST.
The reasons we are interested in the Self-issued Token Credential are because it does not require the user to enter any credential information, which would allow us to support single sign-on (SSO). The Kerberos credential and the X.509 Credential may or may not require the user to enter information - we don't know exactly how they work at this point. Of the three, self-issued token credential seems to be the simplest in concept to implement, and perhaps the easiest for a user to work with. It works as follows:
1) The <UserCredential> element in the managed card contains a <SelfIssuedCredential> child element, which in turn has a <PrivatePersonalIdentifier> child element that holds a PPID. The PPID references an unmanaged card. Recall that PPID is "site-specific." In this case, the "site" (or relying party) is the STS pointed to by the managed card. Thus, the PPID should be the one that is generated for the unmanaged card as if the STS were the relying party. That makes perfect sense, because the STS is, in fact, the relying party that will receive authentication material - the PPID of the unmanaged card. It is as if the STS requested a PPID claim and the user selected the unmanaged card to satisfy that claim.
The XML in the managed card looks like this:
<ic:UserCredential>
<ic:SelfIssuedCredential>
<ic:PrivatePersonalIdentifier>base 64 PPID</ic:PrivatePersonalIdentifier>
</ic:SelfIssuedCredential>
</ic:UserCredential>
2) When the managed card is selected by a user, the unmanaged card's PPID and public key is sent to the STS in the RST as the authentication material.
3) The STS uses the PPID+public key to "lookup" the user account and request the attributes needed to create a security token that will be sent back to the relying party. -- This is the part that we need to figure out how to do in our LDAP CP.
Well, I think that is all I am going to write up for now. I will attempt to do a drawing and send that out later.
Daniel