Sample Document - Testing - may be deleted
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
You can find a template for scenarios and subordinate use cases at the end of this document. Change the status of each scenario and use case appropriately, indicating the meeting date when the decision was made:
- accepted: accepted to be solved in UMA V1 and its associated compliant applications and implementations
- deferred: likely in the correct problem space but deferred for later consideration in future versions
- rejected: not considered to be in the UMA problem space
Scenario: Sharing a Single Resource with a Vendor
Submitted by: Eve Maler
Status: pending
(Provide description of the scenario with all nontechnical particulars, noting requirements, constraints, and other observations. Avoid diagrams.)
Use Case: Separate Resource Host, Relationship Manager, and Recipient
Submitted by: Eve Maler
Status: pending
(Provide description of a use case matching this scenario with all technical particulars, such as the topological configuration of protocol endpoint entities, potential wireframes, listings and assessments of technical issues, and anything else helpful.)
Scenario: (unique-title)
Submitted by: (participant-name)
Status: pending (change to accepted/deferred/rejected and note the date the decision was made)
(Provide description of the scenario with all nontechnical particulars, noting requirements, constraints, and other observations. Avoid diagrams.)
Use Case: (unique-title)
Submitted by: (participant-name)
Status: pending (change to accepted/deferred/rejected and note the date the decision was made)
...
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
| Table of Contents |
|---|
...
| Anchor | ||||
|---|---|---|---|---|
|
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.
Common Building Blocks (Dimensions)
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:
Dimension | Description | Example |
|---|---|---|
Nature of protected resource | A description of the sorts of protected resources at hosts in this scenario, and the scope values that might be applicable, ideally with real-life supporting evidence. Protected resources appear to fall on a continuum from API endpoint (such as status updates) to content-oriented (such as photos), and further, typical actions on them may usefully be classified in terms of how RESTful they are. | In the location services scenario, protection of a location service (a set of one or more API endpoints) might involve scope values such as "write location data", "read precise location data", and "read location data at a city level". |
Sharing models | A description of what sorts of access or sharing the scenario facilitates. Person-to-self sharing occurs when an authorizing user shares access with a service that is acting directly on the same user's behalf (a la "three-legged" OAuth). Person-to-service sharing occurs when an authorizing user shares access with a legal person operating a service that is acting on its own behalf (a la "two-legged" OAuth, where the client is autonomous). Person-to-person sharing (also known as "Alice-to-Bob sharing") occurs when an authorizing user shares access with a different natural person. (@@Fourth category of "person-to-rep sharing" where the autonomous company's service is operated by a human company rep?) | The location services scenario is an example of person-to-self sharing. The calendar scenario is written to explore person-to-self and person-to-service (@@and person-to-rep?) sharing options, but could also apply to person-to-person sharing. |
Nature of policies and claims | A description of the types of policies, and any resulting claims requested, that might be suitable for this scenario and its use cases. | The terms negotiation scenarios discuss likely claims needed in the course of assessing a requesting party's right to get access. |
Cardinality | An accounting of whether the scenario or any of its use cases necessarily involve multiple instances of any of the UMA entities. | The financial loan scenario by its nature involves a requester having to access multiple protected resources, likely from different hosts. The scenario related to moving resources by its nature involves two different AMs: the user's previously chosen AM and their newly chosen one. This information is often usefully conveyed with an architectural diagram along with descriptive text. |
Colocation | A description of likely cases where real-world applications might want or need to support multiple UMA endpoints. | The health data scenario tends to involve actors that serve as both hosts and requesters. The trusted claims scenario proposes that an application offering AM services might also need to be a requester in order to access the UMA-protected claims of some other ("primary") requester. |
Host-AM relationship | An accounting of how hosts and AM come to meet and trust each other in this scenario or its use cases. Dynamic discovery might be required or forbidden. AMs and hosts respectively might need to be well-known, or at least dynamically qualified before the connection is made. | The health data scenario might have a short list of approved AMs to which many hosts around the world may need to dynamically connect as soon as a new patient needs medical care. |
Protected resource discovery | A description of the anticipated method(s) by which a requester learns about a resource of interest to them. The methods may have a dynamic element to them or may require reconfiguration. The methods may or may not involve direct human assistance. | The calendar scenario could mention that most calendar feeds are shared today through URL copying and pasting. |
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
...
| Anchor | ||||
|---|---|---|---|---|
|
| Change History |
|---|