Re: [Txauth] JSON Schema?

Yaron Sheffer <yaronf.ietf@gmail.com> Sat, 11 July 2020 18:11 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE293A1141 for <txauth@ietfa.amsl.com>; Sat, 11 Jul 2020 11:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 HiZaoyOz2Rrb for <txauth@ietfa.amsl.com>; Sat, 11 Jul 2020 11:11:12 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133343A113F for <txauth@ietf.org>; Sat, 11 Jul 2020 11:11:12 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id s10so9038403wrw.12 for <txauth@ietf.org>; Sat, 11 Jul 2020 11:11:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=d1VA0VZ9sV8ZeDumtx5C7HmtLRZNgnx+lrB7qQtBa/8=; b=UZLm9Fl9vSYKF4gQ4L1z5bFHIxmvqOeFhF4TXEtiogmrWS8Gz7SJd6dw+TrQ+Tprce OKX9TNiJpHjcX4n0lJ6NJQCJDG3TXXKJGoJXglAMbq3xZN1eCUM1CYs9iwo46cawnT1w +hzWJCUXH1LiAHP/6G7Yquy7y2XJaMV+9NVoH8n9yueW/ZQoNiI6dTvzFC7M/DBfQFxC wje1kcdbX5n+varPL+mRdISAHod4pI3EyoQlASljFJtYTyIuznnOQ4MaGNJdpi9/F3fV 4+wui5lQc02uzTbgfpS99BpKZ8e6wN9zDelq8QCw4TWu6yOA/c8BhGkX9Bpbp7fRZBwG Nc9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=d1VA0VZ9sV8ZeDumtx5C7HmtLRZNgnx+lrB7qQtBa/8=; b=qLysWNPnLcJX0ZRBulbAVRqHZvBv5jDtXlquSMe23m7fGFxTGvfa7+BSNVaeOyt4LM TTK6luPAWCJ7uyAz7Vba08oPKjAwxbYKKxDNL6/2LiFt68t3zMXl6x5DVY5WaMZlMf/7 tCYrlwPTSy2e9rLzxvfcV2JRFVZrq+Ejv4aRc4DmFvUtL7T/02meWvgwu1jl5k/morGY mR5krV611gaARbaLu52YA0ZQ+46bv+5mxal8ihdWVDw7ezoLh+hDp8FMypflN/CXB3Kc zylbYRFhuSu9KBNT7hz8mwgRU5HhdfEaJIfqLlNEjf+MAYoJJBfvS4BsNIbbUHkg7Te2 TqIA==
X-Gm-Message-State: AOAM531rQPhf17NjDOyP7H/NsBWvC47IuwP+5q3wvJqmQEwoZY+JEQum rGb45rQM2NSUkAEPHgHjkrg=
X-Google-Smtp-Source: ABdhPJxFUgcbZNLuyyptcWFL70Tdw7dVCk9rcXcJN9m3lwTOSxtJnHTYAYbmI2XqDERARrSbA/GuRQ==
X-Received: by 2002:adf:f2c5:: with SMTP id d5mr74448190wrp.96.1594491070161; Sat, 11 Jul 2020 11:11:10 -0700 (PDT)
Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id v9sm16583326wri.3.2020.07.11.11.11.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Jul 2020 11:11:09 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.38.20061401
Date: Sat, 11 Jul 2020 21:11:08 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Dick Hardt <dick.hardt@gmail.com>
CC: <txauth@ietf.org>, Justin Richer <jricher@mit.edu>
Message-ID: <45BD1429-11C6-441E-8DCA-45B00010A2BE@gmail.com>
Thread-Topic: [Txauth] JSON Schema?
References: <CAD9ie-vnA98pobbboS00SAHneEG52_8eMxh_sE3r3jg6gyooGg@mail.gmail.com> <E9EC90C9-7A9A-4909-8627-A161B33E941F@mit.edu> <B3104062-AF2B-4FFB-A8CD-3DD5BE178812@mit.edu> <CAD9ie-u==Yjdyef2bQD+Ngv=bgpw1KVG+ND--CMQv1JOTd3Dqg@mail.gmail.com> <20200707053048.GV16335@kduck.mit.edu>
In-Reply-To: <20200707053048.GV16335@kduck.mit.edu>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/fexl9UT2RgrVZCWFCPIfEyW_ls0>
Subject: Re: [Txauth] JSON Schema?
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Jul 2020 18:11:14 -0000

As far as I can see JSON Schema is the clear winner, from an industry point of view. There's lots of implementations on their web site, although sadly with varying support for different versions. It's actually an IETF miss that this technology is not being standardized here yet. Tim is obviously the expert here, but JSON Schema has the "running code".

The JSON Schema folks tried to bring it into IETF and didn't like the reaction they received (though I looked at the mail archive and it was nothing out of the ordinary). So they took a step back. I talked to them recently and tried to have them re-engage, they may be ready to do that now.

Thanks,
	Yaron

On 7/7/20, 08:31, "Txauth on behalf of Benjamin Kaduk" <txauth-bounces@ietf.org on behalf of kaduk@mit.edu> wrote:

    On Mon, Jul 06, 2020 at 01:16:27PM -0700, Dick Hardt wrote:
    > 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
    > creators)
    > 
    > 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.

    FWIW, draft-ucarion-json-type-definition is in the RFC Editor's queue as a
    document published via the ISE stream, as can be seen at
    https://www.rfc-editor.org/current_queue.php and
    https://datatracker.ietf.org/doc/draft-ucarion-json-type-definition/

    It's only been at the RFC Editor for a week or so, and we're running 10
    weeks minimum to publication, it will not be an RFC for anouther couple
    months at least.

    -Ben

    > 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.
    > 
    > /Dick
    > 
    > [1]
    > https://www.google.com/search?as_q=json+schema&hl=en&ie=UTF-8&btnG=Google%2BSearch&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=tbray.org
    > <https://www.google.com/search?as_q=json+schema&hl=en&ie=UTF-8&btnG=Google%2BSearch&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=tbray.org>
    > 
    > [2] https://datatracker.ietf.org/doc/draft-ucarion-json-type-definition/
    > 
    > [3] https://jsontypedef.com/
    > 
    > [4] https://jsontypedef.com/docs/getting-started/overview
    > 
    > [5] https://tools.ietf.org/html/draft-ucarion-json-type-definition-04
    > 
    > [6] https://tools.ietf.org/html/rfc8610
    > 
    > [7] https://github.com/OAI/OpenAPI-Specification
    > 
    > 
    > On Mon, Jul 6, 2020 at 12:55 PM Justin Richer <jricher@mit.edu> wrote:
    > 
    > >
    > > On Jul 6, 2020, at 3:54 PM, Justin Richer <jricher@mit.edu> 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 <dick.hardt@gmail.com> 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] https://json-schema.org/
    > > [2] https://github.com/dickhardt/XAuth-poc
    > >
    > >
    > > --
    > > Txauth mailing list
    > > Txauth@ietf.org
    > > https://www.ietf.org/mailman/listinfo/txauth
    > >
    > >
    > > --
    > > Txauth mailing list
    > > Txauth@ietf.org
    > > https://www.ietf.org/mailman/listinfo/txauth
    > >
    > >
    > >

    > -- 
    > Txauth mailing list
    > Txauth@ietf.org
    > https://www.ietf.org/mailman/listinfo/txauth

    -- 
    Txauth mailing list
    Txauth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth