Quorum was reached.
Minutes of 2012-02-16 meeting APPROVED.
Next week's meeting is canceled due to RSA and travel.
Maciej, Thomas, and Eve are doing a Google Tech Talk next week. The second tweet chat is a couple of weeks after that. The F2F interop is a month after that. We need to step up our virtual interop planning and preparation.
The problem: In the current spec, the requester app as controlled by the requesting party first asks for a single access token from an AM, which is upgraded whenever a permission gets added – that is, permissions applying to multiple hosts and multiple authorizing users get associated with the same token, and it just gets upgraded over and over. This potentially exposes information to each host that it doesn't have a right to, because it's about other hosts and users. With dumb implementations that expose token content directly, this could be an information leakage problem. We could instruct the AM to release only the token status data that is relevant to each host/authorizing user. Or we'd have to profile the token content pretty severely to include selective encryption in order to solve the problem if we stick with this single massive token.
A proposed solution: Cleanly separate the notions of the wide-scope OAuth "authenticated identity token" that applies to the requester/requesting party/AM and a set of one or more narrow-scope UMA "authorization tokens" that the AM hands out (or upgrades) when the requester asks for permissions to be added.
Lukasz and Maciej will share the details and diagrams for their proposal on the list ASAP.
As of 14 Feb 2012, quorum is 7 of 12.
Non-voting participants:
Regrets: