Re: [Rats] Composite Evidence

["Eric Voit (evoit)" <[e-mail]>]

Hi Michael,

> From: Michael Richardson, January 22, 2020 9:40 PM
> 
> Eric Voit (evoit) <[e-mail]> wrote:
>     > I promised you a definition for Composite Evidence.  You can see my
> proposed
>     > definition directly the text below, but I am not willing yet to
place
>     > it in a
>     > Pull Request. I thought an email thread might be helpful first.
> 
> First, I found the diagram confusing, because I think you rotated our
> previous diagram 90 degress clockwise.

As I was adopting the passport model, I used the Architecture Document
Figure 4 in Section 5.1 as a base.

> The Verifier A, was in my mind, towards me (in the third dimension) out,
> "above" the "Internal Verifier", which we asked to have renamed "Claims
> Collector"
> (Screw the monochrome SVG debate... lets go VRML)

I thought about trying SVG.  But I am not brave enough with the tooling to
be an early IETF adopter :-).
 
> Second, I found the extra hash(),@time, stuff distracting, as it went into
a
> level of detail that just confused me.

I need to put together a submission which defines the elements diagram.
These details are important for exposing why I see the intersections of
evidence types and composite evidence being quite important.  Some of these
reasons are exposed in my reply to Dave & Ned which dives into three types
of evidence (i), (ii), & (iii).

>     > Anyway my strawman definition for Composite Evidence is:  Evidence
> which
>     > includes multiple sub-elements of evidence, more than one of which
can
> be
>     > computationally verified to have been generated by a specific
Attester
>     > Subcomponent or Verifier.
> 
> I am not sure what "computationally" verified means.

Good point, we probably can remove "computationally".
    
> Give an example of something that would not fall into that category.
> Maybe you are trying to abstract "has a signature" to things that can be
> verified without a asymmetric digital signature. (KerbV Ticket?)

It is true I am trying to abstract away from "has a signature".   I didn't
want to exclude things like the possibility that Verifier B to go back to
Verifier A if a trust relationship hasn't been established between them yet.
 
> I think that the key thing that we needed to be able to say is that
Composite
> Evidence is not:
> 1) struct evidence_claims foo[];
> -or-
> 2) struct attestation_results foo[];
> 
> but rather:
>     union composite_evidence {
>           struct evidence_claims ec;
>           struct attestation_results ar;
>     } foo[];

I very much agree with your code above. And the definition needs to reflect
this.   The question which Ned & Dave open up is whether types of
evidence_claims need to be exposed in your union composite_evidence. This
directly hits my question of whether the definition of composite evidence
needs to intersect the definition of evidence types (i), (ii), & (iii).
The more I think about this in the context of your code above, the more I am
hoping to keep the two concepts orthogonal.

Eric

> were I more hip, I'd learn to write this in CDDL.
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh
networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect
[
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails
[
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
>