Original text:
3.1.  3.1.1.  A workload needs to obtain its identity early in its lifecycle.  This identity is sometimes referred to as the "bottom turtle" on which further identity and security context is built.

Reviewer comments:
Define workload identity. Resolves issue
The section talks about identity then defines identifier -- I would recommend it separate things a little more and clarify the differences and relationship. Is the identifier part of the identity? Does it point to the overall identity? Augment it?
NAME - I modified the section to differentiate workload identity and identifier a bit more. Let me know if it looks good enough to merge in as a straw man for the identity section. IN any case we can discuss in the 120 meeting
NAME definitely clearer that they're separate concepts now, and all this can be refined as the draft moves on. Thanks for updating!
Some (rather nit) comments that are not related to what's being discussed on the mailing list.

Revised text:
3.1. <ins> Workload identity often comprises multiple attributes that describe various aspects of a workload.  These attributes can encompass diverse sets of information, including the workload's role within a system, the software it operates, and the hardware environment it utilizes.  Different authorities across various parts of the system define these attribute sets.  This architecture introduces a Workload Identifier for representing and referencing workloads, enabling diverse authorities with distinct identity attribute sets to consistently reference the workload. The Workload Identifier consists of a concise string allocated within a namespace defined by a Trust Domain.  This Workload Identifier is present in Workload Identity Tokens and X.509 certificates issued by the authority for the Trust Domain.  The Workload Identifier is used to associate additional identity attributes to the workload through the use of tokens (workload attribute tokens?) or online look up services.  It may also be used directly in authorization calculations and audit logs. The Trust Domain consists of a string that matches the format of a fully qualified domain name.  It is the intent that a Trust Domain is actually a domain name registered to the organization defining the Trust Domain, but this may not be true in all cases.  The Trust Domain also maps to the issuer of cryptographically signed Workload Identity Tokens (WIT) or X.509 Certificate.  The association between a Trust Domain and the cryptographic root of the signing authority for that Trust Domain must be made securely through an out-of-band mechanisms.  [TODO: where should mechanisms be defined?] The Trust Domain also defines how the rest of the Workload Identifier is constructed.  The Workload Identifier may represent a type of workload such that the same identifier may be used by many instances of the same service.  A Trust Domain may choose identifiers to represent a specific instance of a workload such that each workload of the same type will have a specific identity.  The Trust Domain could choose a naming scheme that allows for both objects by imposing a hierarchical structure on the naming format. The Trust Domain also defines which mechanisms are used to initially bootstrap a workload with a Workload Identifier and the mechanisms for a workload to obtain its workload identity credentials in the form of X.509 certificates and Workload Identity Tokens. </ins> 3.1.1. <ins> [TODO: this section will need to be updated to discuss workload identifier as a concept as well] </ins> A workload needs to obtain its identity early in its lifecycle.  This identity is sometimes referred to as the "bottom turtle" on which further identity and security context is built.