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