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

[Hannes Tschofenig <[e-mail]>]

It would be nice to be able to verify the examples in the document(s). I
understand that the ASCII draft format provides a number of limitations.

I wonder what others think. Have you tried to verify the examples? Have
you encounter problems yourself as well?

Ciao
Hannes

On 04/28/2014 02:50 PM, Brian Campbell wrote:
> To be honest, I'm kind of indifferent to it. Yes, the input into the
> example encodings do include CR+LF (the editor is a Microsoft guy after
> all) but they also have space characters that are removed from the
> beginning of each line, which isn't exactly obvious. Describing that in
> a way that everyone will find easy to understand and use seems like a
> difficult endeavor. The octet sequence is there to unambiguously show
> what the input into the encoding was. And one can also always decode the
> base64url content too, to see exactly what the input was.
> 
> So, yeah, I don't know. I'm not against mentioning the \r\n but I don't
> personally think it helps much.
> 
> 
> 
> 
> On Mon, Apr 28, 2014 at 2:34 AM, Hannes Tschofenig
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Hi Brian,
> 
>     thanks for the pointers.
> 
>     It is easy to see from your code where the issue is. In your code the
>     \r\n sequence is added at the end of each line but due to the nature of
>     the ASCII draft formatting a reader only sees the \n (new line) but not
>     the \r carriage return.
> 
>     While the draft provides the UTF-8 representation of each individual
>     character but, as I mentioned in my email below, none of the tools I
>     found produce a convenient way to use this as input for the base64url
>     encoding procedure.
> 
>     I believe it would be good to mention that each line in the examples is
>     followed by the \r\n character sequence to make it easier for those who
>     want to re-create the examples.
> 
>     What do you think?
> 
>     Ciao
>     Hannes
> 
> 
>     On 04/25/2014 03:03 PM, Brian Campbell wrote:
>     > So JWT 3.1 is based entirely on, and is just a subset of, JWS Appendix
>     > A.1. And I've got a test which validates that example in my JOSE
>     library
>     > <https://bitbucket.org/b_c/jose4j>:
>     >
>     https://bitbucket.org/b_c/jose4j/src/master/src/test/java/org/jose4j/jws/JwsUsingHmacSha256ExampleTest.java
>     >
>     > And here's a verification of the Example Encrypted JWT from Appendix
>     > A.1:
>     >
>     https://bitbucket.org/b_c/jose4j/src/master/src/test/java/org/jose4j/jwe/EncryptedJwtTest.java
>     >
>     > The example in Section 6.1 is different than 3.1 - it's a "Plaintext
>     > JWT" using the "none" JWS alg. I've got verification of that one
>     as well
>     > at the top of
>     >
>     https://bitbucket.org/b_c/jose4j/src/master/src/test/java/org/jose4j/jws/JwsPlaintextTest.java
>     >
>     >
>     > On Fri, Apr 25, 2014 at 4:37 AM, Hannes Tschofenig
>     > <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail]
>     <mailto:[e-mail]>>> 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
>     <http://kjur.github.io>
>     >     <http://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]
>     <mailto:[e-mail]>
>     >     <mailto:[e-mail]
>     <mailto:[e-mail]>>","nbf":1398420753,"exp":1398424353,"iat":1398420753}
>     >
>     >    
>     jwt.encode({"iss":"https://as.example.com","sub":"mailto:[e-mail]
>     <mailto:[e-mail]>
>     >     <mailto:[e-mail]
>     <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] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     >     https://www.ietf.org/mailman/listinfo/oauth
>     >
>     >
> 
>