use UMA to require the requester to assure her they will not misuse or further
share her information
Not sure how UMA would be able to deal with this, if you look at things like
the OECD Data Protection Principles (on which Privacy laws have been based)
there are a lot of things considered misuse
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eve
Maler
Sent: Wednesday, February 03, 2010 10:54 AM
To: OAuth WG
Subject: [OAUTH-WG] UMA use cases (was Re: proposed agenda for second interim
meeting)
Sorry for the delay, and thanks for the push. In scrambling to approve a
passel of scenarios and produce our webinar last week, we got a bit behind.
(By the way, complete recordings are now available. Their quality is not
perfect, but should suffice. Please see
http://kantarainitiative.org/confluence/display/uma/UMA+Explained for
recordings, overview slides, protocol explanation slides, and example
wireframes.)
In order to inform the OAuth V2.0 effort, here is some information about key
User-Managed Access (UMA) use cases and needs. The wiki home is at
http://kantarainitiative.org/confluence/display/uma/Home , and the sidebar on
the right has links to all the available materials.
The focus of UMA is to externalize authorization decisions currently performed by OAuth SPs/servers into a fourth distinct entity we call an "authorization manager" or AM. Protected resources are hosted at endpoints called "hosts" and the endpoints seeking data/service access are called "requesters". An application embodying the AM endpoint can help the "authorizing user" globally manage what otherwise might be a complicated authorization picture among all the services accessing and sharing data about her, including letting her dictate policies for access authorization that the AM enforces. (If you're familiar with classic access management technology, the AM serves as a policy decision point and the hosts are policy enforcement points.) An AM provides the user with the ability to apply discretionary access controls for his/her resources.
The extensive information available about UMA includes a Scenarios and Use
Cases document:
http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+Cases
Here are summaries of two of the group's approved scenarios.
Calendaring: Online calendars, whose content is volatile, are valuable to share on an
ongoing/"feed" basis. In somewhat the same fashion that people today share
online calendars selectively with other people, a user can share a calendar with a vendor
for various purposes. Prior to allowing the access, she might use UMA to require the
requester to assure her they will not misuse or further share her information. Having
authorized access to a particular resource, the user can then examine all the connections
forged to all her shared resources in similar fashion, from a single console.
Personal Loan: A user applies for a loan online, and the loan application site
requires him to provide certain third-party-attested information, such as his
salary, bank account, and credit score. This information is best hosted
directly out of the (several) authoritative sites for it, but the user is able
to package up references to all of it and point the loan site to the package;
the loan site can then become a requester of each relevant resource. The user
can see, from a single place, whether the information has been successfully
received, and can keep a record of its access. (The webinar wireframes show
how this packaging might be achieved, along with illustrating other potential
parts of the user experience.)
UMA currently solves its use cases, in part, with a composition of three instances of OAuth (along with using
XRD metadata and LRDD discovery methods). The user introduces each host to the AM with so-called
"three-legged" (authn plus web delegation) OAuth as a preface to other interactions. Each
requester later dynamically introduces itself to a host with the option of using "two-legged"
(authn only) OAuth, and then introduces itself to the AM using two-legged OAuth -- we think of these as
"automated self-registration" of the services. The draft spec can be found here:
http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol
A few key points:
- UMA wants to give users an opportunity, not just to set unilateral policy
(how long access is allowed over time, whether the user should be asked for
real-time consent in some fashion when access is attempted, and so on), but
also to set terms which the requester must meet. This gives users new tools for
control, and also enables some interesting high-value use cases, involving
requests for access on the basis of third-party-attested claims.
- There is a conceptual similarity between the UMA and WRAP entities, but our analysis so far shows it to be shallow in spots.
For example, WRAP's "protected resource" maps fairly well to an UMA "host" (which may host any number of
protected resources), and WRAP's and OAuth's "client"/"consumer" maps to an UMA "requester".
However, it seems that a WRAP authorization server is assumed to be in the same domain as a protected resource, allowing for
implicit rather than explicit scoping of resources. The UMA authorization manager and any one host may be in entirely separate
domains, and introductions between them are intended to be user-driven.
Eve
On 3 Feb 2010, at 9:34 AM, Eran Hammer-Lahav wrote:
Hi Anthony,
The problem with this approach is that it hasn't worked (multiple times) before
because no one ever wants to do the work of collecting and writing the use
cases. What we get instead are short cryptic lists and pointers to edge cases.
We have a good grasp on how OAuth 1.0 is used and its limitations as addressed
by the WRAP draft.
The best use of my time is to continue working on the drafts and asking
technical questions whenever a decision is needed. If and when someone writes
use cases, I will review those and see if they are supported by the drafts.
I will leave it up to the chairs to decide how they want to guide the working
group.
EHL
-----Original Message-----
From: Anthony Nadalin [mailto:tony...@microsoft.com]
Sent: Wednesday, February 03, 2010 9:02 AM
To: Eran Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting
I would tend to agree with Dick based upon the last call and where
that was heading. I believe that Eve had some use cases to share
around UMA
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Eran Hammer-Lahav
Sent: Wednesday, February 03, 2010 8:41 AM
To: Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
Has anyone gathered and reviewed use cases? I haven't seen much of
that showing up on the list. From my experience, asking people for
use cases rarely works, unless someone is willing to do the work and
collect them (and so far I haven't heard from such volunteer). I much
prefer the process in which we produce a technical document based on
OAuth 1.0 and the new requirements as defined by WRAP, and discuss
use cases as a property of the technical attributes of this draft.
Of course, you don't have to agree with me, but that puts the burden
of producing use cases documentation on you and others interested in
taking that approach. We certainly have room for both, and keep in
mind that my token draft is not (yet) a working group item.
The indication I received from many of the active members of this
list is that we have a strong desire to show up at Anaheim with two
stable drafts. I think we are very close to getting the
authentication piece done following much of OAuth 1.0 functionality
(only cleaner and better structures), as well as treating bearer
tokens as first class citizens. Given that no one has started a
discussion about the delegation flows to include, I doubt we will
have a stable second draft, but I plan on getting the authentication piece stable in time.
It has also been my experience over the past two years that the
biggest challenge is to figure out the authentication piece. The 'go
get a token' piece tends to be much easier to agree on. If we get the
authentication draft to a stable place, my intention is to leave it
there and focus on the second part and come back to it as the
delegation requirements become clearer (if changes are needed). But at least it gives us something stable to build upon.
EHL
-----Original Message-----
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Wednesday, February 03, 2010 7:02 AM
To: Eran Hammer-Lahav
Cc: Peter Saint-Andre; OAuth WG
Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
Hi Eran
I think it is a little early in our phone discussions to get into technical
details.
The next step according to the last call was to gather and review use cases.
Without rough consensus on what problem we are solving, your points
below (which all do need to be discussed at some point) is just
moving around deck chairs on the Titanic.
-- Dick
On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote:
Please add:
- Discuss Adobe's recent request to allow excluding the host/port
from the
signed message.
- With regards to #4, how should the challenge identify the token
to be
used (realm comes free, do we need another)?
- Should a single token support multiple signature algorithms? This
has
implications as to the information the client has to include with
the request (the algorithm used, etc.).
- Where should the token structure live? OAuth 1.0 includes two
response
parameters (token and token_secret). However, since we are now
moving towards having the algorithm part of the token definition, as
well as duration and other attributes, the server will need to
provide this information to the client. This calls for a simple
schema (can be any format but need to agree to consistent names). It
is currently part of the authorization/delegation draft
(implicitly), but we should discuss moving it to the authentication
draft since that's where it is used (the
authorization draft simply hands those "things"
out).
EHL
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
