Proof of Process: Collaborative Authorship Extension

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 .

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

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.

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-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 } ]]>

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

Attestation Content The attestation binds the collaborator's identity to specific checkpoints and contribution claims, enabling per-contributor accountability.

Attestation Timing Collaborator attestations may be collected:

Incrementally: Each collaborator signs after their contribution period ends.
At export: All collaborators sign when the Evidence packet is finalized.
Post-hoc: Collaborators sign after reviewing the complete Evidence (attestation-timestamp will be later than final checkpoint).

The attestation-timestamp enables Verifiers to determine when each collaborator endorsed the Evidence.

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

Verify that all collaborator-attestation signatures are valid.
Verify that checkpoint-ranges claimed by collaborators do not have unexplained gaps (all checkpoints should be attributed).
Verify that checkpoint-ranges do not overlap for modes that prohibit concurrent editing (sequential mode).
For merge events, verify that the merge-time falls within the active-periods of the merged contributors.
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

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.

Collaborative Evidence Example Academic paper with three co-authors:

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 . Full security considerations for the Proof of Process format are specified in .

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