AffixIOAFFIXIO
Contact

Issuer verifier

Issuer and verifier split architecture

AffixIO works best when issuers hold source attributes and verifiers only check proofs. That split keeps PII upstream and lets every gate speak the same allow or deny language.

Category Infrastructure Updated 17 July 2026 Reading ~7 min
ISSUERVERIFIERSPLITZERO PIIML-DSA-65STATELESS
Offline gate product Evaluate All trends

Issuer verifier split architecture assigns attribute custody to issuers and outcome checking to verifiers, connected by signed proofs.

Field note. One party issuing and verifying without separation fails most enterprise security reviews. Split the roles explicitly.

Clean roles

Issuers mint proofs from systems of record. Verifiers call AffixIO verify and gate on allow or deny. Neither role should casually absorb the other's data.

Portals and SDKs exist for both sides. Keep network and access controls aligned with the split.

Multi-party programmes

One issuer can serve many verifiers. That is the point for marketplaces, government programmes, and agent platforms.

Document who may issue. Mis-issuance is a governance problem, not a verify bug.

Rollout notes for issuer-verifier split

Place issue at consent or policy satisfaction, then verify at the first external boundary. Deny should return a stable code for support. Allow should attach Merkle metadata to the record your finance or ops team already stores.

When WAN is unreliable, run local verify with cached keys and sync Merkle inclusion later. Offline QR and edge agents use the same spent-proof rules as online gates.

Token reuse

When every system is both

Monoliths that store identity and also gate access recreate a KYC database at every boundary.

Mixed responsibilities

The same service holds documents and decides entry.

Hard partner onboarding

Each vendor wants a data feed instead of a verify API.

Retention confusion

Nobody knows which copy is authoritative.

Implementation path

Split issuer and verifier so no single node holds everything

Monolithic verify stacks concentrate breach risk and audit blind spots. Issuer-verifier split lets proofs travel between parties with Merkle evidence auditors can replay independently.

  1. Name the issuer systems

    Sources of truth.

  2. Name the verifier gates

    Checkout, door, tool, API.

  3. Connect with AffixIO proofs

    Issue then verify.

  4. Forbid casual data copies

    At verifier sites.

Readiness review

Readiness checks for issuer-verifier split

  • Draw the issuer/verifier diagram for your programme.
  • Ensure verifiers do not store documents by default.
  • Publish who may issue credentials.
  • Use /issuer/ and /verifier/ portals where relevant.
  • Review technical architecture docs.

Risk FAQ

Questions on issuer-verifier split

Can one org be both?

Yes, but keep the roles logically split in systems and retention.

Where do portals fit?

/issuer/ and /verifier/ support operations on each side.

SDK on-prem?

Supported for issue and verify on infrastructure you control.

Architecture docs?

/docs/technical-architecture

Next reads

Pages that support issuer-verifier split

Infrastructure

More infrastructure briefs

Design issuer-verifier split flows

Run split issue and verify in sandbox, then map handoff points to your partner or merchant boundaries.

Offline gate product Contact