I'd like to clarify the use of dataschema, because it's usage can lead to risks and same can be achieved otherwise.
Current description of dataschema context header:
Generally, the API definition is used which can be found based on service. If present, should point to a section of the AsyncAPI/OpenAPI containing the schema of the message.
I'd propose to change this to:
The schema of the message data (payload). If present, it should point to a section of the AsyncAPI/OpenAPI containing the schema of the message.
Most of the time, this attribute is not needed:
- validation should be done against the schema that verifies the expectations of the consumer (i.e. the AsyncAPI/OpenAPI used during its development), not against a dynamic schema that a producer provides.
- dynamic lookup of a
dataschema URL provided by an untrusted source could pose a security risk
A consumer can look up the message schema in the AsyncAPI/OpenAPI description based on the type value of an incoming message.
I'd like to clarify the use of
dataschema, because it's usage can lead to risks and same can be achieved otherwise.Current description of
dataschemacontext header:I'd propose to change this to:
The schema of the message data (payload). If present, it should point to a section of the AsyncAPI/OpenAPI containing the schema of the message.
Most of the time, this attribute is not needed:
dataschemaURL provided by an untrusted source could pose a security riskA consumer can look up the message schema in the AsyncAPI/OpenAPI description based on the
typevalue of an incoming message.