UMA telecon 2010-02-25

Date and Time

• Day: Thursday, 25 Feb 2010
• 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)

Agenda

• Roll call
  • Any missing next week due to RSA?
• Approve minutes of UMA telecon 2010-02-18
• Action item review
• Spec review
  • Expect a new draft by Wednesday night; please review carefully before the call if possible
  • Report from spec editors' meeting
  • Review new spec changes
• Lexicon discussion
  • Establish need (if any) for legal dimension
  • Establish need (if any) for custodial dimension
  • Custodian scenario review
• AOB

Attendees

As of 19 Feb 2010, quorum is 9 of 16.

1. Akram, Hasan
2. Bryan, Paul
3. Catalano, Domenico
4. Holodnik, Tom
5. Lizar, Mark
6. Machulak, Maciej
7. Maler, Eve
8. Smith, Bill

Guest:

• Joni Brennan (staff)

Regrets:

• Trent Adams
• Joe Andrieu

(TomH and Paul send regrets for next week.)

Minutes

New AI summary

Roll call

Quorum was not reached.

(Anybody who has to miss next week due to RSA? No.)

Approve minutes of UMA telecon 2010-02-18

Deferred due to lack of quorum.

Action item review

• 2009-12-03-04 Eve Open Add terms-negotiation scenarios to Scenarios document. Delayed while we sort through requester concepts.
• 2010-01-28-2 Joe Open Edit protected inbox scenario in response to telecon and email discussion. Still pending.
• 2010-02-11-1 Paul Open Develop new core spec draft. See below.

Spec review

• Report from spec editors' meeting

We now have a spec editing team, with TomH and Maciej taking on some spec editing duties, and Eve and Paul continuing. Ultimately, Paul may need to step away as official lead spec editor (necessitating a new vote), but we can cross that bridge when we come to it.

• Review new spec changes

Paul hasn't quite gotten all the spec simplifications done. Part of this process involves removing many of the discovery steps and using well-known locations instead. Paul has been engaging with Eran H-L and others on the OAuth list regarding planned directions for OAuth discovery, and it appears our earlier assumptions are no longer valid: It was suggested there to use link headers, which contradicts Eran's recent XRD work, and Eran himself spoke in favor. Observing the volatility that has been introduced into the OAuth V2.0 process, and struggling with how consumer/client credentials would get issued in the new OAuth, Paul now feels WRAP may be a better fit at this point.

Our early analysis of WRAP for UMA purposes surfaced a key issue about token scoping, but we have been revising our estimation of this issue's severity. WRAP would require one access token per resource (e.g. one token for each of 100 photos in a photo set), but today's UMA already requires authorization negotiation for each resource anyway.

If we now allow the requester to carry an authorization token to the host, it would simplify the spec (at the cost of some flexibility for scale reasons). It would also change the nature of the requester's relationship with the host, in that the requester could theoretically approach the host just once, if it already knows where the AM is and satisfies the AM's criteria for getting a token and then carries it straight to the host without having been there yet. And at the least, the host no longer requires that the requester has to pre-register with it (as far as UMA is concerned; the host might demand it anyway).

The possibility still exists for negotiating a "scoped token" (a la the hints in the Simple Web Token spec, with the scope field), but need we solve that today? Why can't we allow the host to make a back-channel call to the AM to interpret the token (essentially getting a policy decision), to have it scoped in real time? This amounts to retaining the PEP/PDP model embedded "inside" the STS model that WRAP uses.

• WRAP's STS model: requester gets a token directly from the STS (our AM), which is directly usable at the host
• UMA's PDP model today: requester believes, based on its AM interactions, that it will be authorized, and approaches the host, which always asks the PDP (our AM) for a policy decision

Would it be useful to have a hybrid model, which satisfies simple use cases by allowing the token to be directly usable, and complex (e.g. wider-scope) use cases by allowing the host to send the token to be interpreted by the AM? Bill suggests: Or should we require the requester to be the conduit for resolving the scope? Eve argues in favor of the former, since the PDP model is classic and widely adopted, and since she'd like to avoid ever burdening the requester more than the host. Maciej really wants to ensure that we have a solution for scoping tokens some way or other, and is interested to see how chatty the protocol comes out to be using these two different solutions. E.g. "requester gets scope" might be fewer steps than "host gets scope".

We have a spec editing team meeting next Wednesday, where we will carry forward this last (hopefully) major refit of the protocol. Paul now knows what direction to take in the spec and will produce it before then.

Lexicon discussion

The new policy definition is: "A policy is an instruction an authorizing user gives an AM to govern its calculation of access authorization decisions. A policy may involve dictating a requirement for a requester to provide one or more claims." The group accepts it.

The new claim definition is: "A claim is a statement (as defined in IDCclaim) conveyed by a requester to an AM in an attempt to satisfy a requirement for access." This leans pretty heavily on the not entirely satisfactory Identity Commons definition (if people think that one means IMI claims specifically, though it doesn't say so), but that's okay. Tom asks: How will claims about the requesting party be verified? Eve: They could be third-party asserted and signed.

The requesting party definition is: "A requesting party is a web user, or a corporation (or other legal person), that uses a requester to seek protected resource access on his or her or its own behalf." The term "authorizing user" covers both protocol and legal purposes, but Eve's theory is that we need to distinguish the protocol vs. legal aspects for the requesting side in the spec. We'll go with this for now.

Let's discuss "primary resource user" as part of the custodian scenario; maybe it shouldn't be defined in the protocol spec itself. (Later...) We agreed not to put this term into the spec but to keep it in the lexicon.

Custodian scenario review

Maciej's scenario focuses specifically on an underage person who must delegate authorization control to a responsible adult in her life. Paul questioned how liability would work in this circumstance. The parent, in creating an account at the AM, presumably would have to be verified as to their age and other credentials. The host would have to whitelist trusted AMs that check for this. Regarding introducing the authorizing user into the picture, the host would have to manage this. These seemed to be the biggest outstanding issues.

Regarding mandatory vs. discretionary access controls (MAC vs. DAC – these are industry terms), Maciej feels that they are only one lens through which the scenario can be viewed. He doesn't see this scenario as mandatory per se vs. discretionary. Paul agrees that it's only when you get into tiered access controls that the host potentially has to worry about this.

Eve's study of the LPSO.com site seems to bear out our assumption that this entire process can be essentially invisible to the protocol, and the host simply takes on the major burden of associating an authorizing user with the primary resource user's account and managing the liability chain according to the business model and regulatory compliance burden they have. All agree with this characterization. We'll try and approve the edited scenario next time.

Next Meeting: UMA telecon 2010-03-04

• Day: Thursday, 4 Mar 2010
• 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)