View Source

UMA telecon 2010-03-04

Date and Time

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)

Agenda

Roll call
Approve minutes of UMA telecon 2010-02-18 and UMA telecon 2010-02-25
Note changes to next week's meeting schedule
- 3 hours on Wednesday, no time on Thursday (see last section below)
- Regular dial-in
Action item review
Spec review and discussion (new spec revision)
Scenario dispositions (if revised in time for the call):
- Custodian scenario
- Protected inbox scenario
AOB

Attendees

As of 2 Mar 2010, quorum is 9 of 16.

Adams, Trent
Akram, Hasan
Catalano, Domenico
Fletcher, George
Machulak, Maciej
Maler, Eve

Non-voting participant:

RLBob Morgan

Guests:

Joni Brennan (staff)

Regrets:

Tom Holodnik
Paul Bryan

Minutes

Roll call

Quorum was not reached.

Approve minutes of UMA telecon 2010-02-18 and UMA telecon 2010-02-25

Deferred due to lack of quorum.

Note changes to next week's meeting schedule

3 hours on Wednesday, no time on Thursday
Regular dial-in

Action item review

2010-02-11-1 Paul Open Develop new core spec draft. Now closed.

Spec review and discussion (new spec revision)

Eve described the general ways in which this spec proposal differs from the existing spec – mostly it is shorter and "absorbs" more from the underlying specs (WRAP, hostmeta, and XRD, in this case).

The terminology section has taken out the formal definition of the word "policy". Trent cautions that the word "policy" has a lot of meanings in the outside world, and we should be cautious about how we wield it. E.g., regulatory bodies make policy, which is very different from what we mean. We should try to use it in a qualified fashion, like user policy or access control policy.

Step 1 is conceptually the same as in the existing spec, but a lot of metadata discovery back-and-forth has been dropped in favor of a single hostmeta XRD file. George comments that there may be improvements we can make over time, such as declaring right up front what claim formats (claims-required lists and received claims documents) it supports rather than conveying that later in the protocol and using explanatory "Title" elements.

The part in Step 1 that refers to "user delegation" profiles is the moral equivalent of saying "three-legged OAuth" in the existing spec.

Step 2 is UMA's version of a "how to get a token" phase, which in WRAP is done with what it calls "profiles". George had made some important observations on the mailing list about this step, pointing out that in a person-to-person sharing scenario, perhaps we should see this getting-a-token process as a kind of user delegation profile. Are we going to have to bind a requesting user to the requester app it uses? Eve suspects so, in some fashion.

Whereas our existing spec uses three instances of OAuth (three-legged for user/host/AM, and two-legged for requester/host and requester/AM), going in a WRAP-friendly direction could look like two intertwined instances of WRAP (user delegation profile for user/host/AM, and either autonomous client profile for "requesting legal person"/AM or user delegation profile for "requesting natural person"/AM). The addition of the claims-required cycle could be a fairly modular extension that could apply to any of the profiles in which a requesting party would engage. So a requesting natural person would be faced with a UX that asks them questions, for example ("click I Agree to agree to the terms" etc.).

George wonders if Nat's work on CX could play into such an extension. Eve describes previous analyses done on CX, and concerns about requiring mutual digital signing (crypto burden) and the lack of user-drivenness of the contract (the user accepts the RP's contract). We hope we can learn more about how this applies. George questions the ability to avoid crypto if we end up relying on signing in other places. E.g., if third-party claims conveyed by the requester need some binding to the requester, would that be through crypto?

Step 2 proposes a solution for the wrap_scope parameter, in which the requester conveys to the AM the desired scope of access. George spoke in favor, and particularly spoke in favor of simple wildcarding. Eve's example of designing XRD templating into hostmeta (where they were wary of how complicated it could get) doesn't seem to apply to this case. E.g., we can always just make "*" be the last path component, and get a lot of bang for the buck.

Step 3 invents a way, which doesn't involve signature validation on the part of the host, for a host to achieve token validation. It just uses its own access token obtained in step 1 to access the AM's API for token validation. George thinks token validation could be done in either way (offloading the work or analyzing the token locally), and maybe if WRAP ends up defining both methods, UMA will end up profiling to use one, or maybe it will still allow both.

Eve asks: Should we proceed on this basis, and thereby both depend on the IETF process to define a WRAP-incorporating OAuth 2.0 and influence it to make progress in desired directions quickly? George speaks in favor, as long as we argue for higher-value, higher-security, and higher-sensitivity use cases in addition to the SSL/bearer token paradigm, and as long as non-SSL/signed use cases remain an option. RLBob suggests that we make clear that we're using WRAP as an interim step while waiting for the IETF work to complete, since the WRAP spec itself is a dead end. Maciej speaks in favor of starting with the proposal for future spec work, and stands ready to help with that effort.

In an abundance of caution, Eve will keep the proposal on her personal wiki area while continuing to develop it. We'll hope to get proper consensus at next week's meeting to move onto the new footing.

Next Meeting: UMA telecon 2010-03-10

NOTE: No Thursday meeting next week!

Day: Wednesday, 10 Mar 2010
Time: 9:00am-12:00pm PST | 12:00-3:00pm EST | 17:00-20:00 UTC (time chart)
On-Site:
- Intel offices in Hillsboro, JF3 building, room JFCC121 (conference details)
Dial-In:
- Skype: +9900827042954214
- US: +1-201-793-9022 | Room Code: 295-4214 (other local country numbers available on request)

Browser not supported