Re: [apps-discuss] JSON Schema considered harmful

[Nico Williams <[e-mail]>]

On Thu, Sep 20, 2012 at 8:52 AM, Phillip Hallam-Baker <[e-mail]> wrote:
> I found using a schema helpful in writing the SAML spec but I didn't use XML
> schema. I used a tool and generated the XML Schema and the text from my own
> schema language. That addressed the problem of the spec and schema being out
> of sync which was a real bear as the SAML TC made major changes to the
> schema, adding and dropping items at each con-call

OK, we're getting to the meat of the complaint.  It's not about how or
who but about failures of the end product (XML Schema, JSON Schema).

> What I think we need for the IETF is a tool to help document protocols. Now
> that might be a schema done right or it might be a protocol description
> tool.

I agree.  I don't know that this is a realistic expectation (but see
below), and in particular I'm skeptical that enough code can be
generated from such a tool (as compared to merely data
encoding/decoding) that it would be anywhere near as useful as data
description languages have been.  But I'd like to be proven wrong!
(Or even to prove myself wrong.)

The ITU-T would say that SDL should be it, no doubt :), but SDL is
weirdly incompatible with ASN.1 (SDL is case-insensitive(!) while
ASN.1 is case-sensitive), and anyways, I don't think I care for SDL.

That said, and as has been demonstrated before, there's a large degree
of duality between the various data description languages that we
have.  Thus we have XER (XML Encoding Rules for ASN.1), and
FastInfoSet (PER encoding applied to XML) and so on.  And I think the
proposition that XDR is a subset of ASN.1/PER with 4-octet alignment
and non-packed encoding of optional/defaulted fields, is defensible.
Therefore I think at least a unified data description language is
possible.

What is difficult to manage is protocol flows, particularly when there
is cryptography involved.  We might be able to use any of various
high-level programming languages (e.g., Haskell, Python, Scheme, ...)
in combination with a) a generic data description language and b) some
functions left undefined (defined in English language prose rather
than a formal language).  (I would prefer to use a LISP or Scheme with
a powerful macro language so as to make it easier to generate code
from the specification by just defining a suitable set of macros.)

Maybe we could experiment with this?

> Extensibility is certainly problematic. I have seen pretty much every WG
> using XML end up in rat hole after rat hole as people try to consider what v
> 1.1 of the spec might look like. XML Schema looks like it should answer that
> question but it does not. And not many other tools do so either.
>
> This problem crops up in a JSON protocol as well. Should unknown tags be
> ignored or cause an error? Should there be a mechanism that allows
> intentional breaking of backwards compatibility in cases where doing so may
> cause applications to do the wrong thing?

This shows up in ASN.1 as well.  ASN.1 lets you say that extensions
"go here" and are to be ignored by decoders that don't expect them,
but, so what, it's not enough.  We always end up having to signal or
negotiate the use of extensions, and I don't find that to be
particularly problematic.  Perhaps XML Schema is particularly
disastrous w.r.t. extensibility?  But I doubt it.  Instead I suspect
that some wish that extensibility were simpler and more automatic, but
I'm afraid that it simply cannot be.

> Even the terminology can be disastrous. There is a feature in X,509v3 that
> is designed to allow a certificate to say 'if you don't understand and
> process this extension then reject this certificate'. The original intention
> was to allow extensions to specify new revocation/status checking schemes.
> RPs that did not understand the scheme could not use the certificate.
>
> Unfortunately that feature was called 'critical' which also means
> 'important'. And so people started using 'critical' to mean 'I think this is
> important' and not 'I think this so important that you should break
> backwards compatibility'. This is why I called the same feature 'Conditions'
> in the SAML specification and disguised it so that it didn't look like a
> criticality flag. But Conditions and Criticality are the exact same thing.
> The SAML assertion structure began life as part of a design to re-do X.509
> in XML which is why it had to have some equivalent of criticality.

Criticality is a big deal.  We don't want to render extant
implementations vulnerable when we extend a protocol, but we don't
want to break interop with them either, and sometimes you just cannot
have both of those.  It mostly behooves us to get things like PKI
right from day zero, and yet that also is wishful thinking.  I wish I
had an actual, better answer here; I don't.

> What we need in my view is a way to identify the places where additional
> items can be added into protocol messages and a default that additional
> items are prohibited everywhere else. So in my Simple JSON Schema I would
> represent a SAML assertion like thing something like:

OK, like ASN.1 extensibility markers then.  (Really, we only keep
re-inventing the wheel :)  Maybe we need JER -- JSON Encoding Rules
for ASN.1 :)

> The Any type is an intrinsic type that refers to an object that is tagged
> with the object type. So an authentication assertion would be tagged with a
> "authentication" an authorization assertion with "authorization" and so on.

So, like typed holes in ASN.1 (including the Information Object Set, a
very difficult to use syntax extension to ASN.1 that adds very useful
formalism).

Nico
--