UMA telecon 2009-11-12

Owned by Former user (Deleted)
Last updated: Nov 12, 2009Version comment
7 min read

UMA telecon 2009-11-12

Date and Time

NOTE: The UTC hour has changed, but we're back on our "normal" schedule (9am in Seattle, 6pm in Munich, and so on) now that all seasonal time changes have been taken into account worldwide.

  • Day: Thursday, 12 Nov 2009
  • Time: 9:00-10:30am PST | 12:00-1:30pm EST | 17:00-18:30 UTC (time chart)
  • Dial-In:
    • Skype: +9900827042954214
    • US: +1-201-793-9022 | Room Code: 295-4214 (other local country numbers available on request)

Attendees

Quorum is 13 of 24. Voting participants:

  1. Adams, Trent
  2. Akram, Hasan
  3. Bryan, Paul
  4. Carroll, Tom
  5. Catalano, Domenico
  6. Fletcher, George
  7. Hanson, Michael
  8. Hogberg, Jonas
  9. Holodnik, Tom
  10. Machulak, Maciej
  11. Maler, Eve
  12. Smith, Bill
  13. Stollman, Jeff

Guests:

  • Joni Brennan (staff)

Regrets

  • David Chadwick
  • Christian Scholz
  • Iain Henderson
  • Peter Davis
  • Gerry Beuchelt

Agenda

  • Administrative
    • Roll call and administrative stuff
    • Approve minutes of UMA F2F 2009-11-02
    • Meeting schedule for rest of 2009: Nov 19, Dec 3, Dec 10, Dec 17?
  • Implications of WRAP
  • AOB

Minutes

Administrative

Quorum reached.

Deferred so people have time to really study them.

  • Meeting schedule for rest of 2009: Nov 19, Dec 3, Dec 10, Dec 17?

Looks good.

  • F2F meeting schedule in 2010

Let's put all the tentative events on our meeting page and see where we have critical mass. We currently have three, one in March and two in May. We may at least hold "meetups" where there are too few participants for a real meeting.

Implications of WRAP

Overview and terminology primer
  • OAuth as generally used today has a Service Provider (SP) and Consumer (no separate authorization piece)
  • OAuth in its latest spec direction has a Server and Client (no separate authorization piece)
  • UMA has an Authorization Manager (AM), Host, and Requester (illustrated here)
  • WRAP has an Authorization Server (AS), Protected Resource, and Client

George has been involved in this for the last few months. There are a couple of drivers. People have seen less adoption of OAuth than they were hoping; Google and Yahoo! rolled out APIs and didn't see the uptake they expected. That was one factor: Can we do something to increase adoption? If I'm in a browser and I'm moving around, everything is based on a single opaque bearer token; if this is good enough for the web, why couldn't it be good enough for OAuth? Also, can we provide protection by providing short-lived tokens rather than long-lived ones? Google and Yahoo! had already worked on a spec for OAuth session extension that tried to do this. Another driving factor is the Microsoft view of doing things in a claims-based way: Could the token contain claims, so that the "Protected Resource" (UMA would call it the Host) can make decisions based on that? This is bringing an STS or "token issuer" model to an OAuth (or OAuth-like) picture. WS-Security, and ID-WSF, already have a token issuer model.

There are several profiles. The "autonomous client" profiles provide a way for the Requester to identify itself. Whenever it needs a new access token, it re-presents its credentials. For the web-based profiles, a request token can be re-brandished to get a fresh access token over and over.

Client interaction with AS

Eve: Does the Client have to interact directly with the Authorization Server in addition to the Protected Resource? George: Yes; it works with two endpoints. And in fact, this is a little similar to the Yahoo! BBauth/FlickrAuth model. This could be called an "IdP-centric" model, whereas original OAuth could be described as an "SP-centric" model. He's not crazy about the removal of signing, but notes that bearer browser-cookie tokens are widespread.

Separation of concerns

Eve: Are the drivers separable? George: Yes; the session extension for OAuth had a token refresh capability, a concept of invalidating an access token (something like "logout"), and a concept of changing the scope of access. Note that WRAP doesn't deal with how to negotiate precisely what it is you're asking for authorization to access. It has defined a Simple Web Token (SWT) that is about, say, AOL defining an opaque blob as a token format – in practice, it's specific to one company, and thus it's just about as interoperable as the RST/RSTR protocol defined by WS-Trust. If you know you're talking to Yahoo! Updates and AOL Lifestream, you have to know, and code to, whatever extra parameters they each require. Eve: This is roughly true for OAuth today, since SPs are required to provide API documentation to Consumers.

Comparison of AS and AM

Eve: What are the similarities between the WRAP notion of an Authorization Server and UMA's notion of an Authorization Manager? George: WRAP left the majority of the work covered by an AM out of scope. It's up to each individual company to decide how they want to manage the permissioning step. Eve: Again, this is roughly true for OAuth today, since each SP can offer whatever authorization granularity it wants.

Community interactions

Mike: Watching the OAuth and WRAP communities come to terms with each other, WRAP is introducing a set of issues that will get a whole new bunch of people paying attention to "authorization manager"-type use cases. Eve: Maybe this is an opportunity to share our use cases, spec text, and code at this juncture, and get feedback at the IETF and WRAP tables. Our current approach, which composes a flow out of multiple vanilla-OAuth instances, may suffer from whatever deficits OAuth has been discovered to have, but also can be implemented as a very thin shim on top of existing libraries, so this larger community is likely to have opinions about it.

Bearer tokens

Paul B.: Of all the differences between the WRAP and UMA approaches, it seems the bearer token approach amounts to the biggest one. George: Today you can already use the OAuth PLAINTEXT signing algorithm over SSL – or decide you can take the security hit. The current session extension spec uses XRD to let a Consumer discover the endpoint from which to get an access token, and use a standard OAuth flow/endpoint to go back and refresh it. You can also extend the scope of authorization by dropping back into the web delegation flow; this piece came from AOL because it already had it in its proprietary API.

Token life

Paul: How would you deal with very short-lived tokens and claims-handling as proposed by WRAP? George: Either we'd use a 24-hour session length to expire the token, or we'd make the token persistent. WRAP probably doesn't (yet?) include a way, when a token is invalidated, to say "you need to go ask the authorization server for this new capability". The "host" would do some sort of central validation, or do caching plus synchronous notification. Paul: Has some doubt that SWT is sufficient for reasonable needs. George: If the point of an SWT is to allow interop between a Yahoo! and an AOL, then it doesn't meet the bar, but there are simpler cases where the "requester" wants to avoid going through a whole authentication step.

Key management

Paul: His concern about SWT is that it implies the need for PKI, but then ignores it. (smile) There's a shared secret required, but no infrastructure for its management. By contrast, UMA assumes https between the AM and Host. For SWT to work, they'll need the same thing, and it seems out of scope; validating the symmetric key depends on some sort of key infrastructure. George: Agreed, and it's signed anyway! The "requester" doesn't care that it's signed, but the "host" has to do signing. Maybe this doesn't matter because in most deployments you'd encode some data (say, in name/value pairs as SWT defines), encrypt it, and then hand off the signing problem internally to your own infrastructure. The WRAP folks didn't consider the fully distributed case, and this is reflected in the tradeoffs made.

Potential impact of WRAP on UMA design

Paul: If WRAP's current design gets mindshare, we may want to consider moving UMA onto a WRAP infrastructure. George: Our current direction of using two-legged OAuth V1.0a could perhaps end up being replaced by an initial call to a WRAP authz server, but would it necessarily have a big impact on our flows beyond that? Paul: Once we got out of the authentication business, we could layer cleanly on OAuth. But WRAP integrates a new model that joins authentication and authorization together, so this could have a huge impact. Eve: Are we assuming the WRAP authz server and our UMA authz manager would become the same? Paul: He had been assuming yes. George: He's dubious about moving onto a WRAP basis in a huge manner right away; a lot of changes to its approach may still be in the offing. It's viable to consider a model of allowing for more structured data in authz headers (inspired by WRAP) that allows the Host to do things locally that we weren't anticipating before, but flow-wise he wouldn't necessarily use WRAP for anything more than we were already using OAuth.

Development burden allocation

Eve: What is the relative burden of work on the parties, if we assume for a moment that the WRAP and UMA parties map neatly to each other? Paul: Guesses that hosts/protected resources would have roughly the same amount of work. However, requesters/clients would seem to have more work to do, since they have to do more than just trying to "hit a resource" (for a GET or PUT or whatever operation). Requesters/clients and AMs/ASs would seem to have a more "chatty" protocol. Is there a way for WRAP clients to request a token that satisfies a certain scope? George: The spec puts solving this out of scope (so to speak).

Conceptual models

We currently follow an XACML-style model, with a PDP, PEP, PAP, and so on. WRAP is following an STS model, which is entirely claims-based. If we move onto a WRAP basis, we'll probably have to use an SWT format as well.

Summary

The rough consensus is to continue down our current design path while engaging in the larger community discussions and keeping an eye on OAuth directions. It appears that our best window for being heard in the wider community is to have specs and code available throughout the next few weeks (end of year?), and to engage directly on the OAuth and WRAP lists to get feedback. Paul, Eve, and George are already engaged in these venues, but it would be great to have others. Tom H. points out that Intuit has some specific use cases that would ideally feed into all the decision-making. Eve issues a general call to submit scenarios.

Next Meeting: UMA telecon 2009-11-19

  • Day: Thursday, 19 Nov 2009
  • Time: 9:00-10:30am PST | 12:00-1:30pm EST | 17:00-18:30 UTC (time chart)
  • Dial-In:
    • Skype: +9900827042954214
    • US: +1-201-793-9022 | Room Code: 295-4214 (other local country numbers available on request)