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.
...
Regarding the resource set registration API, it is common practice when using NoSQL databases to replicate entity tag (ETag HTTP header) revision information in the body of the response message as well, in a _rev property. The API does not mandate this property (though an early pre-V1.0 draft did include this property).
...
| Anchor | ||||
|---|---|---|---|---|
|
...
The PAT needs to work in a number of circumstances when the a human resource owner is offline. When a client attempts access to a protected resource, requiring the RS to use runtime portions of the protection API, the resource owner is not assumed to be present. At this point, any interactions with the resource owner, for example, access approval workflows, are conducted out of band of the protocol.
Many use cases assume that the resource owner is explicitly "offline", for example, unconscious in a hospital emergency room. Some anticipate that the resource owner may end up "permanently offline" after having asked for the PAT to be issued (such as "digital death" scenarios, which perhaps raise other long-term issues).
The authorization server thus needs to manage the issuance and expiration of the PAT and and any corresponding refresh token appropriately to ensure that the resource server has access when it needs it., or in cases when the resource owner is an organization or other non-person entity and can't interact with the AS at client attempted-access time. This is why UMA authorization is described as "asynchronous": When a client attempts access to a protected resource, requiring the RS to use runtime portions of the protection API, the resource owner is not assumed to be present. At this point, any interactions with the resource owner, for example, any access approval workflows through push notifications or other messaging systems, are conducted out of band of the protocol.
Many use cases assume that the resource owner is explicitly "offline", for example, unconscious in a hospital emergency room (the "break-glass" scenario). Some use cases anticipate that the resource owner may end up "permanently offline" after having asked for the PAT to be issued (such as "digital death" scenarios, which perhaps raise other long-term issues).
The authorization server thus needs to manage the issuance and expiration of the PAT and and any corresponding refresh token appropriately to ensure that the resource server has access when it needs it.
(Note that "break-glass" scenarios that involve enabling client access even in the absence of resource owner policy that permits it fall into the category of "mandatory access control" and are out of band of the UMA protocol. Deployments that allow such access may want to document the relevant circumstances in their agreements about parties' rights and responsibilities on a legal or contractual level.)
...
| Anchor | ||||
|---|---|---|---|---|
|
...