PS I did resist the temptation of doing DH key agreement in the Authorization request /response then using the agreed key as the code proof. That would also be secure but not popular with developers.
John B. On Nov 9, 2013, at 7:51 AM, John Bradley <[email protected]> wrote: > With a native app using a captive browser with no malware, only the response > is susceptible to interception, making encrypting the request redundant. > In other environments and with some user groups the request's challenge needs > to be protected from interception. This may be more the case in a desktop > environment where there is less control over the browser. > > I expect that we will come to two options one unprotected requests and one > for protected requests. > > To Phil's point this is not about identifying the class of software this is > about matching a response to an instance of software. > A software statement gives you a hint about the class of software but not the > instance without per client registration. > > This method gives you the ability to securely return the token to only the > instance of the client that requested it without the overhead of per instance > dynamic registration. > > This is a practical solution to a real problem people are having today, and > versions of this are in production now. > > Nat and I are trying to document it so that there can be interoperability > rather than every AS doing something different. > > John B. > > On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt <[email protected]> > wrote: > >> Hi Nat, >> >> what's the rationale for having different algorithms to produce a code >> challenges? As this may cause interop issues there should be good reasons to >> introduce variants. >> >> regards, >> Torsten. >> >> >> Am 19.10.2013 12:15, schrieb Nat Sakimura: >>> Incorporated the discussion at Berlin meeting and after in the ML. >>> >>> Best, >>> >>> Nat >>> >>> ---------- Forwarded message ---------- >>> From: <[email protected]> >>> Date: 2013/10/19 >>> Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt >>> To: Nat Sakimura <[email protected]>, John Bradley >>> <[email protected]>, Naveen Agarwal <[email protected]> >>> >>> >>> >>> A new version of I-D, draft-sakimura-oauth-tcse-02.txt >>> has been successfully submitted by Nat Sakimura and posted to the >>> IETF repository. >>> >>> Filename: draft-sakimura-oauth-tcse >>> Revision: 02 >>> Title: OAuth Symmetric Proof of Posession for Code Extension >>> Creation date: 2013-10-19 >>> Group: Individual Submission >>> Number of pages: 8 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt >>> Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse >>> Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02 >>> >>> Abstract: >>> The OAuth 2.0 public client utilizing authorization code grant 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 list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
