UMA telecon 2011-01-27

Date and Time

Agenda

Attendees

As of 25 Jan 2011, quorum is 8 of 14.

  1. Mohammad, Alam
  2. Bryan, Paul
  3. Catalano, Domenico
  4. D'Agostino, Salvatore
  5. Fletcher, George
  6. Hardjono, Thomas
  7. Machulak, Maciej
  8. Maler, Eve
  9. Moren, Lukasz
  10. Morrow, Susan
  11. Wolniak, Maciej

Non-voting:

Regrets:

Minutes

New AI summary

2011-01-27-1

Paul Bryan

Open

Revise the Claims 2.0 spec to reference and profile JWT before next Thursday.

He can't make next week's call, but George can.

2011-01-27-2

Eve

Open

Float digital signature requirement proposal on the list.

 

2011-01-27-3

Paul Bryan

Open

Revise the "scoped access" flow list to reflect decisions made in today's meeting.

 

Roll call

Quorum was reached.

Approve minutes of 2011-01-13 and 2011-01-20 meetings

Minutes of 2011-01-13 and 2011-01-20 meetings APPROVED.

Action item review

Scope issues

As noted at the end of yesterday's ad hoc meeting notes, the problem with embedding actual authorization claims into a requester access token is that our AM/host loose coupling leaves the requester with no way to know which of the potentially many tokens it should present in Step 3. What this would naturally devolve into is "one requester access token per resource", which seems like it won't scale. Paul has been a critic of Simple Web Token as well in the past, on the same grounds. When the host and AM are colocated in the same security domain, they can consult with each other as much as they want, out of band of OAuth. But when you tear them apart, you have to consider other options.

Since we already have a standardized host/AM back channel established, Paul recommends going to a strict PDP/PEP model. The host could authenticate the requester successfully in a local fashion, but unless it already has a cached decision from the AM, it would have to call out to the AM for remote validation that the token is associated with the necessary authorizations. George notes that different use cases could argue for different optimizations. If you only have exactly three resources and coarse-grained "read" access to all of them as a set, then putting authorization claims in the token might be tolerable. In fact, the classic OAuth use case is something like a single resource set that's made up of one or several API endpoints (with various scopes/actions possible on them). But the photos/album use case would seem to require Paul's prescription.

Of course, even OAuth use cases get into the token upgrade/downgrade/multiple problem. What's the most attractive way to solve this for UMA in Step 3?

George notes that we know what the scaling and load implications are of letting the PDP do the heavy lifting. It's not hugely efficient, but it's a known quantity. Eve is willing to believe this, though she notes that consumer scale requires handling millions of users, whereas enterprise scale requires handling millions of policies. It would be a "happy problem" if our theoretical worries about AM scaling came true and people clamored for an UMA 2.0 that's more optimized for AM load needs. Paul surmises that we'd see consumer IdPs standing up AMs to take care of scale problems if they didn't already offer them. Susan notes that memcache would be a viable solution in implementing for scale.

So we have consensus that the UMA requester access token, at least in 1.0, may have within it the power to let a host locally authenticate the requester (really it's just authenticating the origin of the request made by the requester), but inherently does not contain authorization claims. We may revise this later with more knowledge and JWT experience, but for now this is the UMA 1.0 solution scope. Implication: Step 3 requires the host to ask the AM for relevant authorization details on first requester presentation of a token.

So what should the requester access token look like? JWT has signed and unsigned modes. The latter's purpose is very close to being the same as a cookie; it's presumed to be valid on its face. It gets security through secure transport layers. To date, in fact, our core spec has dictated that the host outsources requester authentication by asking the AM in real time on the back channel, not just authorization! There are other tricks we could use for the authentication piece that we haven't examined yet. E.g.:

We could learn more about good decisions here by watching how the JWT adoption curve in OAuth goes (e.g. at the next IETF meeting). If resource servers do support JWT signing, then we wouldn't be increasing the burden unduly. And we know some hosts, like, say, hData ones, will need stronger authentication and PKI support all around.

Do we need a new design principle around something like "assurance" or "strong authentication" of entities or similar? The brute-force method of saying it is "Digital signatures: Don't preclude methods of achieving strong authentication through digital signatures, and leverage and adopt them as options where possible."

We walked through the proposed flow of scope communications; everything before "Discussion" markers comes directly from the scoped-access proposal text:

Step 1:

Step 2:

F. AM registers, in the user-specific portion of the host registration area, a scope description that lists the permissions corresponding to the issued access token (defined in this specification for now). Discussion: This is where we really start to go off the rails, based on the previous discussion. The work has to be done, but it's looked up in Step 3 instead. This enables a couple of benefits: the user can change their policy up until the time of the access attempt/policy decision, and the AM can ask for only claims that have expired at the time of the access attempt/policy decision.

Step 3:

Next Meetings