Hi John, why not make the more secure option the only one?
regards, Torsten. John Bradley <ve7...@ve7jtb.com> schrieb: >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 ><tors...@lodderstedt.net> 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: <internet-dra...@ietf.org> >>> Date: 2013/10/19 >>> Subject: New Version Notification for >draft-sakimura-oauth-tcse-02.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-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 >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
