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
