> ## Documentation Index
> Fetch the complete documentation index at: https://docs.phala.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Attestation

> Learn how to verify the ACI gateway attestation report for Confidential AI.

## What the attestation report proves

The attestation report is the gateway's proof of identity. It proves the API is served by a specific workload running inside a genuine TEE and publishes the public keys used to sign receipts and support end-to-end encryption.

Fetch it before trusting receipts:

```bash theme={"system"}
export API_KEY="<API_KEY>"
export BASE="https://inference.phala.com"
export NONCE="$(openssl rand -hex 16)"

curl -s "$BASE/v1/aci/attestation?nonce=$NONCE" \
  -H "Authorization: Bearer $API_KEY" \
  -o report.json
```

## What to inspect first

```bash theme={"system"}
jq '{api_version, workload_id, workload_keyset_digest,
     report_data: .attestation.report_data,
     stale_after: .attestation.freshness.stale_after,
     provenance: .attestation.source_provenance}' report.json
```

Check that:

* `api_version` is `aci/1`.
* `attestation.freshness.stale_after` is in the future.
* `workload_id` and `workload_keyset_digest` are present; receipts must cite the same values.
* `attestation.source_provenance` matches the gateway release you trust.
* `attestation.report_data` is bound to your nonce and the published keyset.

## What the report contains

| Field                            | What it proves                                                                                                 |
| -------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| `workload_id`                    | Stable identity of the gateway workload.                                                                       |
| `workload_keyset_digest`         | Digest over the published keyset. Receipts cite this value.                                                    |
| `attestation.tee_type`           | TEE technology, for example `tdx`.                                                                             |
| `attestation.evidence.quote`     | Hardware-signed TDX quote. This is the root of trust.                                                          |
| `attestation.report_data`        | Value bound into the quote, committing to the nonce and keyset.                                                |
| `attestation.workload_keyset`    | Workload identity, receipt signing keys, E2EE (end-to-end encryption) public keys, TLS keys, and keyset epoch. |
| `attestation.keyset_endorsement` | Signature over the keyset under the workload identity key.                                                     |
| `attestation.source_provenance`  | Source repo, commit, image digest, and image provenance when available.                                        |
| `attestation.freshness`          | Fetch and expiry timestamps.                                                                                   |
| `service_capabilities`           | Runtime capabilities such as supported E2EE versions.                                                          |

## Verification steps

### 1. Verify the TEE quote

Verify `attestation.evidence.quote` against Intel DCAP collateral and confirm the quote's report data matches `attestation.report_data`.

You can use Phala's public verification service for TDX quote decoding:

```bash theme={"system"}
jq -r '.attestation.evidence.quote' report.json > quote.txt

curl -s https://cloud-api.phala.com/api/v1/attestations/verify \
  -H "Content-Type: application/json" \
  -d "{\"hex\":\"$(cat quote.txt)\"}"
```

For local verification, use an Intel DCAP verifier such as [dcap-qvl](https://github.com/Phala-Network/dcap-qvl). For manual inspection, paste the quote into the [TEE Attestation Explorer](https://proof.t16z.com/).

### 2. Verify nonce and keyset binding

The quote's report data must commit to the nonce you generated and to the gateway keyset. This prevents replay and proves the receipt-signing keys belong to the attested workload.

At a high level, your verifier should:

1. Canonicalize the `workload_keyset`.
2. Recompute the expected keyset digest.
3. Confirm the quote report data binds that digest and your `NONCE`.
4. Confirm `workload_keyset_digest` matches the recomputed digest.

### 3. Verify the keyset endorsement

Verify `attestation.keyset_endorsement` under `attestation.workload_keyset.workload_identity`. This ties the receipt signing keys and E2EE keys to the attested workload identity.

Receipts are only valid when their signatures verify under a key from `attestation.workload_keyset.receipt_signing_keys`.

### 4. Check freshness and provenance

`attestation.freshness.stale_after` must be in the future when you verify. In production, compare `attestation.source_provenance.repo_url`, `repo_commit`, and image provenance against the release or source code you are willing to trust.

### 5. Handle multi-instance deployments

The top-level `attestation` is the instance that answered your request. `all_attestations` lists other instances behind the same service. When verifying a receipt, match the receipt's `workload_id` and `workload_keyset_digest` against the attestation for the instance that signed it.

## Legacy compatibility

`GET /v1/attestation/report` remains available for older clients. It returns the gateway attestation in a compatibility response shape and may include top-level signer fields such as `signing_address`. New integrations should use `GET /v1/aci/attestation`.

## Next step

After you verify the gateway report, [verify a response](/phala-cloud/confidential-ai/verify/verify-signature) by checking a signed receipt.