...
- 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
...
| Anchor | ||||
|---|---|---|---|---|
|
The UMA Work Group charter states some design principles that shape the nature of our work:
DP# | Title | Design Principle | Explanation/commentary |
|---|---|---|---|
DP1 | Simple | Simple to understand, implement in an interoperable fashion, and deploy on an Internet-wide scale |
|
DP2 | OAuth | OAuth-based to the extent possible | We may contribute bug reports and RFEs around extensibility, security, and privacy to the IETF OAuth group |
DP3 | ID-agnostic | Agnostic as to the identifier systems used in an individual's various services on the web | This is in order to allow for deployment in "today's Web" |
DP4 | RESTful | Resource-oriented (for example, as suggested by the REST architectural style) and operating natively on the Web to the extent possible |
|
DP5 | Modular | Modular | For example, 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 |
DP6 | Generative | Generative | Able to be combined and extended to support a variety of use cases and emerging application functionality |
DP 7 | Fast | Developed rapidly | In an "agile specification" process that can refactor for emerging needs |
In addition, we have identified emerging design principles in the course of the work:
DP# | Title | Design Principle | Explanation/commentary |
|---|---|---|---|
DP8 | Cryptography | We should avoid adding crypto burdens as part of our simplicity goal. | Avoid adding crypto requirements beyond what existing web app implementations do today. This principle was discussed on 2009-09-10. |
DP9 | Privacy | Protect the privacy of the Authorizing User | The protocol should not provide ways to breach the Authorizing User's privacy, though out-of-band methods are beyond our control. Also, this principle should not be construed as support for protecting the privacy of other parties, or even the same person in a different role (the Requesting User). This principle was discussed on 2009-10-08. |
...
| Anchor | ||||
|---|---|---|---|---|
|
...
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 Discussed on 2009-10-01. Can it be combined with P3? 08; this is wrongly stated and should be rejected. See P9 for a replacement. |
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 |
|
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. |
|
P9 | Correlation of Authorizing User by multiple Hosts | For resources at Host X and resources at Host Y, X and Y must not find out, through their relationship with the AM, that the same Authorizing User uses the other Host. | For example, a user might use the same AM to protect resources at LinkedIn along with their personal interests and hobbies. |
...
| Anchor | ||||
|---|---|---|---|---|
|
...