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
