Identity and Account Model

Draft 0.1 — 2 August 2026
This is an architecture and product baseline. It is not a government identity program, legal identity opinion, KYC policy, or promise that one identity method is sufficient for every transaction.

Objective

ANUKA needs enough identity to create accountable work, portable reputation, payments, permissions, and trustworthy company records without forcing every participant into maximum disclosure.

The governing rule is:

Use the minimum identity assurance required by the risk of the action.

Identity must not become one binary flag called verified. ANUKA separates:

account access;
authentication strength;
control of an identifier or domain;
person or organization identity proofing;
role authority;
contribution history;
reputation evidence;
transaction-specific compliance.

A participant can be strongly authenticated but pseudonymous. A legal identity can be known without proving competence. A company domain can be controlled without proving that the controller is authorized to sell equity. These facts must remain distinct.

Identity subjects

ANUKA recognizes several subject types.

Person

A natural person who participates directly or through authorized agents.

Organization

A legal entity, informal team, community, fund, university, public institution, or other coordinated body.

The exact legal form must be stated when it matters.

Product

A software product, service, protocol, brand, project, or business unit with its own identity and evidence history.

A product is not automatically a legal person.

AI agent

A software actor operating for a declared principal under scoped authority.

An agent does not receive independent moral or legal authority merely because it has a persistent identifier.

Opportunity or contribution

A task, bounty, proposal, experiment, release, review, payment, or result may be an independently addressable subject for provenance and attestations.

The five identity layers

Layer 1 — Account

The account is the technical container used to access ANUKA services.

It may include:

internal account identifier;
login methods;
recovery methods;
device and session records;
notification preferences;
accepted terms;
memberships and roles.

An account is not itself proof of a unique human or legal identity.

Layer 2 — Identifier

An identifier names a subject in a defined namespace.

Examples:

ANUKA participant ID;
organization ID;
product ID;
DID;
verified email address;
GitHub account;
domain name;
blockchain address;
tax or registry identifier held privately.

Identifiers must state their method and controller. ANUKA must not imply that all DIDs, wallets, email addresses, or social accounts provide equal assurance.

Layer 3 — Authentication

Authentication establishes that the current claimant controls an enrolled authenticator or session.

Examples:

passkey;
hardware security key;
authenticator application;
OAuth or OpenID Connect login;
recovery code;
signed wallet challenge.

Authentication answers:

Is this the same account controller who previously enrolled this method?

It does not necessarily answer:

Who is this person in the legal world?

Layer 4 — Proofing and authority

Identity proofing connects a subject to evidence about a real person or organization. Authority verification establishes that the person may act for an organization, product, account, or transaction.

Examples:

organization-domain control;
corporate registry evidence;
officer or administrator authorization;
payment-account ownership check;
government identity verification through a qualified provider;
signed board or founder delegation;
repository administrator confirmation.

Proofing and authority must be scoped. Control of example.com does not prove authority over every company using that brand.

Layer 5 — Reputation and capability

Reputation records what a subject has done, under what conditions, and with what evidence.

It is not identity proofing. It is built from:

accepted contributions;
reviews;
measurable outcomes;
disputes and corrections;
role history;
credentials and endorsements;
verified project relationships.

Assurance profiles

ANUKA should use named, purpose-specific profiles rather than a generic verified badge.

A0 — Local or anonymous interaction

Suitable for:

viewing public Backstage data;
local simulations;
reading documentation;
submitting feedback where anonymous feedback is enabled.

No persistent identity claim is required.

A1 — Account-controlled participant

Evidence may include:

verified email or supported social login;
accepted terms;
basic anti-abuse checks;
account recovery configuration.

Suitable for:

voting where low assurance is acceptable;
saving opportunities;
public comments under project policy;
low-risk unpaid participation.

A2 — Strongly authenticated participant

Requirements may include:

phishing-resistant authentication preferred;
recent authentication for sensitive actions;
device or session risk checks;
verified payout destination where payment is involved.

Suitable for:

paid bounties;
access to permissioned evidence;
reviewer or qualifier roles;
security-sensitive project participation.

A3 — Proofed person or organization

Requirements are selected according to risk and may include external proofing, organization records, domain control, or authorized representative evidence.

Suitable for:

high-value payments;
investor or diligence access;
issuing high-impact credentials;
company ownership claims;
regulated workflows where required.

A4 — Qualified role

A subject has not only been proofed but is authorized or licensed for a defined role.

Examples:

independent auditor;
attorney;
licensed financial professional;
accredited testing body;
authorized company officer.

ANUKA must name the qualification and issuer. A4 is never a universal status.

Risk-based step-up

The same participant can operate at different assurance levels for different actions.

Examples:

reading a public roadmap requires A0;
voting may require A1;
accepting a paid task may require A2 and payout checks;
opening an investor data room may require A2 plus organization approval;
issuing an independent audit credential may require A4.

A high assurance request must explain:

why it is needed;
what evidence is collected;
who receives it;
how long it is retained;
whether an alternative path exists.

Pseudonymity

ANUKA supports accountable pseudonymity where the action permits it.

A pseudonymous participant may:

build contribution history;
receive project-specific credentials;
maintain a public profile without publishing legal identity;
disclose stronger identity only to a payment provider, project, or verifier;
use selective presentations rather than public raw documents.

Pseudonymity must not be marketed as immunity from law, contracts, sanctions, taxes, fraud controls, or project rules.

Uniqueness and proof of personhood

ANUKA should not require global proof of personhood for ordinary participation.

When one-person-one-action constraints are needed, the product should choose the least invasive method that fits the risk:

account age and abuse controls;
project membership;
payment instrument uniqueness;
organization-issued eligibility credential;
external proof-of-personhood provider;
human review for high-impact cases.

No provider should become the mandatory identity root of the entire network without an explicit governance decision and exit path.

Organization identity

A resident company or organization profile should separate:

legal name;
public brand;
jurisdiction and registry identifiers;
operating domains;
authorized representatives;
payment and billing entity;
product ownership or license relationships;
ANUKA project IDs;
verification methods and dates;
active disputes or expired claims.

Claiming an organization

A claim process may use:

domain proof;
repository proof;
billing or payment proof;
registry evidence;
authorization from an existing organization administrator;
manual review for exceptions.

The UI must state exactly what was proved. Domain controlled is not the same as legal entity verified.

Multiple organizations and roles

One person may represent several organizations. Authority must be stored per organization and role, not inherited globally.

Sensitive actions require:

current role;
permitted scope;
recent authentication;
organization policy;
optional second approval.

Product identity

Each product receives a stable ANUKA Project ID independent from its current domain, repository, owner, or steward.

Product identity records may include:

canonical name and aliases;
current and historical domains;
current operator;
legal owner where declared and verified;
repositories and deployment environments;
resident status;
presence-manifest keys;
active stewards;
evidence and credential issuers;
successor or superseded product IDs.

A rebrand should not erase history. A sale or stewardship change must create a dated relationship event rather than silently rewriting ownership history.

AI-agent identity

Every agent action must resolve to:

agent identifier;
agent software and version;
accountable principal;
organization or project context;
granted scopes;
credential or token used;
action timestamp;
tool calls and result status;
human approval requirement where applicable.

Agent classes

Assistant — proposes or drafts; cannot execute privileged actions.
Operator — performs bounded reversible actions.
Reviewer — evaluates evidence under a declared method.
Automation — executes deterministic triggers and workflows.
Autonomous experiment agent — may allocate traffic or budget only within explicit guardrails.

Agent reputation must not be detached from its principal, model version, tool configuration, and operating policy.

Account linking

A participant may link multiple identifiers and accounts.

Linking requires proof of control for each identifier and must record:

linking method;
timestamp;
scope;
whether the link is public;
revocation path;
conflicts or prior ownership.

ANUKA should avoid publishing a global map connecting pseudonyms unless the participant deliberately presents that relationship.

Authentication baseline

The production baseline should prefer:

passkeys or phishing-resistant authenticators;
secure OAuth/OIDC implementations for external identity providers;
short-lived sessions and rotating tokens;
step-up authentication for sensitive actions;
server-side authorization on every protected operation;
recovery codes and multi-method recovery;
session visibility and revocation;
rate limiting and anomaly detection.

SMS should not be the strongest available recovery or authentication factor for high-risk roles.

Authorization model

Identity does not imply permission.

Authorization should evaluate:

subject;
organization and product context;
role;
action;
resource;
assurance profile;
consent;
policy version;
time and environment;
budget or risk limit;
required approvals.

A future implementation may adopt a policy decision and enforcement pattern compatible with standards such as the OpenID AuthZEN Authorization API, but the first release may use an internal policy engine if the contract remains explicit and replaceable.

Recovery

Account and key recovery is part of identity, not an afterthought.

Recovery must distinguish:

account login recovery;
authenticator replacement;
cryptographic-key rotation;
organization administrator recovery;
product ownership dispute;
agent credential revocation;
recovery from a compromised issuer.

High-impact recovery should require stronger evidence and delay than ordinary password reset.

Identity events

All material changes should create immutable or append-only audit events:

account created;
authentication method enrolled or removed;
identifier linked or unlinked;
proofing completed, expired, or revoked;
organization role granted or removed;
product claimed or transferred;
agent registered or disabled;
recovery initiated and completed;
credential issued, suspended, revoked, or superseded.

Public visibility is separate from audit retention.

Data model sketch

{
  "subjectId": "anuka:person:01J...",
  "subjectType": "person",
  "identifiers": [
    {
      "type": "github",
      "value": "sergous",
      "verifiedAt": "2026-08-02T00:00:00Z",
      "visibility": "public"
    }
  ],
  "assurance": [
    {
      "profile": "A2",
      "scope": "paid-contributions",
      "issuer": "anuka:service:identity",
      "validUntil": "2027-08-02T00:00:00Z"
    }
  ],
  "roles": [
    {
      "organizationId": "anuka:org:01J...",
      "role": "product-steward",
      "scope": ["roadmap:write", "experiment:propose"],
      "validUntil": "2026-11-01T00:00:00Z"
    }
  ]
}

This example is illustrative. Production schemas require versioning, privacy classification, status, and legal review.

Prohibited identity patterns

ANUKA must not:

call every account a verified human;
expose legal identity by default;
equate wallet ownership with uniqueness or trustworthiness;
treat government ID as evidence of competence;
require one identity provider for the entire network without portability;
let organization-domain control imply securities, banking, or legal authority;
give AI agents unscoped human credentials;
merge pseudonymous identities silently;
permanently lock a participant to a lost cryptographic key;
use identity assurance as a status hierarchy unrelated to the action.

MVP acceptance criteria

The first identity release is ready when:

accounts support secure login and recovery;
participant, organization, product, and agent IDs are distinct;
organization claiming states exactly what was verified;
permissions are organization- and project-scoped;
activeTab extension identity is separated from website identity;
paid work can require step-up authentication and payout checks;
pseudonymous public participation remains possible for low-risk actions;
every agent has a principal and scoped credential;
identity, authentication, authority, and reputation are separate in the schema and UI;
all material identity changes produce audit events.

Sources

Verification record

Sources opened and checked: 2 August 2026
NIST baseline: SP 800-63 Revision 4, final July 2025
Identity architecture status: Draft
Transaction-specific KYC, sanctions, tax, employment, and financial review required: Yes