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

Brian Campbell <bcampbell@pingidentity.com> Mon, 28 April 2014 12:51 UTC

Return-Path: <bcampbell@pingidentity.com>
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 02BBB1A0710 for <oauth@ietfa.amsl.com>; Mon, 28 Apr 2014 05:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.211
X-Spam-Level:
X-Spam-Status: No, score=0.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FR_TEST_BASE64_BAD=3.189, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no
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 Nb0LPx1SRcUn for <oauth@ietfa.amsl.com>; Mon, 28 Apr 2014 05:51:11 -0700 (PDT)
Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with ESMTP id F27771A047C for <oauth@ietf.org>; Mon, 28 Apr 2014 05:51:09 -0700 (PDT)
Received: from mail-ie0-f181.google.com ([209.85.223.181]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKU15OvVxacHNm0DGbXL59K+6xegZRZRp6@postini.com; Mon, 28 Apr 2014 05:51:09 PDT
Received: by mail-ie0-f181.google.com with SMTP id y20so4572045ier.40 for <oauth@ietf.org>; Mon, 28 Apr 2014 05:51:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7yttI/rN4PqJnbcsckVtV+wNToOFyByEuWeX1dga+Eo=; b=WwQ+pvBrRq57FfV8EukwqaKdfLWl/syKZOp6sc7pjLeNeJlPHjdHqdnqIyRR0VlmcI fJdvxCtPJgF9DZGEPDCb/Z4HWGxFxMf76y+oWLaCC+JIu4lLvVDEoGtehhcXyo+Dg5sO RIt2SOFdKkBJOusS2BcYv97DPKGU68rlcd5wUJIHvySiAZGGQgP3BW906Wg60U3Qbrq3 Eaymh5aDuGYdZZDJRdJfjdK1p37VVAKz1YqOJ4reE7zOUC+UJgMCCgh1QD2e9gfRsCSo 5E6e0Pj5YoXJF0gWeLnngOv3cy8YTtq0SdwJsO+rnfHiqxpAZeuKHXTp0mRTMbshy55d C4vg==
X-Gm-Message-State: ALoCoQkdV5LiQ6eSugj8UrXLwplqd94GwYmtSKaxNFcBVAwHV6EtyKAt698xx9u+t1RMA4McLrFb7tUBMkM94tqgRZidEmyZRwXlAJc7RGa0lHUEEeW1lpFqUw2n464xQLLFQpyQRGxv
X-Received: by 10.43.148.66 with SMTP id kf2mr21636551icc.30.1398689469013; Mon, 28 Apr 2014 05:51:09 -0700 (PDT)
X-Received: by 10.43.148.66 with SMTP id kf2mr21636532icc.30.1398689468779; Mon, 28 Apr 2014 05:51:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.240.201 with HTTP; Mon, 28 Apr 2014 05:50:38 -0700 (PDT)
In-Reply-To: <535E127B.2010504@gmx.net>
References: <535A3AF4.4060506@gmx.net> <CA+k3eCTyA3PPY4BLKUjwJa91ovY5v6EhbwH+Ss2OSsajJdOOPw@mail.gmail.com> <535E127B.2010504@gmx.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 28 Apr 2014 06:50:38 -0600
Message-ID: <CA+k3eCRxcSSJpk+uAxB-FfhsB7UFavNGhtDbwDYhS8tT1=65Jg@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary="001a11c2e5acf0256404f819c4bc"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zP1pikfoVkguxaGJj70p_yjEG6M
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 12:51:13 -0000

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> 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>> 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> 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
> >","nbf":1398420753,"exp":1398424353,"iat":1398420753}
> >
> >     jwt.encode({"iss":"https://as.example.com","sub":"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>
> >     https://www.ietf.org/mailman/listinfo/oauth
> >
> >
>
>