[WG-UMA] Notes from 7 July 2010 focus group meeting

Eve Maler eve at xmlgrrl.com
Wed Jul 7 13:30:08 EDT 2010


I've just uploaded Maciej's doc contributions and added a whole new table to the Working Drafts page to keep track of where we are with all the various drafts:

http://kantarainitiative.org/confluence/display/uma/Working+Drafts

As part of this, I also refreshed the News box on the home page, something I try to do every couple of weeks:

http://kantarainitiative.org/confluence/display/uma/Home

Don't forget to let your interested colleagues know about this work so they can contribute/implement!  And tell them they should follow @UMAWG on Twitter for news as well.  (Hey, does the SMART project have a Twitter handle?)

	Eve

On 7 Jul 2010, at 7:57 AM, Eve Maler wrote:

> Attending: Eve, Domenico, Christian, Maciej, Nat
> 
> We discussed Christian's latest dynamic client binding spec at:
> 
> http://github.com/mrtopf/UMA-Specifications/blob/master/draft-oauth-binding.xml
> 
> ====
> 
> Proposed requirement: The client needs to be uniquely identifiable by the authorization server.
> 
> Discussion: Keep this one.  It motivates the need for the entire spec.
> 
> Rationale: In future occasions where the same client approaches the same server, the server's logs need to be able to track that client's activities.
> 
> UMA-specific motivation: We need dynamic assignment of unique client credentials because our host and requester roles (which map to a client role in OAuth) need to begin interacting with an AM (which maps to an AS role in OAuth) without prior introduction.
> 
> ====
> 
> Proposed requirement: The authorization server needs to know at least the client name.
> Proposed requirement: The authorization server should be able to request more data about a client than just the name.
> 
> Discussion: This requirement has more to do with learning certain properties of the client than with registration per se.  Is it a requirement at the same level?  If the reason for a "display name" is to help a user (in fact, any number of users) *later*, then we should say that.  Let's try to reword as:
> 
> Replacement requirement: The authorization server must be able to learn certain client metadata to facilitate later interaction with that client, likely in the context of an end-user resource owner.
> 
> ====
> 
> Proposed requirement: Client credentials must be used, e.g. to be able to sign requests.
> 
> Discussion: We can probably omit this, since OAuth gives us the possibility of a client ID and an optional secret, and we can't change that.  We don't seem to have any UMA-specific motivations for something outside these parameters.
> 
> Thus concluded our discussion of requirements.  We'll add more as they seem to emerge in the spec-writing process.
> 
> ====
> 
> Then we discussed patterns of credential provisioning.  Christian has outlined three in the draft:
> 
> Proposed pattern: Providing client information on every request and not using client credentials at all.
> 
> Discussion: Does this violate the first requirement above?  The OAuth list discussed this possibility, so maybe we should keep it for now.  So Christian can keep it in place for now, and if we discover we have some UMA-related motivation to include advice around this pattern in our I-D, we can keep it in.
> 
> ====
> 
> Proposed pattern: The client pushes client information to the authorization server which returns client credentials.
> 
> Discussion: This is essentially the push model; what's being pushed is the client metadata.  This matches to the push model in Maciej's spec draft.
> 
> ====
> 
> Proposed pattern (note that the wording differs from what is in Christian's draft): The authorization server pulls information from the client and returns [was "pushes"] client credentials.
> 
> Discussion: We should somehow capture the underlying requirement for why the pulling of metadata is potentially useful.  The pull model gives the strongest possible authentication of the client, so perhaps we should add a requirement like this:
> 
> Proposed requirement: The authorization server must have the option of strongly authenticating the client and its metadata.
> 
> Discussion: Let's keep this wording for now, and wordsmith later.
> 
> Proposed requirement: Something about capturing the specific limitations and needs of the mobile environment and/or the propagation problem?
> 
> Discussion: We intend to use dynamic client binding as a portion of UMA's Step 1 as necessary (whenever the host happens not to have met this AM), and this means that a user is involved approximately "synchronously" in the flow sometimes.  For example, if a user wants to introduce Flixr to CopMonkey and those two services have never met before, Flixr will have to go and get unique client credentials for itself before it can proceed to get an access token that binds it, the user, and CopMonkey together.  Do we have to make pull an option to avoid propagation issues?
> 
> ====
> 
> Proposed requirement or design principle: Import all of UMA's existing requirements and design principles!  This includes simplicity etc.
> 
> The UMA requirements document is here: http://kantarainitiative.org/confluence/display/uma/UMA+Requirements
> 
> ====
> 
> Christian and Maciej will coordinate the editing/forking of the client binding through Skype, hopefully with the goal of having a fleshed-out draft for tomorrow's WG meeting.  Then we can work through it and confirm (or deny) specific pieces in order to make progress.
> 
> ====
> 
> AI: Eve will link Maciej's drafts and assorted other stuff from the wiki.
> 
> 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


Eve Maler
http://www.xmlgrrl.com/blog
http://www.twitter.com/xmlgrrl
http://www.linkedin.com/in/evemaler



More information about the WG-UMA mailing list