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.

To learn about distributed version control systems (DVCS), I’ve been using bazaar on some small projects . I know these DVCSs are supposed to really shine in multi-developer environments spread out across the world but I have found that they offer an incredibly low barrier to entry for a single developer on his own box. This is the typical situation for a college student in computer science and many others as well.

An example could help here. I’m taking a networking class where a bit of code is provided in a framework and we need to use the code for our programs.

cd lab1
bzr init
bzr add
bzr checkin -m "Initial import" 

Done. This folder is now under version control.

When version control is this easy to setup and use, there’s no excuse for not using it.

Some time ago I went on a church mission to Brazil for two years. I didn’t know anything about Brazil or Portuguese. We have a Missionary Training Center where I was inundated with non-stop Portuguese lessons for two months. It moved so fast it was hard to remember everything but it was a good preparation. I went from no knowledge of Portuguese to two months later being dropped off in the small town of Maracajú, Mato Grosso do Sul, Brazil. The other missionary working with me was Brazilian leaving me three hours away from anyone who could understand me. I thought I was learning a lot in the classroom but have since found that the pace of learning doesn’t even compare to complete immersion. I don’t like to go hungry. I learned how to speak.

I’ve been in web development for a long time. Since I’m a student in computer science, I have gravitated towards making the “back-end” of web systems. At the same time I think that user experience is the most important aspect of software design. I found that even though I read a lot about it, my javascript fu was not strong enough. I could design cool, useful apps that were fully functional on the backend, but in order to code up the front I would search for javascript scripts and widgets until I found one that was similar to what I was looking for and then just tweaked it. That works for many things, but other times you can’t fall back on those tactics and must flex your own fu.

After all is said and done, more is said than done. —Aesop

Reading and talking about it aren’t enough. You’ve got to do it yourself.

I gave myself a self-imposed immersion project. I wanted something small enough that I could have some quick success (to entice myself to stick with it) but still be big enough to be interesting.

When the term Ajax first started gaining momentum Jamis Buck blogged a piece about his first Ajax app , a simple word game. The back story was that there was a technical discussion at his work about the merits of asynchronous XMLHTTPRequest versus synchronous XMLHTTPRequest. His little word game was a demonstration to his coworkers showing that asynchronous was the way to go, so that it would not lock up the browser. It was a fun little game that both me and my wife enjoyed playing now and again.

For my javascript immersion project I decided that I would try and write the entire game in javascript with no back-end at all. It was just to force myself to get out of my comfort zone.

Here it is, Devlin’s Word Reorder Game.

Some technical notes:

This is implemented using the excellent jQuery library. The tasteful effects courtesy of the Interface library. The dictionary is just all the four letter words contained in the file /usr/share/dict/words on my Mac. I know, a lot of words you think should be in there aren’t (especially the short pluralized ones like tips, huts etc.). If you can get me a better dictionary I’ll glady switch.

I used jQuery and am glad I did. It takes away a lot of pain experienced in my previous forays into javascript and browser incompatibilities.