Information Cards: Unused (Security) Information

It seems that I have to make up for not posting while my new house was build...

Here is another post for today in the series (1,2,3) of posts around things you always wanted to know about Information Cards but never had the heart to ask.

Did you know that CardSpace does not use the Identity information in an identity enabled EndpointReference? Shocking.
Here is what I heard...

When you import a managed card from a .crd file there is something inside the file that is called the TokenServiceList that contains a sequence of TokenService(s) that contain an EndpointReference. This is defined in WS-Addressing and in our case extended to contain an element "Identity" from the namespace "http://schemas.xmlsoap.org/ws/2006/02/addressingidentity".

<Identity
 xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
 <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
  <X509Data>
   <X509Certificate>
MIICfTCCAeagAwIBAgIBATANBgkqhkiG9w0BAQUFADAqMQ0wCwYDVQQKEwRPU0lTMRkwFwYDVQQLExBJ
bnRlcm9wIEJvZ3VzIENBMB4XDTA4MDYxMTE2MTIxM1oXDTA5MDYxMTE2MTIxM1owSzENMAsGA1UEChME
T1NJUzEZMBcGA1UECxMQSW50ZXJvcCBCb2d1cyBDQTEfMB0GA1UEAxMWdGVzdC5wYW1lbGFwcm9qZWN0
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAz9qsJnJd/ZD8Fr/uGSojxMVoD53w28O14RLB
Hfm3scuFd9ypxy7KU8fOkDyOtKWoHqAVpPd/TRHIYiyRVorEyIiqQpbKCcqUd2YJM9nVxHuOHYvrVXRj
QAVV3Fu4Ncy22Tl+lJRJzWgcfc89aqFoyIv2tmqvAisRyNf6+1eppmcCAwEAAaOBkTCBjjAJBgNVHRME
AjAAMBEGCWCGSAGG+EIBAQQEAwIGQDALBgNVHQ8EBAMCBaAwKgYDVR0lBCMwIQYIKwYBBQUHAwEGCWCG
SAGG+EIEAQYKKwYBBAGCNwoDAzA1BglghkgBhvhCAQ0EKBYmT3BlblNTTCBDZXJ0aWZpY2F0ZSBmb3Ig
U1NMIFdlYiBTZXJ2ZXIwDQYJKoZIhvcNAQEFBQADgYEAIppR+riUA/cxJJBaNGslzoa297XMUqQelJ15
1UcGUWCqTxer2/b5nUG2TpmnA0/7CPCjE2t44st6MImB2tqDtI7DNSCKz19aNlhpoHa8MrCjPKHlDNIU
nqg3ZylCxbwm40G5NFiAXXCUznYyD9J6AhDesSvGCRCo3OStKaxr7jM=
   </X509Certificate>
  </X509Data>
 </KeyInfo>
</Identity>

Can you imagine: CardSpace just throws away this certificate and never uses it!

What is this certificate anyway? Some clever people came up with the idea that EndpointReferences need more security and should be protected by Identity. One way to provide endpoint identity information is to specify which certificate will be used by the (security token issuer) endpoint. This for the theory; in practice CardSpace does not use this information.

Why? Well, when the certificate is valid at the time the information card is issued but invalid after some time then the issuer would have to re-issue all cards that contain an EndpointReference with that certificate attached...
Microsoft thinks, I guess, that in general people - even professionals - are to stupid to handle the crypto-thingy correcly.
I don't know. I think that we should expect an Identity Provider to know its business and part of that business is to handle the certificates/keypairs etc so that the Identity Metasystems handles a renewed certificate without hickups.

An alternative to specifing a certificate is to specify an RsaPublicKey. This has no validity dates attached to it so it can not become invalid. If the STS specifies the public key then it can change certificates or part of the information in the certificate as long as the keypair stays the same.
This advantage of keypairs in contrast to certificates is an disadvantage too. Should the private key of the keypair be compromised then all information cards have to be re-issued (Super-GAU). Well, this falls in the category "This should never happen". We should expect to see this not too often.

Enough gossip for now. Time to call it a day.

Enjoy.