Is this a contradiction in terms? A token with which you can gain authorized access to data resource without giving your identity ? It sounds a bit fanciful to say the least. And even if it didn’t why would we even want it ?
I suggest that it is not, and that we do; and I’d like to propose, design and develop a technology that makes it possible.

First things first, what precisely do I mean by these terms.

Portable: The user can use the exact same token multiple places. Further, the access control enforcement entity need make no call to an external access control policy store in order to make a decision based on the token.

Anonymous: The token contains no personal information about the user, and the entity receiving the token, using it to establish that the user is indeed authorized to access the resource in question, can not establish the user’s identity with the token. Nor is the users identity needed in order to perform the authorization. Proper ownership of the token is established through PKI and cryptographic handshakes.

Authorization: the token is for authorization only, no authentication. If for granting access to resources the user’s identity is required, it must be established some other way.

Token: it is a piece of data. text or binary, XML or plain text. Opaque or not. Mostly passed in the HTTP headers between client and server in the client-server web model. But other ways should be just as workable, Smart cards for example. Headers have limited size, so HTTP POST must be available. In my proposal I’ll stick with XML as the format of the token. SAML tokens are passed in headers now; this token can be passed in the same way.

A fundamental question is whether or not anonymous authorization is even desirable. How can you maintain authorizations without having a database of your users in order to keep track of who you gave the access to.

And if you have a database of all your users and all the access they have, why not authenticate them and check the database for what access they should have and grant or deny their requests accordingly. No need to have special access tokens. This is how things are done now.

I suggest that this is not very efficient for ultra-large scale or distributed solutions. Every single request to be looked up against a database of access control lists. Granted, those ACL databases can themselves be cloned and distributed out to all access control enforcement points. And this is done. Excellent performance is achievable. At the expense of a complex and elaborate setup.

But it requires all these access enforcement points to be in contact with a central system to get fresh copies of the ACL database. And what about portability ? Will the enforcement point accept ACL databases from multiple sources. This may not make much sense if there data is in one place; Just have the one policy creation point and one user store. But if the data is in multiple locations ? As in a distributed system. Will all of these enforcement points authenticate the user against the same user store and authorize the requests against the same policy store? If you have enough copies of both it can be made to scale, but it is hardly efficient. User federation does not help.

With a truly portable token the enforcement point need make no reference to any other access control policy source to be able authorize or reject the request. There is then no need for high performance user stores and distributed access control policies. This significant. There are far more authorization operations than there are authentication operations. An arrangement where the two are not linked is more robust and scaleable. True, a user should only be authenticated once per session, but that still requires a user store to be available. Even with federation. So a token that can be used without a user database is to be preferred from a performance point of view.

 

NB. This is purely technical examination of these issues. From a business point of view things are quite different: The users identity is a valuable commodity that should be gathered up as much as possible along with whatever action the user takes. The legal aspect is neutral: the user’s request is properly authorized either way.

Here is a high-level view of REST-ful use of a data access token.

 

1 User request a token from the data owner. The token can bundle multiple different requests to access data belonging to the owner.

2 Owner grants the token request after approving all the token grants access to. Sending the finished token back to the user.

Note: It makes no difference which party initiates the process of creating the token. At the end both parties have agreed what request are granted by the token, and that is enough. The owner will always have the last word, and can add limitations such as timing without input from the user, but then the user can always decline to use the token.

later

3. send token along with request.

4. check token and check user’s request against the token.

The enforcement point make no reference against a user database or rules database and therefore the token need contain no information directly identifying the user. The token can not be truly anonymous since the user must be able to establish that the user is proper user of the token, but this will not be in the form of a username.