Subject: [OAUTH-WG] PKCE/SPOP

From: John Bradley <[email-masked]>
Date: Sun, 1 Feb 2015 21:07:01 -0300

https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143c246658da06e99c225/draft-ietf-oauth-spop-00.txt <https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143c246658da06e99c225/draft-ietf-oauth-spop-00.txt>

I made some edits to the copy in bitbucket.

I changed the reference for unreserved URI characters to RFC3986.  The Base64 spec we were pointing to is slightly different.
The change allows someone in the future to define a new code_challenge_method that would allow a JWT to be valid.
We unintentionally precluded the use of the “.” in code_challenge and code_verifier. 

I also added an appendix B to show the steps of S256 in a way someone could use as a test vector.

Appendix B is a first cut at it so give me feedback, and I can push it to the document tracker later in the week.

John B.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 3 Feb 2015 06:40:24 -0700

I went thought appendix B and reproduced the same calculations. Which is
nice.

One little nit - to be consitent with the notation defined in §2, the appendix
B should have

   BASE64URL(SHA256(ASCII("code_verifier"))) == code_challenge

rather than

   Base64url(SHA256(ASCII("code_verifier" ))) == code_challenge

On Sun, Feb 1, 2015 at 5:07 PM, John Bradley <[email-masked]> wrote:

>
> https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143c246658da06e99c225/draft-ietf-oauth-spop-00.txt
>
> I changed the reference for unreserved URI characters to RFC3986. The
> Base64 spec we were pointing to is slightly different.
> The change allows someone in the future to define a new
> code_challenge_method that would allow a JWT to be valid.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: John Bradley <[email-masked]>
Date: Tue, 3 Feb 2015 11:51:26 -0300

OK I fixed that in bitbucket.

If I don’t hear back from anyone else I will push that version to the doc tracker this afternoon.

John B.

> On Feb 3, 2015, at 10:40 AM, Brian Campbell <[email-masked]> wrote:
> 
> I went thought appendix B and reproduced the same calculations. Which is nice.
> 
> One little nit - to be consitent with the notation defined in §2, the appendix B should have
> 
> On Sun, Feb 1, 2015 at 5:07 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>

---

From: William Denniss <[email-masked]>
Date: Tue, 3 Feb 2015 17:50:04 -0800

Speaking of Base64url, where it's defined in "Notational Conventions", is
there a way to prevent the HTML markup automatically linkifying "Section
3.2" ?  It's not marked up in the XML, but in the HTML output it is – and
the auto-generated link is incorrect, as it points to Section 3.2 in SPOP,
rather than 3.2 in RFC4648.

This may seem trivial, but the fact that we're using a less common variant
of Base64url makes me want to provide as much accurate context as possible
to help implementers.

This is how it renders today (note the Section 3.2 link)

   Base64url Encoding  Base64 encoding using the URL- and filename-safe
      character set defined in Section 5 of RFC 4648
<http://tools.ietf.org/html/rfc4648#section-5> [RFC4648
<http://tools.ietf.org/html/rfc4648>], with all
      trailing '=' characters omitted (as permitted by Section 3.2
<http://tools.ietf.org/html/draft-ietf-oauth-spop-08#section-3.2>) and
      without the inclusion of any line breaks, whitespace, or other
      additional characters.  (See Appendix A
<http://tools.ietf.org/html/draft-ietf-oauth-spop-08#appendix-A> for
notes on implementing
      base64url encoding without padding.)

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 4 Feb 2015 11:38:20 +0900

Hmmm. A bug at ietf.org rendering engine?
Perhaps we may repeat of RFC4648 again there to avoid this behaviour.

2015-02-04 10:50 GMT+09:00 William Denniss <[email-masked]>:

>       character set defined in Section 5 of RFC 4648 <http://tools.ietf.org/html/rfc4648#section-5> [RFC4648 <http://tools.ietf.org/html/rfc4648>], with all
>       trailing '=' characters omitted (as permitted by Section 3.2 <http://tools.ietf.org/html/draft-ietf-oauth-spop-08#section-3.2>) and
>       additional characters.  (See Appendix A <http://tools.ietf.org/html/draft-ietf-oauth-spop-08#appendix-A> for notes on implementing
>>> Appendix B is a first cut at it so give me feedback, and I can push it
>>> to the document tracker later in the week.
>>>
>>>
>>> John B.
>>>
>>>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: John Bradley <[email-masked]>
Date: Wed, 4 Feb 2015 09:26:24 -0300

I will take a look at it today.   I was using the local python version I think.

John B.
> On Feb 3, 2015, at 11:38 PM, Nat Sakimura <[email-masked]> wrote:
> 
> Hmmm. A bug at ietf.org <http://ietf.org/> rendering engine? 
> 2015-02-04 10:50 GMT+09:00 William Denniss <[email-masked] <mailto:[email-masked]>>:
> Speaking of Base64url, where it's defined in "Notational Conventions", is there a way to prevent the HTML markup automatically linkifying "Section 3.2" ?  It's not marked up in the XML, but in the HTML output it is – and the auto-generated link is incorrect, as it points to Section 3.2 in SPOP, rather than 3.2 in RFC4648.
> 
> This may seem trivial, but the fact that we're using a less common variant of Base64url makes me want to provide as much accurate context as possible to help implementers.
> 
> On Tue, Feb 3, 2015 at 6:51 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> On Feb 3, 2015, at 10:40 AM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> http://nat.sakimura.org/ <http://nat.sakimura.org/>
> @_nat_en

---

From: Brian Campbell <[email-masked]>
Date: Wed, 4 Feb 2015 06:40:12 -0700

I *think* this is the same formatting issue that is discussed, with a way
to work around it, at
http://www.ietf.org/mail-archive/web/jose/current/msg04571.html

On Wed, Feb 4, 2015 at 5:26 AM, John Bradley <[email-masked]> wrote:

>> This may seem trivial, but the fact that we're using a less common
>> variant of Base64url makes me want to provide as much accurate context as
>> possible to help implementers.
>>

---

From: John Bradley <[email-masked]>
Date: Wed, 4 Feb 2015 17:25:53 -0300

Yes that is what it is.  I didn’t know that the HTML was produced based on the TEXT doc rather than the XML.

I have fixed that and a couple of others in the doc.   I am trying to find a way to test it with rfcmarkup before updating.

John B.

> On Feb 4, 2015, at 10:40 AM, Brian Campbell <[email-masked]> wrote:
> 
> I *think* this is the same formatting issue that is discussed, with a way to work around it, at http://www.ietf.org/mail-archive/web/jose/current/msg04571.html <http://www.ietf.org/mail-archive/web/jose/current/msg04571.html>
> 
> On Wed, Feb 4, 2015 at 5:26 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> On Feb 3, 2015, at 11:38 PM, Nat Sakimura <[email-masked] <mailto:[email-masked]>> wrote:
>>