We may speculatively satisfy google and upset even more developers by creating more options. I think google eng should be more directly involved in this discussion and make the case.
That said, i do agree with John's analysis that some clients don't benefit. Just worry that the downgraded google option will always tend to be used. I would prefer to go with a single more secure alg as the common solution. Phil > On Nov 9, 2013, at 10:04, Nat Sakimura <sakim...@gmail.com> wrote: > > 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 <ve7...@ve7jtb.com> のメッセージ: > >> 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 <tors...@lodderstedt.net> >>> wrote: >>> >>> 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
