AttestLayerAttestLayer
ContactStart qualification

Trust Center

What the Partner and Program qualification surfaces do, what they do not do, and how later issued output is verified.

Scope of this page

Public qualification collects business contact and fit information only. It does not accept Buyer Review Pack files, source records, payment-card details, or production credentials, and it does not create a paid entitlement or issued package. If the parties later execute an agreement or purchase a Buyer Review Pack, that service is governed by the executed agreement and the applicable direct-buyer policies.

What AttestLayer is

  • A record-only evidence issuance service
  • Versioned, repeatable evaluation under the same ruleset, schema version, adapter profile, and validation version; package metadata and outputs may change when inputs or service versions change
  • When a Buyer Review Pack is later issued, the package uses a canonical manifest and an Ed25519 signed receipt binding the manifest SHA-256; trust completes only when the receipt key ID resolves to the applicable issuer key published by the AttestLayer Registry
  • No system access, no installs, no agent footprint

What AttestLayer is not

  • Not an audit firm and does not issue audit opinions
  • Not a compliance certification body
  • Not a legal advisor
  • Not controls testing or penetration testing

Security posture

  • Ed25519 signing — an issued Buyer Review Pack includes a cryptographic receipt signed with an Ed25519 issuer key
  • SHA-256 manifests — package-file integrity is bound to a hash manifest at issuance time
  • Hosted verification path — submit the complete ZIP to the verifier; receipt trust requires the applicable issuer key to be published by the AttestLayer Registry and cannot come from a key embedded in the package
  • Record-only model — no system access, no installs, no agent footprint
  • Published security model — security documentation and verification procedures are published and reviewable

Data handling

  • Qualification workload — the application workload is configured in GCP northamerica-northeast1 (Montréal, Canada). Business email, transactional email, optional abuse prevention, and provider support may process limited qualification information outside Quebec or Canada as described in the Privacy and Subprocessors notices.
  • Encryption at rest — AES-256 via Google-managed encryption keys
  • Encryption in transit — TLS 1.2+ for all connections
  • No customer names in registry — registry receipts contain only hashes and timestamps
  • Qualification retention — qualification correspondence and security records are retained only as reasonably necessary for the inquiry, resulting relationship, troubleshooting, incident response, dispute handling, and legal obligations. Paid-package retention is governed separately by the applicable Buyer Review Pack policy or executed agreement.

Current registry trust model

RegistrySelf-witnessed by AttestLayer
CheckpointsSigned by the registry key
ReceiptsEd25519 signed by a separate issuer key and bind the canonical manifest SHA-256
External witness cosignaturesStructurally supported but not active
Independent witnessesNot onboarded yet

How signatures are verified

AttestLayer uses two separate Ed25519 key pairs for different purposes:

Issuer keySigns Buyer Review Pack receipts. Published at issuer.jwks.json.
Registry keySigns checkpoints in the append-only transparency log. Published at registry.jwks.json.

Both key sets are published at the registry. Published historical keys remain available for historical verification according to the Registry Transparency Policy. The two key pairs are completely separate: the issuer key never signs checkpoints and the registry key never signs receipts.

What reviewers can verify independently

  • Receipt signature — verify the Ed25519 signature against issuer.jwks.json
  • Manifest integrity — recalculate each package-file SHA-256 and compare it with the canonical manifest entry
  • Registry inclusion — not currently active for Buyer Review Pack issuance; a package or receipt must not be treated as proof of transparency-log inclusion
  • Key history — inspect the issuer and registry key material published at both JWKS endpoints
  • Independent verification — use the hosted verifier with the complete ZIP; the receipt key ID must resolve to the applicable issuer key published by the AttestLayer Registry, and Registry inclusion is separate and is not currently active for Buyer Review Pack issuance

Verification infrastructure

Public key registrySigning keys are published at registry.attestlayer.com
Key historyPublished issuer and registry key history is available through the Registry
Verify portalverify.attestlayer.com provides client-side proof verification
EvaluationRules are versioned and repeatable; outputs can change when inputs, package metadata, or service versions change

Policies

Security

Security model and controls

Privacy

Privacy policy

Terms

Terms of Service

Subprocessors

Third-party subprocessors

Refund

Refund policy