Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt

[Kathleen Moriarty <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>
> 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 <[e-mail]>
>> 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 <[e-mail]> 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 <[e-mail]>
>>>> 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, <[e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 

Best regards,
Kathleen