Minor edits

Author: pareenaverma

content/learning-paths/servers-and-cloud-computing/cca-trustee/cca-trustee.md

@@ -86,9 +86,9 @@ A verifier driver parses the attestation evidence provided by the hardware TEE.
 1. Verifies the hardware TEE signature of the TEE quote and report provided in the evidence
 2. Receives the evidence and organizes the status into a JSON format to be returned
 
-In this Learning Path AS is configured to use an external CCA verifer.
+In this Learning Path, the AS is configured to use an external CCA verifer.
 
-[Linaro](https://www.linaro.org) provides such an attestation verifier for use with pre-silicon CCA platforms.
+[Linaro](https://www.linaro.org) provides such an attestation verifier for use with pre-silicon Arm CCA platforms.
 This verifier is built from the Open-Source [Veraison project](https://github.com/veraison).
 You can learn more about Veraison and Linaro attestation verifier service in
 [Get Started with CCA Attestation and Veraison](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-veraison/)
@@ -100,7 +100,7 @@ When an attestation request is received by the AS, it uses a policy ID in the re
 to decide which policies should be evaluated.
 The results of all policies evaluated are included in the attestation response.
 
-In this Learning Path AS attestation policy includes specific Arm CCA rules.
+In this Learning Path the AS attestation policy includes specific Arm CCA rules.
 
 #### Reference Value Provider Service (RVPS)
 
@@ -124,7 +124,7 @@ You will run this tool inside of a realm to make requests for an attestation res
 The client tool can also be used to provision the KBS/AS with resources and policies.
 
 KBS Client connects to the KBS in order to perform attestation. To prove the trustworthiness of the environment
-KBS Client sends the evidence (claims) from the TEE in the form of a CCA attestaion token.
+KBS Client sends the evidence (claims) from the TEE in the form of a CCA attestation token.
 You can learn more about CCA attestation tokens in
 [Get Started with CCA Attestation and Veraison](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-veraison/)
 
@@ -141,7 +141,7 @@ When the AS receives an attestation token from the realm via KBS:
 - it calls an external CCA verifer (the Linaro attestation verifier service) to obtain an attestation result.
 - the external CCA verifer checks the token's cryptographic signature,
   verifies that it denotes a confidential computing platform and provides an attestation result.
-- AS also checks the token evidences against a its own attestation policies and updates attestation result status and trustworthiness vectors.
+- it also checks the token evidences against its own attestation policies and updates attestation result status and trustworthiness vectors.
 
 When asked for a resource the KBS uses the attestation result to decide whether to release the secrets into the realm for processing.
 

content/learning-paths/servers-and-cloud-computing/cca-trustee/flow.md

@@ -12,9 +12,7 @@ layout: "learningpathall"
 
 #### Prerequisites
 
-Install git and docker packages. For example, on Ubuntu 24.04 LTS machine:
-
-Set up Docker's apt repository:
+Install docker. For example, on your Ubuntu 24.04 LTS host machine, first set up Docker's apt repository:
 ``` bash
 # Add Docker's official GPG key:
 sudo apt-get update
@@ -31,35 +29,35 @@ echo \
 sudo apt-get update
 ```
 
-Install packages:
+Install git and docker packages:
 ``` bash
 sudo apt-get install git docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
 ```
 
-If you have just installed docker (like with the command line above), add yourself to the docker group:
+Add your user name to the docker group:
 ``` bash
 sudo usermod -aG docker $USER
 newgrp docker
 ```
 
 #### Start Trustee Services docker containers
 
-Clone `cca-trustee` repository:
+Clone the `cca-trustee` repository:
 ``` bash
 git clone https://github.com/ArmDeveloperEcosystem/cca-trustee.git
 ```
 
 This repository contains configuration files used for running Trustee services docker containers with CCA attestation support as a simple cluster.
 The config files are based on the recommended configurations from [KBS Cluster](https://github.com/confidential-containers/trustee/blob/main/kbs/docs/cluster.md)
 
-In addition to the recommended configuration we also made the following changes for this Learning Path:
+In addition to the recommended configuration, the following changes were also made for this Learning Path:
 - Included the external Linaro CCA verifier into AS configuration
-- Included an attesation policy with CCA rules
+- Included an attestation policy with CCA rules
 - Defined an "affirming" resource policy
 - Created a secret demo message.
 - Defined a docker network shared by all containers in this demo.
 
-Go into `cca-trustee` directory and start Trustee services docker containers (as detached services):
+Go into the `cca-trustee` directory and start the Trustee services docker containers (as detached services):
 ``` bash { output_lines = "3-9" }
 cd cca-trustee
 docker compose up -d
@@ -100,7 +98,7 @@ launch the `run-cca-fvp.sh` script to run the Arm CCA pre-built binaries on the
 ./run-cca-fvp.sh
 ```
 
-The `run-cca-fvp.sh` script uses screen command to connect to the different UARTs in the FVP.
+The `run-cca-fvp.sh` script uses the screen command to connect to the different UARTs in the FVP.
 
 You should see the host Linux kernel boot on your terminal. You will be prompted to log in to the host.
 
@@ -134,11 +132,11 @@ realm login: root
 (realm) #
 ```
 
-### Try to run attestation and request a secret
+### Try to use attestation to request a secret
 
 In this step, you will go through the process of using attestation to request
 a secret from the KBS. This will not work on the first attempt.
-But don't worry. We will explain why, and how to rectify the problem.
+But don't worry. You will learn why that is the case, and how to rectify the problem.
 You will have a better understanding of the attestation process as a result.
 
 Change directory to `/cca` and use `openssl` to create a realm RSA key:
@@ -147,19 +145,19 @@ cd /cca
 openssl genrsa -traditional -out realm.key
 ```
 
-Run attestation command and save EAT Attestation Result (EAR) message in JWT (JSON Web Token) format in `ear.jwt` file.
+Run the attestation command and save the EAT Attestation Result (EAR) message in JWT (JSON Web Token) format in a file named `ear.jwt`:
 ```bash
 ./kbs-client --url http://kbs:8080 attest --tee-key-file realm.key >ear.jwt
 ```
 
-Let's try to request a secret demo message using the attestation result:
+Now try to request a secret demo message using the attestation result:
 ```bash
 ./kbs-client --url http://kbs:8080 get-resource \
   --tee-key-file realm.key --attestation-token ear.jwt \
   --path "cca-trustee/demo-message/message.txt"
 ```
 
-The request would fail with `Access denied by policy` and `Token Verifier` errors:
+The request will fail with `Access denied by policy` and `Token Verifier` errors:
 ```output
 [2025-07-23T14:42:55Z WARN  kbs_protocol::client::token_client] Authenticating with KBS failed. Get a new token from the token provider: ErrorInformation {
         error_type: "https://github.com/confidential-containers/kbs/errors/PolicyDeny",
@@ -194,7 +192,7 @@ The following command will use the `arc` tool to verify the cryptographic signat
 
 {{% notice EAR expiry note %}}
 The EAR message produced by Trustee AS in this Learning Path demo is valid for 30 minutes.
-If you spend more time on anylising the message you will start seing errors from `arc verify` command:
+If you spend more time on analyzing the message you will start seeing errors from `arc verify` command:
 
 ``` output
 Using JWK key from JWT header
@@ -205,8 +203,8 @@ Please obtain a new EAR message by re-runing the attestation command.
 {{% /notice %}}
 
 
-`arc verify`  command produces quite a lot of output.
-However, the main part is the CCA attestation token similar to the one you inspected in
+The `arc verify` command produces quite a lot of output.
+However, the main part is the CCA attestation token that is similar to the one you inspected in
 [Get Started with CCA Attestation and Veraison](/learning-paths/servers-and-cloud-computing/cca-veraison) Learning Path.
 
 The most interesting part of the output is towards the bottom, and should look like this:
@@ -241,17 +239,17 @@ You can also check the status of the EAR:
 The warning status is the reason why the KBS chose not to grant access
 to the secret that you requested in the earlier step.
 It has not concluded that the realm is trustworthy.
-But this is simply because we have not supplied an expected reference measurement
+But this is simply because you have not supplied an expected reference measurement
 for the realm. You will do this in the next step.
 
 ### Endorse Realm Initial Measurement (RIM)
 
-For a successful attestaion of your CCA real you need to provide
+For a successful attestation of your CCA real you need to provide
 the Trustee Reference Values Provider Service (RVPS) with a known good reference value.
 
 In a production environment, the known good reference value is generated using a deployment-specific process,
 but for demonstration purposes and simplification, you will use the value which was calculated by `kbs-client`
-in the realm and included into EAT.
+in the realm and included into the EAT.
 
 Get the RIM from the attestation token:
 ```bash { output_lines = "2" }