Scope Transfer Of Information (RTOI)

Why

The various use cases and specifications of UMA use "scopes" to define functionality and/or capabilities that can associated to a Resource and therefore assigned to a Requesting Party (Subject). The collection of "scopes" can change over time and may be contextual specific. There needs to be a clear definition of what "scopes" are applicable to a particular use case and context.

How

Define a scope category system that defines the various scope sets. A scope category shall explain how is shall be used ... the context and audience.

The following scope categories apply to all use case:

Category	Description	Context	Example
registered	Scopes Currently associated with a Registered Resource.  A Resource will have an initial set of scopes when it is registered.  The set of registered scopes can change over time.	RO: Resource Management	["a","b","c","d","e"]
template	Scopes associated to a Resource Type. These scopes could be considered "public" and known by anyone, Theses scopes may be used as a set of "default" scopes by either the Resource Owner or the Requesting Party	All	["a","b","c",d"]
private	Scopes that are assigned to a Resource either initially (in addition to the "template" scopes) or are added after the Resource is registered.  These scopes should not be publicly known. They can be "adhoc" added to a Resource	RO: Resource Management	["e"]
request	Scopes the Requesting Party specifies when trying to access a Resource	RqP: Resource sharing	["c"]
token	Scopes related to the current Requesting Party Token (RPT)	RqP: Resource sharing	["c","d"]
policy	Scopes currently allowed for the Requesting Party based on a Policy	RqP: Resource sharing	["a","c","d","e"]

What

Types

Each resource has a type. Types should be pre-defined and have a meaningful name. Each type shall have an associated set of scopes. These are the template scopes.

Resource Server (RS) "public" configuration, implementation Example:

{
  "scopes": {
    "meta": {
      "description": "Meta data about the resource"
    },
    "content": {
      "description": "The content (JSON) related to the resource"
    },
    "print": { ... },
    "download": { ... },
    "transfer": { ... }
  },
  "types": {
    "healthcare": {
      "scopes": [ "meta", "content", "print" ]
    },
    "finance": {
    }
  }
}

Resource Owner:

The Resource Owner (RO) creates Resources and manages their "registered" scopes.

• It is suggested that the RO use the "template" scopes that are defined by the Resource Server, to initially register a Resource.
  • The RO can add extra scopes to a registered Resource. The are the "private" scopes.
  • The RO grants access to a resource with a collection of permissions.
  • The RO can add / remove scopes for an individual RqP

Requesting Party:

• For Resources that are "shared", the RqP can obtain the
  • policy scopes
  • template scopes
• When a Resource request is submitted to the Resource Server
  • request scopes are sent (and returned)
  • token scopes are returned, from the RPT