\nOU = Users
\nDC = IDA
\nDC = Microsoft
\nDC = com<\/span><\/td>\n<\/tr>\n
\nee 50 05 dd e0 15 dc d6 2a c3 cc 98 53
\n7e 9e b4 c7 a5 4c a7 64 56 66 1e 3d 36
\n4a 11 72 0a eb cf c9 d2 6c 1f 2e b2 2a
\n67 4f 07 52 70 36 f2 89 ec 98 09 bd 61
\n39 b1 52 07 48 9d 36 90 9c 7d de 61 61
\n76 12 5e 19 a5 36 e2 11 ea 14 45 b1 ba
\n12 e3 e2 d5 67 81 d1 1f bb 04 b1 cc 52
\nc2 e5 3e df 09 3d 2b a5<\/span><\/td>\n<\/tr>\n
Everything shown is released every time I use the certificate – which is basically every time I go to a site that asks either for “any old certificate” or for a certificate from my certificate authority. (As far as I know, the information is offered up before verifying that the site isn't evil). You can see that there is a lot of information leakage. X.509 certificates were designed before the privacy implications (to both individuals and their institutions) were well understood.<\/p>\n
Beyond leaking potentially unnecessary information (like my email address), each of the fields shown in yellow is a correlation key that links my identity in one transaction to that in another – either within a single site or across multiple sites. Put another way, each yellow field is a handle that can be used to correlate my profiles. It's nice to have so MANY potential handles available, isn't it? Choosing between serial number, subject DN, public key, key identifier, alternative name and thumbprint is pretty exhausting, but any of them will work when trying to build a super-dossier.<\/p>\n
I call this a “maximal disclosure token” because the same information is released everywhere you go, whether it is required or not. Further, it includes not one, but a whole set of omnidirectional identifiers (see law 4).<\/p>\n
The Liberty Alliance has been forward-thinking enough to use this knowledge to avoid leaking omnidirectional handles to relying parties, through what it calls pseudonynms. For example, “persistent” and “transient” pseudonyms can be put in the tokens by the identity provider, rather than omnidirectional identifiers, and the subject key can be different for every invocation (or skipped altogether). <\/p>\n As a result, while the identity provider knows more about the sites visited by its users, and about the information of relevance to those sites, the ability of the sites to create cross-site profiles without the participation of the identity provider is greatly reduced. SAML does not employ maximal disclosure tokens. So in the threat diagram shown at the right I've removed the RP\/RP collusion threat, which now pales in comparison to the other two.<\/p>\n![](\"\/wp-content\/images\/2007\/06\/saml-pseudonym.jpg\")
SAML tokens represent a step forward in this regard because, being constructed at the time of usage, they only need to contain information relevant to a given transaction. With protocols like the redirect protocol described here<\/a>, the identity provider knows which relying party a user is visiting. <\/p>\n
![](\"\/wp-content\/images\/2007\/06\/saml-sample.jpg\")
<\/p>\n