Original text:
seeing the details of the model. This typically works by having some protected environment in the <del> device attest to some manufacturer service.  If remote attestation succeeds, then the manufacturer service releases either the model, or a key to decrypt a model the Attester already has in encrypted form, to the requester. </del>  A device desiring to run an ML model to do inferencing A "Trusted Application Manager (TAM)" server is responsible for managing the applications running in the TEE of a client device.  To do this, the TAM wants to assess the state of a TEE, or of <del> applications in the TEE, of a client device.  The TEE attests to the TAM, which can then decide whether the TEE is already in compliance with the TAM's latest policy, or if the TAM needs to uninstall, update, or install approved applications in the TEE to bring it back into compliance with the TAM's policy. </del>  A device with a trusted execution environment capable of running trusted applications that can be updated 7.  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 Party trusting the Verifier (or its public key) directly, or might come by trusting an entity (e.g., a Certificate Authority) that is in <del> the Verifier's certificate chain.  The Relying Party might implicitly trust a Verifier (such as in the Verifying Relying Party combination).  Or, for a stronger level of security, the Relying Party might require that the Verifier itself provide information about itself that the Relying Party can use to assess the </del>  trustworthiness of the Verifier before accepting its Attestation Results. <del> The Endorser and Verifier Owner may need to trust the Verifier before giving the Endorsement and Appraisal Policy to it.  Such trust can also be established directly or indirectly, implicitly or explicitly. One explicit way to establish such trust may be the Verifier first acts as an Attester and creates Evidence about itself to be consumed by the Endorser and/or Verifier Owner as the Relying Parties.  If it is accepted as trustworthy, then they can provide Endorsements and Appraisal Policies that enable it to act as a Verifier. </del>  The Verifier trusts (or more specifically, the Verifier's security policy is written in a way that configures the Verifier to trust) a material and the Attesting Environment with equivalent strength protections. <del> In some scenarios, Evidence might contain sensitive information such as Personally Identifiable Information.  Thus, an Attester must trust entities to which it conveys Evidence, to not reveal sensitive data to unauthorized parties.  The Verifier might share this information with other authorized parties, according rules that it controls.  In the background-check model, this Evidence may also be revealed to Relying Party(s). </del>  8.

Reviewer comments:
Diffs look longer than they really are just because text was moved around due to the ordering point raised on the design team call. Also, I found that "Verifying Relying Party" was used in this section without actually being defined so I defined it in context in that sentence (line 686). Also added subsection headings for each role to make it easier to read and refer to. The "recursion" aspect is dealt with by example in the new text starting at line 692, which was the simplest way I could find to do it, where I found that trying to use the term "recurse" or similar just made it harder for me to understand. Other places just refer back to that example. Signed-off-by: Dave Thaler

Revised text:
seeing the details of the model. This typically works by having some protected environment in the  <ins> device go through a remote attestation with some manufacturer service that can assess its trustworthiness.  If remote attestation succeeds, then the manufacturer service releases either the model, or a key to decrypt a model the Attester already has in encrypted form, to the requester. </ins> A device desiring to run an ML model to do inferencing A "Trusted Application Manager (TAM)" server is responsible for managing the applications running in the TEE of a client device.  To do this, the TAM wants to assess the state of a TEE, or of  <ins> applications in the TEE, of a client device.  The TEE conducts a remote attestation procedure with the TAM, which can then decide whether the TEE is already in compliance with the TAM's latest policy, or if the TAM needs to uninstall, update, or install approved applications in the TEE to bring it back into compliance with the TAM's policy. </ins> A device with a trusted execution environment capable of running trusted applications that can be updated 7. <ins> 7.1. </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 Party trusting the Verifier (or its public key) directly, or might come by trusting an entity (e.g., a Certificate Authority) that is in  <ins> the Verifier's certificate chain. The Relying Party might implicitly trust a Verifier, such as in a Verifier/Relying Party combination where the Verifier and Relying Party roles are combined.  Or, for a stronger level of security, the Relying Party might require that the Verifier first provide information about itself that the Relying Party can use to assess the </ins> trustworthiness of the Verifier before accepting its Attestation Results.  <ins> For example, one explicit way for a Relying Party "A" to establish such trust in a Verifier "B", would be for B to first act as an Attester where A acts as a combined Verifier/Relying Party.  If A then accepts B as trustworthy, it can choose to accept B as a Verifier for other Attesters. Similarly, the Relying Party also needs to trust the Relying Party Owner for providing its Appraisal Policy for Attestation Results, and in some scenarios the Relying Party might even require that the Relying Party Owner go through a remote attestation procedure with it before the Relying Party will accept an updated policy.  This can be done similarly to how a Relying Party could establish trust in a Verifier as discussed above. 7.2. In some scenarios, Evidence might contain sensitive information such as Personally Identifiable Information.  Thus, an Attester must trust entities to which it conveys Evidence, to not reveal sensitive data to unauthorized parties.  The Verifier might share this information with other authorized parties, according to rules that it controls. In the background-check model, this Evidence may also be revealed to Relying Party(s). In some cases where Evidence contains sensitive information, an Attester might even require that a Verifier first go through a remote attestation procedure with it before the Attester will send the sensitive Evidence.  This can be done by having the Attester first act as a Verifier/Relying Party, and the Verifier act as its own Attester, as discussed above. 7.3. The Relying Party Owner might also require that the Relying Party first act as an Attester, providing Evidence that the Owner can appraise, before the Owner would give the Relying Party an updated policy that might contain sensitive information.  In such a case, mutual attestation might be needed, in which case typically one side's Evidence must be considered safe to share with an untrusted entity, in order to bootstrap the sequence. 7.4. </ins> The Verifier trusts (or more specifically, the Verifier's security policy is written in a way that configures the Verifier to trust) a material and the Attesting Environment with equivalent strength protections.  <ins> 7.5. In some scenarios, the Endorser and Verifier Owner may need to trust the Verifier before giving the Endorsement and Appraisal Policy to it.  This can be done similarly to how a Relying Party might establish trust in a Verifier as discussed above, and in such a case, mutual attestation might even be needed as discussed in rpowner- trust. </ins> 8.