Re: [Txauth] JSON Schema?

Justin Richer <> Mon, 06 July 2020 19:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB61B3A09F4 for <>; Mon, 6 Jul 2020 12:55:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xB8D1dlxaT_4 for <>; Mon, 6 Jul 2020 12:55:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 266A13A09F0 for <>; Mon, 6 Jul 2020 12:55:54 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 066Js7qW018503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Jul 2020 15:55:52 -0400
From: Justin Richer <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AB2B658A-C92A-419C-96BC-5F2687EF8757"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 6 Jul 2020 15:55:52 -0400
In-Reply-To: <>
To: Dick Hardt <>
References: <> <>
X-Mailer: Apple Mail (2.3608.
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 19:55:57 -0000

> 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