Proof of Process: Collaborative Authorship Extension

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 10 August 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

This document defines mechanisms for documenting collaborative authorship where multiple contributors produce a single work. The collaborative model enables each contributor to attest to their individual contributions while maintaining a unified Evidence chain for the combined document.¶

This extension is defined as a companion to the main Proof of Process specification [I-D.condrey-rats-pop].¶

2. Motivation

Modern knowledge work is frequently collaborative:¶

• Academic papers with multiple co-authors¶
• Legal documents drafted by teams¶
• Technical documentation with subject matter experts¶
• Creative works with co-writers or editors¶

The base Proof of Process Evidence model assumes a single author with one signing key. Without explicit collaboration support, teams must either:¶

• Designate one member to generate Evidence, losing attribution for other contributors.¶
• Generate separate Evidence packets and link them via provenance, losing unified document history.¶
• Share a single signing key, compromising individual accountability.¶

The collaborative authorship model addresses these limitations by enabling multiple contributors to independently attest to their contributions within a shared Evidence structure.¶

3. Collaboration Section Structure

The collaboration section is an optional component of the Evidence packet, identified by integer key 22. It documents the participants and their respective contributions.¶

; Collaboration section for multi-author works
; Key 22 in evidence-packet
collaboration-section = {
    1 => collaboration-mode,         ; mode
    2 => [+ collaborator],           ; participants
    ? 3 => [+ contribution-claim],   ; contributions
    ? 4 => merge-record,             ; merge-history
    ? 5 => collaboration-policy,     ; governance
}

collaboration-mode = &(
    sequential: 1,                   ; One active author at a time
    parallel: 2,                     ; Concurrent editing, merged
    delegated: 3,                    ; Primary author + contributors
    peer-review: 4,                  ; Author + reviewers/editors
)

; Individual collaborator record
collaborator = {
    1 => cose-key,                   ; collaborator-pubkey
    2 => collaborator-role,          ; role
    ? 3 => tstr,                     ; display-name
    ? 4 => tstr,                     ; identifier (ORCID, etc.)
    5 => [+ time-interval],          ; active-periods
    ? 6 => [+ uint],                 ; checkpoint-ranges (indices)
    7 => cose-signature,             ; collaborator-attestation
    ? 8 => contribution-summary,     ; contribution-stats
}

collaborator-role = &(
    primary-author: 1,               ; Main/lead author
    co-author: 2,                    ; Equal contributor
    contributing-author: 3,          ; Section/chapter contributor
    editor: 4,                       ; Editorial contributions
    reviewer: 5,                     ; Review comments incorporated
    technical-contributor: 6,        ; Data, code, figures
    translator: 7,                   ; Translation work
)

; Summary of a collaborator's contributions
contribution-summary = {
    1 => uint,                       ; checkpoints-authored
    2 => uint,                       ; chars-added
    3 => uint,                       ; chars-deleted
    4 => duration,                   ; active-time
    ? 5 => float32,                  ; estimated-contribution-pct
}

; Detailed contribution claims
contribution-claim = {
    1 => contribution-type,          ; type
    2 => cose-key,                   ; contributor-key
    ? 3 => [+ uint],                 ; checkpoint-indices
    ? 4 => tstr,                     ; description
    ? 5 => float32,                  ; extent (0.0-1.0)
}

contribution-type = &(
    original-content: 1,             ; New text/content
    editing: 2,                      ; Revisions to existing content
    research: 3,                     ; Research contribution
    data-analysis: 4,                ; Data/analysis contribution
    figures-tables: 5,               ; Visual elements
    code: 6,                         ; Code contributions
    review-feedback: 7,              ; Review that influenced content
    structural: 8,                   ; Organization/structure
)

; Record of merge operations
merge-record = {
    1 => [+ merge-event],            ; merges
}

merge-event = {
    1 => pop-timestamp,              ; merge-time
    2 => uint,                       ; resulting-checkpoint
    3 => [+ cose-key],               ; merged-contributors
    ? 4 => merge-strategy,           ; strategy
    ? 5 => tstr,                     ; merge-note
}

merge-strategy = &(
    sequential-append: 1,            ; Sections appended in order
    interleaved: 2,                  ; Content merged throughout
    conflict-resolved: 3,            ; Conflicts manually resolved
    automated: 4,                    ; Automated merge tool
)

; Collaboration governance policy
collaboration-policy = {
    ? 1 => uint,                     ; min-approvers-for-merge
    ? 2 => bool,                     ; requires-all-signatures
    ? 3 => tstr,                     ; policy-uri
}

4. Collaborator Attestation

Each collaborator provides an independent attestation of their contribution. This enables Verifiers to confirm that each participant acknowledged their role.¶

collaborator-attestation = COSE_Sign1(
    payload = CBOR_encode({
        1: packet-id,                ; Evidence packet ID
        2: collaborator-pubkey,      ; Attesting collaborator's key
        3: role,                     ; Declared role
        4: active-periods,           ; When contributor was active
        5: checkpoint-ranges,        ; Which checkpoints they authored
        6: contribution-summary,     ; Self-reported contribution stats
        7: attestation-timestamp,    ; When attestation was made
    }),
    key = collaborator-private-key
)

5. Verification of Collaborative Evidence

Verifiers of collaborative Evidence MUST perform additional checks beyond single-author verification:¶

1. Verify that all collaborator-attestation signatures are valid.¶
2. Verify that checkpoint-ranges claimed by collaborators do not have unexplained gaps (all checkpoints should be attributed).¶
3. Verify that checkpoint-ranges do not overlap for modes that prohibit concurrent editing (sequential mode).¶
4. For merge events, verify that the merge-time falls within the active-periods of the merged contributors.¶
5. Verify that contribution-summary statistics are plausible given the checkpoint data (e.g., chars-added should not exceed total chars in attributed checkpoints).¶

The Attestation Result SHOULD document:¶

• Number of collaborators and their roles¶
• Whether all collaborator attestations were verified¶
• Any gaps in checkpoint attribution¶
• Consistency of contribution claims¶

6. Privacy Considerations

Collaborative Evidence inherently reveals information about multiple individuals. Participants SHOULD consider:¶

• Collaborator public keys may be linkable across documents. Contributors may use per-document keypairs for privacy.¶
• Active-periods reveal when each contributor was working, which may be sensitive in some contexts.¶
• Contribution percentages may be contentious; participants SHOULD agree on methodology before Evidence generation.¶
• Reviewer/editor roles reveal the review process, which may be confidential for some publications.¶

7. Collaborative Evidence Example

Academic paper with three co-authors:¶

collaboration-section = {
  1: 2,
  2: [
    {
      1: h'alice-cose-key...',
      2: 1,
      3: "Alice Smith",
      4: "orcid:0000-0001-2345-6789",
      5: [
        {1: 1(1704067200), 2: 1(1706745600)},
      ],
      6: (0, 45),
      7: h'alice-attestation...',
      8: {
        1: 46,
        2: 12500,
        3: 800,
        4: 14400.0,
        5: 0.45
      }
    },
    {
      1: h'bob-cose-key...',
      2: 2,
      3: "Bob Jones",
      5: ({1: 1(1705276800), 2: 1(1706140800)}),
      6: (46, 82),
      7: h'bob-attestation...',
      8: {1: 37, 2: 8900, 3: 450, 4: 10800.0, 5: 0.32}
    },
    {
      1: h'carol-cose-key...',
      2: 3,
      3: "Carol Lee",
      5: ({1: 1(1706400000), 2: 1(1706745600)}),
      6: (83, 105),
      7: h'carol-attestation...',
      8: {1: 23, 2: 5200, 3: 200, 4: 7200.0, 5: 0.23}
    }
  ],
  3: [
    {1: 1, 2: h'alice-key...', 4: "Introduction, Methods"},
    {1: 4, 2: h'bob-key...', 4: "Results, Data Analysis"},
    {1: 5, 2: h'carol-key...', 4: "Figures and Tables"}
  ],
  4: {
    1: [
      {
        1: 1(1706659200),
        2: 100,
        3: (h'alice-key...', h'bob-key...', h'carol-key...'),
        4: 3,
        5: "Final integration of all sections"
      }
    ]
  }
}

8. Security Considerations

Collaborative authorship introduces additional security considerations beyond single-author Evidence:¶

• Key compromise scope: Compromise of one collaborator's key affects only their claimed checkpoints, not the entire document Evidence.¶
• Collusion attacks: Multiple collaborators could collude to fabricate a document history. Verifiers SHOULD consider the number of independent attestations.¶
• Contribution disputes: This format documents claims but cannot resolve disputes about who truly authored content. External arbitration may be needed.¶
• Replay of attestations: Attestations are bound to specific packet-ids to prevent reuse across documents.¶

Collaborator attestations use COSE signatures as defined in [RFC9052]. Full security considerations for the Proof of Process format are specified in [I-D.condrey-rats-pop].¶

9. IANA Considerations

This document has no IANA actions. The collaboration section uses key 22 as defined in the main architecture document.¶

Author's Address