# **Delegation and Organizational Identity**

A not.bot™ identity that controls valuable assets, signs important documents, or makes binding commitments needs an ownership model strong enough to be safe and operational enough to be useful. These goals pull in opposite directions. The stronger the model (more keys required, more parties involved, more airgaps in the signing chain), the more friction every action carries. The looser the model, the larger the blast radius if a key is compromised.

Delegation closes the gap. A heavily-protected identity can delegate narrow, time-bound, revocable authority to less-protected identities that handle routine operations. The protected identity is used only when it must be. The delegates do the day-to-day work. The protected identity retains the authority to revoke any delegate at any time.

This document covers the delegation infrastructure in `did:julia`: the ownership models that benefit from delegation, the two distinct delegation mechanisms (issuer delegation and credential delegation), mandate credentials for capability cascades through AI agents and other principal-agent relationships, self-attested credentials, and the chain of human accountability that terminates every delegation.

## **Principal authority**

The legal frame that grounds did:julia delegation comes from English common law and the law of agency. A *principal* holds authority. A principal can delegate authority to an *agent*. The agent acts within the scope of the delegation. The principal retains the right to direct, revoke, and replace the agent. The agent owes duties (transparency, good faith, action in the principal's interest) back to the principal.

The State of Wyoming codified this frame for digital identity in 2021. [Wyoming SF0039](https://wyoleg.gov/Legislation/2021/SF0039) defines a personal digital identity as "the intangible digital representation of, by and for a natural person, over which he has principal authority and through which he intentionally communicates or acts." The law assigns the natural person the rights of existence, control, persistence, and consent. It assigns service providers the duties of access, transparency, portability, data minimization, and disclosure.

`did:julia` is the principal authority frame implemented in cryptography. Every action taken under a not.bot identity traces back through a chain of delegations to a principal who authorized the chain and can revoke it. The chain terminates at a human key-holder.

## **Why delegation matters**

Several real-world structures require delegation to function.

**Non-digital powers of attorney.** A person assigns another person the authority to act on their behalf, time-bounded, scope-limited, revocable. The same structure expressed digitally is a delegation.

**Companies as non-actors.** A company does not have hands. Every action a company takes happens through a human acting under the company's authority. The company is a governance structure over its human signers, and every operational action is a delegation from that structure to a specific person carrying it out.

**Human hierarchies.** An organization assigns roles, each role carries authorities, and people occupy roles. A person leaving the organization vacates the authorities the role carried. Delegation expresses both the assignment and the vacation in cryptography.

**AI agents.** A human asks an agent to act on their behalf. The agent acts on the human's authority, within whatever scope the human granted. A multi-agent system extends the chain: a human directs an orchestrator, the orchestrator directs workers, each step narrowing the scope. The verifier at the far end of the chain confirms that the worker's attempted action falls within every authorization in the chain that led to it.

`did:julia` carries all of these structures through the same mechanisms.

## **Ownership models**

Before delegation can happen, an identity needs an ownership model. `did:julia` supports four.

### **Single-sig**

One BLS12-381 key authenticates every operation. This is the default model for personal not.bot identities. The key is secured by the secure element of the user's device.

### **Multi-sig**

M-of-N keys are required to authenticate any operation. N keys exist, often held by N separate parties. M of them must produce a valid signature on the operation. A 3-of-5 multi-sig requires 3 signatures from a set of 5.

Multi-sig suits any identity where no single key-holder should be able to act alone: a joint account, a small partnership, a family identity, a high-value personal identity that the user splits across multiple devices and hardware signers.

### **Multi-class multi-sig**

The multi-sig structure extended one level. X-of-Y *classes*, where each class is an M-of-N multi-sig. To authenticate, X classes must each produce a valid M-of-N signature. A single signer can belong to multiple classes but participates in only one class per transaction.

Julia Social's own corporate DID uses this model. The ownership is "2-of-2: 2-of-3, 1-of-3." To use the identity, 2 of 3 executives must sign AND 1 of 3 airgapped hardware signers must sign. The airgapped signers hold keys that never connect to the internet. They sit in separate, secure locations. No combination of compromised executives can use the identity without the hardware signers, and no combination of compromised hardware signers can use it without the executives.

Multi-class multi-sig is a protocol feature available to any identity. A personal identity that holds substantial assets can adopt it the same way a corporation does: one class of device keys, one class of hardware signers, both required. Today's not.bot app handles only single-sig DIDs, a current limitation of the app, not the protocol.

### **Custodian**

A *custodian* is a separate DID authorized to operate the custodied identity. The custodian uses its own keys, signs operations with them, and the custodied identity acts under that authority. Every action a custodian performs is attributable: the custodied DID's on-chain spend record identifies the commanding custodian DID.

The custodian has three restrictions. A custodian cannot rotate the owner's keys, cannot participate in recovery on behalf of the custodied identity, and cannot extend custodial control to a third identity through the custodied identity. These restrictions protect the principal's ultimate authority over the identity.

The custodian is `did:julia`'s bounded analogue of the [DID controller](https://www.w3.org/TR/did-1.0/#did-controller) defined in W3C DID Core: an external DID authorized to act for the subject. The DID controller of that specification holds open-ended control over the DID document. The custodian operates inside the three fixed restrictions above, so the principal keeps key rotation, recovery, and the power to extend control out of any custodian's reach.

Custodianship covers three families of use cases.

**Personal: power of attorney, conservatorship, guardianship.** A power of attorney allows one person to delegate specified legal rights to another, so that the other to act on the person's behalf. A parent acts as custodian for a child's identity until the child comes of age. An adult child acts as custodian for an elderly parent whose capacity to manage a digital identity has declined. A court-appointed guardian acts as custodian for a person determined unable to manage their own affairs. The legal structure (POA, conservatorship, guardianship) and the cryptographic structure (custodian DID with three restrictions) line up.

**Business: commercial digital asset custody.** An enterprise that prefers not to manage its own cryptographic keys assigns a commercial custodian as the operating DID of its corporate identity. The custodian operates under its own multi-class multi-sig and uses the client's identity to perform actions the client authorizes. The same companies that custody digital assets today will offer custodianship for enterprise digital identities.

**Non-human identities.** A DID can be created with no owner keys at all, controlled only through one or more custodians. This suits devices and physical assets that have no capacity to manage cryptographic keys: a real-estate DID controlled by the title-holder or a piece of equipment whose custodian changes when the equipment changes hands, for example.

## **Issuer delegation**

A Julia Social DID never signs credentials with its own keys. The DID delegates issuance authority to an *issuer key*: a singleton coin on the Chia blockchain, owned by a single BLS12-381 key, configured with a set of constraints that limit what credentials the key can sign.

The constraints are the design of the delegation. Each one limits the delegate's authority.

- **Authorized BLS public key.** The single key permitted to sign credentials under this delegation. If the key is compromised, only this delegation is affected, not the issuing DID.
- **Validity window.** A start time before which the delegation is not active, and an end time after which it expires. The delegate cannot sign credentials outside this window.
- **Max expiration.** A latest date any credential signed by this delegation can carry. The delegate cannot issue a credential that outlives the constraint, regardless of the expiration date the delegate sets.
- **Allowed property set.** The set of credential types the delegate may sign. The delegate cannot sign a credential property the original issuer did not authorize. The separation a state government enforces between county clerks (marriage licenses) and the DMV (driver's licenses) is expressible at the property level.

The allowed property set is open by default. A delegated issuer key with no allowed property set can sign credentials under any property in the delegator's namespace. A delegator that wants to scope a key sets the allowed property set on it, and a careful delegator does not leave a production issuer key in the open default.

Julia Social uses issuer delegation in production. The corporate "2-of-2: 2-of-3, 1-of-3" identity is used periodically to delegate credential-issuance authority to a fresh issuer key singleton. Every credential a user receives is signed by one of the current delegates. When necessary, the corporate identity issues a new delegation to a new issuer key.

The protected corporate identity therefore touches the chain only occasionally. Day-to-day credential issuance happens through the delegates.

### **Revocation operations on an issuer key singleton**

Three on-chain operations can revoke or destroy an issuer delegation. The protocol gives the issuing DID an override path so that a compromised delegate cannot keep the delegation alive.

- **Revoke by issuer key.** The delegate updates the issuer key's revocation bitfield to mark specific credentials as revoked. This is the normal operational path. Up to 512 credentials can be revoked in a single transaction. The revocation bitfield supports up to 131,072 separately-revocable credentials.
- **Revoke by issuer DID.** The issuing DID updates the revocation bitfield without the delegate's signature. The protocol does not require the delegate to participate. This is an override path used when necessary.
- **Melt the issuer key.** The issuing DID destroys the singleton. Every credential the singleton ever signed becomes unverifiable in one transaction. There is no need to track down individual credentials.

Melting the issuer key singleton is the strongest tool. As an example, it is the enforcement mechanism for not.bot enrollment partners. If Julia Social suspects a not.bot enrollment partner of substantial fraudulent issuance, Julia Social can melt the partner's issuer key singleton(s). Every credential the partner ever issued becomes invalid at once. Affected users re-enroll elsewhere.

A credential holder cannot revoke their own credentials. The "compromised delegate" scenario is handled by the issuing DID directly, without the delegate's cooperation.

Either party can revoke. The delegate that holds the issuer key can revoke individual credentials it has issued, within the authority it was granted. The issuing DID holds that same power and adds the override path above, which it can exercise without the delegate's cooperation.

## **Credential delegation**

A credential subject can authorize another identity to *present* one or more of their credential claims. The delegate presents the credential, the verifier accepts the presentation, and the verifier sees the credential as if the subject had presented it. The verifier also sees that the presented credential is delegated. The original subject retains the right to revoke the authorization at any time.

Whether a credential can be delegated at all is a choice the issuer makes at issuance. Some credentials are marked non-delegatable; only the subject can ever present them.

A presentation delegation is always time-bounded. It carries a Valid-From and a Valid-To, so no delegate holds presentation rights indefinitely, and the subject can revoke before the window closes.

The subject scopes a presentation delegation along three axes: by issuer, by property, and by value. Value scoping is optional. The three axes let a holder delegate "present my age-over-21 claim from this issuer" without delegating the rest of the credential. A user can authorize an agent to present any credential from their employer limited to job title and not salary.

### **Subdelegation**

When the issuer permits it, a delegate can in turn authorize another identity to present the same credential. Each delegation is its own independent claim. The terminal delegatee presents the original subject's claim as if it were their own, alongside the chain of delegations that connects them.

The chain is validated by *chain walk* at presentation time. The verifier walks every link, confirms each is signed, current, and unrevoked, and confirms the underlying credential is itself valid. Revoking any link in the chain breaks presentation for everyone downstream of that link. Attenuation comes through each delegation's own expiry, which can be shorter than the underlying credential's.

### **Worked example: pay-to-credential with delegated agent access**

A user owns 100 Chia coins controlled by `p2_claim`: each coin unlocks when the holder presents a specific credential the user's DID issues. The user issues 100 such credentials to an AI orchestrator agent, each credential granting the orchestrator the right to spend one of the coins. In this example, the credentials carry no expiration; the user plans to keep them active for the agent's working lifetime.

The orchestrator needs a sub-agent to handle a 30-minute trading window. The orchestrator delegates presentation of 10 of the credentials to the sub-agent, with the delegation expiring in 30 minutes. To make a trade, the sub-agent presents the credentials on-chain to spend the coins.

After 30 minutes the delegation expires. The sub-agent cannot present any further. Coins the sub-agent did not spend remain untouched and under the orchestrator's control. The user's underlying credentials and coins are not affected.

If the user wants to revoke the orchestrator's access, the user's issuer key singleton updates its revocation bitfield. All 100 credentials can be invalidated in one transaction. Every delegated sub-agent downstream of the orchestrator loses access in the same instant.

## **Mandate credentials**

Mandate credentials are a different pattern from credential delegation. Credential delegation passes presentation rights for an existing credential through a chain. Mandate credentials are *new* credentials issued at each link in the chain: the principal issues a credential to the agent granting specific authority to act. When the agent issues a narrower mandate to a downstream agent, the downstream mandate lists the upstream mandate as an antecedent. The chain is verified by walking antecedents through the credential graph.

The verifier's job at the end of a mandate chain is to confirm that the action the terminal agent is attempting falls within the scope of every mandate in the chain. Each mandate must be the same or narrower in scope than the one above it. The terminal action must be permitted by all of them.

Mandate credentials are an open pattern any issuer can use to encode attenuated capability. The pattern admits two distinct verification styles.

### **Unstructured mandates: AI-verified scope**

A mandate written as natural language ("book economy flights between San Francisco and major US cities, total spend under $2,000, travel dates within the next 60 days") is unstructured. A verifier has no rule-based way to parse it. To enforce the mandate, the verifier uses an AI to evaluate whether a specific attempted action falls within the natural-language scope. The AI's judgment is the enforcement mechanism.

Unstructured mandates suit cases where the scope of authority is fluid, contextual, or expressed at a level of detail no rigid schema can capture.

#### Worked example: AI travel booking cascade

A user wants their travel managed by AI agents. The user issues a mandate credential to a travel orchestrator agent.

| Issuer | User's alias DID |
| :---- | :---- |
| Property | Mandate |
| Value | "Book travel for me. Total annual spend under $20,000. No first-class. Notify me before booking anything over $3,000." |
| Subject | Orchestrator's DID |

The orchestrator handles itinerary planning, hotel selection, and flight booking. For flights it relies on a specialized worker agent. The orchestrator issues a narrower mandate to the worker.

| Issuer | Orchestrator's DID |
| :---- | :---- |
| Property | Mandate |
| Value | "Book economy or premium-economy flights only. Departure airports SFO or OAK. Total spend per trip under $1,500." |
| Subject | Worker's DID |
| Antecedents | The user's mandate credential to the orchestrator |

The worker attempts to book a flight from SFO to JFK at $1,200 in economy. The worker assembles a verifiable presentation containing its own mandate (subject presentation, since the worker is the subject) and the orchestrator's mandate (holder presentation, since the orchestrator is the subject of that one). The presentation is sent to the airline's booking system.

The airline's verifier walks the antecedent chain from the worker's mandate to the orchestrator's mandate to the user, confirms each step is valid and unrevoked, and uses AI to confirm the attempted booking falls within the scope of both mandates: the orchestrator's $1,500 cap, SFO/OAK origin, and economy/premium-economy class, plus the user's $20,000 annual cap and no-first-class restriction. The booking proceeds.

If the user revokes the mandate to the orchestrator, the antecedent chain breaks. The worker's next presentation fails. No on-chain action is needed against the worker; the cascade follows from the antecedent structure.

### **Structured mandates: rule-based scope**

A mandate expressed as structured scopes (OAuth 2.1-style permission tokens like `flights.book.economy`, `flights.spend.max.1500`) is rule-parseable. The verifier parses the scope list and confirms each requested action matches a permitted scope. The judgment is mechanical and auditable.

Structured mandates suit cases where the scope is well-defined, the verifier wants reproducible enforcement, and the audit trail needs to be machine-readable.

#### Worked example: structured mandate for a personal finance agent

A user issues a structured mandate credential to a personal finance AI.

| Issuer | User's alias DID |
| :---- | :---- |
| Property | Mandate |
| Value | `["account.read.balances", "account.read.transactions", "transfer.create.between_own_accounts", "transfer.max_amount.5000", "valid.until.2026-12-31"]` |
| Subject | Finance agent's DID |

The agent attempts a $2,000 transfer between two accounts the user owns at the same bank. The bank's verifier parses the scope list, confirms `transfer.create.between_own_accounts` is present, confirms the requested amount ($2,000) is under the `transfer.max_amount` limit ($5,000), confirms the current date is before the validity expiration, and authorizes the transfer.

The verification follows fixed rules. Two banks given the same mandate and the same request reach the same conclusion. The bank's audit log records the scope strings that authorized the action, traceable back to the user's signature on the mandate.

## **Self-attested credentials**

A simple application of issuer delegation: the issuer delegates to itself. An identity delegates issuance authority to its own key, then issues credentials in which it is both the issuer and the subject.

The mechanism lets a user attach signed assertions about their own identity without involving an external issuer. The avatar example:

| Issuer | User's alias DID |
| :---- | :---- |
| Property | Avatar |
| Value | (SVG of the user's chosen avatar) |
| Subject | User's alias DID |

The credential is a signed certificate of a fact about the user, made by the user.

A self-attested credential carries more weight when it is part of a verifiable presentation. A user who signs a public statement and includes their self-attested display name and avatar produces a presentation that carries the statement, the time it was signed, and a verifiable visual identity associated with the signer. A correspondent who receives the presentation can render the user's avatar alongside the message in their own interface, knowing the avatar is the one the user has cryptographically attached to that alias.

The integrity of the data depends on who is reading it. Anyone can self-attest to anything: an attacker could self-attest "this DID is Taylor Swift" without consequence. The value of a self-attested credential is the verifiable cryptographic linkage between the data and the DID. Whether the underlying data is to be trusted is a separate judgment, one that lives outside the credential infrastructure.

## **Human accountability**

Every chain of authority in `did:julia` ends at a human key-holder. A worker AI presents a mandate issued by an orchestrator AI; the orchestrator's mandate is antecedent on a mandate from a human user; the user's identity terminates at the BLS12-381 key on a passport-verified human's device. A delegate of Julia Social's corporate DID signs a credential; the delegation was authorized by Julia Social's "2-of-2: 2-of-3, 1-of-3" identity; the executive class is staffed by named humans, and the airgapped class is operated by named humans. Walking back any not.bot signature ends at a named human signer.

## **What lives where**

**[Identity Architecture (6A)](http://doc_06A_identity_architecture.md)** covers the structure of a not.bot identity: root and alias DIDs, the cryptographic basis of the identifier, display names, and hidden aliases.

**[Credentials, Presentations, and Selective Disclosure (6B)](http://doc_06B_credentials.md)** covers the credential architecture: single-claim credentials, the catalog Julia Social issues, the three presentation modes, antecedents and cascade revocation, holder presentation, pay-to-credential, and the no-phone-home property.

**[Recovery (6D)](http://doc_06D_recovery.md)** covers the recovery model: pre-rotated keys, assisted recovery through recovery agents, and the malicious-recovery scenario and countermeasures.

The **[did:julia Technical Specification (Doc #15)](http://doc_15_did_julia_specification.md)** is the implementer-facing reference for the on-chain protocol, complementary to the conceptual treatment here.