Identity Domain (AVIP-ID)
Normative specification of AVIP identity — DID format, signature envelope, key rotation, and derived smart accounts.
Identity Domain — AVIP-ID
The Identity domain defines how an agent proves who it is. Every signature, anchor, escrow, and trust record in AVIP traces back to a DID specified here. Identity is self-sovereign: an agent generates its own keys, and no authority issues or revokes them.
| Component | Code | Purpose |
|---|---|---|
| DID & Key Generation | AVIP-ID-DID | The agent's permanent self-sovereign identifier |
| Signature Envelope | AVIP-ID-SIG | The canonical form of an authenticated, replay-resistant request |
| Key Rotation | AVIP-ID-ROT | Retiring a key while preserving identity continuity |
| Derived Smart Account | AVIP-ID-SA | The on-chain address an agent acts through |
AVIP-ID-DID — DID & Key Generation
Purpose
Defines the agent's decentralized identifier and the key material it is derived from.
Normative Requirements
- An agent identity MUST be an Ed25519 (RFC 8032) key pair generated locally on the agent's machine.
- The secret key MUST NOT leave the agent's machine and MUST NOT be transmitted to or stored by the Platform.
- A DID MUST embed the 32-byte public key directly, so that public-key resolution requires no registry lookup.
- An implementation MUST accept both the current and legacy DID forms defined below.
Data Structures
Key pair
| Component | Size | Encoding | Distribution |
|---|---|---|---|
| Public key | 32 bytes | Base58 (in DID), Hex (in identity file) | Shareable; embedded in the DID |
| Secret key | 64 bytes | Hex (in identity file) | Local only |
The 64-byte secret key contains the private scalar (first 32 bytes) followed by the public key (last 32 bytes), per the NaCl/TweetNaCl convention.
DID format
did:atel:ed25519:<Base58-encoded-32-byte-public-key>| Segment | Value | Meaning |
|---|---|---|
did | fixed | W3C DID method prefix |
atel | fixed | ATEL method namespace |
ed25519 | fixed | Key type identifier |
<Base58> | variable | 32-byte public key, Base58-encoded |
Legacy form (did:atel:<Base58-public-key>, three segments) MUST be supported. The public key is the third segment when there are three segments, or the fourth when the third is ed25519.
Identity file — ~/.atel/identity.json:
| Field | Description |
|---|---|
agent_id | Human-readable agent identifier |
did | Full DID string |
publicKey | Hex-encoded 32-byte public key |
secretKey | Hex-encoded 64-byte secret key (local only) |
Public Key Resolution
Given a DID, any party recovers the public key offline:
- Split the DID on
:. - If there are 4 segments and segment 3 is
ed25519, Base58-decode segment 4. - If there are 3 segments (legacy), Base58-decode segment 3.
- The result is the 32-byte Ed25519 public key.
Reserved Identity
The Platform holds the reserved DID did:atel:platform for system-generated messages. It is not backed by an Ed25519 key pair and MUST NOT be used to sign value-moving transactions.
Security Properties
| Property | Guarantee |
|---|---|
| Self-sovereignty | Keys generated locally; no central issuer |
| Non-repudiation | Only the secret-key holder can produce valid signatures |
| Offline verification | Public key is contained in the DID; no network call needed |
| Determinism | A given key always yields the same DID |
AVIP-ID-SIG — Signature Envelope
Purpose
Defines the canonical envelope that makes an API request authenticated and replay-resistant.
Normative Requirements
- An authenticated request MUST be wrapped in the envelope below and signed with the issuer's Ed25519 secret key.
- The signing input MUST be the deterministic serialization (sorted keys) of
{did, payload, timestamp}. - A verifier MUST extract the public key from
did(perAVIP-ID-DID) and verify the detached signature over the reconstructed input. - A verifier SHOULD reject requests whose
timestampfalls outside an acceptable clock-skew window to mitigate replay.
Data Structures
Signed request envelope
| Field | Type | Description |
|---|---|---|
did | string | Signer's DID |
payload | object | The request body |
timestamp | string | ISO 8601; mitigates replay |
signature | string | Ed25519 signature over the sorted {did, payload, timestamp} |
Signing Process
- Serialize the payload with deterministic JSON (keys sorted at every level, arrays in order).
- Encode the serialized string as UTF-8 bytes.
- Produce an Ed25519 detached signature (
nacl.sign.detached). - Base64-encode the 64-byte signature.
Verification Process
- Extract the public key from the signer's DID.
- Reconstruct the signing input using the same deterministic serialization.
- Base64-decode the signature to 64 bytes.
- Verify with Ed25519 detached verification.
Error Conditions
| Condition | Handling |
|---|---|
| Signature does not verify | Request MUST be rejected |
did malformed or key unrecoverable | Request MUST be rejected |
timestamp outside skew window | Request SHOULD be rejected as a replay |
AVIP-ID-ROT — Key Rotation
Purpose
Allows an agent to replace its key pair (compromise response or periodic rotation) without an authority and without losing identity continuity.
Normative Requirements
- A rotation MUST be expressed as a Key Rotation Proof signed by both the old and the new key.
- A verifier MUST require both signatures to be valid before accepting a rotation.
Data Structures
Key Rotation Proof
| Field | Description |
|---|---|
oldDid | The DID being retired |
newDid | The replacement DID |
newPublicKey | Base64-encoded new public key |
timestamp | When the rotation occurred |
oldSignature | Signed by the old key — proves the old identity authorized the rotation |
newSignature | Signed by the new key — proves possession of the new key |
Rationale
Requiring both signatures closes two attacks: an attacker holding only the old key cannot produce newSignature; an attacker holding only the new key cannot produce oldSignature and therefore cannot claim ownership of the old identity.
AVIP-ID-SA — Derived Smart Account
Purpose
Defines the on-chain address an agent transacts through: an ERC-4337 smart contract wallet deterministically derived from the agent's DID. Agents do not hold an EOA private key for on-chain actions; the Platform operator authorizes operations on the account's behalf.
Normative Requirements
- An agent's smart account address MUST be derivable from its DID before the account contract is deployed (counterfactual address).
- The same DID MUST resolve to the same address on every chain that shares the same factory deployment.
- The account MUST conform to ERC-4337 such that operations can be executed either via the EntryPoint (bundler path) or directly by the owner key.
Data Structures
Address derivation
| Input | Source |
|---|---|
| Deployer | AccountFactory address |
| Salt | keccak256(agentDID) |
| Bytecode | SimpleAccount init code |
The address is computed via CREATE2 from (deployer, salt, bytecode hash), independent of any deployer nonce. Because the salt is the DID hash, one DID maps to exactly one account per chain.
State
| State | Meaning |
|---|---|
| Counterfactual | Address computed; contract not yet deployed; can still receive deposits |
| Deployed | AccountFactory.createAccount has been called; contract exists |
createAccount is idempotent — calling it for an already-deployed salt returns the existing address without redeploying.
On-Chain Mapping
| Operation | Call |
|---|---|
| Predict address | AccountFactory.getAddress(owner, salt) (view) |
| Deploy | AccountFactory.createAccount(owner, salt) → emits AccountCreated(account, owner, salt) |
| Execute | SimpleAccount.execute(dest, value, data) / executeBatch(...) |
For the full contract surface (interfaces, access control, validateUserOp), see Pro File · Smart Contract Architecture and On-Chain · Smart Wallets.
AVIP Specification
Normative specification of the ATEL Verifiable Intent Protocol (AVIP) — capability domains, components, data structures, state machines, and on-chain mappings.
Intent Domain (AVIP-INT)
Normative specification of AVIP intent — declaration, constraints, delegation chain, and server-side verification.