Page Comparison

h1. Working Drafts

This page collects our draft specifications and other auxiliary material, and various other useful materials that may contribute to them.  See the list of child pages at the bottom for a summary.

The following diagram illustrates the "call tree" of key specifications and other documents that are relevant to the UMA universework. Click on boxes in the diagram to get the corresponding document. (Note that this
diagram
may not keep up with rapid spec changes and links only to one document even if there are multiple representations or versions or variants; the table below gives more detail where warranted.)

{html}
<map name="GraffleExport">
	<area shape=poly coords="346240,191132,370257,149103,419291,149103,460319,180125,435302,222154,386268,222154,346240,191132" href="http://kantarainitiative.org/confluence/display/uma/User+Stories">
	<area shape=rect coords="13795,702487,243169,774537" href="http://tools.ietf.org/html/rfc5785">
	<area shape=rect coords="4028,702487,12687,774537" href="http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html">
	<area shape=rect coords="6847,582404,212147,654454" href="http://tools.ietf.org/html/draft-hammer-hostmeta-13">
	<area shape=rect coords="539374,6847,705489,164114" href="http://kantarainitiative.org/confluence/display/uma/Simple+Access+Authorization+Claims">
	<area shape=poly coords="740514,254176,764531,212147,813565,212147,854593,243169,829576,285198,781542,285198,740514,254176" href="http://kantarainitiative.org/confluence/display/uma/User+Experience#UserExperience-UMATrustedClaims">
	<area shape=poly coords="346240,302210,370257,260180,419291,260180,460319,292202,435302,334231,386268,334231,346240,302210" href="http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+Cases">
	<area shape=poly coords="770535,378262,795552,336233,844586,336233,884614,368255,860597,410284,811563,410284,770535,378262" href="http://kantarainitiative.org/confluence/display/uma/UMA+Trust+Model">
	<area shape=poly coords="346240,413287,370257,371258,419291,371258,460319,403280,435302,445309,386268,445309,346240,413287" href="http://kantarainitiative.org/confluence/display/uma/UMA+Requirements">
	<area shape=rect coords="539374,211146,705489,283196" href="http://kantarainitiative.org/confluence/display/uma/Claims+2.0">
	<area shape=rect coords="706490,470326,936650,542376" href="http://tools.ietf.org/html/draft-hardjono-oauth-dynreg-00">
	<area shape=rect coords="507352,636442,737511,708492" href="http://tools.ietf.org/html/draft-ietf-oauth-v2">
	<area shape=rect coords="507352,330229,737511,402279" href="http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol">
</map>
<img border=0 width="600" src="http://kantarainitiative.org/confluence/download/attachments/17301540/spec-modules.png" usemap="#GraffleExport">
{html}

h2. Specifications in Progress

We are currently using ChristianEve's UMA-Specifications area on github -- [httphttps://github.com/mrtopfxmlgrrl/UMA-Specifications|httphttps://github.com/mrtopfxmlgrrl/UMA-Specifications] -- for our active spec development, with snapshots provided on at [http://mrtopf.clprojects.net/uma/|http://mrtopf.clprojects.net/uma/].this wiki. Following is an accounting of specs and their status.

|| Spec || Description || Status ||
| *UMA Scenarios and Use Cases* | Records the scenarios and use cases governing the development of the User-Managed Access protocol and guiding associated implementations and deployments. | Currently maintained directly on this wiki. Latest version is [here|http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+Cases]. We are behind on assessing and adding scenarios; see below on this page for the "scenario docket". |
| *UMA User Stories* | Records the use cases in a clipped "user story" form similar to that used by the Agile methodology. | Currently maintained directly on this wiki. Latest version is [here|http://kantarainitiative.org/confluence/display/uma/User+Stories]. |
| *UMA Requirements* | Records the specific requirements governing the development of the User-Managed Access protocol and guiding associated implementations and deployments. | Currently maintained directly on this wiki. Latest version is [here|http://kantarainitiative.org/confluence/display/uma/UMA+Requirements]. We treat design principles (beyond the ones in our charter) as "emergent", and collect them as we see fit. |
| *UMA 1.0 Core Protocol* | Defines the User-Managed Access (UMA) 1.0 core protocol. This protocol provides a method for users to control access to their protected resources, residing on any number of host sites, through an authorization manager that makes access decisions based on user policy. | ActiveLatest development currently takes place on [github|http://github.com/mrtopf/UMA-Specifications|http://github.com/mrtopf/UMA-Specifications]. A high-fidelity snapshot is keptversion is [here|http://mrtopf.clprojects.net/uma/draft-uma-core.html] (the [working draft|http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol]. onThe this site is a copy of the high-fidelity one that may not look quite right). Note that the core spec currently points to OAuth 2.0 draft 10, but draft 11 came out recently and we haven't synced with it yetformatting doesn't look perfect due to Confluence wiki limitations. |
| *Resource registration* | Defines Obsolete. Used to define the mechanism for hosts to convey important information about resources that the AM needs to protect. | This [spec|http://mrtopf.clprojects.net/uma/draft-uma-resource-reg.html] has seen significant new progressNow included directly in the core spec. |
| *Dynamic client registration* | Defines how hosts can dynamically discover information about an AM and how hosts and requesters can dynamically register at an AM to get a unique client identifier and optional secret. | Some UMA group participants have contributed an [Internet-Draft|http://tools.ietf.org/html/draft-hardjono-oauth-dyn-reg-v1dynreg-00] to the IETF on this (pretty HTML version [here|http://mrtopf.clprojects.net/uma/draft-oauth-client-registration.html]), and intendhope to continue working on it as an OAuth WG action item. |
| *Protocol Issues* | Random list of issues we need to burn down in working on the specs. | This list is known not to be complete. We are also putting specific spec design issues directly into the specs on [github|http://github.com/mrtopf/UMA-Specifications|http://github.com/mrtopf/UMA-Specifications]. |
| *Claims 2.0* | Defines a JSON-based format for expressing claims and requests for claims. | Currently maintained directly on this wiki. Latest version is [here|http://kantarainitiative.org/confluence/display/uma/Claims+2.0]. (See also the [proposal|http://kantarainitiative.org/confluence/display/uma/User+Experience#UserExperience-UMATrustedClaims] for third-party-asserted "trusted claims".) |
| *Simple Access Authorization Claims* | Uses the Claims 2.0 specification to define a small set of basic claims to be used in the process of User-Managed Access (UMA) access authorization. | Currently maintained directly on this wiki. Latest version is [here|http://kantarainitiative.org/confluence/display/uma/Simple+Access+Authorization+Claims]. |
| *LegalUMA Considerations in UMA AuthorizationTrust Model* | Explores operational, contractual, and legal issues raised by the act of using User-Managed Access (UMA) to authorize another party to get web resource access. | Currently maintained directly on this wiki. Latest version is [here|http://kantarainitiative.org/confluence/display/uma/LegalUMA+Considerations+in+UMA+Authorization]. Awaiting incorporation of many comments, include a contribution by JeffS. |
| *Lexicon* | Compendium of official and unofficial terms and definitions related to UMA. | This document has served as an aid to figuring out legal considerations; now it is not very actively maintained. Latest version is [here|http://kantarainitiative.org/confluence/display/uma/Lexicon]. |

h2. Scenario Docket

Following is the current status of scenarios and their constituent use cases.

|| Scenario nickname || Champion || Status || Other notes ||
| Calendar | Eve | Accepted | |
| E-commerce | Eve | Accepted | |
| Loan | Domenico | Accepted | |
| Distributed services | Christian | Pending | |
| Two-way location | Eve | Pending | |
| Requester delegate | Mike H. | Accepted | One of the two specific use cases was accepted, the other rejected |
| Employer/employee | Eve | Pending | |
| Custodian | Maciej | Pending | |
| Moving resources | Maciej | Pending | |
| Protected inbox | Joe | Pending | |
| CV sharing | Maciej | Accepted | |
| Health data | Gerry | Pending | |
| Car-buying | Iain/Joe | Awaiting submission | This will likely be a summary pointing to the original Kantara InfoSharing document |
| "Hey, sailor" | Eve | Awaiting submission | |
| ACLs with PoCo integration | ? | ? | |
| Terms negotiation: null | Eve | Pending | |
| Terms negotiation: requester identification | Eve | Pending | |
| Terms negotiation: facts | Eve | Awaiting submission | |
| Terms negotiation: promises | Eve | Awaiting submission | |
| Terms negotiation: payments | Eve | Awaiting submission |Trust+Model]. |