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.