Re: [OAUTH-WG] PKCE/SPOP

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.)

On Tue, Feb 3, 2015 at 6:51 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

> 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 <bcampbell@pingidentity.com>
> 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
>
>    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 <ve7jtb@ve7jtb.com> wrote:
>
>>
>> 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.
>>
>>
>> _______________________________________________
>> 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
>
>