DDSXTY15 — Validation of received typeIdentifier/TypeObject

XTYPES implementations can use the TypeLookup service to resolve the TypeObjects associated with TypeIdentifiers.

The client requesting a TypeIdentifier -> TypeObject resolution will receive a serialized "remote" TypeObject a,k.a. TypeObjectSerialized

The receiver normally wants to validate that the received TypeObject actually corresponds to the TypeIdentifier, otherwise a bad TypeIdentifier->TypeObject could "poison the receiver's cache" for any future users of the TypeIdentifier. However this needs to be done using a specific process.

The receiver normally deserializes the TypeObjectSerialized into its own "receiver" TypeObject. This may be different from the "receiver" TypeObject that the sender endpoint used. As the TypeObject datatype has mutable and append-able structures it is expected to evolve. In fact the one in xtypes 1.4 is an evolution of the one in xtypes 1.3.

The various versions of the TypeObject are assignable so the deserialization will be successful. However the TypeIdentifier computed in the "received" TypeObject (which is deserialized according to the receiver's type) may not match the typeIdentifier computed on the "sender" TypeObject. Therefore if the receiver computes the validity of the received TypeObject by comparing the typeIdentifier with the one it computes in its own "received" TypeObject the comparison can fail.

The process to validate the received TypeObject shall be that the received computes the TypeIdentifier based on the "received" TypeObjectSerialized. This will validate that the serilalized payload is does have the correct hash. Then after if the validation passes it deserialized into its own "received" TypeObject which may has some added/removed/defaulted fields relative to the "sender" TypeObject. This process is safe due to the lack of pre-image attack on the MD5 hash and the type assignability rules.