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
