Hi folks,
I'm attempting to follow the reference verification algorithm and am stumbling on the statement that "ref-claims in a reference-triple-record can contain one or more entries. This multiplicity can have different meanings" from section 5.1.5. I've gone through #442, #523, and #571 (plus some of the associated PRs) and am unable to form a consistent mental model of this multiplicity. I'm likely missing a key concept, so any help in clearing up my confusion is appreciated. Referenced excerpts with additional emphasis are included at the end.
This comment best illustrates the problem I see: #500 (review). It's stated that:
T = [
E=e_0,
[
M{ K=k_0, V=v_0 },
M{ K=k_0, V=v_1 }
]
]
is shorthand for:
T_1 = [
E=e_0,
[
M{ K=k_0, V=v_0 }
]
]
+
T_2 = [
E=e_0, # Was e in original comment. Based on the context, I believe e_0 was intended.
[
M{ K=k_0, V=v_1 }
]
]
Section 5.1.5 seems consistent with this, however, it's not clear to me how this aligns with the reference verification algorithm.
Let's say the evidence is:
ET = [
E=e_0,
[
M{ K=k_0, V=v_0 }
]
]
Also assume v_0 and v_1 make incompatible assertions about the same property, say name (e.g. v_0 matches when name=foo, v_1 matches when name=bar). The CoRIM author intends to say "both foo and bar are valid for name under mkey=k_0 and environment e_0".
We then produce the rv lists corresponding to each reference value form given above. Authority, cmtype, etc omitted for brevity:
# from T
rv_1 = [
{
condition: {
environment: e_0,
element-list: [
{element-id: k_0, element-claims: v_0 },
{element-id: k_0, element-claims: v_1 },
]
},
addition: { environment: e_0 }
}
]
# from T1 + T2
rv_2 = [
{
condition: {
environment: e_0,
element-list: [
{element-id: k_0, element-claims: v_0 }
]
},
addition: { environment: e_0 }
},
{
condition: {
environment: e_0,
element-list: [
{element-id: k_0, element-claims: v_1 }
]
},
addition: { environment: e_0 }
}
]
It seems that these rv lists will yield different additions to the ACS based on section 9.4.4's statement that "If every entry in the condition ECT element-list has a matching entry in the ACS entry element-list field then the element lists match.".
rv_1 would seemingly not match since the evidence does not satisfy both v_0 and v_1 at the same time. rv_2 would match because v_0 and v_1 are checked as part of different element-lists. So it seems we get different results based on whether the claims are split across multiple ref-claims.
So question is:
- Did I follow the reference algorithm correctly?
- If so, is the difference in behavior I see aligned with the intended functioning of the algorithm? Or are fixes required to align sections 9.3.3 and 9.4.4 with the intended behavior where the two forms are interchangeable?
Referenced excerpts
From section 5.1.5:
The ref-claims in a reference-triple-record can contain one or more entries. This multiplicity can have different meanings:
- Each ref-claims entry can represent a different possible state of the Environment.
- Each ref-claims entry can represent a possible state of a different measured element (identified by its mkey) within the Environment.
Section 9.1.4.2:
Step 1. An rv list entry (Section 9.1.4.1) is allocated.
Step 2. The cmtype of the addition ECT in the rv entry is set to
reference-values.
Step 3. The Reference Values Triple (RVT) (Section 5.1.5) populates
the rv ECTs.
i RVT.ref-env
copy(environment-map, rv.condition.environment.environment-map)
copy(environment-map, rv.addition.environment.environment-map)
ii For each e in RVT.ref-claims:
copy(e.measurement-map, rv.condition.element-list.element-map)
Step 4. The signer of the Reference Values conceptual message is
copied to the rv.addition.authority field.
Step 5. If the Reference Values conceptual message has a profile,
the profile identifier is copied to the rv.addition.profile
field.
From section 9.3.3:
Reference Values are matched with ACS entries by iterating through
the rv list. For each rv entry, the condition ECT is compared with
an ACS ECT, where the ACS ECT cmtype contains evidence.
From section 9.4.4:
The Verifier SHALL iterate over all the entries in the condition ECT
element-list and compare each one against the corresponding entry in
the ACS entry element-list.
If every entry in the condition ECT element-list has a matching entry
in the ACS entry element-list field then the element lists match.
Hi folks,
I'm attempting to follow the reference verification algorithm and am stumbling on the statement that "ref-claims in a reference-triple-record can contain one or more entries. This multiplicity can have different meanings" from section 5.1.5. I've gone through #442, #523, and #571 (plus some of the associated PRs) and am unable to form a consistent mental model of this multiplicity. I'm likely missing a key concept, so any help in clearing up my confusion is appreciated. Referenced excerpts with additional emphasis are included at the end.
This comment best illustrates the problem I see: #500 (review). It's stated that:
is shorthand for:
Section 5.1.5 seems consistent with this, however, it's not clear to me how this aligns with the reference verification algorithm.
Let's say the evidence is:
Also assume v_0 and v_1 make incompatible assertions about the same property, say
name(e.g. v_0 matches when name=foo, v_1 matches when name=bar). The CoRIM author intends to say "both foo and bar are valid for name under mkey=k_0 and environment e_0".We then produce the rv lists corresponding to each reference value form given above. Authority, cmtype, etc omitted for brevity:
It seems that these rv lists will yield different additions to the ACS based on section 9.4.4's statement that "If every entry in the condition ECT element-list has a matching entry in the ACS entry element-list field then the element lists match.".
rv_1 would seemingly not match since the evidence does not satisfy both v_0 and v_1 at the same time. rv_2 would match because v_0 and v_1 are checked as part of different element-lists. So it seems we get different results based on whether the claims are split across multiple ref-claims.
So question is:
Referenced excerpts
From section 5.1.5:
Section 9.1.4.2:
From section 9.3.3:
From section 9.4.4: