Re: [Json] Schemas & so on
Phillip Hallam-Baker <ietf@hallambaker.com> Wed, 04 May 2016 14:35 UTC
Return-Path: <hallam@gmail.com>
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 C149D12D1E2 for <json@ietfa.amsl.com>; Wed, 4 May 2016 07:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 QxWezlQu1zTj for <json@ietfa.amsl.com>; Wed, 4 May 2016 07:35:30 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 6D33412D0B6 for <json@ietf.org>; Wed, 4 May 2016 07:29:58 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id x7so25495019qkd.3 for <json@ietf.org>; Wed, 04 May 2016 07:29:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=zxWgYCpr9z3dlT+Agu8qe0ixfrgLKeRWY7Oc/O4sNJk=; b=f9giJx5klis6zlw29kQf4ZW7FGndwVxHFzAQhKQXVFNA3ECOElRjEJIZtIHwOdH466 gGYtDUIJIGTvRV/Owydlat7olbajxgqNXznvxkgRCBcyAh6/BumqvfUSlKzBydMxHdGr JpKdq53Lu39z+lwSp6C63WeAtf9OnWfBInQ9oa8XwJ0tSgCRi/EplnQHbtkf6TErhOgy k2uy4v80IfeashDfu7pHg9arIAeweYOabYdUV/C7tJZZZd2fnuiGH8mOBNBNnnuXG3cL Wf9j+tZqwQuf7BjF7lJBjsYeTfDWl6v6vrkLBmd/2NVfI3w+Lgmg24xmMcdV8baeV/xi 3aOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=zxWgYCpr9z3dlT+Agu8qe0ixfrgLKeRWY7Oc/O4sNJk=; b=Cuxv/Jp+lFbxKNrgtN0lwaTfrdNfO+QuTf0wpWGQzIy0e71nicHs/VJNEECkwQNMkp Q6HFg9MWvOvujUUapJYflx4x+Kw0gycg1iYJclqqJc5KAj/7edxNs0lrEMrClLSDf55T hQu1q7btZcVBP+8SQtlZUSNDyBaAKiTGVD248WQBbV4fURWPTDv4r7irT1aMHeN3oOkA ytLKH9Ryq2GxOcTx1BnM/0UXbAoKpFU8Mtit0Csh2iloeIkxeIxCqw7hLelHcO+r4EQo sQYJK5cNlk7G/GqBLthM9LCpjEQe2A2qCpi3kfffb+EgylQDMu2nN/moLaTCDHMUsoL6 W0Ug==
X-Gm-Message-State: AOPr4FVBSZ8Tx1Otj8iif+Fyi4kNd49DgvkVLtnMP5SWKmvXsa2gngy3Jat0IEqllMo1LG52rWEb9p1Wg1tGlQ==
MIME-Version: 1.0
X-Received: by 10.55.217.9 with SMTP id u9mr8824891qki.27.1462372197502; Wed, 04 May 2016 07:29:57 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.55.24.38 with HTTP; Wed, 4 May 2016 07:29:57 -0700 (PDT)
In-Reply-To: <CAMm+Lwgjvidj5=Hx1XyNZk0sEZuHBxxTVW0Vc2bBBOYR_VO6cw@mail.gmail.com>
References: <CAHBU6itCV9MXmALdKtE9-vjUPG6-6ZqdqzrmZkcEzSUysi3S-w@mail.gmail.com> <AC93811D-A16A-4527-B2EB-C6A9FC6D4F17@mnot.net> <20160503010109.GA17482@mercury.ccil.org> <CAMm+LwjVnh5H4REM9tUJjb7QvL2arxjkhjWybHerxbXUvkcMdA@mail.gmail.com> <20160503172537.GM29513@mercury.ccil.org> <CAMm+LwhMyFawLEQ-e04TA9hw8nsRbG0+1f3hEAhAYc0sgNqtjA@mail.gmail.com> <b60b59d0-ec4e-fba9-fe81-13b0d924ae50@codalogic.com> <D134B11A-34D6-48C3-87EE-5BFAFDCEE757@cisco.com> <CAMm+LwjtwwVErnB3MDW_n4ONt-h5XYKg2SGGrOOqw7XwKr6zmQ@mail.gmail.com> <46FCFC42-3FF1-4CD5-A397-A0553B43AC39@cisco.com> <20160503214528.GF6756@mercury.ccil.org> <CAMm+Lwgjvidj5=Hx1XyNZk0sEZuHBxxTVW0Vc2bBBOYR_VO6cw@mail.gmail.com>
Date: Wed, 04 May 2016 10:29:57 -0400
X-Google-Sender-Auth: h5Y1WfSAbVElH1IQ3FRJu3y3uxg
Message-ID: <CAMm+LwitQ+CZXj6PQzctuxHKZXR5KpR5ixBSUjUDvzOpqjF6OQ@mail.gmail.com>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
To: John Cowan <cowan@mercury.ccil.org>
Content-Type: multipart/alternative; boundary="001a1149aa685c999a0532050f67"
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/2mmeYLDgZTj6_P_xkTzpJRU_OAw>
Cc: Tim Bray <tbray@textuality.com>, Peter Cordell <petejson@codalogic.com>, "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Schemas & so on
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 04 May 2016 14:35:32 -0000
If we did get into extended schema discussions, one of my main issues that I don't see well supported in existing schema systems is support for encryption and signature. These are features that I really would like to be able to have supported in the 'validation' layer. In the Mesh I have nested structures where portions of the inner structure are signed. A user profile contains a set of application profiles, both of which are signed. One side effect is that every profile structure ends up having two flavors - signed and unsigned. And that is messy. So for example, say this is my schema without signatures UserProfile Class Applications List <ApplicationProfile> Devices List <DeviceProfile> ApplicationProfile Class <Abstract> ... fields And a JSON encoded object would be: "UserProfile" : { "Applications" : [ {"MailApplicationProfile" : {...} } ] } Since Application Profile is an abstract class, the deserializer needs to know which particular subtype is being decoded. So the instances of the class need to be tagged. Easy enough, right? Well if we add signatures (or encryption) they are in effect just wrappers round a class. But they have the effect of burying that tag I need to decode the object. So I would like to have something like: ApplicationProfile Class <Signed Abstract> "UserProfile" : { "Applications" : [ ["Jose-Header" , $$ {"MailApplicationProfile" : {...} } ] } $$, "Jose-trailer" ] ] ...] } Where $$...$$ is the base 64 signed data blob as a string. Same for encrypted data. This type of approach would let me move all the signature validation parts into code. I would still need to hand code the path math for validation of the signing keys. When rendered in C#, I would get a class like this: class UserProfile : JSON.Object { List <ApplicationProfile> Applications; List <DeviceProfile> Devices; } abstract class ApplicationProfile : JSON.SignedObject { ... fields } class MailApplicationProfile : ApplicationProfile { ... } The JSON.SignedObject class would inherit from JSON.Object and provide mechanisms for verifying signatures, etc. Using the array allows the order of the JOSE data items to be forced which helps a lot in writing verification code into the deserializer which is of course essential if you want to do a one pass deserialization on a constrained device. Encryption would be handled in a similar way by JSON.EncryptedObject.
- [Json] Schemas & so on Tim Bray
- Re: [Json] Schemas & so on Martin J. Dürst
- Re: [Json] Schemas & so on Rob Sayre
- Re: [Json] Schemas & so on Erik Wilde
- Re: [Json] Schemas & so on Erik Wilde
- Re: [Json] Schemas & so on Tim Bray
- Re: [Json] Schemas & so on John Cowan
- Re: [Json] Schemas & so on Phillip Hallam-Baker
- Re: [Json] Schemas & so on Anders Rundgren
- Re: [Json] Schemas & so on Peter Cordell
- Re: [Json] Schemas & so on Joe Hildebrand (jhildebr)
- Re: [Json] Schemas & so on Austin William Wright
- Re: [Json] Schemas & so on Tim Bray
- Re: [Json] Schemas & so on Tim Bray
- Re: [Json] Schemas & so on Mark Nottingham
- Re: [Json] Schemas & so on John Cowan
- Re: [Json] Schemas & so on Mark Nottingham
- Re: [Json] Schemas & so on Erik Wilde
- Re: [Json] Schemas & so on Anders Rundgren
- Re: [Json] Schemas & so on Rob Sayre
- Re: [Json] Schemas & so on Tim Bray
- Re: [Json] Schemas & so on Tim Bray
- Re: [Json] Schemas & so on Erik Wilde
- Re: [Json] Schemas & so on Tim Bray
- Re: [Json] Schemas & so on Cyrus Daboo
- Re: [Json] Schemas & so on John Cowan
- Re: [Json] Schemas & so on John Cowan
- Re: [Json] Schemas & so on Victor Kareh
- Re: [Json] Schemas & so on Peter Cordell
- Re: [Json] Schemas & so on John Cowan
- Re: [Json] Schemas & so on Peter Cordell
- Re: [Json] Schemas & so on John Cowan
- Re: [Json] Schemas & so on Phillip Hallam-Baker
- Re: [Json] Schemas & so on Phillip Hallam-Baker
- Re: [Json] Schemas & so on Erik Wilde
- Re: [Json] Schemas & so on John Cowan
- Re: [Json] Schemas & so on Phillip Hallam-Baker
- Re: [Json] Schemas & so on Phillip Hallam-Baker
- Re: [Json] Schemas & so on John Cowan
- Re: [Json] Schemas & so on John Cowan
- Re: [Json] Schemas & so on Phillip Hallam-Baker
- Re: [Json] Schemas & so on John Cowan
- Re: [Json] Schemas & so on Phillip Hallam-Baker
- Re: [Json] Schemas & so on Peter Cordell
- Re: [Json] Schemas & so on Joe Hildebrand (jhildebr)
- Re: [Json] Schemas & so on Phillip Hallam-Baker
- Re: [Json] Schemas & so on Peter Cordell
- Re: [Json] Schemas & so on Joe Hildebrand (jhildebr)
- Re: [Json] Schemas & so on John Cowan
- Re: [Json] Schemas & so on - int54 Peter Cordell
- Re: [Json] Schemas & so on - int54 John Cowan
- Re: [Json] Schemas & so on Phillip Hallam-Baker
- Re: [Json] Schemas & so on Phillip Hallam-Baker
- Re: [Json] Schemas & so on John Cowan
- Re: [Json] Schemas & so on Phillip Hallam-Baker
- Re: [Json] Schemas & so on Phillip Hallam-Baker