Constrain the name of additional properties?

[Roger Costello]

Hi Folks,

The following schema says that an instance must contain the "name" and "age" properties. Also, the instance can contain any number of additional properties, provided they have a boolean value.

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "type": "object",
    "properties": {
        "name": {"type": "string"},
        "age": {"type": "integer"}
    },
    "required": ["name", "age"],
    "additionalProperties": {
        "type": "boolean"
    }
}

Here's a valid instance:

{
  "name":"John Doe",
  "age": 30,
  "married": false
}

That instance contains one additional property, with name "married" and boolean value, false.

Nice.

But this is also a valid instance:


{
  "name":"John Doe",
  "age": 30,
  "put-secret-information-in-this-name-field": false
}

That's not nice.

Is there a way to constrain the name of the additional property?

/Roger

[Christopher J. White]

Hey Roger,

You want "patternProperties", which allows you to specify a regex.  See:

http://jsonary.com/documentation/json-schema/?section=keywords/Object%20validation#keywords/Object%20validation/02%20-%20patternProperties

...cj

--
You received this message because you are subscribed to the Google Groups "JSON Schema" group.
To unsubscribe from this group and stop receiving emails from it, send an email to json-schema...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Roger Costello]

Thanks Chris! I see how "patternProperties" can be used to constrain the names of additional properties. I rigged up a sample schema to test this (below). So it appears that using additionalProperties with a JSON Schema is not good design, given its security concerns. The better approach is to use "patternProperties". Yes?   /Roger

 

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "type": "object",
    "properties": {
        "name": {"type": "string"},
        "age": {"type": "integer"}
    },
    "required": ["name", "age"],

    "patternProperties": {
        "^(married|divorced|living)$": {"type": "boolean"}
    },
    "additionalProperties": false
}

--
You received this message because you are subscribed to a topic in the Google Groups "JSON Schema" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/json-schema/-YlxAk0A4Iw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to json-schema...@googlegroups.com.

[Austin Wright]

What security concerns do you refer to?

[Joe McIntyre]

Roger,

In my experience with defining Web Services interfaces with different technologies, there are a couple of conflicting goals that often came up.

From the "traditional API" space, the notion of having arbitrary content that could not be verified with certainty (size of message, size of element, ability to prescribe security constraints such as encryption or access control on a per field basis, etc). This resulted in some pretty detailed specifications in the XML and WS-* space.

From the "RESTful" space, a significant contingent resisted specification, with the notion that interfaces would be "locked down" if specified with much rigor. But this space also includes a broad range of use cases such as embedding web content or database blobs as part of content that includes formally defined elements as well (e.g. for keys). This flexibility was often recognized broadly, even if the comfort level for addressing it was not always consistent.

There really isn't a 'right' answer, rather the question was usually about whether the various technology approaches could accommodate these extremes, and the many use cases somewhere in between. And, in some cases, whether the technology would be better suited to narrowing the use cases and using different technologies for the excluded use cases.

I think the [ additionalProperties / patternProperties / required ] discussion falls into this same area. If you want to have a stringent schema, these provide the ability to be very prescriptive in the acceptable content definition (with enumerations as well). At the same time, given that JSON Schema is permissive when constraints are not specified, more free form use cases can be accommodated - however they will usually require additional program logic to ensure the content is acceptable or to filter out badly formed elements.

I think the trade off points are pretty good, although I think that there are use cases that end up being kludgey to implement (e.g. additionalProperties:false conflicts with independent dependencies adding new elements, requiring a patternProperties to be specified to accommodate the new elements).

On the security aspects, for commercial deployment of Web Services (XML or JSON based), it is fairly common to use edge elements to provide message filtering based on size of message, size of elements, well formed message verification and content type (e.g. no binary in text message formats). Validation proxies can also be used, that perform validation only, where both JSON Schema validation processing and other content rules can be applied. The receiving application would still be responsible for validation of arbitrary content that otherwise was acceptable to the network entry of the message.

I may have read a bit more into your question than intended ... but I think you are touching on an interesting area that can be interpreted by different audiences in pretty different manners.

Joe.

[Roger Costello]

 Hi Austin,

 

> What security concerns do you refer to?

 

Unauthorized exfiltration of data.

 

There is no way to use validation of instance documents to detect if a malicious process embedded extra information that is unauthorized, perhaps even highly sensitive,
since the "additionalProperties" keyword with JSON Schema value cannot be constrained (that is, the names of the additional properties cannot be constrained).

 

/Roger