Node Membership Credentials

Bucket replication policies are payload placement policies. They are not just read or decrypt permissions. Unauthorized nodes may sync block, transaction, and record metadata, but they must not store or serve the bucket's encrypted payload bytes.

Credential Model

Each node has an Ed25519 node identity keypair. Each organization has an organization signing key published in chain state as the organization's trusted public key. The organization issues signed node membership credentials:

{
  "credentialId": "credential-node-a-2026-05",
  "nodeId": "node-a",
  "organizationId": "org-noos",
  "nodePublicKey": "-----BEGIN PUBLIC KEY-----...",
  "permissions": ["replicate", "serve_payloads"],
  "issuedAt": "2026-05-25T00:00:00.000Z",
  "expiresAt": "2026-06-25T00:00:00.000Z",
  "issuer": "org-noos",
  "signature": "base64-ed25519-signature-by-org-private-key"
}

The signature covers the canonical credential payload without the signature field. issuer must match organizationId; delegated issuers are not accepted by the current verifier.

Handshake

Before payload replication, a peer must prove both organization membership and possession of the node private key:

1. The requesting node presents its membership credential.
2. The requesting node signs a challenge with the node private key named in the credential.
3. The serving node verifies:
   • the credential schema is valid;
   • the credential was signed by the organization's trusted public key;
   • issuedAt and expiresAt are valid for the current time;
   • the organization has not revoked the credential id or node public key in organization metadata;
   • the node exists in chain state, is active, belongs to the credential organization, and has the credential public key;
   • the challenge issuedAt is fresh within the configured verifier window;
   • the challenge signature verifies against the credential node public key;
   • the credential includes replicate.

Payload endpoints bind the signed challenge to the HTTP method, path, and record ids. This prevents a proof for one payload request from being replayed against a different payload request.

Placement Rules

For replicate_encrypted_to_all_nodes, encrypted payload bytes may be stored by any verified active node following normal payload-hash verification. For per_bucket_key buckets, organization bucket-key envelopes may be shared with active node organizations under the same strategy.

For metadata_only, encrypted payload bytes are not replicated or stored by availability backfill. Organization bucket-key envelopes are not shared for node replication under this strategy; application users still need user-specific key envelopes when they are allowed to decrypt through normal bucket access.

For replicate_encrypted_to_authorized_nodes, the local node must have a verified membership credential with replicate, and then bucket placement is allowed only when:

• the node belongs to the bucket creator organization; or
• the node belongs to an organization with bucket:read_encrypted or bucket:admin for the bucket.

For per_bucket_key buckets, bucket-key sharing follows the same boundary: organization envelopes are accepted only for organizations that the bucket's replication policy would allow as node payload custodians. User envelopes remain governed by normal bucket encrypted-read/admin access.

If a bucket has no explicit access rules, the creator organization remains the only implicit payload-placement organization. Other organizations must receive an explicit bucket access rule before their verified nodes can store payload bytes.

Raw local configuration such as organizationId: "org-noos" is never sufficient to receive or serve encrypted payload bytes. replicate_encrypted_to_all_nodes means all verified active nodes, not anonymous processes or raw public-key headers.

Bucket-Key Rotation

Bucket-key creation and rotation validate every key-envelope recipient against the bucket replication strategy and current access rules. Removing bucket:read_encrypted or bucket:admin stops that organization from appearing in new bucket-key versions. Existing per_bucket_key versions can remain decryptable by old envelope recipients, so cryptographic revocation requires rotating the bucket key after access is removed.

Current Revocation Hook

The verifier checks organization metadata for:

{
  "revokedNodeCredentialIds": ["credential-node-a-2026-05"],
  "revokedNodePublicKeys": ["-----BEGIN PUBLIC KEY-----..."]
}

Future governance can move revocation into a dedicated consensus table without changing the credential verification contract.