• Centralization: Dependence on trusted third parties to issue and verify authorizations
• Revocation challenges: Difficulty in efficiently communicating revocation status
• Context limitations: Inability to verify authorization without online access to central authorities
• Portability issues: Authorizations tied to specific infrastructure or platforms

The evolution toward decentralized identity systems created demand for authorization mechanisms that could operate without centralized intermediaries while maintaining cryptographic verifiability.

KERI's Approach

Signed Authorization Statements

KERI implements authorization through cryptographically signed statements that include the AID (Autonomic Identifier) under which the authorization is issued. This approach provides several critical properties:

Cryptographic Binding: Each authorization statement is cryptographically bound to a specific AID through digital signatures. The signature proves that the controller of the AID at a specific point in time authorized the statement.

Temporal Verification: Verification uses keys that were authoritative at the time of issuance, not necessarily current keys. This is crucial because KERI supports key rotation - the keys used to sign an authorization may have been rotated since issuance, but the authorization remains valid if it was properly signed with keys that were authoritative when issued.

Inherited Security: Authorization security in KERI inherits from the associated AID's security. This means:

• Authorizations are only as secure as the underlying control authority over the AID
• Compromise of AID control authority compromises all authorizations issued under that AID
• The security properties of the KEL (Key Event Log) - including duplicity detection and witness consensus - extend to authorizations

Integration with W3C Verifiable Credentials

KERI's authorization model integrates with W3C Verifiable Credentials (VCs), which represent a standardized form of authorization. VCs utilize the W3C Decentralized Identifier (DID) standard, providing URI-like namespace syntax for decentralized identifiers.

Critical Architectural Distinctions:

The relationship between KERI AIDs and W3C DIDs is nuanced:

• A given DID may be a type of AID - DIDs can be implemented using KERI's autonomic identifier infrastructure
• Not all DIDs are AIDs - Many DID methods do not provide KERI's self-certifying properties
• AIDs may use namespace standards besides DIDs - KERI is namespace agnostic and can support AIDs in any namespace that accepts pseudo-random strings

This flexibility means KERI's authorization model works independently of any specific namespace choice, enabling:

• Universal applicability: Authorization mechanisms work across different identifier namespaces
• W3C VC compatibility: KERI can issue and verify W3C-compliant verifiable credentials
• Namespace independence: No lock-in to specific identifier formats or resolution mechanisms

End-Verifiable Authorization

A key innovation in KERI's approach is end-verifiability of authorizations. Any party receiving an authorization statement can:

1. Retrieve the issuer's KEL to determine key state history
2. Verify the signature using keys that were authoritative at issuance time
3. Check for duplicity by comparing KEL versions from multiple sources
4. Validate the authorization chain if the authorization builds on other authorizations

This end-verifiability eliminates dependence on:

• Online access to central authorities
• Trusted intermediaries for verification
• Real-time revocation checking (though KERI supports this through TELs)

Authorization Chaining and Delegation

KERI supports hierarchical authorization structures through ACDC (Authentic Chained Data Container) chaining:

Proof of Authority Chains: ACDCs can chain together to create verifiable delegation paths. For example:

• GLEIF issues a QVI (Qualified vLEI Issuer) credential authorizing an organization to issue Legal Entity credentials
• The QVI issues a Legal Entity credential to a company
• The company issues an OOR (Official Organizational Role) authorization to a QVI
• The QVI issues an OOR credential to an individual

Each step in this chain is cryptographically verifiable, creating an unbroken chain of authority from the root (GLEIF) to the end credential holder.

Cooperative Delegation: KERI's delegation model is cooperative, requiring both delegator and delegate to participate in cryptographic operations. This ensures:

• Delegators maintain control over what is delegated
• Delegates cannot claim unauthorized delegations
• The delegation relationship is cryptographically verifiable by third parties

Legitimized Identifiers (LIDs)

KERI's authorization model enables legitimized human-meaningful identifiers through the aid|lid couplet pattern:

• An AID establishes a cryptographic trust domain
• Human-meaningful identifiers (LIDs) are authorized within that trust domain
• The authorization creates a verifiable binding between the AID and LID
• This enables human-readable identifiers to inherit the security properties of AIDs

This approach solves the historical tension between security (cryptographic identifiers) and usability (human-meaningful names) by using authorization as the bridge between the two.

Practical Implications

Use Cases

Credential Issuance Authorization: In the vLEI ecosystem, Legal Entities must authorize QVIs to issue role credentials on their behalf. This authorization:

• Specifies which individuals can receive credentials
• Defines the roles being authorized
• Creates an auditable authorization trail
• Enables revocation if authorization is withdrawn

Service Endpoint Authorization: Controllers can authorize specific service endpoints to act on behalf of their AIDs:

• Witness authorization for key event witnessing
• Agent authorization for delegated operations
• Mailbox authorization for message handling

Delegated Authority: Organizations can create hierarchical authorization structures:

• Root AIDs delegate authority to departmental AIDs
• Departmental AIDs delegate to individual AIDs
• Each delegation level maintains independent key management
• Compromise at lower levels doesn't compromise higher levels

Benefits

Cryptographic Verifiability: Every authorization can be cryptographically verified without trusted intermediaries, enabling true zero-trust architectures.

Temporal Integrity: Authorizations remain verifiable even after key rotations, as verification uses historically authoritative keys rather than current keys.

Namespace Agnostic: Authorization mechanisms work across different identifier namespaces (DIDs, URLs, etc.), preventing vendor lock-in.

Hierarchical Scalability: Delegation enables authorization structures that scale from individual users to global enterprises while maintaining cryptographic integrity.

Revocation Support: Integration with TELs (Transaction Event Logs) enables efficient revocation checking when needed, while maintaining offline verifiability for non-revoked authorizations.

Trade-offs

Complexity: KERI's authorization model requires understanding of KELs, key rotation, and temporal key state verification, creating a steeper learning curve than simple token-based systems.

Key Management Burden: Security depends on proper key management by all parties in the authorization chain. Compromise of any AID's keys compromises authorizations issued under that AID.

Verification Overhead: End-verifiable authorization requires verifiers to process KELs and perform cryptographic verification, which is more computationally intensive than simple token validation.

Revocation Latency: While KERI supports revocation through TELs, there may be latency between revocation and verifier awareness, especially in offline scenarios.

Infrastructure Requirements: Full KERI authorization verification requires access to KELs, which may necessitate witness networks, watchers, or other infrastructure components.