Subject: [OAUTH-WG] Recent UMA work that may inform this group's deliberations

From: Eve Maler <[email-masked]>
Date: Thu, 4 Mar 2010 11:01:27 -0800

Folks may be interested to see the following experiment being performed in the UMA group:

http://kantarainitiative.org/confluence/display/[email-masked]/Proposal+for+UMA+1.0+Core+Protocol

This is a proposal for a spec that uses a WRAP-friendly approach to solving our use cases.  Please note the final comments in today's UMA telecon minutes for cautions about additional requirements we have:

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2010-03-04

	Eve

Eve Maler
[email-masked]
http://www.xmlgrrl.com/blog

---

From: Eve Maler <[email-masked]>
Date: Thu, 4 Mar 2010 12:51:39 -0800

As requested on today's call, here's a description of the places where UMA seems to need "more" than what the WRAP paradigm offers (both profiling and extending), based on the proposal at:

Cautions in reading this note:

- The mix of likely needed profiles and extensions for our use of the OAuth 1.0 paradigm (the existing spec on the UMA site) is quite different from the list presented here, and in addition, that spec wasn't written with a goal to highlight such items the way this proposal was.

- The proposal is currently fairly high-level, and other profiling/extension needs may come to light if we proceed down this path -- or some of the needs may disappear.  The proposal nonetheless tries to document profile and extension points as precisely as possible.

- UMA's terminology is similar but not identical to WRAP's.  The proposal tries to be as clear as possible about the distinctions, but caveat lector.

- For all of the profile/extension items listed, they may be of interest only to UMAnitarians, or they might have wider application as optional or required portions of a core OAuth 2.0 spec.  We're not trying to prejudice this outcome, just provide useful information for making the decision in the wider community.

So, with all that said...  Here is the conception of UMA's use of the WRAP paradigm as conceived in the proposal.

1. Currently, WRAP says nothing about how a Protected Resource and an Authorization Server "meet" and figure out how to work together.  UMA has reason to make the user's choice of authorization management (AM) services and hosts of their resources be dynamic and flexible -- that's why it's called "user-managed access" -- so the proposal suggests a special way to use (an embedded instance of one of the user delegation profiles of) WRAP to introduce them, as a "step 1".  (The token thus acquired by the host in this step plays a role in "step 3".)

2a. Another of UMA's goals is to allow authorizing users (roughly, Resource Owners) to make demands of other parties before granting them access rather than just permissioning the connection "silently".  The mechanism for making these demands is to require the requesting side to provide claims (yes, in the identity claims sense) and even to make this process have legal enforceability consequences where possible.  Thus, the proposal suggests an extended getting-a-token phase in a "step 2" that adds a new third option to the two usual WRAP options (successful access token response and unsuccessful access token response): a claims-required response.

2b. Due to our analysis of the legal (cough) and UX dimensions of the UMA proposition, we've discovered that it's useful to separate requesting parties (the legally responsible party "behind" the requester/Client) into legal persons vs. natural persons.  This is a way in which UMA deviates from OAuth and WRAP entirely, in that we're figuring out how to do "person-to-person sharing" (Alice permissions Bob to subscribe to a hosted calendar of hers) along with "person-to-service sharing" (Alice permissions ECommerce.com to grab her current shipping address from her personal datastore).  The current thinking is that it's a matter of putting the requester into a user-delegated flow vs. an autonomous-client flow as part of getting a token in step 2.

2c. Currently, WRAP doesn't say anything about how to fill the scope parameter value.  In this context, an obvious optimization is the "all the photos that happen to be in this folder" authorization scenario.  So we went ahead and proposed a simple JSON-based format for describing both simple access scope and basic wildcarded access scope.

3. The means by which a host interprets an incoming access token is not currently specified in WRAP.  Unfortunately, UMA needs to know. :-)  There seem to be two options: validating it locally or offloading validation.  To avoid putting a signature validation burden on the host, we have proposed a strawman where the host can simply ask the AM to do the validation for it.  (A personal observation: The local/offload choice all depends on various scale and loose coupling factors, but this is appealing for lots of reasons.  It not only views the Authorization Server as an STS performing a typical token validation function, but pretty closely matches the classic access management paradigm where the policy enforcement point asks the centralized policy decision point what to do.  And other useful info could also ride over this back channel, either in extensions or -- as the need arises -- in core OAuth.)

n. Several people at the UMA table continue to be concerned about the overall risks in using the WRAP paradigm for controlling access to various kinds of sensitive information in various ways.  It may not be acceptable in some UMA use cases, e.g., to use replayable tokens.  As I promised on the call, I'll work with the UMA group to research this issue as precisely as possible in preparation for Anaheim, ideally including specific guidance from those who have submitted the most sensitive UMA scenarios or have the biggest concerns.

	Eve

On 4 Mar 2010, at 11:01 AM, Eve Maler wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

Eve Maler
[email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Thu, 4 Mar 2010 17:42:33 -0800

Hi Eve

Looking at the WRAP oriented comments in the spec, here are some comments / questions:

Note
WRAP doesn't seem to say HTTPS is required for the user authorization URL; is this a bug in the WRAP spec? If not, is it a good idea for us to profile it in this way? Finally, is this the right place to say HTTPS is required for all these URLs?

Dick: an HTTPS requirement is prohibitive at times. See http://groups.google.com/group/oauth-wrap-wg/browse_thread/thread/821e73bcbd8033dd?hl=en# for a recent discussion on this.

Note
Need lots of examples for all of this. Also, note that WRAP forces clients to use POST on access token URLs and refresh token URLs; can we use GET in the way described here?

Dick: why do you want GET? There are security issues with using GET to the AS.

Note
Obviously this is just the highest-level sketch of what needs to happen! This needs to be fleshed out. (E.g., the wrap_scope format could be reused here, without any wildcards.)
Also, are we concerned that a malicious host could lie about the attempted resource and method? The only consequence seems to be "false negatives" in managing authorized access, in which case the user would get unhappy pretty quickly.

Dick: it was envisioned that the scope of a function of scope would be embedded in the Access Token. Or perhaps I don't understand the issue.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 4 Mar 2010 17:43:44 -0800

Thanks Eve, comments inserted ... 

On 2010-03-04, at 12:51 PM, Eve Maler wrote:

> 1. Currently, WRAP says nothing about how a Protected Resource and an Authorization Server "meet" and figure out how to work together.

This was explicitly out of scope for WRAP. There are scale and privacy advantages to the PR and AR not meeting. The PR needs to trust the AR the issued the Access Token (and of course be able to verify the Access Token was issued by the AR), but the AR does NOT need to be aware of the PR. In this way, WRAP 

>  UMA has reason to make the user's choice of authorization management (AM) services and hosts of their resources be dynamic and flexible -- that's why it's called "user-managed access" -- so the proposal suggests a special way to use (an embedded instance of one of the user delegation profiles of) WRAP to introduce them, as a "step 1".  (The token thus acquired by the host in this step plays a role in "step 3".)

Interesting use of WRAP. I don't see a hole in WRAP for you to do this. Is there some functionality missing?

> 2a. Another of UMA's goals is to allow authorizing users (roughly, Resource Owners) to make demands of other parties before granting them access rather than just permissioning the connection "silen…

I can see it being useful in a standard return parameter that can contain an value undefined by WRAP (similar to the scope parameter), that is used by the AS to communicate to the Client what else the Client needs to be granted an Access Token. Is this what you are asking for?

> 2b. Due to our analysis of the legal (cough) and UX dimensions of the UMA proposition, we've discovered that it's useful to separate requesting parties (the legally responsible party "behind" the r…

Is there something missing in WRAP to do this?

> 2c. Currently, WRAP doesn't say anything about how to fill the scope parameter value.  In this context, an obvious optimization is the "all the photos that happen to be in this folder" authorizatio…

Different scenarios will require different scope values. We thought it useful to define the parameter so that it would  be easier library providers and specs like UMA to define the value without also having to define the parameter.

> 3. The means by which a host interprets an incoming access token is not currently specified in WRAP.  Unfortunately, UMA needs to know. :-)  There seem to be two options: validating it locally or o…

When developing WRAP, we envisioned that the PR would verify and interpret locally.

> n. Several people at the UMA table continue to be concerned about the overall risks in using the WRAP paradigm for controlling access to various kinds of sensitive information in various ways.  It…

Posting what you find to the list prior to Anaheim would be useful for the rest of us to have a chance to digest and then we can discuss in detail at Anaheim.

-- Dick

---

From: Eve Maler <[email-masked]>
Date: Thu, 4 Mar 2010 23:07:58 -0800

Quick feedback...

> Dick: an HTTPS requirement is prohibitive at times. See http://groups.google.com/group/oauth-wrap-wg/browse_thread/thread/821e73bcbd8033dd?hl=en# for a recent discussion on this.

Okay.

> Dick: why do you want GET? There are security issues with using GET to the AS.

We can probably do away with the GET we have, I'm guessing.  We'll discuss.

> Dick: it was envisioned that the scope of a function of scope would be embedded in the Access Token. Or perhaps I don't understand the issue.

I can see three places a description of scope may need to appear.

1. Initial request for token sent by client/requester to AM/AS, so that the right kind of token can be created - this presumably has to be in-band in the protocol. (This is why there's a wrap_scope parameter on the request and nowhere else, right?) This is what we defined it in the proposed UMA step 2.
2. In the token itself. Indeed this is out of band of the protocol itself.
3. If the protected resource/host outsources token validation (such that the token is opaque to the host as well as the client/requester), then the host would need to supply a description of the attempted access made by the client/requester along with sending the token for validation. The note you're responding to just above is this third case.

	Eve

Eve Maler
[email-masked]

---

From: Eve Maler <[email-masked]>
Date: Fri, 5 Mar 2010 06:57:53 -0800

More below...

> This was explicitly out of scope for WRAP. There are scale and privacy advantages to the PR and AR not meeting. The PR needs to trust the AR the issued the Access Token (and of course be able to ve…

(Unfinished sentence?)

As noted above, it's fine for this to be out of scope for WRAP itself, but it's in UMA's scope.

> Interesting use of WRAP. I don't see a hole in WRAP for you to do this. Is there some functionality missing?

I don't understand the comment/question.  Are you suggesting the WRAP pattern (same as the three-legged OAuth pattern, which our current spec uses) can't be applied to new use cases?  It's pretty much a vanilla application of the pattern.  If it's not interesting as a generic solution and the problem space is only UMA's, that's certainly okay with us.

> I can see it being useful in a standard return parameter that can contain an value undefined by WRAP (similar to the scope parameter), that is used by the AS to communicate to the Client what else…

I'm not sure if we're technically "asking for" anything, just floating the use case and pointing out that if we were to layer on WRAP as it's written today, we'd have to extend the possible responses to token requests somehow.  Maybe a new parameter that flags a need for more info from the client/requester is a good idea, but if it's just another undefined parameter, I'd rather have a clean definition of an "extension point" for how others could add parameters (or response types?).  Lots of undefined fields in a core spec doesn't seem interop-friendly.

> Is there something missing in WRAP to do this?

I'm not sure.  If WRAP has the same assumption OAuth does about the "same person" operating the client app as is logging into the protected resource/AS/SP/server, then that's a conceptual difference.  But I don't think we saw any need (yet) for syntax changes in this area to support what we want to do.

> Different scenarios will require different scope values. We thought it useful to define the parameter so that it would  be easier library providers and specs like UMA to define the value without al…

I'd like to learn more about the other use cases.  If common cases exist and can be sedimented in for more universal support, that would be cool.  (If not, okay.)  But along the lines of my earlier comment on extension points, I'm not sure standardizing the field is valuable without standardizing any values at all -- it may just confuse people about whether they're supposed to stuff a bunch of different things into the one parameter if they seem vaguely "scope"-related, or invent their own, or whatever.  And then you have to worry about how to stuff incompatible scope values into the same parameter side by side for hybrid use cases that use multiple extensions.  Etc.

> When developing WRAP, we envisioned that the PR would verify and interpret locally.

It's probably worth mentioning that at least two UMA scenarios (health data, and distributed social networking services with "data portability") envision applications that frequently serve as both hosts/PRs and requesters/clients, so if processing burdens are removed from the client but placed on the PR, it may not help us all that much.  This is an area where I hope others can chime in with use cases and constraints to figure out which "scaling" options suits them best.  (And if WRAP/OAuth remains silent on the issue, it seems UMA could still define this loop as an extension.)

> Posting what you find to the list prior to Anaheim would be useful for the rest of us to have a chance to digest and then we can discuss in detail at Anaheim.

Thanks for your feedback on these points.  I look forward to continuing the dialogue.

	Eve

Eve Maler
[email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Mon, 8 Mar 2010 14:21:41 -0800

>> This was explicitly out of scope for WRAP. There are scale and privacy advantages to the PR and AR not meeting. The PR needs to trust the AR the issued the Access Token (and of course be able to v…

D'oh ... In this way WRAP is a claims based model.

> I don't understand the comment/question.  Are you suggesting the WRAP pattern (same as the three-legged OAuth pattern, which our current spec uses) can't be applied to new use cases?  It's pretty m…

I have no issue with WRAP being used in this way. I have not seen the pattern before. Perhaps once UMA is well known, others will want to use the same pattern and we can standardize it.

> I'm not sure if we're technically "asking for" anything, just floating the use case and pointing out that if we were to layer on WRAP as it's written today, we'd have to extend the possible respons…

I don't see if as being widely used enough to standardize in the spec. Having UMA standardize it makes sense to me. As mentioned, standardizing the name similar to the wrap_scope parameter would make it easier for libraries.

> I'd like to learn more about the other use cases.  If common cases exist and can be sedimented in for more universal support, that would be cool.  (If not, okay.)  But along the lines of my earlier…

The feedback we received from library writers was standardizing the syntax was useful. There was little agreement on what the value of wrap_scope would be across implementors, but all agreed a standard parameter for scope was useful. We could add to the spec to clarify how the scope parameter should be used. It could make sense for UMA to standardize what the scope values are.

> It's probably worth mentioning that at least two UMA scenarios (health data, and distributed social networking services with "data portability") envision applications that frequently serve as both…

I'm confused by your comments. The Client does not do any processing of the Access Token. Would you clarify who you are trying to offload Access Token validation from and to?

---

From: Eve Maler <[email-masked]>
Date: Tue, 9 Mar 2010 07:05:39 -0800

Thanks for your further feedback.  Just a couple of comments back (eliding other portions of the thread):

> The feedback we received from library writers was standardizing the syntax was useful. There was little agreement on what the value of wrap_scope would be across implementors, but all agreed a stan…

It's a good idea to give guidance on how the scope parameter should be used.  That way, it will help avoid "abuse" of the parameter for other purposes, and clashes if different deployments are using it in different ways.  (I suspect that the tradeoff here is making it (superficially?) appealing for implementers vs. making it more interoperable for deployers.)

> I'm confused by your comments. The Client does not do any processing of the Access Token. Would you clarify who you are trying to offload Access Token validation from and to?

Right, the Client doesn't do this processing.  However, if the point of making tokens opaque to "the Client" is to save them trouble, I wanted to point out that some of our use cases have the same overall application deploying a Client along with also being a Protected Resource, and that it could be reasonable to want to save such an app as much trouble as possible in the aggregate.  WRAP today assumes that "the Protected Resource" validates a signature locally.  However, this could be expensive (in the sense of requiring PKI infrastructure).  Another option is to have it offload validation to the Authorization Server as a back-channel operation, which has its own pros and cons.  For now, in UMA we're thinking of defining the back-channel loop as an extension (which could be completely opaque to the core protocol underneath).

	Eve

Eve Maler
[email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Tue, 9 Mar 2010 07:59:56 -0800

> It's a good idea to give guidance on how the scope parameter should be used.  That way, it will help avoid "abuse" of the parameter for other purposes, and clashes if different deployments are usin…

Thanks. Will add to list of edits.

> Right, the Client doesn't do this processing.  However, if the point of making tokens opaque to "the Client" is to save them trouble, I wanted to point out that some of our use cases have the same…

Understood. We could add to the spec that the validation could happen at a service instead of locally.

-- Dick