Re: [Json] JSON Schema Language

Carsten Bormann <cabo@tzi.org> Mon, 06 May 2019 07:00 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5811B120096 for <json@ietfa.amsl.com>; Mon, 6 May 2019 00:00:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 2PNGmpeY1ns3 for <json@ietfa.amsl.com>; Mon, 6 May 2019 00:00:37 -0700 (PDT)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4CB412003E for <json@ietf.org>; Mon, 6 May 2019 00:00:36 -0700 (PDT)
Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44yDCP4F5qzyll; Mon, 6 May 2019 09:00:33 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <11a605da-0181-a3db-d6f0-e71eb1c1db61@gmail.com>
Date: Mon, 06 May 2019 09:00:33 +0200
Cc: json@ietf.org
X-Mao-Original-Outgoing-Id: 578818830.9411711-13f7834de2759515310c49036385b5d4
Content-Transfer-Encoding: quoted-printable
Message-Id: <374C55B5-BDE6-41FD-AAD7-504FB18FDA8A@tzi.org>
References: <CAJK=1RjV1uv0eOdtFZ8cKn-FfCwCiGP5r2hOz1UamiM6YV4H1A@mail.gmail.com> <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <20190505053921.GA21049@localhost> <ac285e33-0ddc-3b96-fb50-de9b65f40c0e@gmail.com> <20190505070023.GB21049@localhost> <56070772-de6f-2553-94c0-df75c08b4c80@gmail.com> <20190505163626.GC21049@localhost> <CAD2gp_TZYYBTnfd3v6mW2DxjEZxA9nZ-tve_18Gi86gTx8ZcxQ@mail.gmail.com> <11a605da-0181-a3db-d6f0-e71eb1c1db61@gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/f2bs-3nGR9IHBAZfAaomBgLhhwo>
Subject: Re: [Json] JSON Schema Language
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 May 2019 07:00:39 -0000

On May 6, 2019, at 08:33, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> IETF standards like RFC7515) have since years back rather turned to a JSON subset sometimes referred to as I-JSON (RFC 7493).

I cannot find a reference to RFC 7493 in RFC 7515 (part of JOSE).
JOSE does not care, because it signs representations (byte strings), not data model level information.

(JOSE does need ways to represent cryptographic information that may contain numbers that might exceed implementation limits of JSON decoders.  So it represents them as text strings containing BASE64URL(*) encoded byte strings representing big-endian unsigned integers.  That has nothing to do with I-JSON, or actually only with its [incomplete(**)] suggestion to use base64url encoding for byte strings.  Section 2.2 of RFC 7493 does NOT say how to “encode [numbers] in JSON string values”.)

Grüße, Carsten

(*) Where BASE64URL is defined as base64url without padding.
(**) RFC 7493 fails to specify encoding without padding, which, when read at face value, would mean WITH padding according to Section 5 of RFC 4648.
Of course, we know that this isn’t what is meant.