OAuth is a protocol for delegating access via APIs.

It has some complexity in the protocol which can be discussed, but some concerns are:

• state, there are nonces and multiple types of session tokens to keep track of
• no-sharing, no easy way of sharing authorization tokens between systems: each token is only usable within its issued system.

We can think about authorization in a RESTful and user-centric manner and create tokens independently from consumers and service providers. A user should be able to create a token and pass it to any and several service provider, which should be able to parse and act on it.

I picture a way to do this is to specify a unified token format that contains:

• A set of actions (GET/POST/PUT/DELETE) + resource identifier (URL)
• A set of recipients (URLs)
• An optional validity interval of this token
• A set of creator identities (URL) + creator signatures of the token

The resource identifiers may contain wild-cards (not sure: to be discussed to be usable)

A token to give Alice the right to post on this blog could then look roughly like

  recipients=http://alice.example.com
  actions=POST,http://commented.org/posts
  from-validity=2008-04-28Z
  to-validity=2008-12-31Z
  creators=http://commented.org,eW91IGhhZCB0byBsb29rPwoK

The resulting token could then be freely exchanged, and publicly posted if desirable. Encryption of the token may be feasible. A service provider should be able to parse the token and accept it if it’s properly signed by an acceptable creator.

The tokens now contain all the state information needed and can be cleanly passed around. Also, the standardized token format means service providers can present a common, unified UI to end-users, and there is no specific lock-in to any protocol — you could distribute the tokens through email if you wanted to.

Any thoughts?

With the rise of social networking, the advent of provable identities, and ways to authorize access, there is a growing need for a reputation system to recognize good content and good people.

I have been working on this and my principles have been that the system needs to:

• be simple and available as an API,

• be decentralized and accept other systems to participate,

• contain security measures that prevent gaming and abuse,

• be transparent to users so that you know the hows and whys of the score (the correct level needs to be found here to prevent gaming)

• accept reputation for any provable identity (including other systems),

• collect explicit scoring from users,

• implicitly derive reputation of identities by observing current and past behavior,

• associate multiple identities. This means that http://alice.example.com should be able to associate her good karma with her secret http://timerider.example.org identity. This association must be kept hidden for others,

• recognize different categories. A person may be highly rated in some areas, and not in others,

• use a voting model that matches the real world. This model must be limited and untraceable between all parties. Positive behavior should be rewarded.

APIs needed:

• Signup. A user signs up by proving to the system that she own a URL. In exchange, the system creates some shared secret that can be used to authenticate (and possibly encrypt) API requests and responses.

• Bind. Binds an identity to a user’s existing identity.

• Lookup. Looks up the reputation for a specific category. The set of categories is intentionally kept small for simplicity.

• Vote. Submits a reputational vote for a user and a specific category.

• Some security related APIs with a simple way to handle the life cycle of keys and trust.

There could be some possible APIs for user’s profile management, and perhaps statistics.

For the back-end, there are other APIs that needs to be implemented to handle decentralized sharing and calculation of scores. More on that in a later post.

My old friends at VeriSign just opened up their VIP authentication APIs. I like the idea of a VIP developer community. Good luck, guys!

Currently the APIs are the SOAP only, but maybe other flavors will follow. Maybe we’ll see some simpler REST APIs similar to the ones I made for Yubico a while back: Yubico Developer APIs.

I’ve recently had the pleasure of writing some Actionscript 3.0 code for the Flex 3 platform.

Actionscript has some interesting properties (like the dynamic directive to create classes that allow monkey patching mid-flight..)

It also has C# style implicit getters and setters to hide functions behind properties. Not sure if it’s always a good thing, but anyway.

One error message took me ages to understand: Error: Attempted access of inaccessible method get through a reference with static type Class.

That’s what you get when you out of habit tuck a few parentheses at the end of your getter,

var a:ClassA = ClassA.get();

var a:ClassA = ClassA.get;

So, watch out for those habitual parentheses at the end. Severe Duh! warning for old time Java programmers.

This is big. All Usenix proceedings are now available for free.

Matt Blaze has more on the background.