Skip to main content
Use this experimental flow to bind one HTTPS connection to the direct model attestation report it returns.
Obtain the peer certificate and direct attestation report over the same TLS connection. This result does not establish deployment evidence for later independent completion or signature requests. Use the NEAR AI Cloud Gateway for production verification workflows.

​
What this checks

With include_tls_fingerprint=true, the direct report includes tls_cert_fingerprint: the SHA-256 hash of the direct endpoint certificate’s SubjectPublicKeyInfo (SPKI). The verified model quote binds that fingerprint, the model signing identity, and the nonce. This check applies to the direct model connection. It does not verify a connection to cloud-api.near.ai.

​
Verification flow

  1. Generate a fresh 32-byte nonce in the client.
  2. Open a TLS connection to https://<MODEL_SLUG>.completions.near.ai using the trust configuration required by your application.
  3. Read the peer certificate from that connection and calculate SHA-256(SPKI_DER).
  4. Reuse the same open connection to request /v1/attestation/report with include_tls_fingerprint=true, the nonce, and the signing algorithm you require.
  5. Verify the direct report’s Intel TDX quote, then check the nonce, model signer, and TLS-fingerprint binding in the verified quote.
  6. Compare the calculated peer SPKI hash with tls_cert_fingerprint.
A command-line request can retrieve a report, but cannot by itself demonstrate that the report and peer certificate came from one TLS connection. This result applies only to that open TLS connection. Send the inference request on it. If the client reconnects, repeat this flow before treating the new connection as bound.

​
Required handling

Do not use a cached fingerprint as evidence for a new connection. Fetch new evidence after a certificate, signer, measurement, or accepted-attestation-age change.