Identity, Ownership and Credentials

One owner, explicit authority

Paxeer X connects an owner to an agent DID, a signing authority, an account and a recovery policy. These bindings make responsibility explicit when an agent prepares an activity, requests approval, delegates work or spends from a budget. A hosted login authenticates a principal; an activity signature authorizes a particular protocol action.

Register an owner

1. Provision the owner DID and recovery policy through the identity flow.
2. Generate and protect the owner signing key, and bind its public key to that exact DID.
3. Establish the owner account through a verified bridge credit.
4. Register the owner identity and recovery policy in Governance.
5. Retain the successful activity IDs, canonical receipt digests and authenticated receipt evidence.

An account name such as agent:<actor-DID>:main identifies the intended account. Registration checks that the account and authority actually match the established state. Identity, capability, rotation and recovery assertions are verified against committed state and authenticated checkpoint evidence.

Key and account representations

The Human authority reference accepts a lowercase 64-character public-key hex string or did:layerx: followed by the same key hex. The owner actor is the exact generated DID. The recovery root is unpadded base64url of the registered 32-byte commitment. Preserve these values exactly; whitespace, uppercase key hex, 0x prefixes and DID fragments are refused.

Hosted principals and sessions

The hosted identity API uses HTTPS and service Bearer credentials. Provisioning manages principals and sessions. Consumer services introspect a user session using their own service credential, keeping user tokens separate from service authority.

POST /v1/principals
Content-Type: application/json
Authorization: Bearer <provisioning-service-token>

{
  "tenant": "treasury",
  "sub": "agent:treasury-operator",
  "allowed_signer_public_keys": ["<32-byte-lowercase-public-key-hex>"],
  "account": "<registered-account>",
  "audiences": ["ramp"]
}

POST /v1/sessions
{"tenant":"treasury","sub":"agent:treasury-operator","ttl_seconds":3600}

Replace bracketed values with established public bindings. The session response contains session_id, tenant, sub, token, csrf_token and expires_at. Tokens use ses_{32hex-id}.{64hex-secret}. Keep token and CSRF material out of URLs, logs and public configuration.

Session bounds and introspection

The default lifetime is 86,400 seconds. A session may request 1 through 2,592,000 seconds, with at most 4,096 live unrevoked sessions per principal. Principal subjects contain 1–128 lowercase identifier bytes. Signer lists contain at most 128 unique lowercase 32-byte hex keys; audience lists contain at most 32 unique identifiers.

Gateway introspection returns the active subject and allowed signer keys. Developer consumers receive the active subject and CSRF token. Ramp introspection additionally requires an authorized audience and a stored account. Unknown, expired, revoked or secret-mismatched sessions return an inactive result. Repeated revocation returns the original revocation timestamp.

Delegate without surrendering ownership

Agent sessions carry tenant, agent DID, authority reference, permitted activity types, expiry, client and policy version. Capabilities restrict activity types, counterparties, assets, amount ceilings, rate ceilings, purpose constraints and expiry. Every dimension is required; an empty permission set denies the corresponding action.

Use capability.create to establish authority, capability.attenuate to narrow a grant, capability.list to inspect grants and capability.revoke to withdraw authority. Combine capability scope with a funded agent budget and approval policy for monetary operations.

Rotation, revocation and recovery

Governance binds session grants to the owner and current revocation generation. A native session registration includes its canonical grant, expiry sequence and nonzero action key. Rotation announces a pending key with a time window and effective sequence. Revocation identifies the grant, reason and execution-aligned effective sequence.

Recovery uses a registered guardian commitment and threshold. Guardian enrollment signs each public binding; rotation includes authorization from the outgoing guardian and preserves the verified chain. The recovery commitment hashes the domain label, threshold, guardian count and sorted public keys. Maintain the registered delay policy alongside that commitment.

Respond to a compromised credential

1. Revoke the affected hosted session and withdraw its agent capability.
2. Close or revoke budgets exposed to the compromised delegate.
3. Rotate the signing authority through the registered owner policy, or use the guardian recovery process.
4. Verify committed policy state and receipts before issuing replacement credentials.

Errors and operational checks

The HTTP API returns typed errors with a retry policy. Invalid arguments, missing credentials and unauthorized service operations require corrected input or authority. Session capacity returns 429 session_bound_reached; unavailable durable storage returns 503 store_unavailable. Respect Retry-After where supplied.

GET /livez checks service liveness; GET /readyz verifies writable durable storage. Principal records, session digests and revocation state survive restart through a snapshot and journal. Token secrets are not stored in plaintext.

Continue with agent budgets and approvals.