We’ve been having a great discussion on the OSIS-general mailing list, and I wanted to save a bookmark to the thread so that I could come back later.

The thread discusses what exactly an RP should use to uniquely identify a card from a managed card provider.  The current methodology that I’ve been using with the PamelaProject RP’s was to take the isuer certificate signerkeymodulus provided in the SAML 1.1 token and the PPID and hash it together to get  a card hash that is pretty tough to replicate without the original inputs.

The problem started when I encountered a managed card that did not explicitly provide a signerkeymodulus in the token.  It turns out that I could still extract the value, but the point was made that by using the signerkeymodulus of a managed card, I guaranteed that on issuer certificate rotation, the card identifier would become invalid, and the user would have to reassociate their card.  Obviously, this is not an optimal solution.

The solution that was recommended was to generate an identifier for the issuer using the same algorithm IdPs use in section 7.6.1 of the IMI specification,  so I will give that a try right away.  I would say that this is the closest thing to a best practice out there for Relying Parties, and I would recommend that any other RP writers out there that they review whatever policy they are using;  if they are depending on signerkeymodulus, there is at least one IdP out there who does not supply the signerkeymodulus as a separate element in the token, so you’ll be having interoperability issues.  If you are storing the PPID directly, I’d also like to strongly discourage you from doing so, I would consider it just as much of a no-no as if you were storing clear-text passwords.

The thread is worth reading, if you get excited about such things ;)  You can also subscribe to the osis-general list here.