Mintall logoMintall

Specification

Mechanics-first verification specification for Mintall Certificate for Product (MC4P).

1.1 Overview

MC4P certificates are JSON-LD documents that include a signed JWT proof and references to C2PA content credentials embedded in an image. The verification model is designed to support future extensions while preserving baseline verification requirements. Verification involves cryptographic checks of the JWT and C2PA signatures, as well as context binding to ensure the certificate is used in an authorized domain and context.

Public endpoints

  • Certificate JSON-LD
    • GET /api/v1/mc4p/{image_id}/certificate?full=true
    • Returns JSON-LD with optional proof.jwt and (when full=true) contentCredentials.asset.url.
  • Certificate verification (server-side checks)
    • POST /api/v1/mc4p/{image_id}/verify
    • Verifies authorization and (optionally) JWT integrity.
  • JWKS for JWT verification
    • GET /api/v1/.well-known/jwks.json
    • Returns a JWKS (RFC 7517) for verifying proof.jwt.

1.2 Terminology

MC4P Certificate

A Mintall Certificate for Product (MC4P), represented as a JSON-LD document returned by GET /api/v1/mc4p/{image_id}/certificate. When full=true is specified, the response includes additional fields required for full cryptographic and audit verification.

Certificate

Shorthand for MC4P Certificate when used elsewhere in this specification.

JWT (JWS)

A JSON Web Token signed using JSON Web Signature (JWS), used to assert certificate claims and context binding.

JWT proof
Signed JWT included under proof.jwt.
JWKS

JSON Web Key Set used to verify the JWT signature (GET /api/v1/.well-known/jwks.json).

C2PA

The Coalition for Content Provenance and Authenticity specification for embedding cryptographically verifiable content credentials in media assets.

Registry anchor (NFT)

An issuance-time identifier embedded in the asset’s C2PA manifest and optionally mirrored as a reference in MC4P JWT claims.

Context binding

Fields in the certificate that bind it to a specific evaluation context, including verification.authorizedDomains and other bound fields (e.g., productUrl, sku).

Domain authorization

Evidence that the certificate is intended for a merchant domain and that domain control has been verified (public challenge verification: partial).

1.3 Trust Model

  • Trust is based on cryptographic verification of proofs (JWT + C2PA) and consistency checks against observed context (domain + bound fields).

  • The system is designed so third parties can reproduce core checks without private state.

  • No single field or flag is authoritative; verification depends on reproducing checks.

  • Domain authorization is a soft signal. It indicates control over a domain, but does not establish merchant identity or business legitimacy.

  • Some signals (for example registry anchoring) may influence trust scoring, but are not mandatory inputs for third-party verification.

1.4 Verification Guarantees

Integrity

Signed data is tamper-evident (JWT and/or C2PA). Byte-level verification requires image bytes and (for convenience) fields returned when the certificate is fetched with full=true (for example contentCredentials.asset.url).

Context binding

Verification is expected to fail when the certificate is replayed in an unauthorized context.

Domain authorization

Certificates are intended to be valid only on authorized domains.

1.5 Verification Flow

Offline verification

Fetch Certificate

Fetch and parse certificate JSON-LD. Full cryptographic/audit verification may require fetching the certificate with full=true (for example to obtain contentCredentials.asset.url and cryptographicProof).

Verify JWT

Verify JWT signature using JWKS (if present).

Verify C2PA

Verify C2PA manifest against image bytes (if present).

Validate Context

Validate context binding (domain + bound fields).

Additional Checks

This endpoint may perform additional checks that are not yet publicly reproducible.

Server-assisted verification

Agents can call POST /api/v1/mc4p/{image_id}/verify to validate authorization and compare JWT claims against server-computed checks.

Domain verification (status: partial)

Minimum checks require that the observed domain is within verification.authorizedDomains. The verification.domainVerified flag is a Mintall-recorded signal (currently not enforced by the public certificate endpoint). When verification.domainAuthorization is present, a verifier can validate domain control using DNS TXT or HTTP well-known data. If enforcement is enabled server-side, POST /api/v1/mc4p/{image_id}/verify returns 412 Precondition Failed when the authorized domain is not verified.

Detailed steps (agent-oriented)

1) Fetch and parse the certificate (JSON-LD)

  • Fetch the certificate: GET /api/v1/mc4p/{image_id}/certificate?full=true
  • Parse JSON.
  • Extract these fields:
    • imageId (must match {image_id})
    • verification.canonicalUrl (treat as the canonical fetch location)
    • verification.authorizedDomains (list of allowed hostnames)
    • verification.domainVerified (Mintall-recorded verified flag)
    • verification.domainAuthorization (if present)
    • proof.jwt (if present)
    • contentCredentials.hasC2PA
    • contentCredentials.asset.url (if present; requires full=true)
    • registryAnchor.transactionHash / registryAnchor.explorerUrl (if present)

2) Verify the JWT signature (offline)

Preconditions: proof.jwt exists; the agent can fetch JWKS.

  • Fetch JWKS: GET /api/v1/.well-known/jwks.json
  • Verify the JWT signature (RS256) using kid selection from the JWT header and JWKS keys.
  • Validate the JWT payload claims at minimum:
    • imageId equals the certificate imageId
    • authorizedDomains (if present) contains current_domain
    • domain (if present) is consistent with authorizedDomains

Note: the JWKS endpoint is designed to be cached by verifiers.

3) Validate domain authorization (public web verification)

Minimum checks:

  • Require current_domain ∈ verification.authorizedDomains.
  • Require verification.domainVerified == true (Mintall-recorded state).

If verification.domainAuthorization is present, a verifier can additionally validate domain control using public web data (DNS TXT or HTTP well-known).

4) Verify the C2PA manifest (content credentials)

Verify C2PA provenance and integrity against the image bytes you are evaluating (c2patool / CAI SDK).

Notes: full cryptographic verification requires verifying against the actual image bytes. credentials.mintall.ai is a public viewer for humans; automated agents should verify using a C2PA verifier against image bytes instead.

5) Optional registry / anchor lookup

If the certificate includes a registry anchor:

  • Extract registryAnchor.transactionHash and registryAnchor.explorerUrl.

1.6 Failure Semantics

  • A failing check should be treated as untrusted for that context.
  • Verification results should be deterministic given the same inputs (certificate, domain, bytes).

1.7 Non-Goals

  • Guaranteeing merchant identity beyond domain control.
  • Preventing all forms of content theft or UI-layer spoofing.
  • Replacing platform-specific risk scoring models.
  • Breaking changes will be versioned.
  • Acting as a sole source of truth for merchant reputation.

1.8 Status and Evolution

This specification is expected to evolve as new verification signals are added (e.g., additional public registries, richer context binding, expanded error semantics). Backwards compatibility should be preserved where possible.