...

The motivation for creating this proposal was an attempt to find a simple solution for mainly solving the Distributed Authorization Scenario described in the UMA Workgroup. It is also an attempt to reuse more of OAuth than the initial protocol sketch of ProtectServe did back then. Moreover it is an attempt to create several small specifications than one big one. For instance all the mechanics of how to do terms and policies is out of scope for the core protocol.

The main requirement behind this is to be able to do mass authorization without the need for each client to obtain a token for each individual server. Instead the Authorization Manager is introduced to only create a relationship with each Host once and after that any Requester only needs to create a registration with the AM instead of each Host. Moreover the new Requester could additionally be added as new Host in this step, saving some redirects.

The main idea

In the IETF version of OAuth the initial OAuth specification will be divided into at least two: One is describing how to perform a authorized request to a protected resource and the other is describing one possible way of obtaining the OAuth token (by using the redirect mechanism).

...

• Requester is performing authorized requests to a Host (in OAuth terms it's a client)
• Host is the component which hosts a resource which a Requester wants access to (in OAuth terms it's a server)
• Authorization Manager (AM) is the component in the middle which is capable of negotiating between Requesters and Hosts and which can give out tokens. It might also be the central point for managing terms and policies in the future.

Protocol Overview

The protocol contains two initial steps:

1. The registration of the Requester with the AM to be able to call the AM Requester API
2. The registration of the AM with the Host to be able to call the Host Requester API

These steps only need to be done once for each pair (Requester, AM) and (AM, Host). They are long running associations. Both steps are done via normal 3-legged-OAuth. In the end the Requester owns an OAuth Token for the AM Requester API and the AM owns an OAuth Token to call the Host Requester API.

The normal protocol flow contains two additional steps:

1. The Requester obtaining an OAuth token from the Host via the AM
2. The actual call of the Requester to the protected resource on the Host