It’s an extra step, but it’s one that significantly improves the security of your Google Account because it requires the powerful combination of both something you know—your username and password—and something that only you should have—your phone. A hacker would need access to both of these factors to gain access to your account.

That important security enhancement is garnering a lot of attention. What I find interesting is the point that only got a sentence’s mention.

You can also set up one-time application-specific passwords to sign in to your account from non-browser based applications that are designed to only ask for a password, and cannot prompt for the code.

This sounds an awful lot like PAuth, which Don Park suggested as an alternative to OAuth over two years ago. I’ve always wondered why that didn’t get more attention.

The first case, interaction between people, is familiar to anyone using social networking sites like Facebook. When someone adds you as a friend, Facebook sends you a notification prompting you to confirm or deny the request. If you approve the request, that person will be allowed to view your profile.

In effect, a “contract” is established between the two people. Because Facebook knows the identity of each person, restrictions on that contract can be put in place. Privacy settings are a classic example of such a restriction. For example, you can limit who can view your contact information and phone numbers.

The second case, integration between systems, is less familiar but is getting increased attention as data portability becomes necessary. In this scenario, the authorization requirements typically involve only one person who has separate accounts on separate systems.

For example, I use Google Calendar to keep track of my schedule. When I accept event invitations on Facebook, it would be useful to have those events added to my calendar. I would like to allow Facebook to modify my calendar, but I don’t want to allow it access to my email (which is why I won’t give Facebook my Google password).

OAuth specifies a protocol for establishing system-to-system authorization. It allows you to approve access to your data on one system to another system acting on your behalf.

At the core, OAuth defines a mechanism for exchanging access tokens, which are issued during authorization. It is up to the system to implement and enforce different access rights, such as read-only vs. read-write privileges, or access to one set of data but not another.

In the above example, Facebook would be acting on my behalf, automatically adding events to my calendar so that I don’t have to add them manually. Google would recognize that the token used allows access to my calendar, but would deny any attempts to access my mail.

OpenID is an open protocol that allows people to login to websites using a single digital identity, eliminating the need to create another account at each new site you visit. It’s a relatively new technology, and not yet widely deployed, but it is gaining traction.

OAuth was another topic of interest at the event. A separate but related protocol, it specifies how sites grant authorization to other sites that wish to utilize services. Combined with OpenID, some interesting things become possible.

For example, imagine accessing Google Calendar and Travelocity using the same ID. Since the two accounts are linked, when you book a flight, Travelocity can automatically add your flight times to your calendar.

These technologies open up new possibilities for developers and designers to create applications that better server people. Things are still in the early stages, and events like this are important first steps.