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

Eve Maler eve at xmlgrrl.com
Thu Jul 8 11:45:34 EDT 2010


Thanks for posting this!  Re xml2rfc, the formatting options are extremely limited because of the needs of IETF specs.  Here are handy sources:

http://xml.resource.org/
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html (good rundown of all formatting, with examples)
http://lists.xml.resource.org/mailman/listinfo/xml2rfc

	Eve

On 8 Jul 2010, at 2:39 AM, Christian Scholz wrote:

> Hi!
> 
> I updated the draft to include the new requirements but also rewrote
> them a bit or added some more discussion. I also tried to not include
> UMA specific requirements but tried to word them more general.
> 
> You can find it at github or a rendered version here:
> 
> http://mrtopf.clprojects.net/uma/
> 
> This only includes a summary of the processes in question, I will add
> more spec text later hopefully.
> 
> Another point about propagation problem: I am not sure the pull model in
> the spec solves this as it's still started by the client and the server
> would not know at which actual server instance the user will come up.
> This might only work if the user initiates the process but that would
> mean changing OAuth I think.
> 
> So please check the corresponding paragraphs and also check if I
> explained the propagation problem in a way people can understand it. New
> text and addons are welcomed of course.
> 
> And I definitely should try to find a list with all formatting commands
> for xml2rfc ;-)
> 
> -- Christian
> 
> Am 07.07.10 16:57, schrieb Eve Maler:
>> 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
> 
> 
> -- 
> Christian Scholz                          Homepage: http://comlounge.net
> COM.lounge GmbH                                    http://mrtopf.de/blog
> Hanbrucher Str. 33                             http://twitter.com/mrtopf
> 52064 Aachen                                             Skype: HerrTopf
> Tel: +49 241 400 730 0                                  cs at comlounge.net
> Fax: +49 241 979 00 850                                      IRC: MrTopf
> 
> Podcasts:
> Der OpenWeb-Podcast (http://openwebpodcast.de)
> Data Without Borders (http://datawithoutborders.net)
> Politisches: http://politfunk.de/
> Technical: http://comlounge.tv/
> _______________________________________________
> 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