Need definition of what is a group for the purpose of reference value matching

[andrew-draper]

The text uses the placeholder term "group" to describe reference values and endorsed values which are processed together.
There are different ways proposed to encode the group concept in the CoRIM file
We need to agree how the "group" is encoded, and probably rewrite the document to replace the term "group" with new text

[nedmsmith]

(context: Lines 1468-1469 in PR #107) The grouping construct should apply to all forms of claims (Endorsements, Evidence, RVs). The grouping construct isn't itself a conceptual message type. This language treats it like a CM which can be misleading.

[andrew-draper]

In the current text, the term "group" is a placeholder for a set of Reference Values and Endorsed Values which define a Conditional Endorsement. Ned brings up an important point, which is that we should think about extensibility.

I think the high level question we need to address first is: Do we have an expectation that triples in the same CoMID tag are expected to interact with each other more than triples in different CoMID tags?

The answer to this question will inform the direction in which we proceed.

Another way to ask this question is to ask whether all triples must stand alone, or whether triples can be connected?

The more direct question is about how we should represent the general case of Conditional Endorsements in a CoMID?

The current text contains two triples which represent special cases of Conditional Endorsement: Conditional Endorsement Series Triple and Conditional Endorsement Triple. Each of these triples defines a group of Reference Values and Endorsed Values which if processed together define a group.

These triples are only able to describe a group where all reference values and endorsements have the same environment-map.

We need a way to describe groups where the reference values and/or endorsements are in multiple environments.

I have seen three approaches proposed:

1. The group is composed of all reference values and endorsements in the same CoMID tag
2. The group is composed of all reference values and endorsements in the same CoMID tag with the same class-id
3. The group is explicitly described by a triple
   a. This implies that we should deprecate reference-value-triple and endorsed-value-triple
   b. For support of legacy CoMID tags we might want to provide a load time rewrite which converts a tag containing reference-value-triple and endorsed-value-triples into one containing a single grouping triple
   c. If we take this approach then this means that Device Identity Triple and Attestation Keys triple can't be used as part of matching

Both PR #169 and PR #168 take approach 3.

If we take approach 3 then I think we are explicitly saying that tag boundaries do not matter, and that we cannot, in future, define triples which interact with each other because they are in the same tag.

If we take approach 1 or 2 then this limits what we can do with editing the contents of a CoMID tag (which may or may not be a bad thing).

[nedmsmith]

I'm not sure the 3a conclusion make sense. There is a lot of work and working code behind these triples.
Since we have concluded that there are at least three or four types of grouping semantics, it is somewhat ambiguous what we mean by "the group".
The notion that a triple that captures grouping semantics somehow causes reference and endorsed triples to be deprecated isn't obvious.

[nedmsmith]

I'm not convinced the grouping discussion is closed. We should get broader consensus before closing this issue.

[andrew-draper]

I closed this issue (which I filed) because the text referring to group was deleted by PR #193, it has been replaced by multi-conditional-endorsement and other triples.
In our discussions others have used the word "group" to mean something else, there might be more discussions to be had on that.
I think it is probably better to use new issues to discuss those meanings.

[yogeshbdeshpande]

Closing in agreement with ANdy and Ned