And adding to it, it is Google's application team that needs to be persuaded. As usual, persuading application people to use crypto is hard. We have to strike a point that is acceptable to them as well as being somewhat sensible security-wise. Having option to bump up the security is important as a future migration path as well, hence the current design.
=nat via iPhone Nov 10, 2013 1:42、John Bradley <[email protected]> のメッセージ: > Simplicity for clients that don't need the extra security. I happen to > agree with you but it is Google that needs the convincing, as they have > deployed the non crypto version. > As with many things getting people to adopt it is the trick. > > John B. > >> On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt <[email protected]> >> wrote: >> >> Hi John, >> >> why not make the more secure option the only one? >> >> regards, >> Torsten. >> >> >> >> John Bradley <[email protected]> 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 <[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 >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
