UniqueID maintenance in the store

The comments to my blog stopped working. I am working on it, but in the meanwhile here there’s the answer to a comment left by Matt to my former post on PPID vs UniqueID.

Monday, January 15, 2007 6:55 AM by Matt Ellis
# re: UniqueID and PPID

Hi Vittorio.
I’m wondering what happens if the IP’s cert changes (perhaps the private key is compromised)? With a bit of co-ordination, you can update your copy of their public key, so you can still verify incoming tokens, but would the unique id now be incorrect? Is this even a situation that can happen?
Cheers!

Matt 

Hello Matt,
apologies for the delay.

We exclude from the discussion the selfissued card case: if the public key changes, this means that the eintire card changed (including the PPID) and it makes sense to ask to repeat the registration. That said:
Your unique ID can be a function of the public key of the IP and of the PPID:

Uid = F(Pipkey,PPID)

In theory, if you (the RP) stored the PPID somewhere (and it didn’t change in the process, more about it later) you could just reapply the F above and substitute the Uid value in your store.
In practice: when you use a managed card, you can’t be sure of what the PPID value will be. Actually, we recommend to IPs to make that claim available but they can choose not to add it at all. For self issued cards the PPID is a function of the cardID and of the public key of the RP:

PPID = G(Prpkey,Cardid)

Even if we’d apply the same formula for managed cards:

•  the Prpkey may not be available to the STS, for example if we choose not to disclose to the IP with which RP we want to spend the token (= no RequireApplyTo)


•  if the Pipkey changed, the card itself needs to be reissued (since it was signed with the old key pair): the IP policy will determine if the new card will have the same Cardid.

 The above bullets may both determine variations in the value of the PPID of the card, and that change would be much harder to manage than the Pidkey change. While the latter imposes a blanket change, with only one value (the new Pipkey) broadcasted to everybody, variations in the PPID would apply to each and every single card. The IP cannot know which RPs registered the former versions of the card, so the notification of the new PPIDs to RPs may be very hard. It would be easier to ask the user to submit the new card. After all the new token will be signed by the IP that the RP trusts, so it would be just a matter of making the match between an existing profile and the incoming token: how this is done will vary case by case, and depends on the actual claim set and its properties.

HTH 🙂