Technology Matrix

This page is now historical. See the FAQ for up-to-date technology comparisons.

Historical material

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.

Synergies Between Technologies

Following are some potential synergies between UMA and the other technologies mentioned.

• UMA and InfoCard:
  • Claim on card presented to UMA Host could specify location of user's desired AM (UMA step 1)
  • Claim on card presented to UMA Requester could specify URL of resource to be shared rather than resource by value (UMA step 2)
• 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 1
  • 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

Discussion of Feature Descriptions

The feature descriptions in the matrix are not meant to be a complete listing of all possible interesting features in identity and access management systems. Mostly this list has come about because of comparisons that have been made between UMA and other technologies.

login-time attribute transfer

"User attributes" are a subset of data and content that is specific to a user. Typically, user attributes get transferred at the time the user logs in so that the attributes can be used in controlling authorized access. However, sometimes this is just a convenient (or the only) time when such attributes can be accessed. This row indicates technologies that are designed to achieve login-time attribute transfer for whatever purpose.

back-channel controlled access

The "back channel" is the conceptual communications channel on which services talk directly to other services, without any necessity for user intervention. This row refers to controlled data sharing and service access that is able to take place while the user may be entirely unavailable (offline with respect to login sessions at the services involved), although often the user may have a login session going at one of the services.

separate policy decision hub

In classic access management architecture, various separate "points" (essentially endpoints) related to "policy" are identified. Most particularly, a "policy enforcement point (PEP)" and "policy decision point (PDP)" are two different endpoints that communicate in real time so that the PDP can tell the PEP whether to grant some requester the desired access. A fundamental tenet of UMA (captured in requirement R1) is to make these functions separable. This row captures technologies that allow this separation.

on-board storage of user data

The Vendor Relationship Management movement posits a notion of a "personal datastore", which is a host of personal user data that can be made available to other authorized parties. UMA posits a notion of a "relationship management" application, one of whose useful jobs might optionally be local storage of personal user data. This row explores which solutions allow and require local storage of such data.

user-imposed policy

Most of the time today, if a website requires data, users must fill it in to proceed. User-imposed policy gives a user control of which data is shared with the website on her behalf and under what circumstances. (See this discussion of policy and terms issues for more.)

user-imposed terms

Most of the time today, users must simply accept website policies and terms of service if they want to use a website. User-imposed terms give a user the ability to place terms conditions on the offer of data (or service access), which the website can choose to meet or not. (See this discussion of policy and terms issues for more.)

binding of ID(s) to data shared

Many systems that specialize in the exchange of user attributes do so in the context of sharing a user identifier as an essential part of that data. For example, OpenID attribute exchange is predicated on being bound to an OpenID, and most SAML SSO+attributes use cases assume that a subject NameID using a particular identifier format is included (note that SAML does not appear in the matrix). If an identifier in a defined namespace is provided by the data host to the data recipient, this is early binding. If such an identifier is not explicitly provided by the data host but is rather mapped to an identifier known to the data recipient, this is late binding.

Sharing a privacy-enhanced federated identifier (such as a pseudonym) softens the effect of early identifier binding, and indeed this feature category is something of a continuum. For example, an OAuth access token can be seen as an extremely lightweight persistent pseudonym or federated identifier that ties together the user's identifier at a host/SP site and the same user's identifier at a recipient/consumer site. However, it seems useful to observe which technologies include strong early binding as part of their makeup, since it is UMA's goal to be "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'" (see the charter).

RESTful/resource oriented

This feature contrasts with "service-oriented". UMA has a goal to be "Resource-oriented (for example, as suggested by the REST architectural style) and operating natively on the Web to the extent possible" (see the charter).

multi-party write access

Multi-party write access to resources is potentially a desirable characteristic, but there is more than one way to accomplish it. Due to UMA's goal of simplicity (see the charter), it seems valuable to examine the ways in which different technologies achieve this goal.