Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Abstract

This document is a product of the User-Managed Access Work Group. It records the specific requirements 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
  • Eve Maler
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

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

Each requirement has a number, a short title, normative requirement text, and optionally further explanation that is informational. Please copy and revise an existing requirement in adding new ones. Following are the meanings of the status keywords:

  • Proposed: Status when first submitted or still under discussion
  • Approved: Needs to be met 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

Approved Requirements

R#

Title

Requirement

Explanation/commentary

R1

Host/AM separation

It must be possible to provide Host and AM functions in separate Web domains.

Approved on 2009-10-01.

R2

Resource orientation

User data access and service access must be enabled through accessing Web resources that have URLs.

Approved on 2009-10-01.


Proposed Requirements

P#

Title

Requirement

Explanation/commentary

P1

Resource-specific policy limitation

The deployer of an AM must not be required to do any special configuration to enable the AM to present to the User, or to make decisions regarding Requester access to, any resource-specific policies that apply to the resources available at a Host.

Examples of differential filtering of resources include photos of different resolutions, calendars covering different time periods or levels of detail, and locations at address vs. city level. (Paul has an AI to rewrite this one.)

P2

Terms persistence

A set of terms for accessing a resource must be accessible as a Web resource with a URL.

 

P3

Host impersonation of Requesters

A Host must not be able to impersonate Requesters in interacting with an AM.

This came up on 2009-10-01.

P4

Host correlation of multi-Requester activity

A Host must not be able to correlate the same Authorizing User's activity at multiple Requester applications.

This came up on 2009-10-01. Can it be combined with P3?

P5

User AM choice

The UMA protocol must not negatively impact a User's prerogative to choose or even self-host the AM that will protect a resource on any Host.

 

P6

Host following authorization instructions

A Host must allow or deny Requester access to a resource according to a User's desires as conveyed by an AM access decision, or inform the AM of instances where the User wished to grant access but the Host did not or could not.

 

P7

User-defined constraint on access

A Host must not grant a Requester access to a resource in cases where
the AM gave instructions denying access.

 

P8

Access audit log

A Host must inform the AM protecting a particular resource on that Host in a timely way of all successful Requester access events.

 


Change History

Version Date Comment
Current Version (v. 1) Oct 01, 2009 16:23 Former user
v. 14 Dec 15, 2015 14:39 Eve Maler
v. 13 Feb 10, 2011 23:06 Former user
Migration of unmigrated content due to installation of a new plugin
v. 12 Feb 10, 2011 23:06 Former user
Migration of unmigrated content due to installation of a new plugin
v. 11 Feb 10, 2011 23:06 Former user
Migration of unmigrated content due to installation of a new plugin
v. 10 Feb 10, 2011 23:06 Former user
Migrated to Confluence 4.0
v. 9 Feb 10, 2011 23:06 Former user
New emergent design principle #13 on "digital signatures" added.
v. 8 Mar 20, 2010 13:57 Former user
Add DP12 as discussed on 2010-03-18
v. 7 Dec 16, 2009 21:02 Former user
v. 6 Nov 12, 2009 11:00 Former user
v. 5 Nov 03, 2009 12:39 Former user
Added new emerging design principles generated during the first half of UMA F2F 2009-11-02
v. 4 Oct 16, 2009 13:45 Former user
General editorial changes, and decisions made 2009-10-15
v. 3 Oct 08, 2009 15:20 Former user
Added the requirements that were pre-approved as part of the charter approval process
v. 2 Oct 08, 2009 15:11 Former user
Added notations to P4, added P9, and added section for Design Principles
v. 1 Oct 01, 2009 16:23 Former user
  • No labels