Crossed-out numbers indicate proposed requirements that have been discussed and rejected. Bold numbers indicate proposed requirements that have been discussed and accepted, in some form, in the list above.
The AM is not required to understand the representations of resources it is charged with protecting.
We reworded this heavily and approved it on 2009-10-15 as R4.
A set of terms for accessing a resource must be accessible as a Web resource with a URL.
Host impersonation of Requesters
A Host must not be able to impersonate Requesters in interacting with an AM.
This came up on 2009-10-01.
Host correlation of multi-Requester activity
A Host must not be able to correlate the same Authorizing User's activity at multiple Requester applications.
User AM choice
The UMA protocol must not negatively impact a User's prerogative to choose or even self-host the AM that will protect a resource on any Host.
Host following authorization instructions
A Host must allow or deny Requester access to a resource according to a User's desires as conveyed by an AM access decision, or inform the AM of instances where the User wished to grant access but the Host did not or could not.
User-defined constraint on access
A Host must not grant a Requester access to a resource in cases where the AM gave instructions denying access.
Access audit log
A Host must inform the AM protecting a particular resource on that Host in a timely way of all successful Requester access events.
Correlation of Authorizing User by multiple Hosts
For two resources on different Hosts owned by the same Authorizing User and managed by the same AM, the AM must not allow one Host to be able to discover the User's relationship with the other Host.
For example, a user might use the same AM to protect resources at LinkedIn along with their personal interests and hobbies. We reworded this on 2009-10-15 and approved it as R3.
Ensure that it's possible for AMs to offer a "POST once" setting.
This is critical for payments and the like.