Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

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.

 

UMA + reln mgr

InfoCard

Higgins R-Card

OpenID

OAuth

ID-WSF

XACML

Mine!

XRI/XDI

OpenID CX

login-time attribute transfer

 

yes

yes

yes

 

 

 

 

 

yes

back-channel controlled access

yes

 

yes. By PDS if self-issed; By UMA if managed.

 

yes

  yes

 

 

 

yes

separate policy decision hub

yes

  

PDS is hub if self-issued; UMA AM is hub if managed

 

 

 

yes

 

 

 

on-board storage of user data

yes (if RM is a Host)

yes (self-issued cards)

yes (if self-issued cards (by PDS);
no if managed

yes

 

 

 

yes (required)

 

 

user-imposed policy

yes

  

plans to rely on UMA

 

yes

yes (through XACML/CARML)

yes (through CARML)

?

?

 

user-imposed terms

yes

  

plans to rely on UMA

 

 

 

 

 

yes (link contract)

partial (user selection among RP terms)

binding of ID(s) to data shared

late

early (usually)

early (usually) or late

early

late

late

 

late

 

early

RESTful/resource oriented

yes

  

yes

yes

yes

potentially (ID-WSF Evo)

 

yes

 

yes

multi-party write access

user delegates write access

  mutual "co-ownership" of data

short term: user delegates write access of block of attributes
long term: attribute level access control

 

 

 

 

 

 

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

...