Claims aren't static

Another practical issue. Let's say I choose to request an email (or some other) claim from users who submit information cards to my site. I'm likely going to store that claim for later use in the user profile record I keep on my website. But that information could easily get stale over time and the next time the user authenticates with me, the email claim she submits could very well be different.

I'm just curious how those of you deploying relying parties are thinking of dealing with this. It seems as though it might be a good idea to notice the change, and ask her if she wants to update her profile.

I wonder if anyone (MS ) is thinking of putting together a set of guidelines for dealing with these corner cases. It'd sure help the user if websites tended to react the same way in these situations (in the spirit of the 7th law).

Answer this question

Claims aren't static

Chris Honcoop
Why store the user's email address If she's signed up for a class at Pluralsight, we need to send her email from time to time about the class. Even if I'd not used InfoCard I'd be asking for her email address. It's also a good moniker to use to identify the user, unlike a PPID, which (at least as Andy Harjanto has described to me) is computed by hashing my public key, which makes it useless as a long-term identifier because that key is eventually going to change when I update my certificate, and therefore I lose track of all my InfoCard users every year or so. I can't afford that. So the user is just going to have to trust that I'm not going to collude with another website or sell her personal information tied to her email address. But that's pretty standard privacy policy stuff. Unlink the PPID from my public key and then we'll talk ;-)

I agree with you that if a claim isn't needed long term, it shouldn't be stored. My post isn't addressing those claims. What I'm thinking about is those particular claims that I do want to mirror, like someone's surname, which could change. Once again, this is just me thinking out loud and trying to get the community thinking about these issues early.
Pavan Apuroop
Oh, I'm not saying "don't store them" Obviously, that email-address is pretty valuable for communication. But I think we're on the same page there anyway.

The PPID is based off of the relying party's Public key--when the certificate is not HA. On High Assurance certficates, it's actually calculated from the OLSC (org,location,state,country) -- that's been physically verified by the CA. So, with an HA cert, you can get reissued with different keys, and the calculated PPID is constant :D

There has been many-a-discussion around mirroring of claims into proviles, and obviously, there are arguments either way.

g

Garrett Serack | Program Manager |Federated Identity Team | Microsoft Corporation
blog:http://blogs.msdn.com/garretts
skillpoint
We are indeed building perscriptive guidance around these issues.

It's important that people can get that consistent experience everywhere.

One way to look at it:

If you want to take the values from the claims, why even store them Do you *need* that information. If someone subverted your database, would it be better if you didn't even have names in there, regardless of other data, that becomes one less way to even correleate information.

And, because PPIDs are not replicated for a user between sites, there could possibly be no way to correlate individuals. That's kinda nice to put into your privacy policy. :D

g

Garrett Serack | Program Manager |Federated Identity Team | Microsoft Corporation
blog:http://blogs.msdn.com/garretts
Claims aren't static

Answer this question