Passport Protocol

Draft 0.1 — 2 August 2026
An ANUKA Passport is not a government passport, legal identity document, credit report, investment rating, or independent certification unless a specific credential says otherwise.

Objective

ANUKA Passports let people, companies, products, and AI agents present selected evidence to a particular audience for a particular purpose.

The governing rule is:

A passport is a controlled presentation of evidence, not a permanent public dossier.

The passport layer must make trustworthy facts easier to share while preserving context, privacy, correction rights, and source transparency.

Passport types

Participant Passport

Presents selected evidence about a person’s:

identifiers and public profile;
contribution history;
verified roles;
capabilities and endorsements;
accepted work;
measurable outcomes;
review quality;
payment or completion history where appropriate;
active credentials and disputes.

Company Passport

Presents selected evidence about an organization:

legal or operating identity;
domains and products;
resident status;
governance and authorized representatives;
verified integrations;
quality processes;
public metrics;
delivery and support evidence;
security or compliance credentials;
active opportunities and funded improvements.

Product Passport

Focuses on one product or service:

ownership or operating relationships;
release and roadmap history;
public Backstage state;
contribution and experiment records;
verified adoption or quality evidence;
stewards and reviewers;
supported capabilities;
public incident and correction records.

Traction Passport

A company-controlled presentation of selected business performance evidence, such as:

revenue trend;
customer growth;
activation;
retention;
usage;
conversion;
support quality;
delivery performance;
experiment history.

Every metric must include source, time range, definition, aggregation, verification method, and limitations.

Agent Passport

Presents an AI agent’s:

principal;
software and version;
allowed tools and scopes;
operating policy;
prior actions and outcomes;
review history;
incident and revocation status.

An Agent Passport must never imply that the agent is independently liable or authorized beyond its principal’s grant.

Passport architecture

ANUKA separates four things:

Source records — raw or canonical events held by source systems.
Credentials and attestations — signed claims by identifiable issuers.
Passport view — a selected, purpose-bound presentation.
Verifier decision — the relying party’s contextual interpretation.

The passport itself should not duplicate every raw record. It references or presents sufficient evidence under defined disclosure rules.

Issuer–holder–verifier model

ANUKA aligns with the W3C Verifiable Credentials model where useful.

Issuer makes claims and secures a credential.
Holder possesses or controls presentation of credentials.
Verifier requests and evaluates a presentation.
Subject is the person, organization, product, agent, contribution, or result described.

The holder and subject may differ. For example, a company may hold a credential about one of its products.

Passport views

A passport is not one universal page. It contains named views.

Public view

Suitable for a website, social profile, public Backstage, or QR link.

It should contain only intentionally published information and must avoid sensitive raw evidence.

Opportunity view

Shows evidence relevant to a bounty, stewardship role, review task, or project application.

Company-partner view

Shows operational, security, delivery, or relationship evidence for a prospective customer or partner.

Investor view

Shows founder-controlled traction evidence, corporate records, data-room references, risks, and metric methodology.

Investor view must not imply broker-dealer activity, investment recommendation, valuation guarantee, or securities compliance.

Compliance or reviewer view

Shows restricted evidence to an authorized auditor, verifier, or qualifier.

Recovery view

Contains enough information for account, organization, credential, or key recovery under a separately protected process.

Selective disclosure

The passport must support disclosure at the claim level where practical.

A participant should be able to present:

that a capability credential exists without revealing unrelated credentials;
that a threshold was met without exposing an exact value where supported;
one project history without disclosing all employers or clients;
a current role without publishing private contract terms;
an organization relationship without exposing personal addresses or identifiers.

Selective disclosure must not be promised when the chosen credential format, cryptosuite, verifier, or source cannot support it.

Presentation request

A verifier should request only what it needs.

A request should state:

verifier identity;
purpose;
requested claims;
required issuers or assurance;
retention period;
whether a decision may affect employment, payment, access, financing, or another material interest;
whether the presentation will be shared onward;
expiration of the request.

The holder must see and approve the actual requested fields before presentation.

Issuance and presentation protocols

The ANUKA protocol should remain format-agnostic at the product boundary while adopting interoperable standards where mature.

Credential issuance

OpenID for Verifiable Credential Issuance 1.0 may be used for OAuth-protected credential issuance to compatible wallets and holders.

Credential presentation

OpenID for Verifiable Presentations 1.0 may be used for requesting and delivering credential presentations.

Browser and native delivery

The first product may also use secure ANUKA-hosted presentations and signed JSON while wallet interoperability matures, provided the data model and migration path remain explicit.

Achievement credentials

Open Badges 3.0 can inform portable capability and achievement credentials because it supports criteria, evidence, issuer identity, endorsements, and W3C-compatible verifiable credentials.

ANUKA should extend rather than fork mature achievement standards when the use case fits.

Passport claim model

Every displayed claim should contain or resolve to:

claim identifier;
subject;
claim type;
value or assertion;
issuer or attester;
evidence references;
method or criteria;
valid-from and optional expiry;
status endpoint or status evidence;
disclosure audience;
correction or dispute state;
schema and version.

Example passport envelope

{
  "passportVersion": "0.1",
  "passportId": "anuka:passport:01J...",
  "subject": "anuka:person:01J...",
  "view": "opportunity",
  "purpose": "apply-for-growth-experiment-review",
  "audience": ["anuka:project:01J..."],
  "expiresAt": "2026-08-09T00:00:00Z",
  "claims": [
    {
      "type": "VerifiedContributionCount",
      "value": 18,
      "context": "saas-onboarding",
      "issuer": "anuka:service:reputation",
      "evidence": ["anuka:graph-query:01J..."]
    },
    {
      "type": "CapabilityCredential",
      "credential": "urn:uuid:..."
    }
  ],
  "holderApproval": {
    "approvedAt": "2026-08-02T00:00:00Z",
    "method": "passkey"
  }
}

This envelope is illustrative and is not yet a ratified schema.

Credential classes

Identity-control credential

States control of an account, domain, repository, wallet, organization role, or product relationship.

Capability credential

States that the subject demonstrated a capability under declared criteria.

Contribution credential

States that a contribution was accepted, reviewed, or reached a milestone.

Outcome credential

States an observed result and verification method.

Stewardship credential

States bounded operating authority over a product or domain.

Residency credential

States participation in the ANUKA network under a named rules version.

Quality credential

States conformance to a defined quality protocol or assessment program.

It must not be called certification unless the program and certifier satisfy the declared certification rules.

Traction credential

States a metric or business result from a declared source, method, and time period.

Endorsements

An endorsement is a separate claim by an endorser, not a property the subject can add unilaterally.

Endorsements should identify:

endorser;
endorsed subject or credential;
scope;
rationale;
evidence or relationship;
validity period;
conflicts of interest;
revocation or withdrawal status.

Paid endorsements must be disclosed where material.

Passport status

A passport or credential may be:

active;
expired;
suspended;
revoked;
superseded;
disputed;
corrected;
archived.

The UI must not hide adverse status merely because a cached public card still renders.

W3C Bitstring Status List v1.0 provides a privacy-preserving mechanism for publishing suspension, revocation, or related credential status. ANUKA may use it for compatible credential populations while preserving product-level correction and dispute records.

Freshness

Each claim needs a freshness policy.

Examples:

account control: recent authentication;
domain control: periodic challenge;
organization authority: role expiry or revalidation;
revenue metric: updated through a named date;
capability: historical and non-expiring, but context may age;
security assessment: expires after a declared interval;
passport presentation: short-lived and audience-bound where sensitive.

A passport should display verified through, not simply verified.

Source confidence

The passport must distinguish:

self-asserted;
source-connected;
organization-issued;
peer-reviewed;
independently reviewed;
cryptographically signed;
audited under a named standard.

These labels are not a linear ladder. A cryptographically signed self-assertion may still be weak evidence.

Privacy controls

The holder or authorized organization should be able to:

choose public and private views;
preview the exact presentation;
set audience and expiry;
hide raw evidence where a derived credential is sufficient;
revoke optional sharing links;
see presentation history where practical;
export credentials and records;
challenge inaccurate claims;
separate legal identity from public pseudonym.

ANUKA must not create a default public dossier from data originally collected for private work administration.

Company-controlled metrics

For public traction and quality claims, a company chooses what to publish, but it cannot alter the verification meaning.

A company may choose:

which metric;
time range;
absolute value or trend;
update frequency;
public, partner, or investor audience.

It may not label a manually entered number as source-connected or independently verified.

Disputes and corrections

A subject must be able to dispute a claim or its interpretation.

The system should preserve:

disputed claim;
dispute reason;
supporting evidence;
issuer response;
correction or rejection;
review authority;
timestamps;
appeal state.

A correction should not silently erase the existence of a materially relied-upon prior claim.

Passport rendering

Every human-readable passport card should show:

subject;
view purpose;
issuer or data source;
verification level;
last updated date;
status;
important limitations;
link to machine-readable presentation;
report or dispute control.

Visual confidence indicators must not outrun the underlying evidence.

API rules

Passport APIs must:

require audience and purpose for restricted views;
return schema version;
identify source and status for every claim;
avoid returning undisclosed claims through alternate endpoints;
prevent enumeration of private passports;
log material presentations;
use short-lived URLs or tokens for restricted access;
support revocation and expiry;
make caching policy explicit.

Legal and decision boundaries

A Passport used for employment, credit, housing, insurance, financing, or other regulated eligibility decisions may trigger laws beyond ordinary profile sharing.

ANUKA must not assume that participant consent alone removes obligations under the Fair Credit Reporting Act, anti-discrimination law, privacy law, or state and local rules.

The network should initially position participant passports as participant-controlled portfolios and contribution credentials, not third-party background reports sold for adverse employment decisions.

Prohibited passport patterns

ANUKA must not:

create one universal public passport view;
publish legal identity by default;
call a passport government-issued;
merge all reputation into one score;
hide expired, revoked, or disputed status;
imply an issuer is independent when it is affiliated;
expose raw customer or employer data without authorization;
allow a company to relabel self-reported metrics as verified;
make sensitive credentials permanently public;
require an ANUKA-hosted wallet as the only export path.

MVP acceptance criteria

The first Passport release is ready when:

participant, company, product, traction, and agent passport types are distinct;
each passport supports at least public and permissioned views;
every claim shows source, status, scope, and freshness;
the holder previews restricted presentations;
public metrics require company authorization;
credentials can expire, revoke, suspend, supersede, and dispute;
passport export is available in documented JSON;
the UI never uses a generic verified badge without explanation;
passport links can expire and be revoked;
employment or investor use is clearly labeled as requiring separate legal and decision policy.

Sources

Verification record

Sources opened and checked: 2 August 2026
OpenID4VP Final: July 2025
OpenID4VCI Final: September 2025
W3C VC and status baseline: Recommendations dated 15 May 2025
Passport protocol status: Draft
Employment, financial, identity-proofing, and privacy counsel required before regulated use: Yes