Eve Maler kindly prepared an excellent set of slides for me to present at IIW#16 in Mountain View, CA late April: UMA_for_IIW16_2013-05

After discussions during the presentation, I believe one of the technical issues that still causes confusion is the fact that UMA uses three (3) distinct OAuth2.0 Tokens:

• AAT Tokens: Authorization API Token — this OAuth2.0 token is used by the Client to prove (to the Authorization Server) that it has authorization to access the APIs at the Authorization Server.
• PAT Tokens: Protection API Tokens — this OAuth2.0 token is used by the Resource Server to prove (to the Authorization Server) that the Resource Owner (e.g. Alice) has provided it (the Resource Server) with authorization to register Alice’s resource at the Authorization Server.
• RPT Tokens: Requesting Party Tokens — this OAuth2.0 token provides authorization for the Requesting Party to access resources at the Resource Server.

Here are the key take-aways:

1. All three tokens are OAuth2.0 tokens.
2. All three tokens are issued by the Authorization Server (or what used to be called the Authorization Manager in UMA).
3. All three tokens should ideally be used in conjunction with the relevant parts of the UMA Binding Obligations (BO) spec. The BO spec tells the parties involved what their legal obligations will be.