[WG-UMA] Notes from 28 July 2010 focus meeting

George Fletcher george.fletcher at teamaol.com
Wed Jul 28 13:17:22 EDT 2010


Just to make sure I understand, here are some key decisions... are these 
correct?

1. The connection between the invoking client and the url they provide 
is being left out-of-scope.
2. "Pull" is preferred over "push" (due to the issues with securing the 
data in the "push" model)
3. The key to verify signed pushed metadata SHOULD be present in the XRD 
"pulled" via the supplied URL (otherwise sig verification will fail)

Question:
1. Do we need to draw a distinction between app instance registration 
and app "class" registration? Or another way to think about it is, 
should the AS give out the same client_id and client_secret to any app 
that registers with a given app "class". For example, any app providing 
a URL for the iphone photo app will get that app's client id and secret?

Thanks,
George

On 7/28/10 10:56 AM, Eve Maler wrote:
>
> Attending: Eve, Kevin Cox (new WG member!), Nat, Domenico
>
> Administrative:
>
> 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?
>
> Dynamic registration:
>
> 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.
>
> Meetings:
>
> 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.
>
> Eve Maler
> http://www.xmlgrrl.com/blog
> http://www.twitter.com/xmlgrrl
> http://www.linkedin.com/in/evemaler
>
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma
>

-- 
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: george.fletcher at corp.aol.com
AOL Inc.                          Home: gffletch at aol.com
Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20100728/ab262862/attachment.html 


More information about the WG-UMA mailing list