add vendor and model to measurement-values-map

[nedmsmith]

Although vendor and model can be included in an environment-map and as such become accepted claims by a verifier. Constrained implementations that rely exclusively on a class-id value would not use them, but may need to convey them to the verifier as endorsed values or include them in evidence/ref-values. Hence, these should be added to measurement-values-map.

[thomas-fossati]

What I am concerned with is that we may end up with contradicting values.
If we want to promote their use in endorsed values, which I am personally OK with, I would at the same time actively deprecate their use in the environment.

[nedmsmith]

We can discuss deprecation of values in the environment-map, but that would be a separable discussion as the goal of defining and matching based on a composition logic / taxonomy is different from asserting claims about the composition/component.

[andrew-draper]

I am not convinced this is a good idea as specified in the name.
environment-map already has vendor and model fields which are initialised from DICE fields with the same name. Putting fields in measurement-values-map with the same name makes it difficult to confusing to talk about these fields easily.
If we want to add vendor or model into measurement-values-map then IMHO the added fields should have different names.

[nedmsmith]

If we want to add vendor or model into measurement-values-map then IMHO the added fields should have different names.

these could be vendor-name and model-name.

I would at the same time actively deprecate their use in the environment.

What mechanisms do we have to deprecate an aspect of the schema?