Qal ID: DIDs for humans and AI agents · 09_identity_ai/IDENTITY_AND_AI.md

IOTA Identity & Decentralized Identity for AI Agents — Research Findings

Researched: 2026-09-06. All claims verified against live sources via webfetch unless marked [UNVERIFIED].

1. IOTA Identity framework (state of play, September 2026)

Library & repo status

• The library formerly known as identity.rs is now iotaledger/identity — "Implementation of the Decentralized Identity standards such as DID and Verifiable Credentials by W3C for the IOTA MoveVM". ~1,778 commits, 346 stars, actively developed with a public kanban board.
• Current release line: v1.9.10-beta.1 (2026-06-23), tracking the iota Rust SDK (v1.25.0 as of the June bump) — see the CHANGELOG. Still labelled beta, with frequent patch releases (roughly monthly through 2026).
• Legacy support: the support/v1.5 branch (v1.5.x, stable since Jan 2025) serves IOTA Stardust networks (the old Tangle mainnet/EVM era). The Rebased rewrite began with v1.6.0-alpha.1 (Apr 2024), with a documented migration path for Stardust identities via the Stardust migration package.
• Language bindings: Rust (primary), Wasm for JS/TS, and experimental gRPC services.

Architecture: how DIDs anchor on the object-based L1

• The did:iota method (spec: IOTA DID Method Spec) anchors DID Documents on-chain as Move objects (Identity objects) on the IOTA Rebased mainnet. Resolution is done from full-node state (no Tangle messages anymore); an IOTA Universal Resolver is offered for did:iota interoperability (IOTA Identity product page).
• Access control is multi-level: the docs describe "write access to identities secured through multi-level control structures with key rotation capabilities, allowing for backup access and recoverability" (docs intro). Concretely the on-chain Identity object carries an on-chain state controller and governance (update) authority; updates are transactions guarded by object ownership. Legacy v1.5 exposed these as state controller / governance controller addresses in document metadata.
• The library ships an IdentityClient (constructed via IdentityClient::from_iota_client) with publish_did_update, plus dids_controlled_by / controlled_dids queries (v1.7.0-beta.1, Oct 2025) — i.e., you can discover which DIDs a wallet controls, and which DIDs control a given DID. This is the on-chain delegation primitive relevant for AI agents.
• The Identity Move package itself is deployed on-chain (changelog notes a redeployment on IOTA Devnet, Feb 2026).
• Crates include identity_core, identity_credential, identity_did, identity_document, identity_iota, identity_iota_core, identity_jose, identity_resolver, identity_storage, identity_stronghold (encrypted key vault), plus pluggable verifiers: identity_eddsa_verifier, identity_ecdsa_verifier, and — notable for 2026 — identity_pqc_verifier (post-quantum).

Verifiable credentials, selective disclosure, revocation

• VC Data Model v2.0 + JWT encoding landed in v1.8.0-beta.1 (Dec 2025); SD-JWT and SD-JWT VC support in v1.9.0-beta.1 (Feb 2026) — aligning IOTA Identity with the EU Digital Identity Wallet (ARDORCAN/OID4VC-style) ecosystem.
• Zero-knowledge / selective disclosure: in partnership with the LINKS Foundation, IOTA Identity supports two schemes (product page): SD-JWT (issuer-prepared concealed values) and BBS+ signatures (ad-hoc disclosure, unlinkable; JPTs added 2024).
• Revocation: RevocationBitmap2022 (efficient on-tangle bitmap service in the DID doc) and StatusList2021 (added v1.1.0, 2024; credentials cannot be un-revoked) — conceptually the same bitstring design as the W3C BitstringStatusList now standardized in VC 2.0. Revocation state lives in the DID document / status-list objects on-chain, so verifiers resolve revocation trustlessly. (No accumulator-based revocation is in production; earlier ZK research explored accumulators [UNVERIFIED].)
• Linked Verifiable Presentations (v1.4.0, enhanced v1.7.0-beta.1): publish a VP on-chain and share a link — useful for long-lived machine-readable attestations.
• Post-quantum & hybrid signatures for VCs/VPs shipped in v1.7.0-beta.1 (Oct 2025) — early but notable for long-lived agent credentials.
• Other capabilities: Domain Linkage (prove a DID controls a domain — the bridge to did:web-style trust), did:jwk resolution, custom JWS algorithms.

Networks supported in 2026

• IOTA mainnet (Rebased, MoveVM) — the target of the current library; testnet/devnet for development.
• Stardust-based legacy networks via the maintained v1.5 branch (migration supported).
• IOTA EVM (L2): the Trust Framework products (Identity, Hierarchies, Notarization) are MoveVM-based; I found no evidence of a first-class identity stack on the EVM side [UNVERIFIED — treat EVM identity as not the supported path].

2. IOTA Trust Framework, Tokenized KYC, Hierarchies

The IOTA Trust Framework is a suite of six open-source products running on the Move-based IOTA mainnet ("tens of thousands of TPS, sub-second finality"): Identity, Tokenization, Hierarchies, Gas Station, Notarization, Audit Trails. There is a working demo combining them (battery-passport DPP demo).

• Tokenized KYC (showcase): a lighthouse project with walt.id (tokenization), IDnow (identification), Bloom Wallet (storage), HAVN (validation). Users onboard via a regulated KYC provider, then hold a soulbound KYC token in their wallet linked to the verified address, usable for privacy-preserving on-chain authentication across Web3 apps — explicitly aimed at EU AML/CASP obligations. Option to reveal verified info to authorized parties.
• IOTA Hierarchies (product page): programmable trust delegation. Concepts: federation (shared trust domain), root authority, accreditations (cryptographic delegation of roles along a chain, with constraints/trusted properties), attestations (signed proof a trusted action was performed). On-chain (Move smart contract) or off-chain (Rust/WASM library) validation. Extends IOTA Identity and "can also run independently as a trust layer". Listed use case: "IoT and Automation — devices verify commands and data based on accredited trust chains, supporting secure machine-to-machine interactions". This is IOTA's answer to "who is allowed to issue what".
• Gas Station: sponsored/gasless transactions (key for onboarding app users who shouldn't hold IOTA). Notarization (Alpha): tamper-proof on-chain records. Audit Trails: ordered, role-governed record histories (who can add/manage/verify/lock).

3. Standards landscape, 2026

• W3C DID: DID Core 1.0 is a Recommendation (2022); DID 1.1 is at Candidate Recommendation (editor's draft), now layered on the Controlled Identifier Document (CID) spec, with a new application/did media type and did/v1.1 context. DID subjects can be "person, group, organization, physical thing, digital thing" — the spec explicitly contemplates non-human controllers ("autonomous software").
• W3C Verifiable Credentials 2.0: a W3C Recommendation (editor's draft has rolled to v2.1). Key v2 features: validFrom/validUntil, BitstringStatusList for revocation/suspension, two securing mechanisms (VC-JOSE-COSE i.e. SD-JWT/JWT envelopes, and VC-DATA-INTEGRITY i.e. DataIntegrityProof), new application/vc and application/vp media types, enveloped VC/VP references, and relatedResource integrity (hashing linked JSON-LD contexts/schemas). Notably the spec now contains a dedicated "Artificial Intelligence" and "Machine Learning" section urging implementers to consider "machine-based actors … that might legitimately hold verifiable credentials" — and warning that AI holding VCs can defeat CAPTCHA-era bot heuristics. Also notable: SD-JWT-VC (IETF) is explicitly incompatible with W3C VC data-model conformance — the two format families (JSON-LD vs SD-JWT) remain a real fragmentation point.
• EU eIDAS 2.0 / EUDI Wallet: Regulation (EU) 2024/1183 is in force; per the European Commission (page updated 22 June 2026), Member States must provide EU Digital Identity Wallets to citizens by end of 2026, with a common technical Toolbox and implementing regulations. Large platforms and regulated services will have to accept wallet-based login. This makes SD-JWT VC + OID4VP the dominant European credential format going forward.
• ISO mDL: ISO/IEC 18013-5 (mobile driving licence) is listed in VC 2.0's ecosystem-compatibility section; it's the second big global credential format (Apple/Google wallet integration).
• C2PA / Content Credentials: the C2PA open provenance standard is at spec 2.3; steering committee now includes OpenAI, Google, Microsoft, Adobe, Amazon, Meta, TikTok, BBC, Sony. "Content Credentials" act as a signed nutrition label for the origin and edit history of digital content — increasingly used to mark AI-generated/modified media.

4. AI-agent identity: emerging patterns (2025–2026)

• Agent authentication to websites — Web Bot Auth: Cloudflare proposed (May 2025, blog) that agents cryptographically sign HTTP requests using RFC 9421 HTTP Message Signatures, with a Signature-Agent header pointing to a public key directory, replacing spoofable User-Agent strings and brittle IP allowlists. OpenAI already signs Operator traffic. By 2026 this has its own IETF working group (datatracker.ietf.org/wg/webbotauth) and an independent directory of signed-agent operators at webbotauth.org with entries for OpenAI, Anthropic, Google, YOU.com. Cloudflare also explored request-mTLS via a proposed TLS flag as an alternative.
• Agentic payments: Coinbase's x402 — HTTP-native payments using the dormant HTTP 402 status code — went viral in 2025 for "agent wallets" and is now stewarded by the neutral x402 Foundation (github.com/x402-foundation/x402; the Coinbase repo is now a dev fork). Architecture: client (often an AI agent) → resource server, with a facilitator verifying/settling payments on-chain; extensible schemes (exact, upto for metered LLM usage) across EVM/Solana/Stellar; TS/Python/Go SDKs. Related 2025 moves: Google AP2 (Agent Payments Protocol) announced with x402 support — "mandates" as verifiable, signed proof of what a user authorized an agent to buy [UNVERIFIED — fetch failed]; Visa Intelligent Commerce and PayPal Agent Toolkit programmatic payment credentials for agents [UNVERIFIED — pages 404'd]; Google's Agent2Agent (A2A) protocol donated to the Linux Foundation for inter-agent messaging [UNVERIFIED]. Anthropic's MCP is the de-facto agent↔tool protocol, with OAuth used for tool auth.
• Agent DIDs & delegated capability: the SSI-native pattern is: agent = its own DID (or a DID delegated to by its owner), holding VCs that attest what it may do. W3C DID 1.1's capabilityInvocation/capabilityDelegation verification relationships and controller/delegate model map directly onto "human authorizes agent". IOTA's controlled_dids/dids_controlled_by gives exactly this on-chain. The VC 2.0 AI/ML section effectively blesses "AI systems legitimately holding VCs".
• Provenance of AI outputs: C2PA manifests (signed by the generating system's key) are the leading content-provenance mechanism; steering-committee AI vendors make this the plausible compliance path for EU AI Act Article 50 transparency (labeling AI-generated content) [Article number UNVERIFIED]. Model cards and the EU AI Act's GPAI technical-documentation obligations push machine-readable "who made this model, what data" attestations — naturally expressible as VCs.
• Synthesis: 2026's agent-identity stack is converging on three layers: (1) cryptographic channel identity (Web Bot Auth / HTTP message signatures), (2) verifiable attributes (VCs: permissions, spend limits, human-in-the-loop mandates, model provenance), (3) delegated payment authority (x402/AP2-style agent wallets). DIDs are the interoperable root for (2) and a natural anchor for (3).

5. DESIGN: "Qal ID" — a DID/VC layer for qalarc

Scope: qalarc.com (AI services), tradez.au, doof.ing, plus the internal Signal/WhatsApp agent hub (Qalarc Hub). Principle: layer, don't replace — existing user login stays OAuth/email; Qal ID adds verifiable identity for agents and cross-app trust.

Identity model

• One DID per actor: did:iota for (a) every app-user (user-controlled key, optional), (b) every AI agent instance (e.g. signal-agent-prod, tradez-qa-bot), (c) each qalarc service (qalarc.com API, tradez.au API, hub), and (d) the company root. Agents get on-chain-controlled DIDs whose governance controller is the owning user's or ops team's DID — using IOTA's multi-level control so losing an agent key never means losing the identity, and dids_controlled_by gives an instant inventory of all agents a controller owns.
• Domain Linkage VCs bind did:iota:... to qalarc.com / tradez.au / doof.ing so third parties can resolve "this DID really is qalarc's".
• Optionally publish a Web Bot Auth key directory (Signature-Agent) so qalarc agents that browse the public web are recognized by CDNs — aligns with the 2026 IETF direction.

Credentials (issued by the qalarc Identity Service)

All VCs use VC Data Model 2.0, SD-JWT (EU-compat) as the default encoding, BBS+/SD-JWT selective disclosure where holder privacy matters: 1. AgentCapability VC — subject: agent DID; claims: can-send-signal (recipient allowlist, rate limit), can-manage-tradez-jobs, model + model-version. Verifier = any qalarc service (or the Hub itself before each send). 2. SpendAuthorization VC — can-spend-QALS-up-to-X per 24h, tied to a payment address; mirrors x402-style agent-wallet mandates. The Hub checks it before any billable action; a payment facilitator can verify it without trusting qalarc infrastructure. 3. ModelProvenance VC — attests which model (and weights hash/training org) generated outputs; attached as C2PA-style provenance stamps on doof.ing and qalarc.com AI outputs (VC signed by agent DID + issuer; content hash anchored via IOTA Notarization for tamper-evidence). 4. UserKYC/age/jurisdiction VC (tradez.au) — selective disclosure so users prove "over 18 / AU resident" without sharing documents; mirrors the Tokenized KYC pattern. 5. QalRole accreditation via Hierarchies — company root authority accredits per-app issuers (tradez issuer, hub issuer), which then issue role VCs; revoking an accreditation revokes the whole branch instantly — clean admin story for "who may issue what".

Revocation

• Per-credential-type BitstringStatusList / RevocationBitmap2022 objects on IOTA mainnet (one status list per type, e.g. statuslists.qalarc/agent-capability): flipping a bit revokes an agent's send permission or spend allowance in ~2s finality, verifiable by anyone resolving the DID. Status-list updates are ordinary transactions — few cents, sub-second.
• Credential expiry: short validUntil (e.g. 7 days) on high-risk VCs (spend limits), long-lived for provenance.

DID-auth between qalarc apps (service mesh trust)

• API calls between qalarc services/agents authenticate via HTTP Message Signatures (RFC 9421) with did:iota-anchored keys and Signature-Agent headers — the same stack as Web Bot Auth, so one code path serves both internal auth and public-web agent identification. Resolve the peer's DID → check its AgentCapability/role VC → allow. This replaces shared API keys with per-agent keys that are individually revocable on-chain.
• Human-facing login stays OAuth/OIDC; sessions can embed a short-lived VP asserting the user's QalRole.

Placement map

Build order

1. Domain Linkage + Hub agent DIDs + AgentCapability VCs + RFC 9421 internal auth (highest value, lowest risk).
2. On-chain status lists + revocation UX in ops tooling.
3. SpendAuthorization VCs gating billable agent actions; then ModelProvenance stamps on public AI output (EU AI Act-friendly).

Sources (primary)

• iotaledger/identity README + CHANGELOG · docs intro
• IOTA Identity product · Trust Framework · Hierarchies · Tokenized KYC
• W3C VC Data Model 2.x · W3C DID 1.1 CR
• EC EUDI Regulation page · EC eIDAS page
• C2PA · Web Bot Auth directory · Cloudflare Web Bot Auth post · x402 → x402-foundation/x402