In Context

This post is an attempt to summarize in one place some interoperability issues related to IMI PPID computation that we’ve run into as we get ready for RSA next week.

Specifications

There are two specifications of how to compute the PPID:

1. ISIP 1.0
2. IMI 1.0 (same as ISIP 1.5 submission). A clarification was added as described here: (see  Changes Made in ISIP V1.5 on page 72). It says: “To provide a migration path from non-EV to EV certs, the RP PPID Seed for a non-EV cert containing the same OLSC values is the same as for an EV cert, resulting in the same PPID”

In addition, here’s a very detailed article about this calculation, with example values. Mike suggests that anyone wanting to debug their implementation might want to check its calculations against these known-good values.

CardSpace Versions

1. .Net 3.0 version: implements ISIP 1.0 according to Mike
2. .Net 3.5 version: implements IMI 1.0 according to Mike
3. .Net 3.5 SP1 version: (i) implements IMI 1.0a for token of p-card (ii) implements both ISIP 1.0, and IMI 1.0 to find a p-card that matches the PPID credentials of a “backed” m-card.
4. .Net 3.5 SP2 version: same as #3 above
5. CardSpace 2.0 beta version: same as #3 above

Azigo Versions

• 2.0.0.35 –> 2.0.0.40 versions: implement IMI 1.0

Higgins STS

• Higgins 1.1 STS implements IMI 1.0

Avoco Versions

• It appears to use different PPID-related logic than CardSpace WRT to finding a matching p-card against the PPID of a backed m-card.

Known Incompatibilities (bugs):

1. Pam reported: You can’t export a p-card backed m-card from Azigo 2.0.0.35 and import into .Net 3.5 SP1 version of CardSpace.
2. Paul Battersby of Avoco reported: 1) An Azigo Managed card backed by a CardSpace Personal card using a crds imported from CardSpace. 2) An Azigo Managed card backed by an Azigo Personal card using a crds imported from Azigo Desktop selector. In the first case the PPID matches (i.e. the PPID calculated by the selector matches the PPID stored in the managed card). The algorithm uses a Relying Party Id generated from |O=”*.azigo.net”|L=””|S=””|C=””|. The second scenario fails. However, if I force the code to use a Relying Party Id generated from the public key of the certificate then the PPID matches. This is rather strange as the certificates in the Managed cards from both scenarios are exactly the same and the public key should only be used if the certificate is not valid or the Organizational units are empty.
3. JohnB recently pointed out that Azigo 2.0.0.40 and CardSpace .Net 3.5 SP2 generate different (and thus incompatible) PPID values on p-cards for the PayPal site (site with an EV cert)

The first two above are caused by the same set of inter-related issues. The root cause is an inability to validate the certificate of cardpres.azigo.net and as a result Azigo computes the wrong PPID for this site. We thought that we could fix this by including then entire certificate chain in the .crd. We did this today, but there are other related issues and we need another 2 days to deploy a new version of our hosted i-card service (service.azigo.com)