Change:
added 4.4 "Roles and Entities", also removed the last occurrence of the artifact "role composition", and retained section 4.3 as is and added the usage scenario from issue
The introduction section uses the phrase "role compositions and data flows" then mentions "Passport Model" as an example of a role composition. In section 4.3 on Composite Device the second to last section describes "combinations of roles" using an example involving a Composite Device. I think the architecture should have crisper understanding of two concepts a) "topological models" (as defined by the section 5 heading that describes Passport, BKC and Hybrid; b) "role composition" which ought to refer to the "combining of roles" by a given entity. The terms "role composition" and "combining of roles" are too similar for them to have different meanings and "role composition" as an alias for "topological models" is unnecessary. I suggest pulling the second to the last paragraph in section 4.3 into a new section 4.4 titled "Role Composition" that has a paragraph defining role composition conceptually followed by the paragraph taken from section 4.3. Suggested Text for section 4.4: RATS roles are implemented by entities (e.g., devices). A simple realization of the architecture associates a single role to a single entity; for example, the topological models described in section 5.1 and 5.2 follow this convention. However, entities may host multiple roles as a way to accommodate more sophisticated use cases and deployment scenarios. An entity that both connects to a wide-area network and to a system bus may play both Attester and Verifier roles. As a system bus entity, a Verifier consumes Evidence from other devices connected to the system bus that implement an Attester role. As a wide-area network connected entity, it may implement an Attester role. The entity, as a system bus Verifier, may choose to fully isolate its role as a wide-area network Attester. Alternatively, attestation results might reflect an aggregation of system bus operational state claims in the form of Evidence. For example, in the Composite Device scenario, the lead Attester... Additionally, the introduction section should change "role composition" terminology to "topological models" as it references Passport.
"Role Composition" will be worked out of document.
Also addressed in Issue55. I recommend closing this issue.
"role composition" no longer appears in the doc. I agree this can be closed.
Taking into account the recent trends in terminology used in draft text & PR, I am proposing to add Entity and Sub-Entity to the terminology section. We do not need to over-specify here. Hence, only mentioning Composite Device and Components as an examplew for each of the terms in the definition text could be enough. Are there any objections to this proposal? If not, we could create a PR and address it in next week's meeting.
Agree so long as it is understood that other words can be used in place of entity when they add context for readability such as component, sub-component, device, environment and so forth.
This now relates to the comments on

Discussion:
roles and their interaction via conceptual messages.  Additionally, this document defines a universal set of terms that can be mapped to various existing and emerging Remote Attestation Procedures.  Common <del> role compositions and data flows, such as the "Passport Model" and the "Background-Check Model" are illustrated to enable readers of this document to map their current and emerging solutions to the architecture provided and the corresponding terminology defined.  A common terminology that provides a well-understood semantic meaning to the concepts, roles, and models in this document is vital to create semantic interoperability between solutions and across different platforms. </del> <ins> topological models and the data flows associated with them, such as the "Passport Model" and the "Background-Check Model" are illustrated.  The purpose is to enable readers of this document to map their current and emerging solutions to the architecture provided and the corresponding terminology defined.  A common terminology that provides a well-understood semantic meaning to the concepts, roles, and models in this document is vital to create semantic interoperability between solutions and across different platforms. </ins> Amongst other things, this document is about trust and trustworthiness.  Trust is a decision being made.  Trustworthiness is

6. <ins> An entity in the RATS architecture includes at least one of the roles defined in this document.  As a result, the entity can participate as a constituent of the RATS architecture.  Additionally, an entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles.  In these cases, interaction between these roles do not necessarily use the Internet Protocol. They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. For example, an entity that both connects to a wide-area network and to a system bus is taking on both the Attester and Verifier roles. As a system bus entity, a Verifier consumes Evidence from other devices connected to the system bus that implement Attester roles. As a wide-area network connected entity, it may implement an Attester role.  The entity, as a system bus Verifier, may choose to fully isolate its role as a wide-area network Attester. In essence, an entity that combines more than one role also creates and consumes the corresponding conceptual messages as defined in this document. 7. </ins> The scope of this document is scenarios for which a Relying Party trusts a Verifier that can appraise the trustworthiness of information about an Attester.  Such trust might come by the Relying

the background-check model, this Evidence may also be revealed to Relying Party(s). <del> 7. </del> <ins> 8. </ins> <del> 7.1. </del> <ins> 8.1. </ins> Today, Evidence tends to be highly device-specific, since the information in the Evidence often includes vendor-specific

isolation would require Appraisal Policy to be based on device- specific details (e.g., a device public key). <del> 7.2. </del> <ins> 8.2. </ins> An Endorsement is a secure statement that some entity (e.g., a manufacturer) vouches for the integrity of the device's signing

may need device-specific information such as a public key for the device or component or user on the device. <del> 7.3. </del> <ins> 8.3. </ins> Attestation Results may indicate compliance or non-compliance with a Verifier's Appraisal Policy.  A result that indicates non-compliance

relationship with one entity, rather than a larger set of entities, for purposes of its Appraisal Policy. <del> 8. </del> <ins> 9. </ins> The following diagram illustrates a relationship to which remote attestation is desired to be added:

Evidence that encodes claims in one format, while issuing Attestation Results that encode claims in a different format. <del> 9. </del> <ins> 10. </ins> It is important to prevent replay attacks where an attacker replays old Evidence or an old Attestation Result that is no longer correct.

have been generated at boot, and then used in claims as long as the signer can guarantee that they cannot have changed since boot. <del> 10. </del> <ins> 11. </ins> The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a

Results are responsible for detailing what kinds of information are disclosed, and to whom they are exposed. <del> 11. </del> <ins> 12. </ins> Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation

roles, then the relaying entity should not expect to have access to the Evidence. <del> 12. </del> <ins> 13. </ins> This document does not require any actions by IANA. <del> 13. </del> <ins> 14. </ins> Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica Fitzgerald-McKay, Thomas Fossati, Diego Lopez, Laurence Lundblade,