Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt

[John Bradley <[e-mail]>]

I have made some edits to make it consistent.  They are checked into the butbucket repo nat and I use, but we can’t update the official draft during the freeze before the IETF meeting.

https://bitbucket.org/Nat/oauth-spop

> On Jul 9, 2015, at 3:19 PM, Brian Campbell <[e-mail]> wrote:
> 
> I agree with William that it's a little confusing. I get that there's a desire to discourage using "plain" but perhaps the language (especially the MUST NOT in 7.2) should be lightened up just a bit? 
> 
> On Wed, Jul 8, 2015 at 8:22 PM, William Denniss <[e-mail] <mailto:[e-mail]>> wrote:
> Following up the discussion on today's NAPPS call, I understand why plain is not presented as the recommended approach in the spec (though it still has some value over not doing PKCE at all, in that it mitigates against the current known attack where a rogue app registers the same custom URI scheme as another), but I feel that after all the back and forth the picture is a little confusing.
> 
> In particular, 4.2 and 4.4.1 include some examples where plain is supported:
> 
> 4.2
> Clients SHOULD use the S256 transformation.  The plain transformation is for compatibility with existing deployments and for constrained environments that can't use the S256 transformation.
>  
> 4.4.1.
> If the client is capable of using "S256", it MUST use "S256", as "S256" is Mandatory To Implement (MTI) on the server. Clients are permitted to use "plain" only if they cannot support "S256" for some technical reason and knows that the server supports "plain".
> 
> But then 7.2 is very vocal that it MUST NOT be used for new implementations:
> 
> 7.2
> Because of this, "plain" SHOULD NOT be used, and exists only for compatibility with deployed implementations where the request path is already protected.  The "plain" method MUST NOT be used in new implementations.
> 
>  What if those new implementations are constrained, as indicated in 4.2 and 4.4.1?
> 
> 
> Also, while S256 is clearly indicated as MTI, little is said about "plain", although it's alluded to that it's not MTI in 4.4.1 ("and knows that the server supports "plain"").
> 
> Should we be more explicit upfront that "plain" is optional for servers to support, if that's the intention?
> 
> 
> On Tue, Jul 7, 2015 at 10:51 PM, William Denniss <[e-mail] <mailto:[e-mail]>> wrote:
> t_m works for me, I just think we should have some indication that it's the name of the transform. Will you also update where it is referenced in the description below Figure 2?
> 
> 
> 
> On Tue, Jul 7, 2015 at 6:28 PM, John Bradley <[e-mail] <mailto:[e-mail]>> wrote:
> Thanks, I fixed my finger dyslexia for the next draft.
> 
> I changed it to t_m rather than “t”  I think that is clearer.  If I were to do it the other way XML2RFC would have double quotes in the text version.
> 
> John B. 
> 
>> On Jul 7, 2015, at 9:38 PM, William Denniss <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> In version 14, there's a typo on this line ("deso") in Section 7.2:
>> 
>> `"plain" method deso not protect`
>> 
>> Also, in the 1.1 Protocol Flow diagram, regarding the text:
>> 
>> `+ t(code_verifier), t`
>> 
>> I wonder if it makes more sense to represent as `+ t(code_verifier), "t"` (note the quotes on the second 't') given that it's a string representation of the method that's being sent?
>> 
>> 
>> On Mon, Jul 6, 2015 at 4:05 PM, <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>  This draft is a work item of the Web Authorization Protocol Working Group of the IETF.
>> 
>>         Title           : Proof Key for Code Exchange by OAuth Public Clients
>>         Authors         : Nat Sakimura
>>                           John Bradley
>>                           Naveen Agarwal
>>         Filename        : draft-ietf-oauth-spop-14.txt
>>         Pages           : 20
>>         Date            : 2015-07-06
>> 
>> Abstract:
>>    OAuth 2.0 public clients utilizing the Authorization Code Grant are
>>    susceptible to the authorization code interception attack.  This
>>    specification describes the attack as well as a technique to mitigate
>>    against the threat through the use of Proof Key for Code Exchange
>>    (PKCE, pronounced "pixy").
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/>
>> 
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-oauth-spop-14 <https://tools.ietf.org/html/draft-ietf-oauth-spop-14>
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-14 <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-14>
>> 
>> 
>> 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 <http://tools.ietf.org/>.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>