...

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).

In this specification we will use plain OAuth to perform an authorized request from a Requester to a Host. The only difference will be on how the Requester obtains a token for being used with the HostThe OAuth specification states that the described Redirection Based Authorization is only one way for a server to provide a client with a token. Therefor this specification is describing an alternative way for a client to obtain a server without the need for it to have a direct relationship with the server. This is done with the additional component of an Authorization Manager in the middle. So the actual call of the client to a resource on the server is done as described in the OAuth specification and only the way of obtaining that token is different.

This is done by a chained token transfer. For this the Requester calls the Token Requester API on the Authorization Manager (AM) and the AM in turn calls the Token Requester API of the Host. The Host then returns a token (maybe with prior checks) to the AM which in turn is given to the Requester which then can perform the actual call with it.

...

• 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 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

Initial Registrations

Requester - AM Registration

Each Requester which wants to use the AM's services need to register with the AM. This is usually triggered by the user on the Requester who wants the Requester to be able to access the user's resources.

The flow is a normal