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?

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.

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.

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.

Matt Blaze has more on the background.

Unfortunately, relying parties have to go through a lot of extra work logging people in and merging existing user accounts.

OpenID is already quite difficult to enable as it is, and now relying parties have to implement several new API calls.

Neither of these APIs seem to have been openly discussed and it’s not clear how they were designed. Is there a public security analysis? Why are high-value parameters such as “I agree to the terms of service” sent in the clear and unsigned?

Clickpass is a promising idea, but my advice to an RP would be to hold off implementing it until the protocol has had some time in the open.

Can’t wait to see how they will mix this goody-bag of new variables such as SMS, location, device movement, voice, mobility, etc., into their identity and authentication solutions.

Nothing You Can Do About It

What’s better than writing some music to get over it? Here’s a rocker in my best Dizzy Miss Lizzy style, dominant 7ths and all.

As always, Sibelius Scorch users can see and play some of my songs straight in the browser.

As a result, it seems it was hacked in a day and thousands of user names and passwords (from all walks of life) are now in the wild. Some people can’t resist a challenge apparently.

Lars Olofsson shows some interesting statistics about password choices and lengths, linked from Flashback.

What does this mean for an OpenID user?

Do your due diligence.

OpenID can provide tremendous value for its users, but all OpenID providers are not equal. Look at how they make you log in. Ask them how they store your data and about internal and external processes. Ask about how they keep your data private and secure. Make sure you know how they handle your usage trails.

And choose providers well.

One of the pain points with OpenID is that it’s quite hard to implement it as a customer. If you’re a small business with a home-grown web site, it’s a daunting task, despite excellent write-ups and a number of excellent software components.

Mom and Pop needs a simpler way of adding OpenID to their site. An identity proxy service that takes care of all OpenID magic with a simple API that customers hand the received the OpenID identifier to and get the equivalence of a yes/no back from the API?

I think the browser redirects, return addresses and trust roots (realms) could be properly handled as per the protocol.

Hmmm….. Anyone interested? ;)