Primary keys in the identity metasystem

Dominick discusses the problem of determining how to uniquely identify users who present information cards to your application. If you keep a profile for those users, you need a way of linking the incoming claims to the user's profile. When I was first learning about CardSpace and the metasystem, it seemed as though PPIDs were a good answer. But once I learned that PPIDs weren't necessarily stable, I became wary of recommending their use.

One fact remains true no matter how you define the primary key for users. You need to pay attention to the public key claim when you are accepting personal cards. If you haven't heard about this before, read why here.

So my suggestion is this: just store the public key in your user profile. I disagree with the approach the Token sample class takes via its UniqueID property - they don't expose the public key directly; instead they have you pick a claim URI that represents your primary key (I guess you're screwed if you wanted a multi-part primary key). Then they hash the value of that “identity“ claim with the public key. Why don't they just expose the public key directly, like WCF with it's System.IdentityModel does? That would allow ME to decide how I'm going to pay attention to it.

I'd personally rather just store the public key (or more likely a SHA-256 hash of it) in the user profile. To me, this is clearer than mixing it up with some other claim. Too bad the Token class refuses to give it up directly, and instead insists on hashing it with some other claim.

UPDATE: I wrote the code to allow you to access the public key in my next post.