Section 3.3.1 is not clear

[thomas-fossati]

Carl, about #78 :

'I read the PR but can't say that it helps much. The phrase "If a label changes Verifier state beyond a "hint"" must be evaluated from the point of view of a verifier, right? If different verifiers may elect to use or ignore a "hint", I don't see how this could be any other way. The rest of that sentence establishes that how a verifier acts upon a "hint" determines whether a label is considered to carry semantic content. This impacts the next sentence, which states that "the collection SHOULD be signed by an attestation key" when a label carries semantic content. Maybe stating "if an attester expects for a label to change Verifier state beyond a "hint"" would salvage the paragraph. Separately, is "label" right here or should it be "item" or "message"? It might also help if "hint" were defined in this context as well as how the "hint" notion interacts with the last point made in the security considerations section.'

[thomas-fossati]

/cc @deeglaze

[nedmsmith]

"hint" refers to textin the json-collection and (int/text) in the cbor-collection.

We didn't provide CDDL tagging to help with semantics. Possibly we could define them as:

json-collection = {
  ? "__cmwc_t": ~uri / oid
  + hint: text => json-CMW / c2j-tunnel
}

cbor-collection = {
  ? "__cmwc_t": ~uri / oid
  + hint: (int / text) => cbor-CMW / j2c-tunnel
}

then the prose in §3.3.1 would be more easily connected for the reader.

The prose might be improved by:

"A CMW Collection's tree structure is not required to be a spanning tree of the system's composite Attester topology. If the hint includes semantic content for a Verifier (e.g., for better Verifier performance or human comprehension), the collection SHOULD be integrity protected, e.g., by including it in a signed token such as a CWT or JWT."

Note: It isn't strictly necessary to include the hint in an Evidence structure. For example, DICE includes hint information in a certificate extension, but not one that is considered to be Evidence such as DiceTcbInfo. Certs can play multiple roles so it may not be exclusively an "attestation" key.

Technically, hints aren't Evidence because there is no expectation for matching Reference Values and because they are information intended for consumption by a Verifier. Uncorroborated Evidence is still meaningful without RVs, but the intended audience is a RP (or appraisal policy), whereas hints would not be added to an ACS.

A CWT/JWT containing EAT Claims is said to be an "EAT" token, but a profile determines whether it is Evidence, Endorsement, or RVs. A cmw can contain both Evidence and non-evidence information, much like a DICE cert does. The hint information is non-evidence.

A second form of integrity protection is to create a Claim that has the same semantics as the hint and put that claim in Evidence or Endorsements. This seems like an advanced alternative that doesn't need to be captured in prose as the current example is sufficient to illustrate the concept of integrity protection.

It isn't necessary to include the signed token / Evidence in a CMW collection either, as long as it is integrity protected somehow.

[thomas-fossati]

"hint" refers to textin the json-collection and (int/text) in the cbor-collection.

We didn't provide CDDL tagging to help with semantics. Possibly we could define them as:

json-collection = {
  ? "__cmwc_t": ~uri / oid
  + hint: text => json-CMW / c2j-tunnel
}

cbor-collection = {
  ? "__cmwc_t": ~uri / oid
  + hint: (int / text) => cbor-CMW / j2c-tunnel
}

then the prose in §3.3.1 would be more easily connected for the reader.

We already have the term "label" to refer to that, we should just use it consistently.

[nedmsmith]

We already have the term "label" to refer to that, we should just use it consistently.

I didn't see label in the CDDL. That is the part that is potentially confusing to readers IMO.

Does this CDDL work:

json-collection = {
  ? "__cmwc_t": ~uri / oid
  + label: text => json-CMW / c2j-tunnel
}

cbor-collection = {
  ? "__cmwc_t": ~uri / oid
  + label: (int / text) => cbor-CMW / j2c-tunnel
}

[thomas-fossati]

We already have the term "label" to refer to that, we should just use it consistently.

I didn't see label in the CDDL. That is the part that is potentially confusing to readers IMO.

Does this CDDL work:

json-collection = {
  ? "__cmwc_t": ~uri / oid
  + label: text => json-CMW / c2j-tunnel
}

cbor-collection = {
  ? "__cmwc_t": ~uri / oid
  + label: (int / text) => cbor-CMW / j2c-tunnel
}

I think you need to do:

@@ -1,9 +1,9 @@
 json-collection = {
   ? "__cmwc_t": ~uri / oid
   + &(label: text) => json-CMW / c2j-tunnel
 }

 cbor-collection = {
   ? "__cmwc_t": ~uri / oid
   + &(label: (int / text)) => cbor-CMW / j2c-tunnel
 }

[nedmsmith]

fixed by PR #106