I think -15 does address the inconsistency. On Fri, Jul 10, 2015 at 9:36 AM, John Bradley <ve7...@ve7jtb.com> wrote:
> 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/ > > Thank you, > Kathleen > > On Thu, Jul 9, 2015 at 2:46 PM, John Bradley <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 >> >> 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> >> 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> >>> 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> 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> >>>>> 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> 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/ >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> 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 >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > > Best regards, > Kathleen > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
