Yes I believe I I addressed these comments as part of Barry’s discuss points. They were comments on the changes that Barry introduced that caused a inconsistency. I resolved that in 15.
I think it is good to go. > On Jul 10, 2015, at 12:29 PM, Kathleen Moriarty > <kathleen.moriarty.i...@gmail.com> wrote: > > John, > > The updates were included in the version I approved for posting that also > addressed Barry's discuss points, correct? > > Are we good with the current version to move forward: > https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ > <https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/> > > Thank you, > Kathleen > > On Thu, Jul 9, 2015 at 2:46 PM, John Bradley <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>> wrote: > 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 <https://bitbucket.org/Nat/oauth-spop> > >> On Jul 9, 2015, at 3:19 PM, Brian Campbell <bcampb...@pingidentity.com >> <mailto: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 <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > > > -- > > Best regards, > Kathleen
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
