Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt

[John Bradley <[e-mail]>]

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 <[e-mail]> wrote:

> Hi John,
> 
> why not make the more secure option the only one?
> 
> regards,
> Torsten.
> 
> 
> 
> John Bradley <[e-mail]> 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 <[e-mail]> 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: <[e-mail]>
>>> Date: 2013/10/19
>>> Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
>>> To: Nat Sakimura <[e-mail]>, John Bradley <[e-mail]>, Naveen Agarwal <[e-mail]>
>>> 
>>> 
>>> 
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>