...
The following matrix compares and contrasts UMA (in combination with some relationship management application interface) with other related technologies. Note that the indications of features are not meant to imply value judgments, nor are the feature descriptions or technologies meant to represent complete listings. (Further discussion of the feature descriptions appears below.)
The slides from the EIC workshop held 4 May 2010 contains a series of diagrams that may be helpful in comparing the architectures of several popular technologies mentioned below.
| UMA + reln mgr | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
login-time attribute transfer |
| yes | yes | yes |
|
|
|
|
| yes |
back-channel controlled access | yes |
| yes |
| yes | yes |
|
|
| yes |
separate policy decision hub | yes |
|
|
|
|
| yes |
|
|
|
on-board storage of user data | yes (if RM is a Host) | yes (self-issued cards) | yes (self-issued cards) | yes |
|
|
| yes (required) |
|
|
user-imposed policy | yes |
|
|
| yes | yes (through XACML/CARML) | yes (through CARML) | ? | ? |
|
user-imposed terms | yes |
|
|
|
|
|
|
| yes (link contract) | partial (user selection among RP terms) |
binding of ID(s) to data shared | late | early (usually) | early (usually) | early | late | late |
| late |
| early |
RESTful/resource oriented | yes |
|
| yes | yes | potentially (ID-WSF Evo) |
| yes |
| yes |
multi-party write access | user delegates write access |
| mutual "co-ownership" of data |
|
|
|
|
|
| user delegates write access |
...
- UMA and InfoCard:
- Claim on card presented to UMA Host could specify location of user's desired AM (UMA step 01)
- Claim on card presented to UMA Requester could specify URL of resource to be shared rather than resource by value (UMA step 12)
- UMA and R-Card:
- Same as InfoCard; special R-Card UDR claim could have lessons for UMA about provisioning pointers to locations of resources and multi-resource packages
- UMA and OpenID:
- UMA should not depend on OpenID but could take advantage of something like the OpenID/OAuth hybrid (and possibly build on top of the actual OpenID/OAuth hybrid) for a smooth integrated experience
- UMA and OAuth:
- UMA is intended to build on top of OAuth and reuse true OAuth as closely as possible in achieving its goals
- Some service-access use cases for UMA involve OAuth explicitly
- UMA and ID-WSF:
- ID-WSF Web Service Provider (WSP) works like an UMA Host and Web Service Consumer (WSC) works like an UMA Requester
- "RESTful ID-WSF" work involves OAuth-based introductions of WSPs to Discovery Service closely akin to UMA's Step 01
- UMA distributed-services scenario is similar to canonical ID-WSF service discovery model
- UMA and XACML:
- UMA is like "user-driven XACML", with user-selected policies and terms governing a policy decision point's (PDP's) behavior
- UMA could be seen as a "RESTful binding" of a protocol inspired by XACML's decision-making protocol
- The XACML policy expression language, and policy languages such as CARML that profile this language, are candidates for UMA's terms-setting ability.
- UMA and Mine!:
- The Mine! assumes a relationship manager component that aggregates/co-locates what UMA would call AM and Host functionality
- Implementations of the Mine! might decide to implement UMA-compliant AM and Host protocol endpoints
- UMA and XRI:
- UMA's notion of user-driven terms appears conceptually identical to XRI's notion of link contracts and could possibly serve as a concrete solution for them
- XRI's XRD metadata spec could, in a manner similar to ID-WSF's Discovery Service, be useful in a service catalog role in combination with UMA
- UMA (as could OAuth?) could protect an XRD metadata resource in order to contribute to "trusted discovery" of it
- UMA and CX:
- UMA and CX share a goal of binding data sharing to terms
- CX could have lessons for UMA in using cryptography to make contracts highly enforceable, as well as lessons in handling user-driven terms
...