Merge pull request #206346 from mssindhurid/main

update faq

Author: ttorble

articles/attestation/faq.yml

@@ -36,12 +36,11 @@ sections:
       - question: |
           What validations does Azure Attestation perform for attesting SGX enclaves
         answer: |
-          Azure Attestation is a unified framework for remotely attesting different types of TEEs. Azure Attestation:
+          During SGX attestation process, Azure Attestation performs the following validations:
           
-             - Validates if the trusted root of a signed enclave quote belongs to Intel.
-             - Validates if the enclave quote meets the Azure security baseline as defined by Trusted Hardware Identity Management (THIM).
-             - Validates if the SHA256 hash of Enclave Held Data (EHD) in the attestation request object matches the first 32 bytes of reportData field in the enclave quote.
-             - Allows customers to create an attestation provider and configure a custom policy. In addition to the above validations, Azure Attestation evaluates the enclave quote against the policy. Policies define authorization rules for the enclave and also dictate issuance rules for generating the attestation token. To confirm if intended software is running in an enclave, customers can add authorization rules to verify if **mrsigner** and **mrenclave** fields in the enclave quote matches the values of customer binaries.
+             - Validates if the trusted root of signed enclave quote belongs to Intel
+             - Validates if the TEE quote meets Azure security baseline as defined by Trusted Hardware Identity Management (THIM)
+             - If customer created an attestation provider and configured a custom policy, in addition to the above validations, Azure Attestation evaluates the TEE quote against the attestation policy. Using attestation policies, customers can define authorization rules for the TEE and also dictate issuance rules for generating the attestation token
           
       - question: |
           How can a verifier obtain the collateral for SGX attestation supported by Azure Attestation
@@ -54,14 +53,14 @@ sections:
           How to shift to Azure Attestation from other SGX attestation models
         answer: |
           - After installing Azure Confidential computing virtual machine, install Azure DCAP library ([Windows/](https://www.nuget.org/packages/Microsoft.Azure.DCAP/) [Linux](https://packages.microsoft.com/ubuntu/18.04/prod/pool/main/a/az-dcap-client/)) to leverage the benefits offered by Trusted Hardware Identity Management (THIM).
-          - Remote attestation client needs to be authored which can retrieve the enclave evidence and send requests to Azure Attestation. See [code samples](/samples/browse/?expanded=azure&terms=attestation) for reference 
+          - Remote attestation client needs to be authored which can retrieve the enclave evidence and send requests to Azure Attestation. See [code samples](https://github.com/Azure-Samples/microsoft-azure-attestation) for reference 
           - Attestation requests can be sent to the REST API endpoint of default providers or custom attestation providers 
           - In [2018-09-01-preview](https://github.com/Azure/azure-rest-api-specs/tree/master/specification/attestation/data-plane/Microsoft.Attestation/stable/2018-09-01-preview) API version, the client needs to send Azure AD access token along with the evidence to SGX attest API endpoint. The Azure AD access token is not a required parameter to perform SGX attestation in [2020-10-01](https://github.com/Azure/azure-rest-api-specs/tree/master/specification/attestation/data-plane/Microsoft.Attestation/stable/2020-10-01) API version
           
       - question: |
           How can the relying party verify the integrity of attestation token and confirm that Azure Attestation is running inside an enclave
         answer: |
-          Attestation token generated by Azure Attestation is signed using a self-signed certificate. The signing certificates are exposed via an [OpenID metadata endpoint](/rest/api/attestation/metadataconfiguration/get). Relying party can retrieve the signing certificates from this endpoint and perform signature verification of the attestation token. The signing certificate also includes SGX quote of the TEE inside which Azure Attestation runs. If relying party also prefers to check if Azure Attestation is running inside a valid SGX enclave, the SGX quote can be retrieved from the signing certificate and locally validated.  
+          Attestation token generated by Azure Attestation is signed using a self-signed certificate. The signing certificates are exposed via an [OpenID metadata endpoint](/rest/api/attestation/metadataconfiguration/get). Relying party can retrieve the signing certificates from this endpoint and perform signature verification of the attestation token. The signing certificate also includes SGX quote of the TEE inside which Azure Attestation runs. If relying party also prefers to check if Azure Attestation is running inside a valid SGX enclave, the SGX quote can be retrieved from the signing certificate and locally validated. See [code samples](https://github.com/Azure-Samples/microsoft-azure-attestation/tree/master/sgx.attest.sample.oe.sdk) for more information
           
       - question: |
           How long is an attestation token valid?
@@ -76,7 +75,7 @@ sections:
       - question: |
           Is it possible for the relying party to share secrets with the validated Trusted Execution Environments (TEEs)
         answer: |
-          Public key generated within an enclave can be expressed in the Enclave Held Data (EHD) property of the attestation request object sent by the client to Azure Attestation. After confirming if SHA256 hash of EHD is expressed in reportData field of the quote, Azure Attestation includes EHD in the attestation token. Relying party can use the EHD from the verified attestation response to encrypt the secrets and share with the enclave. See [Azure Attestation basic concepts](basic-concepts.md) for more information.
+          At the time of TEE evidence creation, code running inside the TEE can include arbitrary information in the evidence. For e.g. the TEE can create one or more asymmetric key pairs, serialize the public key components of these key pairs as JWKS JSON string and include the JWKS JSON string in the TEE evidence as RunTimeData { quote, JWKS JSON string }. Azure Attestation checks if SHA256 hash of the RuntimeData matches the lower 32 bytes of the quote's "report data" attribute. Post evaluating the TEE evidence, Azure Attestation generates JWT with the JWKS available as a claim named "keys" under the "x-ms-runtime" claim. The RunTimeData can be further used by relying party to establish secure channel and securely transmit data to the TEE.
 
       - question: |
           Where does Azure Attestation store customer data?