TriadicFrameworks
Обзор

RFC‑REV‑0024: Revocation and Re‑Signing Protocol

Title: Signature Revocation and Re‑Signing for Remix Scrolls
Status: Draft
Author: Nawder Loswin + Copilot
Date: 2025‑11‑12
Version: 0.1

1. Purpose#

Provide contributors with a secure mechanism to revoke compromised signatures and re‑sign scrolls without breaking lineage continuity. This ensures validator‑grade authenticity while maintaining collaborative authorship across remix generations.

2. Workflow Steps#

  1. Revocation Request

    • Contributor submits revocation event citing compromised signature.
    • Registry marks signature as revoked in verification schema.
    • Scroll remains valid but flagged for re‑signing.

  2. Re‑Signing Invitation

    • Contributors notified via subscription service (RFC‑SUB‑0019).
    • Scroll enters “pending re‑signing” stage in cycle monitoring dashboard.

  3. Signature Replacement

    • Contributor generates new signature (PGP/ECDSA/symbolic).
    • New signature appended to scroll metadata.
    • Revoked signature preserved in dignity layer for historical trace.

  4. Lineage Continuity

    • Scroll lineage index updated to include both revoked and re‑signed events.
    • Ancestry graph shows continuity: revoked signature → re‑signed signature.

  5. Verification Report Update

    • Signature Verification Service (RFC‑VER‑0023) re‑validates scroll.
    • Report updated with new contributor status.

3. Schema Extension#

File: registry/signatures/revocation_schema.yml

4. API Endpoints#

  • POST /signatures/revoke → Submit revocation event.
  • POST /signatures/resign → Submit replacement signature.
  • GET /signatures/status/{scroll_id} → Retrieve signature status for a scroll.
  • GET /signatures/history/{contributor_id} → View contributor’s revocation/re‑sign history.

5. Python‑style Stub#

File: api/revocation_service.py

6. Dashboard Integration#

  • Revocation Panel: Contributors submit revocation requests.
  • Re‑Signing Panel: Contributors upload replacement signatures.
  • Lineage Graph Overlay: Nodes show revoked → re‑signed transitions.
  • Verification Badge: Scroll marked “authorship re‑signed” once validated.

7. Validator Hooks#

  • Schema compliance: Revocation events must match revocation_schema.yml.
  • Checksum: Each revocation/re‑sign event includes checksum for reproducibility.
  • Lineage integrity: Revoked signatures preserved in ancestry index.
  • Dignity separation: Revocation reasons stored distinctly from narratives.

8. Concept Sketch (textual)#

Scroll: scroll-010
 └─ Contributor: user42
 └─ Signature: revoked (reason: compromised)
 └─ Replacement Signature: valid (PGP)
 └─ Status: re-signed
 └─ Lineage: scroll-003 → scroll-010 (authorship continuity preserved)

This Revocation and Re‑Signing Protocol ensures compromised signatures can be revoked and replaced without breaking lineage continuity, preserving validator‑grade authenticity and collaborative dignity.

Updated

Работает на Docsbook
RFC‑REV‑0024 Revocation And Re‑Signing Protocol — TriadicFrameworks