Page Comparison

...

(2) PURPOSE: Please provide a clear statement of purpose and justification why the proposed WG is necessary.

The purpose of this Work Group is threefold:

• To develop a set of draft specifications that enable a resource owner to control the authorization of data sharing and other protected-resource access made between online services on the owner’s behalf or with the owner’s authorization by an autonomous requesting party, and to facilitate the development of interoperable implementations of these specifications by others. It is a particular priority in this effort to enable and empower individual people in the resource owner role, for the purpose of gaining personal control of his or her personal information.

• To develop contractual framework specifications that facilitate establishing obligations to which operators and users of services taking part in access-related interactions must adhere, and to encourage the adoption of the framework in identity and access federations and other ecosystems that enable distributed authorization. It is a particular priority in this effort to enable setting the rules of engagement for informed, meaningful control of access.

• To develop or facilitate the creation of one or more technical-level and business-level profiles that enable the interconnection of interoperable UMA-compliant ecosystems with high-value, privacy-preserving identity federations and ecosystems.

Specifically, this Work Group is responsible for:

...

Developing contractual framework specifications as appropriate

...

UMA 2.0 Recommendations define a) a means for a client, representing a requesting party, to use a permission ticket to request an OAuth 2.0 access token to gain access to a protected resource asynchronously from the time a resource owner authorizes access and b) a means for an UMA-enabled authorization server and resource server to be loosely coupled, or federated, in a secure and authorized resource owner context.

The purpose of this Work Group is:

• To maintain the UMA specifications and consider developing enhancements to and any future versions of them
  • For example, to consider whether extension and profile proposals contributed to the Work Group should result in Work Group deliverables
• To develop Business Model reports and/or specifications that support the enablement of a license-based model for controlling access rights to personal digital assets, in liaison with other relevant bodies
  • For example, working with the Kantara Consent and Information Sharing Work Group
• To promote UMA adoption
  • For example, by offering support for profiling and extension creation and creating educational materials
• To promote interoperability of independent implementations of UMA

(3) SCOPE: Explain the scope and definition of the planned work.

The specifications Deliverables must meet the following basic functional requirements, in addition to specific use cases and requirements later identified by this Work Group:

• Support the notion of a distinct online service for managing data-sharing and service-access relationships ("access relationships" for short) between an individual and his or her online services that request such access
• Allow an individual to select policies and enforceable contract terms that govern access, as well as data storage, further usage, and further sharing on the part of requesting services
• Allow an individual to conduct short-term and long-term management of access relationships, including modifying the conditions of access or terminating the relationship entirely
• Allow an individual to audit and monitor various aspects of access relationships
• Allow requesting services to interact directly with responding services in a fashion guided by policy while an individual is offline, reserving real-time user approval for extraordinary circumstances
• Allow requesting services to interact with multiple responding services associated with the same individual

The specifications must meet the following basic design principles, in addition to any emergent design principles later identified by this Work Group:

...

core design principles:

• Simple: Simple to understand, implement in an interoperable fashion, and deploy on an Internet-wide scale
• OAuth: OAuth-based to the extent possible (while contributing bug reports and RFEs around extensibility, security, and privacy to the IETF OAuth group)
• ID-agnostic: Agnostic as to the identifier systems used in an individual's various services on the web, in order to allow for deployment in "today's Web"
• RESTful: Resource-oriented (for example, as suggested by the REST architectural style) and operating natively on the Web to the extent possible
• Modular: Modular (e.g., incorporating other existing specifications by reference where appropriate, and breaking down this Work Group's draft specifications into multiple pieces where reuse by different communities is likely)
• Generative: Generative (able to be combined and extended to support a variety of use cases and emerging application functionality)
• Fast: Developed rapidly, in an "agile specification" process that can refactor for emerging needs

They must also meet the following additional design principles:

• Cryptography: Avoid adding cryptography burdens as part of the Simple principle
• Privacy: Protect the privacy of the resource owner and requesting party
• Distributed ecosystems: Complexity should be borne by the authorization server vs. the resource server or client, if possible
• Authentication: Stay out of the authentication business as much as possible
• User experience: ease of end-user experience should inform UMA’s protocol design

They must also meet the following functional requirements:

• Support the notion of a distinct online service for managing data-sharing and service- and device-access relationships ("access relationships" for short) between an individual and other parties that request such access
• Allow a person (individual or legal person) to select policies and enforceable contract terms that govern access, as well as data storage, further usage, and further sharing on the part of requesting services
• Allow a person to conduct short-term and long-term management of access relationships, including modifying the conditions of access or terminating the relationship entirely
• Allow a person to audit and monitor various aspects of access relationships
• Allow requesting services to interact directly with responding services in a fashion guided by policy while an individual is offline, reserving real-time user approval for extraordinary circumstances
• Allow requesting services to interact with multiple responding services associated with the same individual

(4) DRAFT TECHNICAL SPECIFICATIONS: List Working Titles of draft Technical Specifications to be produced (if any), projected completion dates, and the Standards Setting Organization(s) to which they will be submitted upon approval by the Membership.

It is anticipated that the The following technical specifications will be produced, with modular spec boundaries subject to change; both are anticipated to be submitted to the IETF for further work and completion:may be developed in 2018:

• One or more extension and/or profile specifications
• Business Model Clause Templates for User-Managed Access (UMA) Profile of OAuth 2.0
• OAuth Dynamic Client Registration Protocol
• OAuth 2.0 Resource Set Registration
• Binding Obligations on User-Managed Access (UMA) Participantsthis may be a report instead; final title to be determined)
• Updates to the UMA 2.0 specifications as warranted

(5) OTHER DRAFT RECOMMENDATIONS: Other Draft Recommendations and projected completion dates for submission for All Member Ballot.

It is anticipated that the following auxiliary materials will be produced, at a minimum:

...

The following reports are anticipated to be developed in 2018 (final titles and document boundaries to be determined):

• A Licensing-Based Model for User-Managed Access Overview
• Business Model Scenarios for User-Managed Access Implementation Guide

...

• Additional business model-related reports

(6) LEADERSHIP: Proposed WG Chair and Editor(s) (if any) subject to confirmation by a vote of the WG Participants.

At the time of this charter’s revision, following are the members of the leadership team:

• Chair: Eve Maler, XMLgrrl.comForgeRock
• Vice-chair: Maciej Machulak, Cloud Identity Ltd
• Technical specification editor: Thomas Hardjono, MIT
• Contractual framework editor: Dazza Greenwood, Civics.com
• Graphics/UX editorHSBC
• Graphics and User Experience Editor: Domenico Catalano, Oracle
• Implementations Coordinator: Maciej Machulak, HSBC

(7) AUDIENCE: Anticipated audience or users of the work.

The anticipated audience for the documents produced by this Work Group includes developers, deployers, and designers of online services digital services, including IoT device ecosystems, that act on behalf of individual users. The group also anticipates gathering input from individual users of online services in order to respond to their needs and preferencesnatural and legal persons, including legal representatives of organizations operating such services.

(8) DURATION: Objective criteria for determining when the work of the WG has been completed (or a statement that the WG is intended to be a standing WG to address work that is expected to be ongoing).

This is intended to be a standing Work Group is an ongoing effort; it anticipates developing a draft V1.0 set of technical specifications and other auxiliary materials by the end of 2013, facilitating the development of multiple independent draft implementations as appropriate during this time, and a draft contractual framework soon after. This targeted duration and other aspects of this charter (except the IPR policy stated below) are subject to review, amendment, and extension as approved by the Kantara Leadership Council.to address work that is expected to be ongoing.

(9) IPR POLICY: The Organization approved Intellectual Property Rights Policy under which the WG will operate.

Kantara IPR Policy - Option LibertyPatent & Copyright: Reciprocal Royalty Free with Opt-Out to Reasonable And Non discriminatory (RAND) (HTML version)

10) RELATED WORK AND LIAISONS: Related work being done in other WGs or other organizations and any proposed liaison with those other WGs or organizations.

This Work Group has a number of dependencies on, and shared goals with, the output of other efforts. The Kantara groups and external efforts with which this Work Group intends to liaise informally include (but are not limited to):

• OASIS XACML Technical Committee
• OASIS XDI TC and other personal cloud standards efforts
• OpenID FoundationKantara Consent and Information Sharing Work Group
• Kantara Consent Management Work Group
• OpenID Foundation HEART Work Group
• Open Identity Exchange
• IETF OAuth Working GroupDirect, Blue Button Plus, and other external and related Kantara healthcare groups

(11) CONTRIBUTIONS (optional): A list of contributions that the proposers anticipate will be made to the WG.

...

• J. Trent Adams, ISOC
• Hasan Akram, Fraunhofer Institute of Secured Information Technology
• Joe Andrieu (individual participant affiliated with SwitchBook)
• Gerald Beuchelt (individual participant affiliated with MITRE)
• Paul Bryan, Sun Microsystems
• Andy Dale (individual participant affiliated with OCLC)
• Iain Henderson (individual affiliated with Mydex CIC)
• Hubert Le Van Gong, Sun Microsystems
• Mark Lizar (individual affiliated with Identity Trust CIC)
• Eve Maler, Sun Microsystems
• Andrew Nash, PayPal
• Drummond Reed, Information Card Foundation
• Christian Scholz, DataPortability.org
• Paul Trevithick (individual participant affiliated with Azigo)
• Robin Wilton (individual participant affiliated with Future Identity)

History