There are two main types of authentication systems, credential based authentication and relationship based authentication.

An example of a credential based system is your driver’s license. When I present my driver’s license I am presenting a hard-to-forge token from a trusted third party, in this case the government. Since you know it is hard to forge you are comfortable accepting that it is indeed from the state of Oregon, since the biometric is printed directly on the token you are comfortable accepting that I am subject being asserted and so you accept that as identification. You don’t need to call the Oregon DMV or contact them in any way. You have the credential and can verify it with just the information available.

An example of a relationship based system is your credit card. The card itself doesn’t carry any money on it—the merchant must contact the issuer of the credit card on every transaction. The credit card is basically a note saying, “call Discover, this is my account number to ask them if I have sufficient funds for this purchase”. The merchant actually calls up Discover, asks them if I have sufficient funds and Discover says “yes” or “no”. Discover must be contacted on every transaction. Without contacting Discover, the merchant can’t verify anything.

Even though a lot of identity systems are a mixture of these two, the essence of the protocol falls into one of these two camps.

OpenID is a relationship based system. To log into a website, you present your OpenID, a url, which is basically a note telling the website who your identity provider is (you lookup the url to obtain the XRDS service document that contains this information). The website hasn’t necessarily run into this identity provider before so it must decide if it trusts it enough for what the application is providing.

InfoCards are mostly credential based. A website or service presents at login identity providers it will accept. After the user selects an appropriate card the card selector contacts the identity provider and obtains credentials. The assertions are signed cryptographically by the identity provider’s private key (hard to forge) and are given to the original website. The website verifies the assertions by checking the signatures with the identity provider’s public key.

Credential based systems:

• assertions are hard to forge tokens
  • usually comes down to something based on the Public Key Infrastructure (PKI) (cryptography)
• credentials are difficult to revoke (that’s why InfoCards limit the time assertions are valid to mitigate this)
• we don’t have to contact the issuer of the credential to verify it
  • can work offline
  • performant

Relationship based systems:

• assertions are just another party saying “yes” or “no”
  • Not dependent on PKI (although you do need to know that the identity provider is who they say they are)
• credentials are easy to revoke—the next time the question is asked the identity provider says “no” and they will be asked on the next transaction
• we must be able to contact the issuer on each transaction.
  • must be online
  • verification is “slower” than verifying a credential (contacting someone else is slower than just verifying locally)

PKI has been around for a long time but has not caught on with the public in general. It’s hard enough for geeks to get right. Relationship based systems are very natural, they model how a lot of things work in real life. In later posts I’ll write about some of my latest work—taking things that are possible with credential based systems but aren’t available for general use and seeing if I can tweak them into something feasible using relationships in the hopes that it could actually become generally available.