Abstract

This document is a product of the User-Managed Access Work Group. It records the scenarios and use cases governing the development of the User-Managed Access protocol and guiding associated implementations and deployments.

Status

This document is currently under active development. Its latest version can always be found here. See the Change History at the end of this document for its revision number.

Editors

• Hasan Ibne Akram (lead editor)
• Gerald Beuchelt
• Domenico Catalano
• Maciej Machulak
• Eve Maler
• Christian Scholz
• Thomas Hardjono

Intellectual Property Notice

The User-Managed Access Work Group operates under Option Liberty and the publication of this document is governed by the policies outlined in this option.

Table of Contents

Introduction and Instructions

This document is a product of the User-Managed Access Work Group. It records the scenarios and use cases governing the development of the User-Managed Access protocol and guiding associated implementations and deployments, and outlines technical issues raised thereby.

Please copy and revise an existing scenario in adding new scenarios and subordinate use cases. Each scenario is created as a separate child wiki page with a name like xyz_scenario and then linked from here. Change the status keyword in each scenario and use case title as appropriate:

• Pending: Initial status when first submitted
• Accepted: Needs to be accounted for in UMA V1 and/or its associated compliant implementations
• Deferred: Relevant to the problem space; may be considered in future versions
• Rejected: Out of scope

Edit the descriptions of technical issues and scope questions to reflect (or point to) group decisions about how to handle them.

As a further refinement to help us in classifying and prioritizing the use cases, we would like to add a section to each use case describing the building-block features or dimensions that are present in a given use case.  The current list of features or dimensions are as follows:

• Scope: This is the scope of actions that are available to be performed.
• Cardinality: This pertains to the number of participants involved in the use case. For example, how many Hosts and AMs are involved within the use case.
• Nature of host: This dimension pertains to the host being either a host only, or whether it also takes-on the role of a Requestor in some sub-scenario of the use case.
• Dynamism vs Static-ness: This dimension pertains to the Host-AM interaction. It attempts to capture the degree of interactions required between a Host and AM in satisfying the use case scenario. This can range from all participants having been pre-configured with information about each other (very static), to the situation in which the AM and Host must communicate or interact every time A Requester submits a request.
• Resource discovery: This dimension addresses the aspect of the degree to which a new Requestor must learn about available resources.
• Nature of access to protected resource: This dimension is related to the Scopes dimension and addresses the means used to access protected resources at a Host, such as whether (a) an API end-point is identified and used, or (b) a content-oriented approach (such as URLs) is used.
• Person-to-self: This dimension is closely related to the Nature of Host dimension, and may only occur is rare use cases.  It pertains to the situation in which the same entity (user) is required to connect separately to the Host in order to explicitly perform some task under a different role. Thus, although the Host may identify the entity (user) differently on each of these connections, the situation is such that only the same entity (user) can complete this task. hence this dimension is referred to as person to herself/himself.

Change History