UMA telecon 2010-07-22

Date and Time

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

Agenda

• Administrative
  • IRC channel reminder: #umawg on irc.freenode.net (web interface)
  • Roll call
  • Approve minutes of 2010-07-15 meeting
  • Action item review
  • Future legal/focus subgroup meetings?
  • Status reports from the wider UMA world
• Dynamic registration I-D (formatted, source)
  • Aim to make final decisions in this meeting
  • Push vs. pull vs. both vs. merged: What UMA-specific input (e.g. around trusted claims) do we need to provide to help the OAuth group decide?
  • Section on pushing metadata directly: moved?
  • New section on extensibility: written?
  • Include proposal for solution for dynamic binding of user-agent clients?
  • Any other outstanding issues?
• Resource Registration specifics (existing proposal)
  • New SMART draft?
  • How close to I-D form?
  • Walk through major issues and list decision-points
• AOB

Attendees

As of 22 July 2010, quorum is 6 of 10.

1. Catalano, Domenico
2. Fletcher, George
3. Hardjono, Thomas
4. Holodnik, Tom
5. Machulak, Maciej
6. Maler, Eve
7. Moren, Lukasz

Guests:

• Anna Ticktin (staff)

Regrets:

• Christian Scholz
• Kevin Cox

Minutes

New AI summary

Roll call

Quorum was reached.

Approve minutes of 2010-07-15 meeting

Minutes of 2010-07-15 meeting APPROVED, with correction to Tom Holodnik's attendance status.

Future legal/focus subgroup meetings?

We don't know about any scheduled legal subgroup meetings at the moment. We will consider holding a focus subgroup meeting next Wednesday morning; stay tuned.

Status reports from the wider UMA world

We'll make this agenda item a regular feature.

Maciej reports:

• The evaluation of the SMART UX has begun. They have already made some UX changes and gathered lots of UX ideas based on initial feedback (40 completed questionnaires). They still want to have as many study participants as possible (more info here); the goal is at least 80-90.

• They are refactoring their implementation library and will send suggestions to the WG based on this. There isn't enough time in the day to execute on all the ideas they have. The "UMA/j" library will be open-sourced very shortly; it will be modularized to help manage protocol changes and they have a goal of fostering a code contribution community.

Eve reports:

• She attended the SOUPS conference last week. She did a lightning talk on the special challenges of doing technology transfer in building web protocols intended for Internet scale, and also spoke to several researchers who are exploring problem spaces similar to UMA's.

• This week she spoke on UMA at the Cloud Identity Summit (slides), and had lots of offline conversations with other attendees who are interested in UMA as a potential solution for a variety of use cases (health, consumer identity data...). There is strong interest in exploring open-source implementations when they become available.

Dynamic registration I-D (formatted, source)

The goal is to make final decisions in this meeting, and then do a final edit. It's way too late to get I-Ds into official consideration at next week's IETF meeting in Maastricht, but we can mail it out unofficially as soon as it's actually ready.

Meta-issues around this I-D and its organization:

Eve asks: Instead of eliminating options from this draft, what if we edit each registration flow option in place, commenting on how well it meets the requirements we've stated? The OAuth group is the one that has to decide, after all. Thomas suggests that the trust-layer concerns should go in a Security Considerations section.

Further, Eve suggests that since we're applying our own UMA design principles in discussing this, such as simplicity and others (DP1), we should mention those in this document. Even if we explore multiple registration flows, we might want to recommend that the OAuth group pick a single one, or as few as possible.

If we do this, then, George suggests that in keeping 3.1 we should also add a new implementation section 4.1 to explore what the solution should look like in native-app cases. Eve is uncomfortable with out spending a lot more time to work on the harder cases for registration flows we're not even certain will be needed in initial deployment phases.

Let's discuss on the list, with real revised spec text to look at. See discussion and tentative conclusions below.

Section on providing metadata directly (registration flow 3.1): move it?

This is the registration flow called "Providing client information on every request and not using client credentials at all." We were planning to move this to an appendix, but maybe should keep it in place given Eve's suggestion above.

George notes that in the last meeting we discussed the need for a consistent trust layer in order to ensure that the user is presented with the right info about the client. So the requirement, with its explanatory text, seems fine as is; an accurate representation of who the client is will need to be presented to every user consistently. Tom notes that providing digitally signed metadata using this registration flow could achieve this requirement just fine.

In this I-D, we should probably punt on the big trust-layer (e.g. global PKI) issues and not try to design a be-all end-all solution for providing signed metadata directly each time without wielding a client ID.

Requirement 2.4 on mobile devices:

Should we revise this requirement to say "Automatic client binding must be possible from web-server applications and also applications running on mobile devices"? Yes. We have been implicitly assuming that web server-based flows would be covered but we should say it. Currently UMA's step 1 assumes usage of the web server flow exclusively, because the host-as-client has to be a always-online web server. However, UMA's step 2 does require the requester-as-client to approach the AM-as-AS using one of several OAuth profiles, which we haven't yet profiled further but we suspected we'd have to. It's likely that the web server flow wouldn't be sufficient, and native apps should be an option.

*Interaction of requirements 2.1 and 2.4 in giving a problem to the native-app case:

George notes that there are problems in building trust correctly with a native app, because it doesn't have a web server endpoint that the authorization server side can correlate with the provided metadata URL. So even the pull model for native apps has questionable properties; it's just difficult to achieve.

Tom asks whether a native app on, say, a phone, representing a unique instance of an application should get different credentials from the same kind of native app running on a different phone. George suspects that the best way to go is to give each instance different credentials.

Push vs. pull vs. both vs. merged: What UMA-specific input (e.g. around trusted claims) do we need to provide to help the OAuth group decide?

George observes that push seems substantially simpler than pull, and could have just as much security – and you could even push statically signed metadata so that the signing cost isn't greater. If this is the case, then the pull pattern benefits mobile devices but doesn't generically benefit the rest of the ecosystem. Eve suggests that maybe, in this case, the "merged" approach that Christian mentioned in email can be a graceful-degradation case for mobile. The minimum information that the client must send initially is the URL anyway, for proper user confirmation that they're authorizing the right party.

Maciej proposes that the trust problem with native apps could be solved though a nonce-like approach (as sketched in this web sequence diagram). The idea is that the client's "request file" (OpenID Artifact Binding terminology) could be dynamically revised to include a nonce that the native app provided to the server. This seems to have promise, though we don't necessarily want to put together an airtight proposal on this for I-D purposes.

Conclusion:

Eve will try and revise the I-D to propose a single merged solution and to incorporate commentary on the thinking that went into it, mapping to our requirements and design principles.

Resource Registration specifics (existing proposal)

The initial feedback from users in the SMART UX study was that it was really hard to see which resources were protected. So the goal is now to change how resources get registered; the user wants to be logged in at the AM and to select the host applications from there. This suggests a pull model so that the AM can discover resources protected at each host, not the other way around.

Eve observes that "this way around" is often presented to users in today's OAuth world, where a first-party app (server) like Twitter might show users an "application gallery" of (statically registered) clients from which they can choose in beginning to protect their stuff. So if the host hasn't been introduced to the AM yet, the user can take the opportunity to do so at that moment, and then return to the AM and hang out there to configure policies and play with resources and such.

If we stick to the pull model for the RRAPI, then, it sounds like it's consistent both with users' expectations and with requirements to avoid the server propagation problem. The SMART approach has been to implement "bidirectional OAuth", where the host can lodge a token with the AM that the latter can then use at a protected endpoint at the host. (Wow.) Maciej will share more info on this soon. It adds one additional simple HTTP call.

Next Meetings

• Stay tuned on whether we'll hold a focus subgroup meeting on Wednesday, 28 Jul 2010.
• WG telecon on Thursday, 29 Jul 2010, at 9-10:30am PT (time chart)