Node Attestation

Node attestation policy (Node 0.30.0)

The Bridge sends the already-sealed CER to the Node unchanged. For Consequential records, Node operational headers may include:

X-NexArt-Visibility: public|private
X-NexArt-Readable-Fields: request,result

These headers are not fields inside the CER. Readable fields are acknowledged separately by the Node. The Node does not rewrite the CER, convert Protected values to Readable, convert Readable values to commitments, or change the certificate hash.

Node attestation

Node attestation is optional and separate from ingestion. Ingesting an event does not automatically contact NexArt Node.

POST https://bridge.nexart.io/api/v1/results/{resultId}/attest
Authorization: Bearer <NEXART_API_KEY>

Discovery:   GET  https://node.nexart.io/.well-known/nexart-node.json
Attestation: POST https://node.nexart.io/api/attest

The Bridge submits the exact already-sealed CER. Successful HTTP status alone is not considered proof. Evidence Bridge verifies the returned Node receipt cryptographically. Verification includes:

• certificate-hash binding
• Node identity
• kid
• Ed25519 signature
• published key
• key lifecycle
• canonical receipt payload

Before submission, the Bridge loads the persisted CER, confirms eligibility, re-verifies local integrity and checks all required confidential openings. It submits the unchanged CER and confirms the receipt binds the same certificate hash. If the Node is unavailable or returns invalid evidence, the local CER remains unchanged.

Confidential plaintext and private openings are not submitted to NexArt Node. Only the CER with its commitment envelopes is sent for attestation.

A 200 or 201 response alone does not mean VERIFIED. The production Node may return different successful 2xx status codes depending on the path or version. The cryptographic receipt verification is authoritative.

Node discovery

Discovery values such as activeKid change over time, so treat the following as an illustration of the shape rather than fixed values.

{
  "service": "NexArt Attestation Node",
  "nodeId": "nexart-node-prod-1",
  "activeKid": "k1",
  "status": "ok",
  "protocol": {
    "default": "1.3.1",
    "supported": ["1.2.0", "1.3.1"]
  },
  "wellKnown": "/.well-known/nexart-node.json"
}

Read protocol.default for the current default and protocol.supported for supported protocol versions. Do not interpret the legacy top-level protocolVersion field as the authoritative current default. The Node supports protocol 1.2.0 and 1.3.1; the current default is 1.3.1.

RFC 3161 timestamping

NexArt Node receipts can include independent RFC 3161 timestamp evidence. This timestamp is separate from the execution timestamp reported by the producer.

• Producer-reported execution time: the producer reports that this execution occurred at time T.
• RFC 3161 timestamp: an independent timestamp authority provides cryptographic evidence that the relevant digest existed by timestamp T2.

These are different claims and must not be equated.

VERIFIED
PRESENT_NOT_VERIFIED
NOT_PRESENT
NOT_VERIFIED

Presence of a timestamp token alone is not enough to mark it VERIFIED. The verifier must validate:

• timestamp token
• message imprint binding
• certificate chain
• trusted TSA roots
• time validity

Production NexArt uses RFC 3161 timestamp infrastructure including DigiCert TSA services. Responder certificates and chains can rotate, so verifiers should validate against trusted roots rather than a hardcoded responder name.

For the wider verification model, see Verification Model and Independent Verification.