Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Common Building Blocks (Dimensions)

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 @@link, 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 @@link is an example of person-to-self sharing. The calendar scenario @@link 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. @@more re claims

@@

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 @@link by its nature involves

a requester having to access multiple protected resources, likely from

different hosts. The scenario related to moving resources @@link 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 @@link tends to involve actors that serve as

both hosts and requesters. The trusted claims scenario @@link 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 @@link 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 @@link

could mention that most calendar feeds are shared today through URL

copying and pasting.

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:

...

  • 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.
  • Sharing Models

*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 @@link is an example of person-to-self  sharing. The calendar scenario @@link 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.

Include Page
uma:calendar_scenario
uma:calendar_scenario

...