> If you aren't willing to accept the risk of native apps that can't keep
> secrets, don't support such apps.
We continue to say "can't keep secrets". I think what we mean is
"can't keep secrets that are embedded in the code". One could imagine
an install-time, leap-of-faith binding to a remotel
On Thu, Jun 2, 2011 at 5:40 PM, Brian Eaton wrote:
> Well, "rely" is a strong-term. I know of various teams who do this. I
> don't know of any teams that put a heavy reliance on it.
It might validly be just one element of a defense-in-depth strategy.
Regards,
Dave
David B. Nelson
Sr. Softwa
On Thu, Jun 2, 2011 at 4:24 PM, Thomas Hardjono wrote:
> Oh ok, now I get what "authenticating the client" means here. My bad.
> Perhaps the term "authenticating" is not accurate. Maybe "integrity
> verification" of client code is a better phrase.
It *may* include integrity verification of the c
> The group is operating under the assumption that most
> native apps are publicly deployed or that copies of the
> app bundle/binary can at least be obtained by a malicious
> party.
Agreed.
> ... its always possible for the attacker to disassemble the
> program and obtain the secret.
Always pos
> Most native apps will be forgeable ...
I don't understand the rationale behind this assertion. Would you
please point me to the discussion that elaborates on this point.
Thanks!
Regards,
Dave
David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
This issue has likely been discussed "long ago", but I'd like to
potentially re-open the discussion.
> o Native applications that use the authorization code grant type flow
> SHOULD do so without client password credentials, due to their inability to
> keep those credentials confidential.
I u
Hi Hannes,
One comment immediately in the title. Isn't OAuth short for Open
Authorization, not Authentication?
Regards,
Dave
David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
___
OAuth mailing list
OAuth@ietf.o
On Mon, Apr 18, 2011 at 6:46 PM, Eran Hammer-Lahav wrote:
> Procedural issue:
> The companies interested in this work have already showed interest
> in other companion specification so the argument of having to point
> developers to multiple documents is completely without merit.
I'm sorry that
