UMA telecon 2011-01-27

Date and Time

• WG telecon on Thursday, 27 Jan 2011, at 9-10:30am PT (time chart)
  • Skype line "C": +9900827042954214
  • US: +1-201-793-9022 | Room Code: 295-4214

Agenda

• Roll call
• Approve minutes of 2011-01-13 and 2011-01-20 meetings
• Action item review
• Scope issues
  • Scoped-access spec draft
  • Report from Jan 12 ad hoc call
  • Report from Jan 26 ad hoc call
  • Capture design decisions
  • Assign AIs for core/scoped-access/rreg spec edits
• AOB

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:

• Kevin Cox
• Frank Wray

Regrets:

• Cordny Nederkoorn

Minutes

New AI summary

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

• 2010-11-18-4 Eve Open Capture new user stories in the wiki. Aging; getting more urgent, not less.
• 2011-01-06-1 Paul Bryan, Sal Open Come up with a recommendation for using or fixing JWT to solve the requester authentication/correlation problem in Step 3. Closed; JWT defines a few attributes in a JSON structure for the purposes of issuing a token, but offers no detail about the key infrastructure, which is the hard part. One mode is "signed", the other is "unsigned". There's not even a way to define a subject. Our Claims 2.0 work could be leveraged to fill some of the gaps. JWT offers C14n and signing of the message, and the audience. It's open as to the claim identifier, as long as they're OIDs or URIs. Their intent is to have an IANA registry to trap common claims and give them short names. Any claim could be identified a URI, but it makes the token longer.
• 2011-01-06-4 Susan Open Write draft UMA trust model. In progress; Susan has been working through user stories and mapping trust model implications (what Rainer H. calls "constellations") to them. Her goal is to have a draft in time for a working session with Rainer and Patrick Curry.

Scope issues

• Scoped-access spec draft
• Report from Jan 12 ad hoc call
• Report from Jan 26 ad hoc call
• Capture design decisions
• Assign AIs for core/scoped-access/rreg spec edits

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?

• A simple solution for the simplest OAuth-type use cases plus a comprehensive PDP/PEP-model solution – not great
• A PDP solution only – clean but involves the same "dumb mule vs. referral" tradeoffs as our previous discussion around Step 2
• A PDP solution for now, with eventual definition of a token structure standard that gives interoperability around an uber-token-revision approach

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.:

• The AM could encrypt the token that it gives to the requester with a private key that the host found out by prearrangement. Then the host could validate locally that the token really came from the AM. But if we require the host to go back to the AM for authorization anyway, why go to the trouble?

• The AM could generate a suitably long and random identifier for the requester. If you want security that's at least slightly better than just "bearer", such that you can establish at least that this requester is allowed to present this token, then you have to test the binding between the requester and the token. George notes the implementation implication (for consumer scale) that if the identifier is encrypted so that it maintains state, it could be cracked over time. Alternatively, though, if the AM has to store the long identifiers over time, there are costs to that too. We could leave this choice entirely up to the AM, except in the case where the host needs to grab keys from the AM – but this solution means the host now has to be able to "do crypto", so we should think about whether this is an undue burden.

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:

• A. Host registers resource set descriptions and action descriptions with AM (described in [draft-uma-resource-reg]).Discussion: Change to reflect new way of handling/referencing action descriptions.

• B. AM maps authorization constraints to permissions according to the user's instructions (out of band).

Step 2:

• A. Requester attempts to access protected resource at host, allowing host to infer the requester's desired resource set and action. Discussion: We have treated the provisioning of resource knowledge from the user (or whoever) to the requester as out of band. However, the tclaims scenario may have to minimally solve it.

• B. Host tells requester the identifier of a resource set that would suffice for access to the resource, and redirects requester to AM (defined in this specification for now). It is assumed that the requester has out-of-band knowledge of possible actions on the resource to which it had attempted access, through host API documentation. Discussion: We're comfortable with the host having this level of discretion over which resource set is the relevant one.

• C. Requester asks AM for an access token, specifying the identifiers of the desired resource set and action(s) (defined in this specification for now). Discussion: Should we further subdivide Step 2 so that the requester first gets an access token that represents requester authentication only (let's call it "authentication of the request" made by the requester), and then it gets challenged by the AM as necessary for claims to ensure that the user's policy is met? Paul argues that this item and the rest of the list need to be revised to reflect our new decisions. He'll do that.

• D. AM looks up the authorization constraints associated with these identifiers and asks for claims as required to satisfy the constraints. Discussion: This is still good, in theory.

• E. Assuming the constraints are satisfied, AM issues an access token and optional refresh token to requester. Discussion: This is still good, in theory.

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:

• A. Requester attempts to access the resource again, this time presenting its requester access token.

• B. Host conveys token to AM for validation. Discussion: This now becomes a request for the AM to authenticate the requester's request message, along with a request for an authorization decision against the resource set and action to which access was attempted.

• C. AM responds saying if the token is still valid (not expired) and providing the token's scope identifier (defined in this specification for now).

• D. Host looks up scope description and confirms that the attempted access matches the permissions granted for this token (defined in this specification for now).

Next Meetings

• WG telecon on Thursday, 3 Feb 2011, at 9-10:30am PT (time chart) – Eve regrets; Maciej will publish the agenda and chair the meeting
• WG telecon on Thursday, 10 Feb 2011, at 9-10:30am PT (time chart)
• WG telecon on Thursday, 17 Feb 2011, at 9-10:30am PT (time chart) – during RSA conference
• WG telecon on Thursday, 24 Feb 2011, at 9-10:30am PT (time chart)