Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 - Examples
Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 28 April 2014 14:34 UTC
Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5651A6F12 for <oauth@ietfa.amsl.com>; Mon, 28 Apr 2014 07:34:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.951
X-Spam-Level:
X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EU4e0IYUuS1Q for <oauth@ietfa.amsl.com>; Mon, 28 Apr 2014 07:34:49 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE091A6F07 for <oauth@ietf.org>; Mon, 28 Apr 2014 07:34:49 -0700 (PDT)
Received: from [192.168.131.128] ([80.92.122.106]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lz3rc-1X0poT1hke-014DQ5; Mon, 28 Apr 2014 16:34:45 +0200
Message-ID: <535E661C.9080002@gmx.net>
Date: Mon, 28 Apr 2014 16:30:52 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Brian Campbell <bcampbell@pingidentity.com>
References: <535A3AF4.4060506@gmx.net> <CA+k3eCTyA3PPY4BLKUjwJa91ovY5v6EhbwH+Ss2OSsajJdOOPw@mail.gmail.com> <535E127B.2010504@gmx.net> <CA+k3eCRxcSSJpk+uAxB-FfhsB7UFavNGhtDbwDYhS8tT1=65Jg@mail.gmail.com>
In-Reply-To: <CA+k3eCRxcSSJpk+uAxB-FfhsB7UFavNGhtDbwDYhS8tT1=65Jg@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="jJEfpDc1LJnnWLE16f7upiQ9b5TebFDSw"
X-Provags-ID: V03:K0:k3g952YFMuLw+bldGRx+IQBrlMvQKdcOu5aO3aAuXHUWzJXG5o5 yz/NUsbzaI9lNSfFXWEeDU5eAr0i6eHii0jHM0doBz+ZsuOvyVqklbSCEVGeq1Rd3R9bgCk 9HZds8OaY7FeJ8ZE8dO8ycpr7maSY73l3ZuJKL4b7jG+nAkMeZbN1J+7Al+cBreUPpmNcQm ye4ZQSNdLMcTw9wtkyVuQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ozUfHzRy-neFgQSDobqBMzwKF3E
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 - Examples
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Apr 2014 14:34:51 -0000
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.tschofenig@gmx.net <mailto:hannes.tschofenig@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.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net> > <mailto:hannes.tschofenig@gmx.net > <mailto:hannes.tschofenig@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:john@example.com > <mailto:john@example.com> > > <mailto:john@example.com > <mailto:john@example.com>>","nbf":1398420753,"exp":1398424353,"iat":1398420753} > > > > > jwt.encode({"iss":"https://as.example.com","sub":"mailto:john@example.com > <mailto:john@example.com> > > <mailto:john@example.com > <mailto:john@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 > > > > > >
- [OAUTH-WG] draft-ietf-oauth-json-web-token-19 - E… Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Sergey Beryozkin
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Antonio Sanso
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Brian Campbell
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Brian Campbell
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Mike Jones
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Brian Campbell
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Mike Jones
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Mike Jones
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Mike Jones