Passports

A passport confers nothing on its own. It is a container bound to a subject, and it accumulates attestations that issuers have made about that subject. A passport carrying five credentials permits no more capital movement than an empty one, because permission is expressed by a mandate and resolved at preflight. The passport supplies facts. The mandate decides what those facts are worth.

That separation matters. Identity systems that attach capability to a credential answer a real and difficult question — is this actor who they claim to be — but they answer it in a form that fuses it with a second question: may this actor do this particular thing. The first has a durable answer that changes slowly. The second depends on the asset, the amount, the venue and the state of a daily limit. Keeping credentials free of capability means an issuer can attest to a fact once and have that fact reused across many mandates without needing to know, or approve, what any of them authorize.

The issuer, subject, credential-type triple

Every credential is identified by three components. Removing any one of them leaves something policy cannot evaluate.

The issuer is the party that made the assertion and is accountable for it. An assertion with no attributable issuer is a rumour, and a policy engine has no principled way to weigh a rumour. Attribution is also what makes revocation possible: the party that said something is the party that can withdraw it.

The subject is the party the assertion is about. Subject binding is what prevents a credential from behaving like a bearer instrument. A credential asserting that one subject is eligible says nothing about anyone who happens to hold a copy of it.

The credential type is a stable identifier naming what was asserted, such as STOCK_TOKEN_ELIGIBLE. It is the only part of the credential that policy text refers to directly.

ISSUER                    SUBJECT
   |                         ^
   | asserts                 | about
   v                         |
+-----------------------------------+
|  CREDENTIAL                       |
|  type:   STOCK_TOKEN_ELIGIBLE     |
|  window: valid_from / valid_until |
|  status: active or revoked        |
+-----------------------------------+
   |
   v
PASSPORT 0x7F...94A

A policy clause is therefore a question about the triple: does an acceptable issuer currently assert this credential type about this subject? Which issuers are acceptable is configuration, not a property of the credential. Two deployments of the same architecture may accept different issuer sets for the same credential type and reach different decisions on identical facts. That is intended. Jurisdictions disagree about who is competent to attest to what, and the architecture should not pretend otherwise.

What a credential asserts, and what it deliberately omits

A credential records a conclusion. It does not carry the evidence behind it. STOCK_TOKEN_ELIGIBLE asserts that the subject meets the criteria its issuer applies for holding tokenized equity exposure. It does not contain a document number, a residential address, a date of birth, a scan, or a tax identifier.

Three properties make the conclusion the better object to circulate.

Evaluation needs only the conclusion. A credential check asks whether an accepted issuer currently asserts the required type about the subject, whether that assertion is inside its validity window, and whether it has been withdrawn. The personal data that produced the conclusion changes none of those three answers, so carrying it adds exposure without adding decision value.

Disclosure damage scales with what is carried. A leaked attestation that some address was found eligible in a category is a far smaller event than a leaked identity dossier. Minimizing what is written down is the most dependable privacy control available, because it does not rely on any access control staying correct forever.

Conclusions and evidence age differently. An address changes without changing eligibility. A sanctions screen ages even when nothing about the subject changed. Recording the conclusion, with an explicit validity window, states the thing that actually needs to be re-established.

Issuance

Issuance is the act by which an issuer binds a credential type to a subject and publishes an attestation that others can verify as its own. The architecture does not name issuers and does not specify who is qualified. It requires that an issuer be identifiable, that its attestations be verifiable as originating from it, and that it retain the ability to revoke what it issued.

Issuers differ in kind. A verification provider, a fund administrator, a compliance function inside an institution and a venue operator can all occupy the issuer role for different credential types, and nothing in the model requires them to coordinate. They publish independent assertions about the same subject, and the mandate author decides which combination is required.

Validity windows

Every credential carries a validity window: a point from which it takes effect and, in most cases, a point at which it lapses. The window is part of the assertion, not metadata attached to it. An issuer stating that a subject passed an anti-money-laundering screen is stating something about a moment in time, and the window is how that temporal scope is written down.

Expiry is ordinary. It is the intended end of a bounded assertion, and preflight treats it as a normal outcome by returning CREDENTIAL_EXPIRED rather than failing open or treating a lapsed credential as merely stale. Credential windows are independent of mandate duration. A mandate can be well within its own term and still be unusable because a credential it depends on has lapsed, which surfaces as CREDENTIAL_EXPIRED and not MANDATE_EXPIRED. The two clocks are distinct because they express different things: how long an authority was granted, and how long a fact was warranted.

Revocation

Revocation is initiated by the issuer, because the issuer is the only party in the triple with standing to withdraw its own assertion. A subject cannot revoke a fact stated about them. A relying party cannot revoke it either; it can only decline to accept it. A revoked credential is not deleted. It moves to a revoked state, which preserves the record that the assertion once stood and the point at which it ceased to.

Revocation propagates without touching any mandate. This follows from how mandates reference credentials: a mandate names a required credential type and the issuers it will accept, never a copy of a credential's contents. Resolution happens at evaluation time, so the current status of a credential is read on every preflight.

ISSUER revokes STOCK_TOKEN_ELIGIBLE at 14:02
        |
        v
PASSPORT 0x7F...94A
   credential status -> revoked
        |
        v
NEXT PREFLIGHT at 14:03
        |
        v
BLOCKED + CREDENTIAL_REVOKED

In the running example, actor 0x81...29F operates under a mandate that requires STOCK_TOKEN_ELIGIBLE. If that credential on passport 0x7F...94A is revoked at 14:02, the actor's next proposed AAPL purchase is refused at 14:03 with CREDENTIAL_REVOKED. No mandate was rewritten, no migration ran, and nothing was re-signed. Every other mandate depending on the same credential type stops at the same instant, whoever authored it.

Revocation is forward-looking. It refuses the next execution; it does not unwind the last one. Settled transactions remain settled. A system that needs retroactive remedy needs a different mechanism, and the security model is explicit that authorization control is not a substitute for the finality of settlement.

Example credential types

The types below are the ones used throughout this documentation. They are illustrative. They are not a compliance programme, not a registry PASS operates, and not a claim about what any jurisdiction requires. A deployment defines the credential types its policies require.

Each name is a stable identifier, and stability is the point. Policy text, audit records and decision logs refer to the same string over time, so a refusal recorded a year ago remains legible today. Renaming a credential type is a breaking change to every mandate that requires it, which is why the identifier is part of the interface rather than a label.

A credential record

The following sketch shows the shape of a credential record. It is an interface illustration rather than a wire format.

{
  "credential_type": "STOCK_TOKEN_ELIGIBLE",
  "subject": "0x3A...F02",
  "passport": "0x7F...94A",
  "issuer": "0x4C...1B8",
  "issued_at": "2026-03-04T09:12:00Z",
  "valid_from": "2026-03-04T09:12:00Z",
  "valid_until": "2027-03-04T09:12:00Z",
  "status": "active",
  "evidence_reference": "sha256:9f2c...e17"
}

Note what is absent. There is no name, no document, no address and no jurisdictional narrative. The evidence reference is a commitment to material the issuer holds in its own systems. The evaluating system does not resolve it and does not need to. It exists so that an issuer can later demonstrate, to a party entitled to ask, what the assertion rested on.

Offchain verification, onchain conclusion

Verification is specialized work. Document examination, sanctions screening, accreditation assessment and jurisdictional analysis are performed by parties with the licences, staff and legal exposure to perform them. PASS does not perform verification and does not attempt to.

The architecture separates the performance of verification from the recording of its conclusion. An identity provider does its work in its own environment, under its own obligations, holding the underlying records. What reaches the onchain surface is the conclusion, attributed to its issuer and bounded by a validity window. Sensitive material stays where accountability for it already sits, and only what execution needs to read is published.

Privacy considerations

The design property that supports privacy here is structural rather than cryptographic. Because policy evaluates credential types rather than personal data, the data never has to be present for a decision to be reached. An attestation model in which a subject demonstrates that an issuer asserts a type about them, without revealing the underlying records or further linkage, is compatible with this architecture. The specification is deliberately written so that external attestation schemes and privacy-preserving credential models can occupy the issuer role. That is a statement about what the architecture permits. It is not a claim that any particular cryptographic scheme is implemented.

Honesty requires stating the residual exposure. An onchain attestation is observable. The set of credential types a passport carries is itself information, and combinations of types can be narrowing, particularly where a credential type is rare or a jurisdiction is small. Correlation between a passport and the addresses that transact under mandates referencing it is available to anyone watching. Minimizing credential contents reduces the severity of disclosure. It does not make a public attestation private.

What a passport is not

A passport is not a profile. It holds discrete assertions with issuers and expiries, not a description of a person or an institution.

It is not a collectible. It is bound to its subject and carries no meaning if moved. A transferred container of assertions about someone else produces nothing a policy engine would accept.

It is not a reputation score. Credentials are not aggregated, weighted or ranked into a number. Policy asks discrete questions with discrete answers, which is what makes a decision explainable after the fact.

It is not a consumer identity badge. Its audience is a policy engine, not an interface. Nothing in the model is designed to be displayed as a status.

Where credentials surface in a decision

Credentials are read inside preflight, after an adapter has decoded the proposed call into an Execution Intent and after the actor's binding to a live mandate has been established, but before the scope and the numeric limits of that mandate are applied. The order is not incidental. A call that cannot be decoded cannot be described in the terms a credential requirement is written in, so normalization precedes every other question.

PROPOSED EXECUTION
        |
        v
ADAPTER -> EXECUTION INTENT
        |
        v
ACTOR AND MANDATE    <- binding, status, window
        |
        v
CREDENTIAL GATE      <- issuer, window, status
        |
        v
MANDATE CONSTRAINTS  <- action, asset, venue, limits
        |
        v
AUTHORIZED  |  BLOCKED + REASON CODE

Three Reason Codes concern credentials. They are kept distinct because the remedy for each differs.

A decision carries one Reason Code, and these three are not interchangeable. A credential failure is never collapsed into a generic refusal, because the party receiving it has to know whether to seek issuance, seek re-attestation, or approach the issuer about a withdrawal.

Passing every credential check settles one gate only. The proposed execution must still satisfy the action, asset, venue and limit constraints of the mandate that governs it. In the running example, actor 0x81...29F acts for subject 0x3A...F02 and presents that subject's passport 0x7F...94A with STOCK_TOKEN_ELIGIBLE present and current, under a mandate whose maximum transaction is $2,500 and whose daily exposure limit is $10,000. A proposed $3,000 AAPL purchase is refused with TX_LIMIT_EXCEEDED. A $1,000 AAPL purchase sits inside the transaction limit and is still refused with DAILY_LIMIT_EXCEEDED once $9,500 of that day's exposure has been consumed. Neither refusal concerns the credentials, which were valid throughout.

Credentials constrain who may act; they make no promise about market, smart-contract, oracle or governance risk once execution proceeds, and the security model sets out what that leaves exposed.