Depending on the level of assurance that you might want to achieve, it could have been a random string. That's how some of the existing but widely deployed implementations are doing.
I have taken a step forward to do the hashing to give a little more protection that even if a malware on the device captures the request, it would not be able to use it in time. That's a kind of man-in-the-middle and by that time happens, your device is fairly badly compromised so there are opinion that it would not matter much by that time that just a random string would suffice. If the WG feels that way, I am happy to change it to a random string as well. The current "hash" design was a middle ground between a random string and HMAC etc. 2013/9/3 Prateek Mishra <prateek.mis...@oracle.com> > Nat - is there cryptanalysis of the proposed model available anyplace? > > Extending protocols by throwing in a smidgen of hashing and a tablespoon > of encryption is often a bad idea. One of the strengths of *RFC* 6749 is > that it avoids stuff like that. > > What do you mean when you say - > > [quote] > The server MUST NOT include the "tcsh" value in the form that any entity > but itself can extract it. > [\quote] > > Is this even theoretically achievable without a stateful server that > maintains a table of [code x tcsh] pairs? > > If not, how should the server embed tcsh in "code" and what constructions > are recommended? > > - prateek > > As some of you know, passing the authorization code securely to a native > app on iOS platform is next to impossible. Malicious application may > register the same custom scheme as the victim application and hope to > obtain the code, whose success rate is rather high. > > We have discussed about it during the OpenID Conenct Meeting at IETF 87 > on Sunday, and over a lengthy thread on the OpenID AB/Connect work group > list. I have captured the discussion in the form of I-D. It is pretty short > and hopefully easy to read. > > IMHO, although it came up as an issue in OpenID Connect, this is a quite > useful extension to OAuth 2.0 in general. > > Best, > > Nat Sakimura > > ---------- Forwarded message ---------- > From: <internet-dra...@ietf.org> > Date: 2013/7/30 > Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt > To: Nat Sakimura <sakim...@gmail.com>, John Bradley < > jbrad...@pingidentity.com>, Naveen Agarwal <n...@google.com> > > > > A new version of I-D, draft-sakimura-oauth-tcse-00.txt > has been successfully submitted by Nat Sakimura and posted to the > IETF repository. > > Filename: draft-sakimura-oauth-tcse > Revision: 00 > Title: OAuth Transient Client Secret Extension for Public Clients > Creation date: 2013-07-29 > Group: Individual Submission > Number of pages: 7 > URL: > http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt > Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse > Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00 > > > Abstract: > The OAuth 2.0 public client utilizing code flow is susceptible to the > code interception attack. This specification describe a mechanism > that acts as a control against this threat. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
