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 > <hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net>> 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 > > <hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net> > <mailto:hannes.tschofe...@gmx.net > <mailto:hannes.tschofe...@gmx.net>>> 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:j...@example.com > <mailto:j...@example.com> > > <mailto:j...@example.com > > <mailto:j...@example.com>>","nbf":1398420753,"exp":1398424353,"iat":1398420753} > > > > > jwt.encode({"iss":"https://as.example.com","sub":"mailto:j...@example.com > <mailto:j...@example.com> > > <mailto:j...@example.com > > <mailto:j...@example.com>>","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 > > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org > <mailto:OAuth@ietf.org>> > > https://www.ietf.org/mailman/listinfo/oauth > > > > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
