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 <bcampb...@pingidentity.com> 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 <wdenn...@google.com > <mailto:wdenn...@google.com>> 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 <wdenn...@google.com > <mailto:wdenn...@google.com>> 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 <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>> 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 <wdenn...@google.com >> <mailto:wdenn...@google.com>> 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, <internet-dra...@ietf.org >> <mailto:internet-dra...@ietf.org>> 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 >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
