[WG-UMA] Draft minutes of UMA telecon 2010-07-22

George Fletcher george.fletcher at teamaol.com
Fri Jul 23 16:59:40 EDT 2010

The only difference in "general" OAuth is that the client id and secret 
are provisioned out of band, so if "trust" is needed, the secret is used 
and sent in the initial request (or used for signing in 1.0a). So it's 
harder for someone to impersonate the app because they have to have the 

In the dynamic registration case, all the attacker has to do is "point" 
to the xrd that identifies the app rather than present the secret.

However, we might be able to close some of that with Maciej's proposal.


On 7/23/10 4:42 PM, Christian Scholz wrote:
> Am 23.07.10 20:45, schrieb George Fletcher:
>> The only concern is that by giving out the same client id and secret to
>> any app that claims it is that app, it is possible to steal that app's
>> secret and then get access to resources that have already been approved.
>> Taking this approach makes it very critical to establish that the client
>> "app" is really who it claims to be.
> Thanks for the clarification! But isn't this a general OAuth2.0 problem
> then? Maybe you should bring it up on the OAuth list :)
> -- Christian
>> Thanks,
>> George
>> On 7/23/10 2:40 PM, Christian Scholz wrote:
>>> Hi!
>>> Am 23.07.10 18:51, schrieb Holodnik, Tom:
>>>> I had a minor note about the minutes that Eve prepared (to clarify a
>>>> question I raised).
>>>> Tom asks whether a native app on, say, a phone, representing a unique
>>>> instance of an application should get different credentials from the
>>>> same kind of native app running on a different phone. George suspects
>>>> that the best way to go is to give each instance different
>>>> credentials.
>>> So why is that necessary? It is in fact the same app but different
>>> instances and it's just the first step before authorizing the user in
>>> which case the individual app instance is then authorized.
>>> And as in OAuth today there is also no requirement (and it's not
>>> possible anyway) to register each device.
>>> my .02EUR
>>> -- Christian
>>>> What I was after was whether the same software running on different
>>>> machines, running on behalf of the same user (or the same group of
>>>> people, like a business) should get the same client ID and secret or
>>>> whether it needed to be unique.  George (rightly, in my opinion) said
>>>> that it must be unique.
>>>> The impact of this is that if Alice grants permissions to Bob to
>>>> access her resources using Application A, that access is extended to
>>>> Bob, running an instance of Application A on one of his machines (any
>>>> or all of which is running Application A). This seems like something
>>>> that would have some usability or operational impact that we might
>>>> want to be explicit about.
>>>> Lacking this, it seems there would be significant risks from brute
>>>> forcing and spoofing.
>>>> My intention was to expand on what we mean about uniquely identifying
>>>> an application.
>>>> Thanks, -tom
>>>> Tom Holodnik  -  Security Architect -- Intuit Inc.  -   Office:
>>>> 650-944-5494  -  Mobile: 650-387-6574
>>>> _______________________________________________ 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20100723/66916eab/attachment.html 

More information about the WG-UMA mailing list