Difference between revisions of "User Managed Access - UMA"

From IIW
Jump to: navigation, search
(Created page with '=Issue/Topic: User-Managed Access (UMA)= ==Monday – Session 3 - E== Convener: Eve Maler Notes-taker(s): Tom Holodnik ==A. Tags for the session - technology discussed/ideas ...')
 
Line 3: Line 3:
 
==Monday – Session 3 - E==
 
==Monday – Session 3 - E==
  
Convener: Eve Maler
+
* Convener: Eve Maler
Notes-taker(s): Tom Holodnik
+
* Notes-taker(s): Tom Holodnik
  
 
==A. Tags for the session - technology discussed/ideas considered:==
 
==A. Tags for the session - technology discussed/ideas considered:==
Line 28: Line 28:
  
 
Influences:
 
Influences:
policy-decision making
+
 
privacy
+
* policy-decision making
informational self-determination
+
* privacy
data portability
+
* informational self-determination
the "open stack"
+
* data portability
volunteered personal information
+
* the "open stack"
personal data stores
+
* volunteered personal information
 +
* personal data stores
  
 
outcomes:
 
outcomes:
a dashboard that allows you to control access
 
engaged data sharing
 
  
a protocol headed toward IETF applications area
+
* a dashboard that allows you to control access
a set of draft specs free for anyone to implement
+
* engaged data sharing
multiple implementations under way
+
 
simple, OAuth-based, identifier agnostic, RESTful, modular, generative (can be used to build more things) and developed rapdily
+
* a protocol headed toward IETF applications area
targeting delivery as a spec (to IETF) in the August time frame
+
* a set of draft specs free for anyone to implement
 +
* multiple implementations under way
 +
* simple, OAuth-based, identifier agnostic, RESTful, modular, generative (can be used to build more things) and developed rapdily
 +
* targeting delivery as a spec (to IETF) in the August time frame
  
 
The players:
 
The players:
Authorizing user  - a web user who config's the AM with policies to control how to make access control decisions)
+
 
Host (protected resource server)  - enforces access to the protected resources it hosts
+
* Authorizing user  - a web user who config's the AM with policies to control how to make access control decisions)
Authorization Manager (AM) - carries out an authorizing users policies
+
* Host (protected resource server)  - enforces access to the protected resources it hosts
Requester  - an entity that wants to access the AU's resources
+
* Authorization Manager (AM) - carries out an authorizing users policies
 +
* Requester  - an entity that wants to access the AU's resources
  
 
Compare OAuth and UMA models:
 
Compare OAuth and UMA models:
  
the UMA model is different from the OAuth model in subtle ways; it establishes a contract for access management
+
* the UMA model is different from the OAuth model in subtle ways; it establishes a contract for access management
the UMA AM may also usefully be co-located with IdP and discovery
+
* the UMA AM may also usefully be co-located with IdP and discovery
  
 
participants:
 
participants:
there is one resource owner and consumer in OAuth; the UMA user may be granting access to an autonomous party
+
 
resource server respects tokens from its authz server; the host  outsources authz jobs to an authz manager chosen by the user
+
* there is one resource owner and consumer in OAuth; the UMA user may be granting access to an autonomous party
the authz server issues tokens based on the client's ability to authN; the authZ manager ussues tokens based on user policy and clienams coneryned by the requester
+
* resource server respects tokens from its authz server; the host  outsources authz jobs to an authz manager chosen by the user
 +
* the authz server issues tokens based on the client's ability to authN; the authZ manager ussues tokens based on user policy and clienams coneryned by the requester
  
 
provisioning:
 
provisioning:
cleint and server must meet outside the OAuth context to provision trust; the requester can walk up to a protected reseource and attempt to get access without registering first
+
 
 +
* client and server must meet outside the OAuth context to provision trust; the requester can walk up to a protected reseource and attempt to get access without registering first
  
 
dynamic trust:
 
dynamic trust:
the resource server meets its authz server ahead of time and is coupled with it;  the authz user can mediate the introduction of each of the hosts to the authz manager we wants to use
+
 
the resource server validates tokens in an unspecified manner, assumed locally;  the host has the option to ask the authZ manager to validate tokens in real time
+
* the resource server meets its authz server ahead of time and is coupled with it;  the authz user can mediate the introduction of each of the hosts to the authz manager we wants to use
 +
* the resource server validates tokens in an unspecified manner, assumed locally;  the host has the option to ask the authZ manager to validate tokens in real time
  
 
protocol:
 
protocol:
OAuth: get a token, use a token;  uma: intro, get token, use token
+
 
user delegation flows and automous flows; UMA: profiles of OAuth flows
+
* OAuth: get a token, use a token;  uma: intro, get token, use token
 +
* user delegation flows and automous flows; UMA: profiles of OAuth flows
  
 
relationship with OAuth: based on OAuth 2.
 
relationship with OAuth: based on OAuth 2.
  
UMA Protocol Details:
+
UMA Protocol Details: (reference the links at the top of the notes)
(reference the links at the top of the notes)
 
  
 
Establishing trust; passing a handle to the protected resources
 
Establishing trust; passing a handle to the protected resources
- could establish trust on first use (TOFU)
+
 
 +
* could establish trust on first use (TOFU)
  
 
Policies:
 
Policies:
unilateral - e.g. allow access for a week
+
 
claims-requiring -  "allow anyone access who agrees to my licensing terms"  or allow access to someone who can prove themselves to to bob@mailco.com, or allow access to anyone 18 years old or more.
+
* unilateral - e.g. allow access for a week
 +
* claims-requiring -  "allow anyone access who agrees to my licensing terms"  or allow access to someone who can prove themselves to to bob@mailco.com, or allow access to anyone 18 years old or more.
  
 
Claims 2.0 are by default JSON based claims that establish attributes about a user; they don't have to be issued by the requester, but they could be issued by an IdP associated with the requester.
 
Claims 2.0 are by default JSON based claims that establish attributes about a user; they don't have to be issued by the requester, but they could be issued by an IdP associated with the requester.

Revision as of 04:57, 19 May 2010

Issue/Topic: User-Managed Access (UMA)

Monday – Session 3 - E

  • Convener: Eve Maler
  • Notes-taker(s): Tom Holodnik

A. Tags for the session - technology discussed/ideas considered:

#UMA #authorization #user-centric #OAuth #JSON #Python #policy #claims

B. Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

For complete details, please see: http://kantarainitiative.org/confluence/display/uma/Home

The protocol flow is described here: http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol

Here’s a friendly overview: http://kantarainitiative.org/confluence/display/uma/UMA+Explained

Session slides: http://kantarainitiative.org/confluence/download/attachments/37751312/IIW10-UMA-May2010.pdf

History:

ProtectServe evolved into UMA. Last IIW, WRAP was presented; it overturned some OAuth dependencies that UMA had had.

UMA:

Influences:

  • policy-decision making
  • privacy
  • informational self-determination
  • data portability
  • the "open stack"
  • volunteered personal information
  • personal data stores

outcomes:

  • a dashboard that allows you to control access
  • engaged data sharing
  • a protocol headed toward IETF applications area
  • a set of draft specs free for anyone to implement
  • multiple implementations under way
  • simple, OAuth-based, identifier agnostic, RESTful, modular, generative (can be used to build more things) and developed rapdily
  • targeting delivery as a spec (to IETF) in the August time frame

The players:

  • Authorizing user - a web user who config's the AM with policies to control how to make access control decisions)
  • Host (protected resource server) - enforces access to the protected resources it hosts
  • Authorization Manager (AM) - carries out an authorizing users policies
  • Requester - an entity that wants to access the AU's resources

Compare OAuth and UMA models:

  • the UMA model is different from the OAuth model in subtle ways; it establishes a contract for access management
  • the UMA AM may also usefully be co-located with IdP and discovery

participants:

  • there is one resource owner and consumer in OAuth; the UMA user may be granting access to an autonomous party
  • resource server respects tokens from its authz server; the host outsources authz jobs to an authz manager chosen by the user
  • the authz server issues tokens based on the client's ability to authN; the authZ manager ussues tokens based on user policy and clienams coneryned by the requester

provisioning:

  • client and server must meet outside the OAuth context to provision trust; the requester can walk up to a protected reseource and attempt to get access without registering first

dynamic trust:

  • the resource server meets its authz server ahead of time and is coupled with it; the authz user can mediate the introduction of each of the hosts to the authz manager we wants to use
  • the resource server validates tokens in an unspecified manner, assumed locally; the host has the option to ask the authZ manager to validate tokens in real time

protocol:

  • OAuth: get a token, use a token; uma: intro, get token, use token
  • user delegation flows and automous flows; UMA: profiles of OAuth flows

relationship with OAuth: based on OAuth 2.

UMA Protocol Details: (reference the links at the top of the notes)

Establishing trust; passing a handle to the protected resources

  • could establish trust on first use (TOFU)

Policies:

  • unilateral - e.g. allow access for a week
  • claims-requiring - "allow anyone access who agrees to my licensing terms" or allow access to someone who can prove themselves to to bob@mailco.com, or allow access to anyone 18 years old or more.

Claims 2.0 are by default JSON based claims that establish attributes about a user; they don't have to be issued by the requester, but they could be issued by an IdP associated with the requester.

Demos and Implementations in progress:

SMART at Newcastle University: This illustrates how to issue and manage simple kinds of claims: http://kantarainitiative.org/confluence/download/attachments/38371737/SMARTOverview.pdf http://kantarainitiative.org/confluence/display/uma/SMART+project+user+experience

Christian Scholz: This illustrates how we might create policies and provision access to resources we want to protect with an UMA AM: Prototype: http://bitbucket.org/mrtopf/uma Demo: http://host.clprojects.net/

Comment: if the token does not contain information about the resource (and to whom it was issued), it's vulnerable to confused deputy

claims confirmation could be as simple as "confirm that you are over 18" or "confirm that you will abide by the terms of Creative Commons..." - enforceable legally, or could be supported by claims issued through CardSpace/InfoCards, could be a URL of a BBB statement, or a URL pointing to other indepedent assertion of claims.