Abstract 

This document is a non-normative set of auxiliary material produced by the User-Managed Access Work Group. It provides advice to, and discussions relevant to, developers and deployers of UMA-enabled software systems, services, and applications.

...

Rather than the resource description document pointing to a series of scope URIs that must be dereferenced (as was the case in UMA V1.0.x), the authorization server in UMA V2.0 can instead make use of the OpenID Connect discovery document and its scopes_supported metadata item, which, when filled with (the same) scope description document URIs, allows for development-time discovery of the necessary scope information.

...

Anchor
extension-oppties extension-oppties

Extension Opportunities

UMA presents a number of opportunities for extension. This section discusses some that have arisen in UMA design discussions that generally have not been taken advantage of, but which may be of interest to third parties.

Anchor
extension-profiles extension-profiles

...

Using Alternate Communications Protocols

...

In some circumstances, it may be desirable to couple UMA software entity roles tightly. For example, an authorization server application might also need to act as a client application in order to retrieve protected resources so that it can present to resource owners a dashboard-like user interface that accurately guides the setting of policy; it might need to access itself-as-authorization server for that purpose. For another example, the same organization might operate both an authorization server and a resource server that communicate only with each other behind a firewall, and it might seek more efficient communication methods between them.

...

In such cases, parts of UMA's flows may require profiling or extension because it is only defined over HTTP. Where appropriate, use the the uma_profiles_supported configuration  configuration property to flag usage of a documented profile or extension.

...

(See issue #267.)

Anchor
rreg-use-cases rreg-use-cases

Resource Registration

...

for OAuth and OpenID Connect

UMA is defined by two specifications. User-Managed Access 2.0 ("Core") makes use of OAuth 2.0 Resource Registration ("RReg"). The latter is meant to be applicable not just to the UMA extension grant of OAuth but also to the other OAuth grants and to OpenID Connect as well, as explained in the introduction to that specification. These propositions need fuller examination and testingThis extensibility has been designed in to RReg, but it needs to be fully tested.

(TBS - add diagrams for the use cases) 

(See issue #273.)

Anchor
openapi openapi

OpenAPI Format for Resource Registration

Currently, a special-purpose data format is used for registering resources and their scopes. The notion of making use of the Swagger-based OpenAPI format has been discussed. (See issue #288.)

Anchor
reduce-chatter reduce-chatter

Facilitating Chatter Reduction at the Resource Server

Enhancing the information returned by the authorization server to the resource server could enable the latter to respond more efficiently in the case of too-frequent client access attempts. (See issue #282.)

Anchor
discovery-at-as discovery-at-as

Informing the Authorization Server About Protected Resource Locations

In UMA V2.0, the uri property of the resource registration document was removed. Those wishing to use the resource server's communications channel with the authorization server to communicate information about a protected resource's location may be interested to look at this area. (See issue #270.)

Anchor
discovery-at-as discovery-at-as

Cascading Authorization Servers

A proposal has been made for enabling a cascading series of authorization servers to contributed to the contents of a requesting party token (RPT). (See issue #260.)

Anchor
discovery-at-as discovery-at-as

Hashed Claims Discovery

A proposal has been made for enabling an authorization server to convey its desired value for a pushed claim to a client in a privacy-sensitive way using a hashed value in a need_info response. (See issue #254.)

Anchor
resource-baskets resource-baskets

Resource Baskets

Currently, it is only possible for resource servers to register "flat" resources for protection, and for authorization servers to have no sophisticated understanding of their structure. It would be possible for an extension to resource description documents to description greater structure and relationships. (See issue #31.)

Anchor
shoebox shoebox

Notification Endpoint

In concert with the technical capabilities of UMA, it would be powerful to require the resource server to notify the authorization server on the resource owner's behalf of certain actions, or actions not taken, either as part of UMA flows (such as refusing to give access even if an RPT grants permission) or outside of UMA flows (such as giving access due to a court order). The Kantara consent receipt standard is one important format that could be made use of together with an endpoint dedicated to such notification. (See the "shoebox issues" (a shoebox being where one might keep all one's receipts).)

...

Anchor
ETag ETag

Managing Resource Registration Revisions 

...