Extensibility and additional payload properties

Question

The CDS Extensibility section provides clear guidelines on payload conventions and extending payloads with proprietary properties. However there are no explicitly defined standards when it comes to additional payload properties that are not intended as proprietary extensions.

For example, consider a payload response includes the following CommonPhoneNumber object, with an additional, undocumented property of carrier, that does not meet the extensibility convention:

{
  "isPreferred": true,
  "purpose": "HOME",
  "countryCode": "string",
  "areaCode": "string",
  "number": "string",
  "extension": "string",
  "fullNumber": "string",
  "carrier": "string"
}

Is this payload considered valid?

What is the expected behaviour from the Data Holder (DH) and Accredited Data Recipient (ADR)?

If it is deemed a valid object, then I would expect that the DH is OK to return it in response, and ADRs should may either use the additional property or ignore it.

If it is deemed an invalid object, then should the DH should treat it as a bug and rectify it? Should ADRs should ignore the additional property, or reject the object as invalid?

Answer

No, the schema in the example above is not valid or compliant.  

The Extensibility standards provide a mechanism to include additional fields safely . Any additional field must be prefixed by a unique Holder Identifier. For example, if the Data Holder has chosen, as Holder Identifier, their lower case ASX symbol, "xyz", the field in the above example should be xyz-carrier. The Extensibility standards use the symbol <HID> as a placeholder for the unique Holder Identifier. 

It is invalid to add fields that do not follow the Extensibility standards. 

That said, there is no obligation on the ADR to reject the valid data if an additional field exists.
The DH should treat is as a bug.  The ADR should ignore the field, use the field or throw an error at their discretion.