Whilst I was rejigging my presentation for the VBUG conference last week I give a quick nod to the different in language Information Cards and SAML use when talking about the information they transport.

Normally identity systems and the applications that use them, WebSphere, WebLogic, PKI et al. talk in terms of asserting identity. SAML and Information Cards talk in terms of claims. There’s a subtle difference;

assert : insist on one’s rights, declare one’s views forcefully
claim : to assert or maintain as a fact: She claimed that he was telling the truth.
dictionary.com Unabridged (v 1.1). Retrieved October 25, 2007

Ok, maybe the distinction is more in my head than in the dictionary, but to me claiming something is softer. An assertion leaves no room for questioning, a claim (to my mind) is an attempt to assert a fact but leaves scope for checking.

Why is this important? Simply because you do need to check the information coming from an Information Card login. Part of the process of accepting information cards is validating the claims made within the SAML token; it is up to you, the relaying party to process and decide on the level of trust and attribution you will levy against those claims.

We’re back to Passport again; consider law 3; Justifiable Parties. It was very hard for people to trust Microsoft to hold login information and details about people. An information card issued against a Passport (Live) account really can only validate one thing, the email address (and yes, if the user is a subscriber to on of the paid Live services then a name and address for payment could be claimed, but who is to say a parent is not purchasing on behalf of a child in this instance). The likes of slashdot et al simply wouldn’t have trusted Microsoft to provide access to their services. This hasn’t changed; you should assign a trust level based on the card issuer; a bank can only trust a information card they issue to allow access to their systems (which will neatly bring us onto single sign on, and what Information Cards aren’t).

How is this going to work? Well it’s up to you I’m afraid. For simple scenarios, for example the Pamela Project plugin for wordpress (as seen on Kim’s blog and Mike’s blog) the claim requested is that of an email address; once a card is presented the newly created local account is put on hold until the email address is verified, just like most account creation processes these days. There is an implicit lack of trust during this process and that’s what you should be aiming for.

Some people seem to believe that managed cards can be trusted more than self-issued (I demonstrated creating a self issued card for Bill Gates during my talk); but this simply isn’t true, it all depends on the managed card provider. The likes of a bank, credit agency or government will have the mechanisms in place to verify things like name, address and so on, however the likes of Versign, who are issuing managed cards for their experimental Personal Identity Provider perform no checking, so the trust level you should have for these cards is the same as that for a self issued card.

It’s a fun problem; you could look at the issuing party and assign a trust level, trusting your own managed cards 100% and verifying the claims made with the rest; at the end of the day you should be assuming that claims may be lies by default.