Re: [Rats] name for outer box of Composite Attester

["Smith, Ned" <[e-mail]>]

I'm advocating for "Composite Device" because the focus of this section is dealing with 'composite' things. The roles however aren't different because a thing can be decomposed into a composite of things. However, there needs to be a context for how the roles relate to the composition of things. We can say that a device is an entity that hosts a RATS role (e.g. Attester). But the device consists of sub-component entities that also host RATS roles (e.g. Attesters). Since the role relationships remain consistent regardless of the entity topology, Each Attester (A, B, C, ...) can be described as three independent cases (e.g. Attester A -- Evidence A --> Verifier, Attester B -- Evidence B --> Verifier, etc.). However, Attester A is providing an additional function, that of assembling the Evidences A, B, C, ... into a new thing called "Composite Evidence". 

From a RATS Roles perspective, we've identified an embellishment of the RATS Roles architecture that either describes Verifier as accepting two inputs "Evidence" and "Composite Evidence" or that "Evidence" is a structure that supports multiple Evidence instances. This clarification needs to be added to the description of Verifier Role IMO.

In the case where it matters to the Verifier that Attester A is authorized / expected / allowed to assemble Evidences B, C, ... in addition to providing Evidence A. Attester A could include in Evidence A that it intended to assemble Evidences B, C, etc. To accomplish this there needs to be a claim that allows Attester A to say this. For the purpose of this email thread I'll call it the "Composite Evidence Claim".

I suppose, there is a philosophical question as to whether this claim is different/same as "Collecting Claims" from a Target environment. I don't think we need to have that discussion since, the goal of the section on "Composite Attestation/Attester" defines the context and semantics surrounding the claim of assembling Composite Evidence. The architecture could allow for anonymous assembly of Composite Evidence or for non-anonymous assembly by using the Composite Evidence Claim in its Evidence. 

In the Passport and Background Check examples, the Evidence flows are simply forwarded. I suppose it is possible for a RATS Role to be in deployment case where it is forwarding Evidence from multiple Attesters. I wouldn't expect this to be a case for the creation of Composite Evidence because the routing behavior is orthogonal to trustworthiness appraisals (I think).

I think it's possible to talk about an attester without introducing the specialized "Lead Attester" because any attester could assert the "Composite Evidence Claim" making it a "Lead Attester". But we don't have special names for Attesters based on the set of claims they might assert. Maybe it is useful to use the words 'lead attester' in prose to describe attestation behaviors of composite devices but I don't think it needs to be architectural.

-Ned


On 2/6/20, 3:33 AM, "RATS on behalf of Michael Richardson" <[e-mail] on behalf of [e-mail]> wrote:

    
    In building Figure 2: Conceptual Data Flow for a Composite Attester
    We had some long discussion about what the label on the outside box
    is. 
    
    We had ideas about:
       * Device
       * Composite Device
       * Attester
    
    We started with Composite Attester, then went to Device, then went back
    to Attester, and then Composite Device was suggested.
    There were some TCG terminology relations mentioned, which I didn't follow on
    Tuesday. 
    
    I also wonder, in trying to talk about things if:
        Verifier -> Verifier A
    
    We had called the Attester B/C as being "sub-Attesters" or some such before,
    but we removed that by instead referring to A as the "Lead", and the others
    having no designation.  I find it difficult to know how to refer to the
    collective B..C,etc.
         
    
    
                          .-----------------------------.
                          |           Verifier          |
                          '-----------------------------'
                                          ^
                                          |
                                          | Composite
                                          | Evidence
                                          |
       .----------------------------------|-------------------------------.
       | .--------------------------------|-----.      .------------.     |
       | |                      .------------.  |      |            |     |
       | |                      |  Attesting |<--------| Attester B |-.   |
       | |                      |Environment |  |      '------------. |   |
       | |  .----------------.  |            |<----------| Attester C |-. |
       | |  |     Target     |  |            |  |        '------------' | |
       | |  | Environment(s) |  |            |<------------| ...        | |
       | |  |                |  '------------'  | Evidence '------------' |
       | |  |                |            ^     |    of                   |
       | |  |                |------------/     | Attesters               |
       | |  '----------------'  Collecting      | (via Internal Links or  |
       | |                      Claims          | Network Connections)    |
       | |                                      |                         |
       | | Lead Attester A                      |                         |
       | '--------------------------------------'                         |
       |                                                                  |
       |                    Device/Composite Device/Attester/TBD #33      |
       '------------------------------------------------------------------'
    
    -- 
    Michael Richardson <[e-mail]>, Sandelman Software Works
     -= IPv6 IoT consulting =-