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

Christian Scholz cs at comlounge.net
Thu Jul 8 05:39:33 EDT 2010


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/


More information about the WG-UMA mailing list