Thanks, Brian! William? Are you good with this version?
On Fri, Jul 10, 2015 at 12:11 PM, Brian Campbell <[email protected] > wrote: > I think -15 does address the inconsistency. > > On Fri, Jul 10, 2015 at 9:36 AM, John Bradley <[email protected]> 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 < >> [email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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, <[email protected]> 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 >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> >> -- >> >> Best regards, >> Kathleen >> >> >> > -- Best regards, Kathleen
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
