On Thu, 2010-02-04 at 19:17 +0000, Anthony Nadalin wrote:
> > 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
I don't imagine there would be any such term called "misuse" that a
requester would claim. There would be specific, possibly enforceable
terms. Examples:
1. Requester will retain accessed information for no longer than {n}
days.
2. Requester will not share accessed information with any third party
except as required to comply with the laws of {region, ...}.
Paul
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 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:[email protected]]
> >> 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: [email protected] [mailto:[email protected]] 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:[email protected]]
> >>> 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
> [email protected]
> http://www.xmlgrrl.com/blog
>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
