[WG-UMA] Notes from 7 July 2010 focus group meeting
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/authoring/draft-mrose-writing-rfcs.html (good rundown of all formatting, with examples)
On 8 Jul 2010, at 2:39 AM, Christian Scholz wrote:
> 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:
> 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:
>> Proposed requirement: The client needs to be uniquely identifiable by
>> the authorization server.
>> Discussion: Keep this one. It motivates the need for the entire
>> 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
>> 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
>> 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:
>> 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
>> AI: Eve will link Maciej's drafts and assorted other stuff from the
>> Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl
>> _______________________________________________ WG-UMA mailing list
>> WG-UMA at kantarainitiative.org
> 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
> 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
More information about the WG-UMA