Request for Comments: KEBAC

Document: RFC-KEBAC-001
Category: Experimental
Status: Draft
Date: November 2025
Authors: The BeTTY Project Contributors

KEBAC: Keyed Encryption-Based Access Control

Status of this memo

This document specifies an experimental access control mechanism for the Internet community and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

Abstract

KEBAC (Keyed Encryption-Based Access Control) is a cryptographic access control system which relies on encryption for authorization and authentication, combined with access control lists (ACLs) and UNIX-style octal permissions.

In KEBAC, authorization is granted by encrypting content to a recipient's public key, and authentication is proven by successful decryption with the corresponding private key. This document describes the KEBAC model, its implementation within the BeTTY protocol, and security considerations for its deployment.

1. Introduction

1.1 Purpose

Traditional access control systems separate authentication (proving who you are) from authorization (what you're allowed to do). This separation requires maintaining permission databases, session tokens, and complex role hierarchies. KEBAC unifies these concepts through cryptography: if you can decrypt it, you can access it.

1.2 Motivation

Modern distributed systems face several access control challenges:

• Credential Management: Passwords, tokens, and sessions are vulnerable to theft
• Federation Complexity: Cross-domain authorization requires complex trust relationships
• Permission Synchronization: Distributed permission databases must stay consistent
• Auditability: Traditional logs can be forged or tampered with
• Zero-Knowledge Hosting: Services want to host encrypted data they cannot read

KEBAC addresses these issues by:

1. Eliminating passwords and tokens entirely
2. Making authorization decisions cryptographically verifiable
3. Enabling zero-knowledge hosting without trusted intermediaries
4. Providing tamper-evident audit trails through signatures
5. Allowing fine-grained access control without centralized databases

1.3 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Identity: A cryptographic keypair (public and private keys) representing a user, service, or group

Owner: The identity that created a resource and has ultimate control over it

Encryption: The process of rendering data unreadable without the corresponding private key

Public Key: The publicly distributed half of an asymmetric keypair

Private Key: The secret half of an asymmetric keypair, never transmitted

Signature: Cryptographic proof that data was created by a specific identity

PRPH: Poor Richard's Pseudo-Homomorphism - operations on encrypted data without full decryption

ACL: Access Control List - mapping of identities to permission levels

Octal: Base-8 numeric representation of permission bits (0-7)

2. KEBAC Principles

2.1 Core Axioms

KEBAC is built on three fundamental principles:

Axiom 1: Authorization Through Encryption
Authorization is granted by encrypting content to a recipient's public key. No separate permission grant is needed.

Axiom 2: Authentication Through Decryption
Authentication is proven by successful decryption. If you can decrypt the data, you are who you claim to be.

Axiom 3: No Passwords, No Sessions
The system never stores, transmits, or compares passwords. Sessions are unnecessary because every request is self-authenticating via signature.

2.2 Implications

These axioms have profound implications:

1. No Password Database: Nothing to steal, nothing to crack
2. No Session Hijacking: No cookies, no tokens to intercept
3. Perfect Forward Secrecy: Past communications remain secure even if keys are compromised later
4. Zero-Knowledge Hosting: Servers can store data they cannot read
5. Cryptographically Verifiable Audit Trail: All actions are signed and tamper-evident

2.3 Comparison to Traditional Access Control

3. Permission Model

3.1 UNIX-Style Octals

KEBAC uses UNIX-style octal permissions (0-7) but redefines their meaning for distributed, federated systems:

3.2 Octal Permission Values

Each permission level is the sum of its component bits:

Note: Type casting works as follows:

• Integer values above 7 MUST evaluate as 7 (full access).
• Boolean true MUST evaluate to 7 (full access).
• Boolean false or an empty string MUST evaluate to 0 (no access).
• Decimal values MUST rounded to integers
• String values MUST be in the form of the "Perms" column above (e.g., "rwx","r--")

3.3 Permission Structure

Permissions are stored in the resource's metadata as an Access Control List (ACL):

{
  "betty": {
    "owner": "alice@betty.land",
    "permissions": {
      "@world": 5,
      "@authenticated": 5,
      "@staff": 7,
      "bob@betty.land": 6,
      "carol@betty.land": 4
    }
  }
}

ACL Rules: 1. Owner automatically has full access (7) without being listed 2. Identities must exist in the PKI system 3. Groups (prefixed with @) expand to their members 4. More specific identities override less specific ones 5. Order of evaluation: specific identity → group → @authenticated → @world

3.4 Special Identities

@world: Everyone, including unauthenticated users (if content is not encrypted)

@authenticated: Any identity with a valid keypair

@group-name: Named groups defined in /system/@groups/

Example group definition:

{
  "betty": {
    "topic": "hash-of-group-name",
    "owner": "admin@betty.land"
  },
  "content": {
    "group": "@staff",
    "display_name": "Staff Members",
    "members": [
      "alice@betty.land",
      "bob@betty.land",
      "carol@betty.land"
    ],
    "admins": ["admin@betty.land"],
    "encryption_key": "age1groupkey..." 
  }
}

4. Cryptographic Operations

4.1 Key Types and Algorithms

KEBAC's cryptographic requirements are not fixed on a particular standard. Keys must be able to provide both signing and encrypting capacities to each user. In the race between encryption and cracking, KEBAC wants you to choose the strongest available option and be able to rotate keys when needed.

4.2 Key Distribution

Public keys are distributed through:

1. PKI Endpoints: GET /api/v1/keys/<identity>
2. Out-of-Band Exchange: Email, QR codes, physical media
3. Key Servers: Standard PGP keyserver protocol
4. Document Metadata: Embedded in signed documents

Key distribution channels MUST be:

• Publicly accessible (for public keys)
• Tamper-evident (via signatures)
• Optionally cached (with configurable TTL)

4.3 Signatures

All operations MUST be signed by the requesting identity:

{
  "routing": {
    "from": "bob@betty.land",
    "signatures": [
      {
        "identity": "bob@betty.land",
        "algorithm": "ed25519",
        "signature": "base64-encoded-signature",
        "timestamp": "2025-11-16T10:00:00Z",
        "salt": "random-unique-value"
      }
    ]
  }
}

Signature Requirements:

• MUST include timestamp (reject old signatures)
• SHOULD include a salt (prevent replay attacks)
• MUST sign entire message body
• MAY include multiple signatures (co-signing)

5. Permissions Mechanisms

After successful decryption, a decrypted document which is fully compliant with KEBAC's permissions system implements ACLs with octal permissions. Because KEBAC is designed for federated local-first systems, it has a different permissions model from UNIX's read/write/execute grants.

In KEBAC, permission grants are structured as follows:

Copy: the ability to decrypt messages. For implementing KEBAC, this means documents must be encrypted to the grantee's public key. Write: the ability to replace or append the document within the implementor's content management system. Index: the ability to include this document in indicies, e.g., make this document searchable independently from a users' copy or write privileges.

5.1 Enforcement Points

KEBAC permissions are enforced at multiple layers:

1. Cryptographic Layer

• Reports permissions to other components
• Verifies decryption capability
• Does NOT enforce non-cryptographic permissions

2. Storage Layer

• Checks write permissions before upsert
• Enforces blind append rules
• Manages version history

3. Indexing Layer

• Checks index permissions before adding to search
• Respects blind append permissions
• Filters search results by access

4. Network Layer

• Verifies signatures on incoming requests
• Returns appropriate error codes
• Rate limits by identity

5.2 Copy Permission (r/4)

Required For: Decrypting and viewing content

Servers do not need to "check" permissions. If the client has the private key corresponding to one of the encrypted symmetric keys, they can decrypt. Otherwise, they cannot.

Mechanism

1. Client requests resource
2. Server returns encrypted content
3. Client attempts decryption
4. Success = authenticated and authorized
5. Failure = Unauthenticated error

5.3 Write Permission (w/2)

Required For: Modifying the resource (upsert or append)

Mechanism

1. Client signs upsert request
2. Signature verification = authentication
3. Server decrypts ACL (requires read access to metadata)
4. Server checks if requester has write permission (2 or above)
5. Allow or deny operation

Write-Only Scenario (permission = 2):

• Can append to resource (blind operation via PRPH or true homomorphic operations)
• CANNOT upsert (replacement requires reading current state)
• Use case: Anonymous submission boxes, tip lines

Read-Write Scenario (permission = 6):

• Can read current state
• Can replace with new version
• Can append new data
• Use case: Collaborative documents

5.4 Index Permission (x/1)

Required For: Including resource in search indices

Mechanism

1. Indexing service processes resource
2. Checks ACL for requester's index permission
3. If permission includes index bit (1), add to index
4. If not, exclude from search results

Index-Only Scenario (permission = 1):

• Resource appears in search results
• Metadata visible (title, tags, summary)
• Content remains encrypted (cannot read)
• Use case: Discoverable but access-controlled content

Read without Index (permission = 4):

• Can read content if you have the topic hash
• Does NOT appear in search results
• Use case: Private sharing by direct link

5.5 Blind Operations (PRPH)

KEBAC supports operations on encrypted data without full decryption through Poor Richard's Pseudo-Homomorphism (PRPH). For full details about PRPH, see the [NBSON-RFC].

PRPH, as the name suggests, is not a true homomorphic operation; instead, it uses a keymap to replace encrypted values within a document. Implementors MAY allow blind operations as follows:

Blind Append (permission = 2 or 3):

1. Client creates new message
2. Encrypts message to owner's public key
3. Uses NBSON index line to locate append point
4. Appends encrypted message without reading existing content
5. Updates index line

Blind Edit (permission = 2 with PRPH level 5):

1. Client has index line decryption key
2. Uses index to locate specific field
3. Encrypts new value to owner's key
4. Replaces old value without reading it
5. Updates index

Configuration: PRPH behavior controlled by nbson.prph_write setting (0-5).

Alternatively, true homomorphic encryption may be deployed in a substitute component for PRPH to provide equivalent functionality; such mathematics are beyond the scope of this RFC.

6. Advanced Features

6.1 Forked Writes

When a user has read permission (4) but NOT write permission (2), servers MAY allow forked writes.

This enables derivative works without permission, while the original remains immutable. Attribution remains automatic and provenance remains auditable.

1. User attempts to upsert document at document identifier abc123
2. Permission check fails (has r-- not rw-)
3. Server computes content hash of submitted document → new document identifier def456
4. New topic owned by requester with full permissions
5. Original document abc123 unchanged, and the forked document maintains provenance

Configuration: Controlled by lakehouse.forked_write (boolean).

6.2 Group Encryption

Groups can use symmetric keys for efficiency.

Group Key Distribution

1. Group admin generates symmetric key
2. Encrypts group key to each member's public key
3. Distributes via secure channel (BeTTY message)
4. Members decrypt group key with their private key
5. Use group key to decrypt group content

Key Rotation

When membership changes, rotate keys: 1. Generate new group key 2. Re-encrypt all group content to new key 3. Distribute new key to current members 4. Archive old content encrypted to old key

6.3 Delegation and Sub-Keys

Identities can create sub-keys for delegation. These sub-keys inherit permissions from the user's parent or previous identity. Sub-keys can be revoked independently, and enable least privilege access, perfect for temporary grants or limiting the cryptographic attack surface by using different keys to distribute interceptable encrypted data.

6.4 Time-Limited Access

Implement time-limited access through scheduled key rotation:

1. Background job checks access_expiry dates
2. When expired, removes identity from ACL
3. Re-encrypts content without that identity's key
4. User loses access automatically

7. Use Cases

The following examples use the BettyDoc format, which is a KEBAC-compliant implementation within the BeTTY protocol. See [BeTTY-Protocol-RFC] for more details.

7.1 Public Readable, Private Writable

Scenario: Blog post, documentation, announcement

{
  "betty": {
    "owner": "alice@betty.land",
    "permissions": {
      "@world": 5
    }
  }
}

Behavior:

• Anyone can read and search
• Only Alice can edit
• Ideal for public content with single author

7.2 Collaborative Document

Scenario: Team wiki, shared project notes

{
  "betty": {
    "owner": "alice@betty.land",
    "permissions": {
      "@team": 7,
      "@world": 1
    }
  }
}

Behavior:

• Team members: full access
• Others: can find in search but not read
• Content is discoverable but protected

7.3 Public Inbox

Scenario: Contact form, anonymous feedback

{
  "betty": {
    "owner": "alice@betty.land",
    "permissions": {
      "@world": 3
    }
  }
}

Behavior:

• Anyone can submit (blind append)
• Anyone can see inbox exists (searchable)
• Only Alice can read submissions
• Ideal for anonymous tips, surveys

7.4 Secret Dead Drop

Scenario: Whistleblowing, confidential submissions

{
  "betty": {
    "owner": "journalist@betty.land",
    "permissions": {
      "@world": 2
    }
  }
}

Behavior:

• Anyone can submit (blind append)
• NOT searchable (not indexed)
• Only owner can read
• Maximum anonymity for submitters

7.5 Private with Selective Sharing

Scenario: Private documents with controlled access

{
  "betty": {
    "owner": "bob@betty.land",
    "permissions": {
      "alice@betty.land": 4,
      "carol@betty.land": 6
    }
  }
}

Behavior:

• Default: no access
• Alice: read only
• Carol: read and edit
• Not searchable by others
• Ideal for confidential collaboration

7.6 Research Group with Time-Limited Interns

Scenario: Academic lab with temporary members

{
  "betty": {
    "owner": "dr-smith@betty.land",
    "permissions": {
      "@research-group": 7,
      "intern-jane@betty.land": 5
    },
    "access_expiry": {
      "intern-jane@betty.land": "2025-12-31T23:59:59Z"
    }
  }
}

Behavior:

• Research group: full access
• Intern: read and search until end of year
• Automatic access revocation
• No manual cleanup needed

8. Security Considerations

8.1 Threat Model

KEBAC protects against:

Password theft: No passwords exist
Session hijacking: No sessions to hijack
Man-in-the-middle: Signatures prevent tampering
Server compromise: Encrypted data unreadable
Permission escalation: Cryptographically enforced
Replay attacks: Timestamps and nonces prevent replay

KEBAC does NOT protect against:

Endpoint compromise: If private key is stolen, attacker has access
Side-channel attacks: Implementation must use constant-time operations
Social engineering: Users must protect their private keys
Quantum computing: Current algorithms vulnerable to future quantum attacks, users must choose strong algorithms
Rubber hose cryptanalysis: Physical coercion can extract keys

8.2 Key Management

Critical Requirements:

1. Private Key Protection:

• MUST be encrypted at rest with strong passphrase
• SHOULD be stored in hardware security module when possible
• MUST NEVER be transmitted over network
• SHOULD be backed up securely

1. Key Rotation:

• SHOULD rotate keys regularly
• MUST rotate immediately if compromise suspected
• MUST re-encrypt content to new keys
• MAY maintain old keys for legacy content

1. Key Revocation:

• MUST re-encrypt all content encrypted to revoked key
• MUST Remove revoked key from all ACLs
• SHOULD Publish revocation certificate to key servers
• SHOULD Maintain revocation list

8.3 Cryptographic Agility

KEBAC implementations MUST support algorithm agility:

• Algorithm identifiers in all cryptographic operations
• Nodes can support multiple algorithms simultaneously
• New algorithms can be added without protocol changes
• Quantum-resistant algorithms can be adopted when mature

Future-Proofing:

• Design allows algorithm field in all operations
• Multiple signatures/encryptions supported
• Graceful degradation if algorithm unsupported

8.4 Denial of Service

KEBAC implementations SHOULD implement:

1. Rate Limiting: Limit requests per identity per time window
2. Signature Verification Limits: Cap CPU time for verification
3. Request Size Limits: Maximum message size
4. Connection Limits: Max concurrent connections per identity
5. Computational Limits: Timeout long-running operations

8.5 Privacy Considerations

Data Privacy: Content encrypted at rest protects this data from server operators, allowing Torrent-like distributed hosting for files.

Metadata Privacy:

When KEBAC is implemented with [NBSON], each field is indivudally encryptable to a different key, which includes metadata.

Social Graph Privacy:

• Following/follower relationships are public
• Group membership may be public (depends on group config)
• Use pseudonyms for privacy-sensitive contexts

8.6 Audit Trail

Implementors MAY store KEBAC operation logs to produce a tamper-evident audit trail:

{
  "event": {
    "from": "bob@betty.land",
    "operation": "upsert",
    "target": "betty://local/documents/abc123",
    "signatures": [{
      "identity": "bob@betty.land",
      "algorithm": "ed25519",
      "signature": "...",
      "timestamp": "2025-11-16T10:00:00Z"
    }]
  }
}

Audit Properties:

• Non-repudiation: Signatures prove identity
• Integrity: Tampering detectable
• Chronology: Timestamps provide ordering

9. Implementation Guidelines

9.1 Client Implementation

Clients MUST:

• Generate keypairs securely (use OS cryptographic APIs)
• Protect private keys (encrypt at rest, secure storage)
• Sign all requests with private key
• Verify signatures on all responses
• Cache public keys with appropriate TTL
• Implement exponential backoff for failures
• Support multiple identities

Clients MAY:

• Use hardware security modules when available
• Implement key rotation reminders
• Warn users about weak passphrases
• Provide key backup/recovery options

9.2 Server Implementation

Servers MUST:

• Verify signatures on all incoming requests
• Enforce ACL permissions at appropriate layers
• Support multiple cryptographic algorithms
• Reject expired timestamps

Servers SHOULD:

• Rate limit by identity
• Log all access attempts (signed audit trail)
• Cache permission checks for performance
• Support PRPH for blind operations
• Implement efficient key distribution
• Provide detailed error messages (without leaking info)
• Monitor for suspicious patterns

Servers MAY: - substitute true homomorphic encryption in place of PRPH

10. Comparison to Other Systems

10.1 vs. OAuth 2.0

10.2 vs. Kerberos

10.3 vs. RBAC (Role-Based Access Control)

11. References

11.1 Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017.

11.2 Informative References

[Capability-Myths] Miller, M., "Capability Myths Demolished", 2003.

[BeTTY-Protocol-RFC] "The BeTTY Protocol", RFC-BETTY-001.

[NBSON-RFC] "NBSON Storage Format", NBSON-RFC-001.

12. Acknowledgments

KEBAC builds upon concepts from:

• Public key cryptography pioneered by Diffie, Hellman, Rivest, Shamir, and Adleman

• Plan 9 From Bell Labs and UNIX

• Git and content-addressed storage with cryptographic verification

• Phil Alden Robinson's Sneakers (1992), starring Donal Logue as mathematician Gunter Janek:

  There exists an intriguing possibility for a far more elegant solution... we might induce homomorphisms from the principal ordinance of each of these fields...

Special thanks to cryptographers who made strong encryption accessible to all.

Appendix A: Example Protocol Flow

Note: this appendix uses document vocabulary from the [BeTTY Protocol], [BettyMsg/BettyDoc Standard] and pseudocode in Python.

A.1 User Registration

1. Client generates Ed25519 keypair (signing)
2. Client generates X25519 keypair (encryption)
3. Client creates identity document:
   {
     "identity": "alice@betty.land",
     "signing_key": "age1abc...",
     "encryption_key": "age1xyz...",
     "created": "2025-11-16T10:00:00Z"
   }
4. Client signs document with private signing key
5. Client publishes to node at betty://betty.land/api/v1/keys/alice@betty.land
6. Node stores public keys (not private keys!)

A.2 Creating an Encrypted Document

1. Alice creates document:
   {
     "title": "Secret Plan",
     "content": "The secret is..."
   }

2. Alice specifies ACL:
   {
     "owner": "alice@betty.land",
     "permissions": {
       "bob@betty.land": 4
     }
   }

3. System generates random symmetric key K
4. System encrypts document with K → C
5. System encrypts K to Alice's public key → K_alice
6. System encrypts K to Bob's public key → K_bob
7. System stores:
   {
     "betty": {
       "owner": "alice@betty.land",
       "permissions": {
         "bob@betty.land": 4
       }
     },
     "meta": {
       "encryption": {
         "recipients": {
           "alice@betty.land": K_alice,
           "bob@betty.land": K_bob
         }
       }
     },
     "content": C
   }

A.3 Bob Reads the Document

1. Bob requests document (signed request)
2. Node verifies Bob's signature → authenticated
3. Node returns encrypted document
4. Bob's client finds K_bob in recipients
5. Bob decrypts K_bob with his private key → K
6. Bob decrypts C with K → original document
7. Success! Bob can read (has permission 4)

A.4 Bob Attempts to Edit (Permission Denied)

1. Bob modifies document locally
2. Bob signs upsert request
3. Node verifies signature → authenticated as Bob
4. Node decrypts ACL (using Bob's key, since he has read access)
5. Node checks permissions: Bob has 4 (r--), needs 6 (rw-)
6. Node returns error:
   {
     "error": "Unauthorized",
     "message": "Write permission required",
     "current_permission": 4,
     "required_permission": 6
   }

A.5 Carol Blind Appends to Public Inbox

Note: this example refers to [NBSON] and its use of Poor Richard's Pseudo-Homomorphism or PRPH, which uses keymaps to modify encrypted values without having to decrypt them. In NBSON, queue documents may be appended by adding a line to the end of the file, with individual encryption.

1. Carol creates message (not encrypted yet):
   {
     "from": "carol@betty.land",
     "message": "Anonymous feedback here"
   }

2. Carol encrypts message to inbox owner's public key → M_encrypted

3. Carol signs append request:
   {
     "routing": {
       "from": "carol@betty.land",
       "operation": "append",
       "target": "betty://local/inbox/abc123",
       "signatures": [...]
     },
     "payload": M_encrypted
   }

4. Node verifies signature → authenticated as Carol
5. Node checks permissions: @world has 3 (-wx)
6. Node uses PRPH to append without decrypting existing content:
   - Reads NBSON index line
   - Locates append point
   - Writes M_encrypted to queue
   - Updates index
7. Success! Carol appended without reading

8. Alice (inbox owner) later reads:
   - Decrypts entire queue with her private key
   - Sees Carol's message and all others

Appendix B: Error Responses

B.1 Unauthenticated

Cause: Cannot decrypt document with available keys

{
  "routing": {
    "from": "system",
    "to": "requesting-identity"
  },
  "meta": {
    "tags": ["error", "authentication"]
  },
  "payload": {
    "error": "Unauthenticated",
    "message": "Cannot decrypt document with available keys",
    "required": "Private key corresponding to one of the recipient public keys",
    "available_recipients": [
      "alice@betty.land",
      "bob@betty.land"
    ]
  }
}

Scenarios:

• User lacks private key for any recipient
• Document not encrypted to user's public key
• Corrupted encryption metadata

B.2 Unauthorized

Cause: Insufficient permissions for requested operation

{
  "routing": {
    "from": "system",
    "to": "bob@betty.land"
  },
  "meta": {
    "tags": ["error", "authorization"]
  },
  "payload": {
    "error": "Unauthorized",
    "message": "Insufficient permissions for operation",
    "operation": "upsert",
    "required_permission": 6,
    "current_permission": 4,
    "permission_breakdown": {
      "read": true,
      "write": false,
      "index": false
    },
    "suggestion": "Request write access from owner or create forked copy"
  }
}

Scenarios:

• Write attempt with read-only permission (4)
• Index attempt without index bit (permission < 1)
• Upsert attempt with write-only permission (2)

B.3 SignatureInvalid

Cause: Signature verification failed

{
  "routing": {
    "from": "system"
  },
  "meta": {
    "tags": ["error", "authentication", "signature"]
  },
  "payload": {
    "error": "SignatureInvalid",
    "message": "Signature verification failed",
    "identity": "bob@betty.land",
    "signature_algorithm": "ed25519",
    "possible_causes": [
      "Message was tampered with",
      "Wrong private key used for signing",
      "Public key mismatch",
      "Corrupted signature data"
    ]
  }
}

B.4 TimestampExpired

Cause: Request timestamp too old

{
  "routing": {
    "from": "system"
  },
  "meta": {
    "tags": ["error", "replay-protection"]
  },
  "payload": {
    "error": "TimestampExpired",
    "message": "Request timestamp outside acceptable window",
    "request_timestamp": "2025-11-15T10:00:00Z",
    "server_time": "2025-11-16T10:00:00Z",
    "max_age_seconds": 300,
    "suggestion": "Synchronize system clock and retry"
  }
}

B.5 KeyNotFound

Cause: Required key not in PKI system

{
  "routing": {
    "from": "system"
  },
  "meta": {
    "tags": ["error", "key-management"]
  },
  "payload": {
    "error": "KeyNotFound",
    "message": "Required public key not found in PKI",
    "identity": "unknown@betty.land",
    "key_type": "encryption",
    "suggestion": "Ensure identity is registered at betty://betty.land/api/v1/keys/unknown@betty.land"
  }
}

Appendix C: Permission Decision Trees

C.1 Read Access Decision

Can user read document?
│
├─ Is user the owner?
│  └─ YES → Allow (owner always has full access)
│
├─ Can user decrypt ACL?
│  ├─ NO → Deny (Unauthenticated)
│  └─ YES → Continue
│
├─ User's permission value & 4 (read bit)?
│  ├─ NO → Deny (Unauthorized)
│  └─ YES → Allow
│
└─ Can user decrypt content?
   ├─ NO → Deny (Unauthenticated - key not in recipients)
   └─ YES → Success!

C.2 Write Access Decision

Can user write (upsert) document?
│
├─ Is user the owner?
│  └─ YES → Allow
│
├─ Can user decrypt ACL?
│  ├─ NO → Deny (Unauthenticated)
│  └─ YES → Continue
│
└─ User's permission value & 2 (write bit)?
   ├─ NO → Check if forked writes enabled
   │  ├─ NO → Deny (Unauthorized)
   │  └─ YES & user has read (4)?
   │     ├─ YES → Allow fork (new topic)
   │     └─ NO → Deny (Unauthorized)
   │
   └─ YES → User's permission value & 4 (read bit)?
      ├─ NO → Deny (Upsert requires read+write, suggest append)
      └─ YES → Allow

C.3 Append Access Decision

Can user append to document?
│
├─ Is user the owner?
│  └─ YES → Allow
│
├─ Can user decrypt ACL?
│  ├─ NO → Deny (Unauthenticated)
│  └─ YES → Continue
│
└─ User's permission value & 2 (write bit)?
   ├─ NO → Deny (Unauthorized)
   └─ YES → Check PRPH configuration
      │
      ├─ User's permission value & 4 (read bit)?
      │  └─ YES → Allow (read+write)
      │
      └─ PRPH level >= 2 (blind-append)?
         ├─ YES → Allow (blind append)
         └─ NO → Deny (Read required for append)

C.4 Index Access Decision

Can user add document to index?
│
├─ Is user the owner?
│  └─ YES → Allow
│
├─ Can user decrypt ACL?
│  ├─ NO → Deny (Unauthenticated)
│  └─ YES → Continue
│
└─ User's permission value & 1 (index bit)?
   ├─ NO → Deny (Unauthorized)
   └─ YES → Allow

Authors' Addresses

The BeTTY Project
https://betty.land
Email: betty-protocol@betty.land

Full Copyright Statement

Copyright (C) The BeTTY Project (2025). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.

This document itself may not be modified in any way, such as by removing the copyright notice or references to the BeTTY Project, except as needed for the purpose of developing BeTTY standards in which case the procedures for copyrights defined in the BeTTY Process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the BeTTY Project or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE BETTY PROJECT DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

End of RFC