Code change:
Evidence as well as all accompanying Event Logs back to the Verifier. While it is crucial that Claims, the Handle, and the Attester <del> Identity information MUST be cryptographically bound to the signature of Evidence, they MAY be presented obfuscated, encrypted, or cryptographically blinded.  For further reference see section security-and-privacy-considerations. </del> <ins> Identity information (i.e., the Authentication Secret) MUST be cryptographically bound to the signature of Evidence, they MAY be presented obfuscated, encrypted, or cryptographically blinded.  For further reference see section security-and-privacy-considerations. </ins> <del> As soon as the Verifier receives the signed Evidence and Event Logs, it appraises the Evidence.  For this purpose, it validates the </del> <ins> As soon as the Verifier receives the Evidence and the Event Logs, it appraises the Evidence.  For this purpose, it validates the </ins> signature, the Attester Identity, and the Handle, and then appraises the Claims.  Appraisal procedures are application-specific and can be conducted via comparison of the Claims with corresponding Reference

Related discussion:
text: Signed-off-by: Michael Eckel
Based on URL Previous section says “Attester Identity” is about “a distinguishable Attesting Environment”, and here says it’s about “a distinguishable Attester”.
How to understand “without accompanying evidence about its validity”?
I think it means that there is no certificate conveyed along with it which proves its validity.
I think this is related to and should be fixed.
Based on URL The Attester Identity is to identify which Attester the Evidence comes from. But if the Attester has multiple Attesting Environments, what should be the Attester Identity?
The TPM’s AIK certificate is one kind of Attester Identity, right?
"The TPM’s AIK certificate is one kind of Attester Identity, right?": Correct.
"The Attester Identity is to identify which Attester the Evidence comes from. But if the Attester has multiple Attesting Environments, what should be the Attester Identity?" I see the point, too, and agree. So, perhaps it should be renamed to "Attesting Environment identity"!? The Attester Identity then should be something different. It may be the TPM AK/AIK of one of the Attesting Environments, but not necessarily.
As discussed, polish can happen later Hi Henk, I've reviewed the reference interaction models I-D recently, I hope the comments below can help improve the draft before the IETF110 draft submission cut-off. Section 3 Disambiguation Comment > This section is talking about the disambiguation of terminology, so I suggest making it a sub-section of Section 2 Terminology. Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)). Comment > About "these types of co-located environments", The previous sentences are about the Verifier and Attester don't need to be remote. So "these" is weird here, because here is about the attesting environment and target environment. Section 5 Direct Anonymous Attestation Comment > I think it's better to move this section to the bottom of the draft.