Prefer mkey over redefining measurement values types?

[deeglaze]

Given that we've restored multiplicity to measurements, it seems prudent to avoid re-specifying types of measurements for measured fields and instead use mkey numbers to represent the field, no?

Thinking from the perspective of tooling, it would be much simpler to give insights about reference values if folks stick to the standard types, and we can just have a mapping of class-id + mkey => colloquial measured field name, and visualization of particular values would not need any further enlightenment.

I'm wondering if we can try to avoid new profiles for every kind of attestation technology when they're not expressing fundamentally new concepts. The expression language you have here is something else.

Example:

$$measurement-values-map-extension //= (
     &(tee.pceid: -80) => $tee-pceid-type
   )
   $tee-pceid-type /= tstr

could be

tee.pceid from TDQUOTE is transformed to

[/ mkey: / 0: 80, / mval: / 1: {/ name: / 11: tee.pceid}]

[nedmsmith]

Yes, that would be a way to reduce dependence on the mvm extensions, however, that might only work for evidence as reference values (for at least several measurements) uses non-exact match semantics, so we might still need the extension points. There is also the matter of timing profiles with product releases.

A possible way forward is to work on a second profile that models some alternatives that make better use of base types.