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

Hi John,

why not make the more secure option the only one?

regards,
Torsten.

John Bradley <ve7jtb@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
><torsten@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-drafts@ietf.org>
>>> Date: 2013/10/19
>>> Subject: New Version Notification for
>draft-sakimura-oauth-tcse-02.txt
>>> To: Nat Sakimura <sakimura@gmail.com>, John Bradley
><jbradley@pingidentity.com>, Naveen Agarwal <naa@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