JSON encoding of `version-scheme`

[thomas-fossati]

When encoding to JSON, we serialise coswid.$version-scheme as a string (see: https://github.com/veraison/swid/blob/main/versionscheme.go#L40-L56).

This was done with the good intention of providing something human-readable, but it is an arbitrary choice and, most importantly, it’s incompatible with use in EAT (e.g., in the sw-version claim, which is also used by the measured component).

For more context, see: veraison/eat#37 (comment)

[kentakayama]

Facts:
According to RFC 9711, the version-scheme is referenced from CoSWID. However, CoSWID defines a format only for CBOR, so there is no agreed-upon encoding/decoding for JSON.
Therefore, my understanding is that veraison/swid supports a JSON representation as an independent, non-standard extension. Given that, either 1 or "multipartnumeric" should be acceptable.

My view:
From the standpoint of readability when viewed as a JSON string—and also, though it’s a small thing, from the standpoint of writing Go’s MarshalJSON and UnmarshalJSON—using a string seems preferable.
For example, if you were to implement UnmarshalJSON, you could simply receive it as a string like this:

var hwversion []string
err := json.Unmarshal(data, &hwversion)
// err check
// length check
// version-scheme value check if exists

So having both variants of hardware-version-type represented as strings does not seem like a bad approach.

[thomas-fossati]

According to RFC 9711, the version-scheme is referenced from CoSWID. However, CoSWID defines a format only for CBOR, so there is no agreed-upon encoding/decoding for JSON.

I am not sure I agree with this exegesis :-)

Absent an explicit mapping override, the default rules for JSON interoperability apply (see Section 7.2.2 of RFC9711), which for uints (such as the $version-scheme range) map to JSON numbers (see Appendix E of RFC8610).

[kentakayama]

Ah, you are right.
This rule should take priority.