OpenID Artifact Binding + AX Lite Sample Site


Working Group

Charter : http://wiki.openid.net/Artifact_Binding
Mail list: specs-ab@openid.net
Repository: BitBucket Draft:HTML Version

TEST DRIVE Artifact Binding

PHP_RP
Javascript RP

This site is an sample implementation of OpenID Artiact Binding: (an OpenID Foundation Chartered Working Group). You can find the specification repository at BitBucket and Web Friendly Version

Simple, Scalable and Extensible

In this implementation, user identities are stored as json file.

Since it is using JSON as the native identity format, it can add any number of attributes. It is extremely extensible.

Any number of identity can be created. However, since this implementation happens to use file system for the identity storage, it has its limitations. In a more scalable implementation, it probably should be stored in Key=Value store.

Identity File

Here is a sample of an identity file:

In each identity, any number of credential can be registered. Credentials are labeled by "cd" prefix. In the example above, it is sha1 password, so, it is stored as "cd:sha1pass".

You can also add any number of attributes. Attributes are labeled with "ax:".

In the example, you see funky notation like "ja_Hani_JP". This is an iso notation for charset_Script_COUNTRY.

Attribute Exchange and OAuth

This draft is completely harmonized with OAuth2.0 May 13 draft.
At the same time, it does not overload the OAuth2.0 variables so we can take advantage of both OpenID and OAuth with it.

For example, "access_token" is not used for OpenID Assertion per se, so we can use it for any API access needs that arises in conjunction with it.

At the same time, it is capable of returning any number of attributes however large in the OpenID Assertion (remember that artifact binding does it sever-to-server and do not get browser restrictions), it SAVES ONE ROUNDTRIP than obtaining attributes through assertion, which happens to be either JSON or JSONP.

In this iplementation, as soon as the user gets back with the assertion, you have all the attributes you requested in an array.

Another good thing about this draft AX Lite is that unlike OAuth scopes, the RP can define whatever the set of the attributes they want to get. This flexibility through standerdization should merit many applications.

Secure and Mobile Friendly

One of the feature of the AB is that it does not send big requests nor response through the borwoser. This means, Also, it has other security features like:

Compatibility with OpenID 2.0

Yes. The assertion format is slightly different than OpenID 2.0. It is JSON instead of Key-Value Form Encoding.

Does it matter?

Probably not. The identifier is the same old OpenID 2.0 identifier so that RP does not need to migrate users, which inherently is a headache if one really wants to do. That is the important part.

Want Identity Data a.k.a. Attributes?

Absolutely. You can get them with your OpenID AB request. You do not need to make additional round-trip to get them.

Moreover, you can repeat the same Direct Assertion Request*1 to the server to get the assertion again, if the OP (and the user) permits it. Attributes through a Simple Standardized RESTful request. You get the data in JSON format so that you can use them immediately.

*1) You better be making sure that the RP is the right one. One way to make it sure is to encrypt the assertion with the intended RP's public key. This is also defined in this spec.

The size of implementation

So, the bells and whistles are so far so good. But it is so full with features, is it not complex to implement?

On the contrarlly, the size of the implementation is very small.

PHP OP relies on mhash, mcrypt, openssl, but the amout of the code is less than 400 lines including debug codes and HTML pages.

PHP RP is only about 200 lines, including HTML pages.

Low assurance RP can also be made of javascript. In this case, a user can just copy and paste the script to utilize this protocol.

[Top]