[WG-UMA] Notes from 28 July 2010 focus meeting
eve at xmlgrrl.com
Wed Jul 28 10:56:13 EDT 2010
Attending: Eve, Kevin Cox (new WG member!), Nat, Domenico
We plan to have a focus call next Monday Aug 2 at the usual focus-call hour of 7am PT; Anna, can you please add this to the calendar and confirm if Line C is available for our use?
We discussed Eve's most recent overall sketch of a flow from 22 Jul 2010:
"- The server expects all clients to give ("push") it a URL at a minimum, since this is the minimum required info to share with a user to ensure authorization is done with the right party and to discover more metadata."
We agreed that this is a correct assumption.
"- The client can additionally supply ("push") some portion, or all, of the other relevant metadata. [Can we assume that web-app clients exclusively "push" all necessary metadata, and native-app clients exclusively "push" only a URL? This way we don't even need a parameter to declare the "type" of registration pattern. I assume this below.]"
Nat points out that for security reasons, the "pull" version of the flow is to be preferred, with the "push" version to be used only when there's no other option.
Nat suggests avoiding the push/pull language. And instead of indicating the flow type, perhaps the client should indicate its own type (just like in OAuth itself), so it's a web server, or native app, or whatever.
We're agreed on all this. So the next question is, which client types will be in a position to need to supply the metadata along with the URL? Nat suggests that the only case in which the metadata has to be supplied directly ("pushed") is when the client is behind a firewall. Since this is somewhat separate from the client type, should there be a parameter that identifies it as being behind the firewall, or is it just implicit in the fact that metadata has been directly supplied? The need is to indicate whether the client is capable of supporting the pulling of metadata from it. So we're back to something close to the original proposal, type="push|pull", except that the desired semantic is more like supports_pull="yes|no".
Eve wonders if there are security implications to clients that lie about this. Nat suggests that the server should be able to choose whether to support only supports_pull="yes" or also "no".
"- The metadata supplied ("pushed") by the client could be signed or unsigned."
We agreed that clients that need to push metadata should have the option to sign it. But then we don't want to get into the sticky trust-model issues of how to validate the signature! We are willing to hand-wave and say that this process is managed out of band in cases where strong authentication of non-push-capable clients is needed. We agreed that signing of pushed metadata is simply optional for our purposes.
"- If signed, the server retrieves ("pulls") a public key from the supplied URL in order to validate the signature, having correlated the domain the client is coming from with the supplied URL."
This was Eve's attempt to solve all those thorny trust-model issues! We're agreed to dump this part and not say anything about it.
"- If only a URL was "pushed", the server returns a random value of the sort shown in Maciej's diagram, which the native app is required to stuff into a location on its home server, with additional back-and-forth as shown..."
Our new assumption is that web servers and native apps will likely be in a position to support the pulling of metadata. Thus, the "default" case is really easy -- the pull happens in the same way as we've already spec'd it. But we still have to say how the pulling of metadata from a native app happens, and Domenico's suggestion from 23 Jul 2010 is the most recent one on the table.
The way it works is: It's a special case for when a user is installing and configuring a native app such as an iPhone app. When the user buys the app from an app store, the first thing they have to do is run the app and let it connect to its server-side (the "WWW" entity from Maciej's flow diagram). The server-side functions like a proxy for the native app on the phone, in arranging for that instance of the app to get unique credentials. Domenico's proposal allows for propagation of app<->Developer.com trust to the authorization server in steps 5 and 6.
Eve is a bit worried that this approach is untried, even though it makes sense. Perhaps we can sketch it in the I-D but not have to strongly recommend it, and let the OAuth group take it from there. We do need a native-app solution for dynamic client registration eventually, but so do a lot of other people.
If we look at Maciej's original web sequence diagram (http://tinyurl.com/3a8tfmr), his idea was that the client would initiate the registration and would get the nonce for later handling by the WWW/Developer.com side. Eve's naive question in general is: What capability would the Developer.com side have to generate unique metadata for that instance of the native app, so that the authorization server can retrieve it? The reason Domenico made his proposal is that he feels it is the both the likelier scenario and allows for better propagation of trust, since the native app first communicates only with its home base, and that web server can handle it from there. In this way, the "native app" flow would look a lot more like the regular web server flow until the last bits.
Nat had sent comments on the existing xml2rfc draft, which are still, in the main, valid. Eve to keep her AI to edit the dyn reg draft (incorporating this discussion and Nat's comments); Domenico will try to support this with new diagrams that we'll try and turn into ASCII form.
Regarding the idea of doing a big "focus meeting" push next week: Would people be available at this same hour on multiple days next week? Domenico is going on vacation next Thursday and will meet next week's official meeting, sadly! But he can do a Monday focus call. Nat can do one focus group meeting next week, and Monday Aug 2 is best for him. Kevin will try and identify someone in his company who might be able to join and contribute actively. Eve can do Monday, and will check with Maciej, Lukasz, and Christian about their availability.
More information about the WG-UMA