Signing delegation

What this attestation records

A signing-delegation attestation is how an organization publishes, to the Attestation Notary graph, that a specific individual is authorized to sign attestations on the organization's behalf. It names the operator, the scope of what they may sign, the effective time range, and the paper-world authority under which the delegation was granted.

Signing delegations are the mechanism by which an organization's cryptographic identity is separated from any specific human's cryptographic identity, matching how corporate signature authority already works in law: the organization holds the authority; officers exercise it on the organization's behalf under bylaws that name who may sign what.

Signer and subject

Signer: the organization's root identity key (under EXT-245 Options B, C, or D — a specific officer's passkey under B, any officer's passkey under any-of-N C, or a K-of-N Squads multisig under D).

Subject: the operator's public key. This is the key that will subsequently sign attestations under the delegation's authority.

Payload fields

See the JSON schema for machine-readable structure. Key fields:

• organization — legal name, EIN, jurisdiction, entity type, registration reference (pointer to the Extol-issued onboarding-verification attestation that anchors the org's real-world identity)
• operator — public key, legal name, title, role scope description
• org_root — the custody tier (B, C, or D), and (under C) the specific officer's public key + legal name + title who executed this delegation
• authorized_activity_types — machine-enforceable list of activity_type URIs the operator may sign under this delegation
• effective_from, effective_until — hard time bounds for the delegation's validity
• authorization_source — pointer to the paper-world authority (board resolution reference, bylaws section for revocation conditions)
• terms_uri — pointer to the versioned Pattern 3 attestation terms in effect at issuance (Iapetus IETF versioned-terms pattern)

Revocation

Delegation revocation follows the Notary Spec §4.3 additive-revocation convention: the org root key signs a new attestation whose activity_type is notary.extol.work/v1/revocation and whose subject is the SHA-256 of the target delegation attestation's canonical bytes. Revocation is prospective only: attestations the operator signed under this delegation before the revocation timestamp remain valid; the operator may sign no new attestations after that timestamp.

Under Option B (single officer), only that officer can sign a revocation. Under Option C (multi-officer any-of-N), any active officer can sign a revocation targeting the delegation. Under Option D (K-of-N Squads), a K-of-N ceremony is required.

Downstream reader discipline

A reader walking the graph to validate an operator-signed attestation MUST verify:

1. The operator-signed attestation's activity_type is listed in the delegation's authorized_activity_types.
2. The operator-signed attestation's signer_asserted_at falls within the delegation's effective_from / effective_until range.
3. The delegation has not been revoked as of the operator-signed attestation's signer_asserted_at.
4. The org root pubkey that signed the delegation has itself been anchored by an Extol-issued onboarding-verification attestation.

A delegation signed by an unanchored org root pubkey is a legitimate cryptographic claim about authorization but weak organizational-identity evidence — the reader has no way to know which real-world organization the root pubkey represents.