hi Hannes.
On Apr 25, 2014, at 12:37 PM, Hannes Tschofenig <[email protected]> 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 see http://www.ietf.org/mail-archive/web/oauth/current/msg11599.html regards antonio > > 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:[email protected]","nbf":1398420753,"exp":1398424353,"iat":1398420753} > > jwt.encode({"iss":"https://as.example.com","sub":"mailto:[email protected]","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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
