UMA telecon 2010-07-22
Date and Time
As of 22 July 2010, quorum is 6 of 10.
New AI summary
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.
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.
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.
Is this site useful to you? Please share it!
| | More
Pages in this Space: