Re: [Txauth] JSON Schema?

Dick Hardt <> Mon, 06 July 2020 20:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 610653A0A50 for <>; Mon, 6 Jul 2020 13:17:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oi7C_VHHQUTR for <>; Mon, 6 Jul 2020 13:17:05 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8966D3A0A49 for <>; Mon, 6 Jul 2020 13:17:05 -0700 (PDT)
Received: by with SMTP id d17so32356332ljl.3 for <>; Mon, 06 Jul 2020 13:17:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SxCNnClmu4slK56y+cQvmOU8xYxJvEtPJNcBROW7dwQ=; b=X6Ikct0QobIGit8vnjoPBPJyc8YQ7F55gSxRh0kU5cKPGQyNBtmjotDhdgOxz+x6OY Sy9Hd28YRHiDms/kDdrB8ukFT1J1aNbZYzVKuHyBvSyqfu+i8+32HTlN6m58aWYwE1ya EVSnojvi9p6ivabv9w41NiMNQJHo/b+iTkg7LY7xa+TvujZUcFlNBM/32LuDoIu02DaA b3BVVvFQ3sI0RFEnvern5mrMX+gMa+9ovMj9DaNWdROVuMfyRlMkv8KcF8qdSMRnWRIk pmwINMyfwnJaAMPrLYaDYVedQU16V4FpKq3XPGbcMVNSQMUTSAmv/KTcA4I/HmW2Ng3+ 9CIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SxCNnClmu4slK56y+cQvmOU8xYxJvEtPJNcBROW7dwQ=; b=s0Cdop/sZObO9grVw8OVo1Pp3Ds0S0uqFdgDRujTwL285tlkf64a8/CGDE3vt1xJZc pBrkuyQcIranu5Fy8BRkkJOy1CqJ3X8YNY1qf/8QHdIIDl8RDvo5fhWEYGBn0f8He+aQ Zlg9//VvCCgMK2Tw63lqaneRRWFClaV9byW8sVPZbeN8op3+XlPdBg+rv4iFbL+BDrb3 cZilbvjYyYSdLZ0OyiUMr1V/ubU8bAjmiHzBUoqRYcdfzAuemi10MReL/QWJjCh2RV1G hwtU8NGFw76Qp1KtjicukRkOG1BYGaTdltAD8wTuewN1oX8q3SI8Azi0srH+APjiiKxB S3Xg==
X-Gm-Message-State: AOAM533qTXlrxtSe2F4yjR4IUBABH0K4g4YXMsxK0EtExE0IP3kBJiLP dkzgs/skVuwZwHv3Am7cxFCoXrTn9tzDlKdvCbo=
X-Google-Smtp-Source: ABdhPJx9je/lb4FY8ehCUSK9Jbr1W3nsKEVvCvFJq9pA6x+WnshknlB+a5YQD2+ofKQi6f4Keof2N1e3OTWhxPS+m2Q=
X-Received: by 2002:a2e:b607:: with SMTP id r7mr22733493ljn.5.1594066623352; Mon, 06 Jul 2020 13:17:03 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Dick Hardt <>
Date: Mon, 6 Jul 2020 13:16:27 -0700
Message-ID: <>
To: Justin Richer <>
Content-Type: multipart/alternative; boundary="000000000000d555ee05a9cb8eef"
Archived-At: <>
Subject: Re: [Txauth] JSON Schema?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Jul 2020 20:17:09 -0000

Thanks Wayne and Justin.

I agree that we would not want to make it an implementation requirement.

I asked Tim Bray his thoughts (edited the IETF JSON specs, one of XML

Tim has written a number of blog posts on JSON Schema. TL;DR: he is not a
huge fan.

He pointed out the IETF JSON Type Definition ID [2]. This looks much
simpler and addresses many of the concerns Tim had expressed with JSON
Schema. It also has a more recent draft published on the IETF.
Unfortunately there do not seem to be many implementations, and the website
[3] is missing the promised docs [4]. The latest ID [5] looks to be derived
from CDDL (RFC 8610) [6].

I reached out to the core JSON Schema people, and they are focussed on
making JSON Schema changes to support efforts for the next version of Open
API [7]

My take: I may use Open Schema in my PoC implementation not unlike what
Wayne did, but it does not look like either JSON Schema or JSON Type
Definition is ready for the WG to use at this point.









On Mon, Jul 6, 2020 at 12:55 PM Justin Richer <> wrote:

> On Jul 6, 2020, at 3:54 PM, Justin Richer <> wrote:
> I think it’s potentially ok for defining the specification and its
> boundaries, but it is not ok if it ends up requiring client and AS
> developers to use JSON Schema directly to implement anything. In other
> words, you should be a able to still write a bunch of hand-crafted
> validation code to make it work, or to use a parser that drops things into
> structured objects for you (like my Java implementation of XYZ does). Much
> like my argument against JSONLD, I think anything beyond a JSON parser
> … and generator is too much to ask. (Sorry, hit send too early.)
> Another aspect that I don’t like about JSON schema is that it makes it
> difficult to describe things in terms of polymorphic data types.
> Polymorphism in the protocol is an important part of the XYZ proposal’s
> design, and as a feature it directly addresses a number of the items you
> found when doing your XAuth implementation, like parsing OAuth scopes and
> dealing with the authorization/authorizations mutually-exclusive oddness
> that you mentioned. I strongly believe that GNAP should make use of a
> polymorphic protocol structure for these and other reasons. Polymorphism is
> a built-in feature of the JSON data model, and it’s also fully possible to
> support under CBOR and other data serialization languages. Even JWT most
> famously uses polymorphism for the “aud” field, which can be a string or an
> array of strings depending on context, all with clear semantics. Defining
> that in JSON schema is not impossible, but it’s not easy.
> So overall, I think JSON schema is probably not a good fit here.
>  — Justin
> On Jul 6, 2020, at 3:00 PM, Dick Hardt <> wrote:
> Hey
> Does anyone have experience and/or opinions on JSON Schema [1]?
> When implementing XAuth [2], I wrote a bunch of hand crafted JSON
> validation code. JSON schema looks like it could be a great way to validate
> input, and to create automated tests for output. It may also be a great way
> to document the Grant Response JSON.
> / Dick
> [1]
> [2]
> --
> Txauth mailing list
> --
> Txauth mailing list