Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 - Examples

[Sergey Beryozkin <[e-mail]>]

As far as I recall the spec example uses line separators and it can 
affect the output

Thanks, Sergey

On 25/04/14 11:37, Hannes Tschofenig wrote:
> Hi all,
>
> As a document shepherd I have to verify the entire document and this
> includes the examples as well.
>
> Section 3.1:
>
> You write:
>
> "
>     The following octet sequence is the UTF-8 representation of the JWT
>     Header/JWS Header above:
>
>     [123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32,
>     34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]
> "
>
> The values IMHO are represented in Decimal code point rather than Octal
> UTF-8 bytes, as stated above.
> See the following online tool to see the difference:
> http://www.ltg.ed.ac.uk/~richard/utf-8.cgi?input=%22&mode=char
>
> Note that you could also show a hex encoding instead (e.g., via
> http://ostermiller.org/calc/encode.html) Hixie's decoder would then
> produce the correct decoding. Here is the link to his software:
> http://software.hixie.ch/utilities/cgi/unicode-decoder/utf8-decoder
> (Note that this program seems to have flaws for most other options.)
>
> When do a Base64URL encoding of
>
> {"typ":"JWT","alg":"HS256"}
>
> then I get
>
> eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
>
> but your spec says:
>
> eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
>
> Same with {"iss":"joe","exp":1300819380,"http://example.com/is_root":true}.
>
> My result:
> eyJpc3MiOiJqb2UiLCJleHAiOjEzMDA4MTkzODAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
>
> Your result:
> eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
>
> Note: I am using this online tool for Base64URL encoding:
> http://kjur.github.io/jsjws/tool_b64uenc.html.
> Interestingly, when I dump the data into http://jwt.io/ then I get a
> correct decoding. It might well be that the kjur.github.io has a flaw.
>
> Just wanted to check what tool you have used to create these encodings.
>
>
> Section 6.1:
>
> The example in Section 6.1 is the same as in 3.1. Maybe it would be
> useful to show something different here.
>
> The example in Appendix A.1 is more sophisticated since it demonstrates
> encryption. To verify it I would need to have a library that supports
> JWE and RSAES-PKCS1-V1_5 and AES_128_CBC_HMAC_SHA_256. Which library
> have you been using?
>
> I was wondering whether it would make sense to add two other examples,
> namely for integrity protection. One example showing an HMAC-based keyed
> message digest and another one using a digital signature.
>
> Here is a simple example to add that almost all JWT libraries seem to be
> able to create and verify:
>
> Header:
> {"alg":"HS256","typ":"JWT"}
>
> I use the HS256 algorithm with a shared secret '12345'.
>
> Body:
>
> {"iss":"https://as.example.com","sub":"mailto:[e-mail]","nbf":1398420753,"exp":1398424353,"iat":1398420753}
>
> jwt.encode({"iss":"https://as.example.com","sub":"mailto:[e-mail]","nbf":1398420753,"exp":1398424353,"iat":1398420753},"12345",
> "HS256")
>
> I used http://www.onlineconversion.com/unix_time.htm to create the
> date/time values:
> "nbf":1398420753 --> Fri, 25 Apr 2014 10:12:33 GMT
> "exp":1398424353 --> Fri, 25 Apr 2014 11:12:33 GMT
> "iat":1398420753 --> Fri, 25 Apr 2014 10:12:33 GMT
>
> Here is the output created with https://github.com/progrium/pyjwt/ and
> verified with http://jwt.io/:
> eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2FzLmV4YW1wbGUuY29tIiwiaWF0IjoxMzk4NDIwNzUzLCJzdWIiOiJtYWlsdG86am9obkBleGFtcGxlLmNvbSIsImV4cCI6MTM5ODQyNDM1MywibmJmIjoxMzk4NDIwNzUzfQ.0gfRUIley70bMP7hN6sMWkHwHezdrv2E1LAVcNdTsq4
>
> Ciao
> Hannes
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>