Allow "required" list to have undefined properties

[sisp]

I think requiring property names listed in required to be defined in properties is too strict. I also couldn't find this requirement in the JSON Schema or OpenAPI specs. JSON Schema validators and the Swagger Editor are fine with property names listed in required that are not defined in properties.

It makes sense to list required properties without defining them in properties when using allOf where one sub-schema requires some properties but does not specify them while another sub-schema only provides the specifications of the properties (possibly even without stating which ones are required and which ones aren't). This is especially useful when referencing and merging schema definitions or when expressing discriminated unions with some properties that are common to all union members.

I suggest to remove the following code block

https://github.com/p1c2u/openapi-spec-validator/blob/3f53e957812a9c545d71226e3a4d696240e2cee6/openapi_spec_validator/validators.py#L134-L142

and the require_properties argument:

https://github.com/p1c2u/openapi-spec-validator/blob/3f53e957812a9c545d71226e3a4d696240e2cee6/openapi_spec_validator/validators.py#L123

I have seen the test case

https://github.com/p1c2u/openapi-spec-validator/blob/3f53e957812a9c545d71226e3a4d696240e2cee6/tests/integration/test_validators.py#L83-L115

but it also seems to be valid to express this schema like this:

{
    'Credit': {
        'type': 'object',
        'properties': {
            'clientId': {'type': 'string'},
        }
    },
    'CreditCreate': {
        'type': 'object',
        'required': ['clientId'],
        'allOf': [
            {
                '$ref': '#/components/schemas/Credit'
            },
            # possibly more schemas to merge ...
        ]
    }
}

Or did I miss this rule somewhere in the spec?

[edermaxc]

Hi Guys, did any one figure out a workaround for this problem changing the spec?

[hibougeek]

@p1c2u I did a pull request to solve this issue (#154) . Could you review it please ? We are currently blocked on our side, it will helpful to have a status on it.

[Marwen94]

Thanks @hibougeek ! We are blocked by this also.

[tembleking]

The problem with #312 is that it left the validation in an inconsistent state: if the schema contains allOf then it will still try to validate that the fields are present in the inner referenced components.

This is what's causing #390 and what I tried to fix in #391.
So either we never validate the presence of inner properties defined in the required, or we always check them.

I'd rather try to validate that required are always defined in properties, even if the OpenAPI spec does not enforce it, because if you define a field in required but do not define it under properties, and the request body doesn't include that field, it will still be considered invalid. The presence of the field is enforced by the required list.

Example:

type: object
required:
  - foo

In this case, foo is required, even though it is not defined under properties. If foo is missing in the request body, validation will fail. If it is present, it will accept any value, because its schema is {} by default (i.e., no constraints).

To avoid ambiguity, it's best practice to define all required fields explicitly in properties:

type: object
required:
  - foo
properties:
  foo:
    type: string