IIW - User contributions [en]

User Managed Access

2010-05-19T05:06:56Z

Eve Maler: Created page with '=Issue/Topic: User-Managed Access (UMA) Claims 2.0= ==Tuesday – Session 4 - C== * Convener: Tom Holodnik * Notes-taker(s): Eve Maler ==A. Tags for the session - technology ...'

=Issue/Topic: User-Managed Access (UMA) Claims 2.0=

==Tuesday – Session 4 - C==

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

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

#UMA #authorization #policy #claims #digital-signature #self-asserted

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

See Tom's slides: http://kantarainitiative.org/confluence/download/attachments/37751312/UMA+Claims+-+IIWX.pdf

UMA has two really great ideas in it: dynamicism and claims. Dynamicism is by its nature inclusive, and claims are by their nature exclusive.

Claims are going to have to support both self-asserted data and third-party-asserted data. And there are even ways of authenticating a "walk-up" requesting party that are so lightweight that they feel like self-asserted data. E.g., if in the process of engaging with a future requesting party in person (your dentist) you give them a tear-off paper with a unique temporary password that they need to present when seeking calendar access, you've authenticated them pretty strongly and only need to correlate "the same party" in future.

If you want to share dental records on a more formally authenticated basis, other things might have to happen.

UMA needs to have a unified way of "being" a requester endpoint, even if it has different flows for how they are interacted with. We think we have that now.

Should a specific person at a company be given access to Alice's stuff, or should a role at the company (or just generically "the company") be given access? The former is brittle.

What if you want to grant any plumber who has a good certification rating access to my plumbing service record? There will be company and certifier assertions involved.

Claim format definitions clearly need to have a generic/horizontal core set, and likely we would need domain-specific plugins for specialized policies and claims.

Notes IIW10

2010-05-19T05:05:08Z

Eve Maler:

== MONDAY ==

=== Session 1 ===

C: [[Designing Faceted ID System]]

D: [[Nascar for Sharing]] and Personal Service Distovery

E: [[Using DNS + ENUM]]

F: [[Getting Started in Internet Identity]]

G: [[Can the Open Pile Become Beautiful Again]]

H: [[Small Business Software on the Open Web]]

I: [[OAuth 2.0 WTF]]

O: [[Online Voter ID How do we do that?]]

=== Session 2 ===

A: [[Digital Heritage]]

C: [[Recovering a Lost Identity]]

E: [[Voluntary Oblivious Compliance]]

F: [[P2P Network Version Vega]]

G: [[A New Liberty? to prevent single vendor dominance]]

I: [[OpenID Connect WTF]]

=== Session 3 ===

A: [[Magic Signatures and Salmon]]

B: [[Cet Competing e-ID providers creating a Market]]

C: [[OneSocialWeb]] XMPP & Social Web

D: [[What do regular web devs need to know about ID]]

E: [[User Managed Access - UMA]] (protocol)

F: [[Permission vs Consent]]

G: [[eCitizen OpenID National Architecture]]

I: [[OpenID Connect: Under the Hood]]

=== Session 4 ===

A: [[How to Connect a Site to Major Providers Easily]]

B: [[Trying to use PubSubHubbub]]

C: [[Privacy Enhancing Approach]]

D: [[Contextual Identity]]

E: [[Identity Lifecycle]]

F: [[Verified Attribute Schema]]

O: [[Personal Data Stores]]

=== Session 5 ===

D: [[Voice Biometrics]]

E: [[VRM Parts & Whole]]

F: [[Linking Data Across Social Networks APIs]]

G: [[Six Degrees of Sharing]]

I: [[OAuth 2]]

K: [[ORCID Open Research Contributor ID]]

== TUESDAY ==

=== Session 1 ===

C: [[Strong Auth and OpenID getting Comfie]]

D: [[Information Cards and Gov Cards]]

E: [[De-Confusion Big Picture]]

F: [[Open Geneology]]

G: [[XRD Provisioning]]

H: [[Building MITER ID]]

I: [[OAuth 2.0 and SASL]]

=== Session 2 ===

A: [[Info Grid Graphic Database]]

B: [[Legal Issues Underpinning of UMA]] ("UMA and the law")

E: [[Contacts in the Browser]]

F: [[Migrating from HTTP to HTTPS OpenID]]

G: [[Identity Business Models]]

H: [[Patents, People Development Pools]]

I: [[Enterprise Signing in OAuth]]

=== Session 3 ===

A: [[Simple Reputation Feed]]

C: [[Lawyers + Accountants]]

D: [[The Right Question]] Making Privacy Policies User-Centric vs. Data Centric

E: [[OIX]]

F: [[UX w/no logout...single sign out]]

G: [[URL - Sharing using the Stack]]

L: [[Secure Web Auth]]

O: [[The Case for and Design of KRL]]

=== Session 4 ===

A: [[Research Report on Info Sharing]]

B: [[OAuth 2 for Native Apps]]

C: [[User Managed Access]] (Claims 2.0)

E: [[Client Side OptIN Cross Site Data Sharing]]

F: [[Telco vs. The NET]]

G: [[Web Biz Card]]

H: [[SAML Profiles for OAuth]]

I: [[Separating: ID, Credential, and Attribute Management]]

J: [[Story Cubing and Synergies]]

O: [[OpenID-Artifact Binding]]

=== Session 5 ===

A: [[Biz Model on Distributed Social Web]]

C: [[Directory Federation]]

D: [[Honey Roasted Death Camp Salad]]

E: [[OpenIDvNext Discovery]]

G: [[Implications of User Owned Controlled Data as Official Government Policy]]

I: [[Google as an OpenID RP]]

== WEDNESDAY ==

=== Session 1 ===

=== Session 2 ===

=== Session 3 ===

=== Session 4 ===

=== Session 5 ===

Legal Issues Underpinning of UMA

2010-05-19T05:00:09Z

Eve Maler: Created page with '=Issue/Topic: UMA and the law= ==Tuesday – Session 2 - B== * Convener: Jeff Stollman * Notes-taker(s): Eve Maler ==A. Tags for the session - technology discussed/ideas consi...'

=Issue/Topic: UMA and the law=

==Tuesday – Session 2 - B==

* Convener: Jeff Stollman
* Notes-taker(s): Eve Maler

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

#UMA #authorization #contract #agreement #clickwrap #terms-of-service

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

UMA main site: http://kantarainitiative.org/confluence/display/uma/Home

UMA unfinished Legal Considerations document: http://kantarainitiative.org/confluence/display/uma/Legal+Considerations+in+UMA+Authorization

Attending: Jeff Stollman (leader), Heather West, Iain Henderson, Eve Maler, Mason Lee, Judith Bush, Alex Smolen, Stacy Pitsillides, Brian ...worth (? - didn't catch), Mark Lizar

Some participants in the UMA Work Group at the Kantara Initiatives have been focusing specifically on legal considerations. One concern is scalability. Even if we constrain UMA initially to something that will work simply, we want it to scale much bigger eventually.

UMA holds out the prospect of an individually negotiated contract between an authorizing user and a requesting party, which starts out with the user's wishes being the initial terms. The user's wishes can be carried out by an "authorization manager" that decides whether a requester application deserves to get an access token (a la OAuth) for accessing some host.

Liability is the place where all federated identity seems to fall apart! As Tom Smedinghoff has pointed out to us, we need to figure out what legal theory of liability should be in play. E.g., there's contract, tort, negligence… Heather explains that contract law doesn't see the "I Agree" clicking process as an example of a contract. It's just terms of service (clickwrap). The OIX approach is going in the direction of contracts, which is much stronger. The Computer Fraud and Abuse Act is what has been used most often to prosecute TOS violations, same as for prosecuting hackers -- and TOS is simply not very strong.

However, if UMA were used to ask for positively asserted claims vs. just a user interface that asks for "click to agree", or if UMA were deployed within a trust framework that is contract-based, it's possible to apply a contract theory of liability.

Iain's Information Sharing work at Kantara, and his work at Mydex.org, focuses in part on "volunteered information". His lawyers have said that volunteered information with an advertisement of the terms would use contract law. Europe has the eight principles of privacy protection, and if these principles are part of the offered contract terms, it becomes quite strong.

Contract theory is the only one that scales internationally. Various boundaries are relevant to this question: domestic, treaty-member nations vs. non-treaty nations, etc. Again, certified parties to a trust framework are a strong way to get some level of contract protection.

Eve sketches two areas of UMA that seem like they would have impact on the liability theory used.

One is the particular user experience on the requesting-party end. E.g., if it's Bob (person-to-person or Alice-to-Bob sharing), we don't necessarily want to make him agree to the same privacy policies, to the same "strength", as if it's a company (person-to-service sharing where the service is run by a company acting on its own behalf). And you might have an "I Agree" button for Bob, but not the company.

The other is the particular method that Alice uses to provision the requesting party with knowledge of the resource. The Data Dominatrix method has Alice pasting (or whatever) a URL in the recipient's interface, and the latter discovers the constraints on trying to get the information. The Hey Sailor method has Alice advertising something like a personal RFP, and Iain notes that if the advertisement also includes the offered terms, that would use standard contract law.

Brian points out that the UMA proposition is a lot like DRM for personal information. Alex observes that the power imbalance between people and companies seems to make that okay. :-)

If you want to have a contract between the authorizing and requesting parties, but the intermediary parties only have pairwise TOS's, the TOS's can weaken the contract at the ends.

The UMA protocol uses the technical notion (not the legal notion) of "claims" for finding out more about the requesting party to figure out if they qualify to get access. What if the authorization manager demanded a claim saying (in a verifiable way) that the requesting party is a certified member of a trust framework? This could mitigate the risk of having any part of the ecosystem using TOS's versus a contract.

Heather points out the example of the Veteran's Administration, which is incredibly successful with its e-health records because the entire ecosystem is under very strong contractual privacy protections, which makes it easy for ordinary humans to understand and consistently applicable by other parties in the ecosystem. Could it be the case that more stringent but more consistent privacy controls could be good for the growth of the commercial market! However, recognizing that "privacy" and "security" generally aren't good selling points, it's hard to use this rationale for business benefits.

What would incentive hosts to accept an authorization manager's policy decisions, and all the liability implications thereof? The theory of the UMA folks is that most websites offer terrible (or no) selective sharing options, and if they could offer it as a value-add simply by adding an "UMAnizing" module, that would be attractive.

How would the changes in various contracts in the ecosystem be handled? UMA could help an authorizing user decide to revoke access, but what if other entities in the system change their policies? If there were a standard for giving notice of changes (maybe using Atom feeds?), that could be used.

User Managed Access - UMA

2010-05-19T04:57:34Z

Eve Maler:

=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.

Permission vs Consent

2010-05-19T04:55:24Z

Eve Maler: Created page with '=Issue/Topic: Permission and Consent= ==Monday – Session 3 - F== * Convener: Kevin Marks * Notes-taker(s): Stacey Pitsillides ==A. Tags for the session - technology discusse...'

=Issue/Topic: Permission and Consent=

==Monday – Session 3 - F==

* Convener: Kevin Marks
* Notes-taker(s): Stacey Pitsillides

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

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

* User name/ password model
* More comprehensible to people
* You were doing what with my stuff???
* Meaningful choice about what I’m providing
* How many users they’ve got to sign up/ not how many users understand
* what they’ve signed up for.
* What am I giving permission for this thing to do?
* Is this app gonna do something bad to me, do people I know and trust, trust it
* App invites – neg half of it
* The app is able to deduce who my friends are?
* Holding the app – personal context
* Quality, copy, disappointment
* Permissions you give to that app
* Disclosure- this app demands these things and you cant switch them off
* Binary yes or no!
* Info to help you make your choice
* “we need you e-mail” wait till you have the reason to answer the
* question - gets them more e-mail addys that you cannot use
* trade- want that- prove your value
* know when your gonna use it
* bring the user to you ?? design system so
* consent for sharing – abstract idea of groups
* delegating identity back to you – empathy
* statement of purpose
* the cake is a lie – Randy Farmer
* specific statements of claims – say the following things on my app-
* when you make an assertion…. Separation between app provider
* classify apps – different ?
* im a level 3 guaranteed app
* set of purposes mapped to a set of capabilities
* sensitivity of information – defaults – exception – purpose statements
* compared to categories
* redemption ? new app 0 is better then -5 ask forgiveness button /
* reputation decay ?
* post on my behalf
* this spams me
* promises, drag the canneries in – initial promise
* how you develop trust?
* Abuse mitigation tool
* Curated computing - social curation within an app store
* How do you scale trust without a legal framework ??

User Managed Access - UMA

2010-05-19T04:51:32Z

Eve Maler: 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 ...'

=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:
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

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.