



Network Working Group                                        B. Morrison
Internet-Draft                                    Alter Meridian Pty Ltd
Intended status: Informational                               18 May 2026
Expires: 19 November 2026


  Reviewed-By Trailer: Sovereign-Portable Peer-Review Attribution for
                      Content-Hash-Bound Artefacts
                 draft-morrison-reviewed-by-trailer-01

Abstract

   This document defines a trailer grammar for sovereign-portable peer
   review as an extension of the identity-attributed commit grammar in
   [COMMITS].  The grammar introduces one required trailer (Reviewed-
   By:) and three optional companion trailers (Review-Stance:, Review-
   Of:, Witnessed-By:) that bind a Sovereign-tier ~handle to a specific
   act of review over a specific content artefact, cryptographically
   signed using the Ed25519 mechanism of [COMMITS].  The mechanism
   applies uniformly to git commits, document manifests, pre-prints,
   patent disclosures, and any other content-addressable artefact.
   Reviewer reputation accumulates on the sovereign handle rather than
   on a publisher's platform, making reviewer trust portable across
   journals, pre-print servers, and private review contexts.
   Pseudonymous review for anonymous peer-review processes is supported
   by permitting a Sovereign handle whose underlying party is concealed
   through out-of-band key custody, preserving full cryptographic
   verifiability of the review act without disclosing the reviewer's
   underlying identity.  The grammar is positioned as complementary to
   CRediT [CREDIT], ORCID [ORCID], and DOI [DOI] attribution
   infrastructure, not as a replacement for them.

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 19 November 2026.



Morrison                Expires 19 November 2026                [Page 1]

Internet-Draft             Reviewed-By Trailer                  May 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.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   3
   2.  Copyright Notice  . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Requirements Language . . . . . . . . . . . . . . . . . .   6
     4.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Identity Tier Taxonomy (Informative Reference)  . . . . . . .   7
   6.  Trailer Grammar (Normative) . . . . . . . . . . . . . . . . .   8
     6.1.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.2.  Placement . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.3.  Ordering  . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.4.  Multiplicity Rules  . . . . . . . . . . . . . . . . . . .   9
   7.  Signature Algorithm (Normative) . . . . . . . . . . . . . . .  10
     7.1.  Algorithm and Signed Payload  . . . . . . . . . . . . . .  10
     7.2.  Rationale for Canonicalised-Content-Hash Signing  . . . .  11
     7.3.  Signature Format  . . . . . . . . . . . . . . . . . . . .  11
   8.  DNS Resolution (Normative Reference)  . . . . . . . . . . . .  11
     8.1.  Reviewer Key Resolution . . . . . . . . . . . . . . . . .  11
     8.2.  Witness Resolution  . . . . . . . . . . . . . . . . . . .  12
   9.  Verifier Behaviour (Normative)  . . . . . . . . . . . . . . .  12
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  13
     10.1.  Reviewer Reputation Portability  . . . . . . . . . . . .  13
     10.2.  Pseudonymity and Anonymous Peer Review . . . . . . . . .  14
     10.3.  Review Spam  . . . . . . . . . . . . . . . . . . . . . .  14
     10.4.  Review Bribery and Conflict of Interest  . . . . . . . .  14
     10.5.  Witness Collusion  . . . . . . . . . . . . . . . . . . .  15
     10.6.  Content-Hash Forgery . . . . . . . . . . . . . . . . . .  15
     10.7.  Key Custody at the Review-Signing Boundary . . . . . . .  15
     10.8.  Negative Attribution: Missing Review Disclosure  . . . .  15



Morrison                Expires 19 November 2026                [Page 2]

Internet-Draft             Reviewed-By Trailer                  May 2026


   11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  15
     11.1.  Pseudonymity as a First-Class Concern  . . . . . . . . .  16
     11.2.  DNS-Linkability Risk . . . . . . . . . . . . . . . . . .  16
     11.3.  Right to Withdraw a Review . . . . . . . . . . . . . . .  16
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
     12.1.  Trailer Name Registration  . . . . . . . . . . . . . . .  16
     12.2.  Stance Value Registry  . . . . . . . . . . . . . . . . .  17
     12.3.  No Other IANA Actions  . . . . . . . . . . . . . . . . .  17
   13. Relationship to Existing Standards  . . . . . . . . . . . . .  17
   14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  19
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     15.2.  Informative References . . . . . . . . . . . . . . . . .  20
   16. Author's Address  . . . . . . . . . . . . . . . . . . . . . .  20
   17. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     17.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     17.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22

1.  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 October 13, 2026.

2.  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.







Morrison                Expires 19 November 2026                [Page 3]

Internet-Draft             Reviewed-By Trailer                  May 2026


3.  Introduction

3.1.  Problem Statement

   Peer review of scholarly, scientific, and technical artefacts is
   today captured by a small number of publishing intermediaries whose
   editorial platforms hold the only durable record of a reviewer's
   contribution.  When a reviewer accepts an invitation from a journal,
   the journal records the review against an internal reviewer profile;
   when the reviewer moves to another venue, that record does not travel
   with them.  The mechanisms currently available for attaching reviewer
   identity to a review are fragmented and individually inadequate:

   *  *Journal reviewer databases.* Each publisher (Elsevier, Springer
      Nature, Wiley, PLOS) maintains an internal reviewer profile.
      Reviewer reputation is platform-local.  Migrating between
      publishers re-roots reputation.

   *  *ORCID reviewer credit [ORCID].* ORCID supports a "Peer Review"
      activity type in which a publisher asserts that a given ORCID iD
      performed a review.  The assertion is publisher-attested; the
      reviewer cannot publish a review record without publisher
      cooperation, and cannot cryptographically demonstrate the review
      occurred without that cooperation.

   *  *CRediT contributor roles [CREDIT].* CRediT is a controlled
      vocabulary for author-level contribution (conceptualisation,
      methodology, writing, etc.).  It is orthogonal to review: CRediT
      describes what authors did, not what reviewers said.

   *  *Open-review initiatives (eLife [ELIFE-OPENREVIEW], F1000, arXiv
      trackbacks).* These publish review content openly but continue to
      locate reviewer identity inside the publisher's platform; leaving
      the platform ends the review's discoverability.

   *  *COPE guidance [COPE].* Establishes ethical norms for peer review
      but does not specify a format, attribution mechanism, or
      cryptographic binding.

   None of the above provides a provider-neutral, DNS-resolvable,
   cryptographically-bound attribution mechanism for peer review that
   lets a reviewer accumulate portable reputation outside any
   publisher's platform.

3.2.  Design Goals

   This document defines a review-trailer grammar with the following
   goals:



Morrison                Expires 19 November 2026                [Page 4]

Internet-Draft             Reviewed-By Trailer                  May 2026


   1.  *Provider-neutral.* No dependency on any specific publisher, pre-
       print server, or editorial platform.

   2.  *Sovereign-portable.* Reviewer reputation accumulates on the
       reviewer's sovereign ~handle rather than on any publisher's
       platform.  A reviewer who moves between journals, or between open
       review and private review, carries their signed review history
       with them.

   3.  *Content-bound.* Every review trailer is bound to a specific
       content hash, so that a review of version 1 of a manuscript
       cannot be silently re-attributed to version 2.

   4.  *Cryptographically verifiable.* Review attribution is bound by an
       Ed25519 signature whose public key is reachable from DNS without
       prior trust establishment, reusing the signature model of
       [COMMITS].

   5.  *Pseudonymity-preserving.* Anonymous peer review remains a load-
       bearing institution in some disciplines.  The grammar supports
       pseudonymous review by permitting a Sovereign handle whose
       underlying party is concealed through out-of-band key custody,
       retaining cryptographic verifiability of the review act without
       disclosing the reviewer's underlying identity.

   6.  *Category-safe against misattribution.* Conformant parsers reject
       cross-tier handle placement (e.g., an Instrument-tier handle in a
       Reviewed-By: slot) as a structural grammar violation, not a
       policy decision.

3.3.  Scope

   This document specifies:

   *  The Reviewed-By:, Review-Stance:, Review-Of:, and Witnessed-By:
      trailer grammar in ABNF [RFC5234].

   *  Reuse of the Identity-Signature:, Identity-Key-Id:, and Identity-
      Anchor: cryptographic trailers from [COMMITS].

   *  Multiplicity, placement, and ordering rules.

   *  Verifier behaviour for accepting, rejecting, and surfacing review
      states.

   *  Security and privacy considerations specific to peer review.

   This document does NOT specify:



Morrison                Expires 19 November 2026                [Page 5]

Internet-Draft             Reviewed-By Trailer                  May 2026


   *  The ~handle identity primitive itself, which is defined by
      [MCPDNS] and incorporated by reference through [COMMITS].

   *  The normative tier taxonomy, which is defined in [COMMITS]
      Section 3 and restated briefly in Section 3 of this document.

   *  An editorial workflow or an editorial decision algorithm.  This
      document defines an attribution grammar, not a review process.

   *  The economic rails for reviewer compensation.  These are out of
      scope; the anti-extraction posture of Section 8 is summarised at
      the level required to motivate protocol-layer design choices.

4.  Terminology

4.1.  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 RFC2119 [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

4.2.  Definitions

   Handle  A ~-prefixed identifier per [MCPDNS], as incorporated into
      [COMMITS].  Handles are the unit of identity addressing in this
      document.

   Sovereign Tier Handle  Per [COMMITS] Section 2.2.  A handle
      representing a human individual or formal organisation with direct
      cryptographic agency; holds its own private key; can sign.

   Pseudonymous Sovereign Handle  A Sovereign-tier handle whose
      underlying real-world party is intentionally concealed.  No
      syntactic marker distinguishes a pseudonymous Sovereign handle
      from a directly-identified one; the distinction is policy-level
      and is held by the reviewer (or by an editorial intermediary)
      through out-of-band key custody and assignment records.
      Pseudonymous Sovereign handles sign with the same cryptographic
      weight as any other Sovereign handle and are admissible wherever a
      Sovereign handle is admissible.

   Instrument Tier Handle  Per [COMMITS] Section 2.2.  A handle
      representing an AI model, API endpoint, or tool class; holds no
      key; cannot sign.  Instrument handles are inadmissible in review
      slots.




Morrison                Expires 19 November 2026                [Page 6]

Internet-Draft             Reviewed-By Trailer                  May 2026


   Review Act  A discrete act of evaluation performed by a Sovereign
      reviewer against a specific content artefact identified by content
      hash.  A review act produces one trailer block.

   Content Hash  A cryptographic digest (SHA-256 or SHA-512, or the git
      object hash family of [COMMITS]) of the canonicalised artefact
      being reviewed.  The hash binds the review to a specific manifest
      state and prevents silent re-attribution across revisions.

   Review Stance  A controlled-vocabulary enumeration of the reviewer's
      disposition toward the artefact.  Permitted values are accept,
      reject, revise, endorse, and dispute.

   Witness  A second Sovereign-tier handle that attests to having
      observed the review act being performed, without taking review
      responsibility.  Used for signing ceremonies and high-stakes
      review contexts (patent disclosures, adversarial reviews).

   Conformant Verifier  A consumer of review trailers that implements
      the parsing, rejection, and signature-verification rules defined
      in Section 7.

5.  Identity Tier Taxonomy (Informative Reference)

   The review-trailer grammar reuses the three-tier taxonomy defined in
   [COMMITS] Section 3 without extension.  Pseudonymous review is
   expressed as a Sovereign handle whose underlying party is concealed
   through out-of-band key custody (Section 2.2); no separate tier or
   syntactic suffix is introduced.

   +============+===============+================+=====================+
   | Tier       | Cryptographic | Admissible in  | Examples            |
   |            | Agency        | Reviewed-By:   |                     |
   |            |               | / Witnessed-   |                     |
   |            |               | By:            |                     |
   +============+===============+================+=====================+
   | Sovereign  | Holds own     | Yes            | ~alice,             |
   |            | key, signs    |                | ~example.com,       |
   |            |               |                | ~reviewer-kappa     |
   +------------+---------------+----------------+---------------------+
   | Bot        | Scoped        | No             | ~example-deps.bot,  |
   |            | delegated key |                | ~example-triage.bot |
   +------------+---------------+----------------+---------------------+
   | Instrument | No key, no    | No             | ~example-model-1,   |
   |            | signature     |                | ~example-model-2    |
   +------------+---------------+----------------+---------------------+

                                  Table 1



Morrison                Expires 19 November 2026                [Page 7]

Internet-Draft             Reviewed-By Trailer                  May 2026


   The Bot and Instrument tiers are inadmissible in review slots because
   peer review is an attestational act that requires cryptographic
   sovereign agency.  Conformant verifiers MUST reject cross-tier
   placement per Section 7.  Where AI-instrument involvement in review
   drafting must be disclosed, the separate Drafted-With: trailer of
   [COMMITS] SHOULD be used alongside Reviewed-By:.

6.  Trailer Grammar (Normative)

6.1.  ABNF

   The following ABNF [RFC5234] defines the syntax of each trailer.
   Implementations MUST accept exactly this grammar.  Terminals not
   defined here are imported from [RFC5234] or from [COMMITS]
   Section 4.1.

   ``` reviewed-by-trailer = "Reviewed-By:" SP review-handle CRLF
   review-stance-trailer = "Review-Stance:" SP stance-value CRLF review-
   of-trailer = "Review-Of:" SP content-hash-ref CRLF witnessed-by-
   trailer = "Witnessed-By:" SP sovereign-handle CRLF

   review-handle = sovereign-handle sovereign-handle = "~" handle-label
   ; per [COMMITS] Section 4.1

   stance-value = "accept" / "reject" / "revise" / "endorse" / "dispute"

   content-hash-ref = hash-algorithm ":" hash-value hash-algorithm =
   "sha256" / "sha512" / "git-sha1" / "git-sha256" hash-value = 1*HEXDIG

   handle-label = 1*63( ALPHA / DIGIT / "-" / "_" / "." ) ; per
   [COMMITS] ```

   Pseudonymous review is grammatically indistinguishable from direct-
   identity review: both forms appear as a sovereign-handle production.
   Whether the underlying party is concealed is a policy-level property
   held out-of-band by the reviewer (or by an editorial intermediary
   that manages pseudonym assignment) and is not exposed in the trailer
   grammar.  Cryptographic verification proceeds identically in either
   case.

   The cryptographic trailers Identity-Signature:, Identity-Key-Id:, and
   Identity-Anchor: are imported unchanged from [COMMITS] Section 4.1
   and MAY appear in a review trailer block under the multiplicity rules
   of Section 4.4 below.







Morrison                Expires 19 November 2026                [Page 8]

Internet-Draft             Reviewed-By Trailer                  May 2026


6.2.  Placement

   Review trailers MUST appear in the trailer/footer block of the
   containing artefact.  For git commits, this is the commit message
   footer as defined in [COMMITS] Section 4.2.  For document manifests
   (e.g., a REVIEW.md review record, a manifest appended to a pre-print,
   or a trailer block embedded in a patent disclosure submission form),
   the trailer block MUST appear as the final block of the document,
   separated from the preceding content by exactly one blank line.

   A review trailer block is distinguished from a commit trailer block
   of [COMMITS] by the presence of at least one Reviewed-By: trailer.
   The two trailer types MAY coexist on the same artefact: for example,
   a pre-print draft committed to a git repository MAY carry both an
   Acted-By: trailer (attributing the commit) and a Reviewed-By: trailer
   (attributing a subsequent review of the committed content).
   Verifiers MUST parse them independently.

6.3.  Ordering

   Review trailers SHOULD appear in the following canonical order:

   1.  Reviewed-By:

   2.  Review-Stance:

   3.  Review-Of:

   4.  Witnessed-By:

   5.  Identity-Signature:

   6.  Identity-Key-Id:

   7.  Identity-Anchor:

   Verifiers MUST accept trailers in any order, but emitters SHOULD
   follow the canonical order to support diff-based review.

6.4.  Multiplicity Rules

   The following multiplicity constraints apply to a single review
   trailer block:

   *  *Reviewed-By:* - Exactly one trailer per review block.  A single
      artefact MAY receive multiple review blocks over its lifetime (one
      per reviewer); each block is independently attributed and
      verified.



Morrison                Expires 19 November 2026                [Page 9]

Internet-Draft             Reviewed-By Trailer                  May 2026


   *  *Review-Stance:* - At most one trailer per review block.  A review
      takes exactly one stance at a time.  If the reviewer's disposition
      is nuanced (e.g., "revise and resubmit with stance leaning toward
      accept"), the primary stance SHOULD be selected and the nuance
      recorded in the review body, not in additional stance trailers.

   *  *Review-Of:* - At most one trailer per review block.  A review is
      bound to exactly one content-hash reference.  A reviewer
      commenting on multiple artefacts MUST emit a separate review block
      per artefact.

   *  *Witnessed-By:* - Zero or more trailers per review block.  Multi-
      witness ceremonies (e.g., patent disclosure reviews requiring two
      witness signatures) are permitted and expected.  Multiple
      witnesses form an unordered set; order of appearance is not
      semantically significant.

   *  *Identity-Signature: and Identity-Key-Id:* - These two trailers
      MUST appear together or not at all, per [COMMITS] Section 4.4.
      When present, they bind to the most recent preceding Reviewed-By:
      trailer in the block.  Witness signatures, if required, are
      recorded as separate trailer blocks each rooted at a Reviewed-By:
      copy of the reviewer's handle or, alternatively, as witness-
      specific signature pairs whose binding is specified by the
      containing manifest.

   *  *Identity-Anchor:* - OPTIONAL in this version of the
      specification.  Implementations targeting transparency-log-
      anchored review attribution MUST emit it.

7.  Signature Algorithm (Normative)

7.1.  Algorithm and Signed Payload

   The signature algorithm is Ed25519 [RFC8032], reused unchanged from
   [COMMITS] Section 5.

   The signed payload is the raw byte representation of the
   canonicalised-content hash of the artefact under review, as named in
   the Review-Of: trailer.  The algorithm named in the content-hash-ref
   determines which digest is produced; the signed bytes are the raw
   digest, not a hex-encoded string.









Morrison                Expires 19 November 2026               [Page 10]

Internet-Draft             Reviewed-By Trailer                  May 2026


7.2.  Rationale for Canonicalised-Content-Hash Signing

   The signature binds the reviewer's sovereign key to the exact
   canonicalised content of the artefact being reviewed.  This is
   distinct from (and orthogonal to) the tree-hash signing model of
   [COMMITS].  A review is a statement about content, not about commit
   history; binding the review to the content hash preserves the
   review's attribution across re-export of the artefact into different
   containers (a pre-print re-uploaded to arXiv, the same manuscript
   ingested by a journal's submission system, a patent specification
   exported to PDF) as long as the canonicalisation yields the same
   digest.

   Manifest hashes (envelope digests of the publisher's submission
   record) are deliberately NOT used as the signed payload.  If a
   publisher re-packages the artefact, the manifest hash changes while
   the content is identical; binding reviews to manifest hashes would
   invalidate reviewer signatures under routine publisher operations.
   The authority over what constitutes "canonical content" rests with
   the artefact's originator (the author) rather than with the
   publisher; this preserves sovereign-portability of review.

7.3.  Signature Format

   Signature encoding follows [COMMITS] Section 5.4 without
   modification.  The trailer value is ed25519: followed by the
   base64url-encoded 64-byte signature per [RFC4648].

8.  DNS Resolution (Normative Reference)

8.1.  Reviewer Key Resolution

   The reviewer's public key is resolved via the _alter.<zone> DNS
   record mechanism of [MCPDNS], exactly as specified in [COMMITS]
   Section 6.1.  No mechanism is provided for verifiers to learn, from
   the trailer grammar or the DNS record alone, whether a given
   Sovereign handle is operated by a directly-identified party or by a
   concealed party under pseudonymous key custody.  Where the
   distinction matters editorially, it is conveyed through separate out-
   of-band channels (editorial assignment records, conference of
   record); the protocol layer does not surface it.










Morrison                Expires 19 November 2026               [Page 11]

Internet-Draft             Reviewed-By Trailer                  May 2026


8.2.  Witness Resolution

   Witness handles resolve identically to reviewer handles.  Witnesses
   MUST be Sovereign-tier handles.  Although the grammar does not
   distinguish pseudonymous from directly-identified Sovereign handles,
   the witness role is expressly an on-the-record presence attestation;
   witnesses SHOULD therefore use Sovereign handles whose underlying
   identity is publicly resolvable by the intended verifier audience,
   since concealed-party witnessing materially weakens the attestation.

9.  Verifier Behaviour (Normative)

   A conformant verifier MUST perform the following steps in order:

   1.  *Parse all review trailers from the trailer block.* Trailers
       appearing outside the block MUST be ignored.

   2.  *Reject cross-slot category errors.* For each trailer, resolve
       the handle's tier per [MCPDNS].  If any handle appears in a slot
       other than its tier's admissible slot - for example, an
       Instrument-tier handle in a Reviewed-By: slot, or a Bot-tier
       handle in a Reviewed-By: or Witnessed-By: slot - the trailer
       block is malformed and the verifier MUST reject it as a category
       error.  The error message SHOULD identify the offending trailer
       by name.

   3.  *Validate the controlled-vocabulary stance.* If a Review-Stance:
       trailer is present, its value MUST be one of the five stance
       values defined in Section 4.1.  Unknown stance values MUST cause
       the review to be marked as malformed.

   4.  *Verify signatures, if present.* If Identity-Signature: and
       Identity-Key-Id: are present, the verifier MUST:

       a.  Extract the key-id from the Identity-Key-Id: trailer. b.
       Resolve the corresponding public key by querying the Reviewed-By:
       handle's _alter record per Section 6.1. c.  Compute or retrieve
       the canonicalised-content hash of the artefact referenced by
       Review-Of:. d.  Verify the Ed25519 signature against that hash
       using the resolved public key.

       If signature verification fails, the verifier MUST mark the
       review as unverified and MUST NOT report it as having a valid
       sovereign attribution.

   5.  *Verify content-hash binding.* If Review-Of: is present, the
       verifier SHOULD recompute the content hash from the artefact as
       delivered and compare it to the value in Review-Of:.  Mismatch



Morrison                Expires 19 November 2026               [Page 12]

Internet-Draft             Reviewed-By Trailer                  May 2026


       indicates either artefact tampering or review attribution to a
       different version; the verifier MUST surface this condition and
       MUST NOT silently accept the review.

   A conformant verifier SHOULD additionally:

   1.  *Distinguish review states in user-facing output.* Verifiers
       SHOULD present three distinct states:

       *  verified - Reviewed-By: present with a valid Identity-
          Signature: resolving to the published key AND content-hash
          match.

       *  claimed - Reviewed-By: present without a signature, or with a
          signature whose key cannot be resolved.

       *  hash-mismatch - signature valid but content digest differs
          from Review-Of:.

       Conflating these states is a security defect.  Whether a verified
       review is directly-identified or pseudonymous is not derivable
       from the grammar; verifiers MUST NOT attempt to classify reviews
       along that axis from the trailer block alone.

10.  Security Considerations

10.1.  Reviewer Reputation Portability

   Once a reviewer accumulates a signed review history on a sovereign
   ~handle, that history is architecturally outside any publisher's
   control.  A publisher cannot unilaterally revoke, rewrite, or
   platform-lock the reviewer's past signed reviews; a reviewer
   migrating to a new publisher carries the chain of signed review acts
   with them, and any verifier (a future organisation, a tenure
   committee, a grant panel, an adversarial peer) can check the chain
   end-to-end without publisher cooperation.

   This is an intentional redistribution of control away from platform-
   owned reviewer databases.  Publishers remain the venue of record for
   the editorial decision process; they cease to be the venue of record
   for the reviewer's reputation.










Morrison                Expires 19 November 2026               [Page 13]

Internet-Draft             Reviewed-By Trailer                  May 2026


10.2.  Pseudonymity and Anonymous Peer Review

   A Sovereign handle whose underlying party is concealed carries the
   same cryptographic weight as a directly-identified Sovereign handle
   and is grammatically indistinguishable from it.  This preserves
   double-blind review where disciplinary norms require it, while still
   producing a verifiable signed review chain.  Publishers operating
   anonymous-review workflows MAY mint or delegate a per-review
   Sovereign handle for the reviewer, discard the assignment-to-real-
   identity binding after the editorial process concludes, and rely on
   the reviewer's own key custody to retain the signed record for future
   portability.

   The mapping between a concealed Sovereign handle and its underlying
   party is the responsibility of the reviewer and, optionally, of the
   editorial intermediary that facilitates the pseudonymous assignment.
   This document does not specify that mapping mechanism;
   implementations SHOULD document the assignment and custody model they
   use.

10.3.  Review Spam

   A malicious sovereign MAY publish arbitrary signed reviews
   attributing nonsense stances to arbitrary artefact hashes.  The
   mitigation is not a protocol-layer filter but the reputational cost
   absorbed by the reviewer's own handle: spammy signatures accumulate
   against the same sovereign key that carries the reviewer's legitimate
   work.  Verifiers SHOULD surface reviewer history to readers (e.g.,
   "this handle has produced 12 reviews across 4 venues, of which 2
   appear to be spam").

10.4.  Review Bribery and Conflict of Interest

   The grammar does not and cannot prevent a reviewer from being bribed
   to produce an unjustified positive review, nor from concealing a
   conflict of interest.  Any economic counter-incentive is external to
   this specification: implementations operating on incentive-aligned
   rails can apply return-on-reputation invariants in which sustained
   honest reviewing compounds the reviewer's earnings stream while a
   single detected conflict-of-interest violation invalidates a
   disproportionate fraction of that stream.  Conflict disclosure is a
   policy-layer concern; this protocol provides the truthful path for
   honest reviewers, not a verification path against dishonest ones.








Morrison                Expires 19 November 2026               [Page 14]

Internet-Draft             Reviewed-By Trailer                  May 2026


10.5.  Witness Collusion

   Witness trailers attest to the presence of the reviewer at the review
   act; they do not attest to the review's substantive merit.  Two
   witnesses colluding with a dishonest reviewer can still produce a
   validly-signed multi-witness block over a fraudulent review.  Witness
   signatures therefore raise the cost of forgery but do not eliminate
   it.  High-stakes review contexts (patent disclosure reviews,
   adversarial expert reviews) SHOULD require witnesses whose sovereign
   identities have independent reputational stakes that are lost by
   collusion.

10.6.  Content-Hash Forgery

   An attacker who can forge content with the same canonicalised hash as
   an honestly-reviewed artefact can silently re-attribute the
   reviewer's signature to forged content.  The mitigation is the
   cryptographic strength of the chosen hash-algorithm.  Implementations
   SHOULD default to sha256 or stronger and SHOULD NOT accept git-sha1
   for high-assurance review contexts, in line with [COMMITS]
   Section 8.4.

10.7.  Key Custody at the Review-Signing Boundary

   The same key-custody considerations as [COMMITS] Section 8.6 apply
   unchanged: the signing operation MUST NOT occur in an unprivileged
   process that does not mediate access to the private key.  Signing
   ceremonies for high-stakes reviews (patent disclosures, adversarial
   expert reviews) SHOULD additionally bind the signing key to a
   hardware authenticator and record the witness handles inside the
   trailer block before the signature is produced.

10.8.  Negative Attribution: Missing Review Disclosure

   A publisher MAY elect to omit the Reviewed-By: trailer when
   publishing a review in order to conceal the reviewer's identity even
   after review acceptance; this is detectable by the reviewer
   themselves (who retains their own signed copy) but not by third
   parties.  The grammar defined here provides the positive attribution
   path; it does not force publishers to disclose reviewer identity
   where editorial policy forbids it.

11.  Privacy Considerations








Morrison                Expires 19 November 2026               [Page 15]

Internet-Draft             Reviewed-By Trailer                  May 2026


11.1.  Pseudonymity as a First-Class Concern

   Anonymous peer review exists because disciplinary communities have
   judged the costs of fully-attributed review (retaliation, seniority
   bias, disciplinary politics) to exceed the benefits.  This document
   accepts that judgment by treating pseudonymous Sovereign handles as
   first-class cryptographic participants rather than as a degraded
   fallback.  Because pseudonymous and directly-identified Sovereign
   handles are grammatically indistinguishable, implementations cannot
   reliably classify a review as pseudonymous from the trailer block
   alone; they MUST NOT emit operational warnings or user-facing nudges
   that characterise a review as lower-trust on the basis of suspected
   pseudonymity.

11.2.  DNS-Linkability Risk

   Every DNS resolution of a ~handle leaks the verifying party's
   interest in that handle to the DNS path (recursive resolvers, on-path
   observers, zone operators).  Reviewers performing sensitive reviews
   under pseudonymous Sovereign handles SHOULD host the handle's zone
   with an infrastructure provider that is not the same entity as the
   publisher; otherwise the publisher's own DNS telemetry can de-
   pseudonymise review-assignment patterns.

11.3.  Right to Withdraw a Review

   A reviewer who wishes to withdraw a past review cannot unmake the
   cryptographic fact of the signed block; they MAY publish a
   superseding trailer block (a Reviewed-By: carrying a Review-Stance:
   dispute against their own prior review hash) that records the
   retraction without erasing the prior signature.  The grammar is
   append-only by construction; retraction is done forward, not by
   deletion.

12.  IANA Considerations

12.1.  Trailer Name Registration

   If a git/document trailer name registry is established by IANA (see
   [COMMITS] Section 9.1), this document requests registration of the
   following additional trailer names with reference to this
   specification:

   *  Reviewed-By

   *  Review-Stance

   *  Review-Of



Morrison                Expires 19 November 2026               [Page 16]

Internet-Draft             Reviewed-By Trailer                  May 2026


   *  Witnessed-By

   The cryptographic trailers (Identity-Signature, Identity-Key-Id,
   Identity-Anchor) are registered by [COMMITS] and are not separately
   registered here.

12.2.  Stance Value Registry

   This document requests IANA registration of a "Peer Review Stance
   Values" registry, initially populated with the five values of
   Section 4.1 (accept, reject, revise, endorse, dispute).  The
   registration policy is "Specification Required" (RFC 8126).
   Extensions to the vocabulary MUST justify why the existing five
   values are insufficient for the proposed use case.

12.3.  No Other IANA Actions

   This document requests no other IANA actions.  The did:alter: URI
   scheme, the identitylog:// URI scheme, and the Ed25519 signature
   encoding are all inherited from [COMMITS].

13.  Relationship to Existing Standards

   The review-trailer grammar is intended to coexist with and complement
   existing peer-review attribution infrastructure, not to replace it.

   +=======================+====================+=====================+
   | Mechanism             | Purpose            | Coexistence with    |
   |                       |                    | this spec           |
   +=======================+====================+=====================+
   | ORCID peer-review     | Publisher-attested | Complementary.      |
   | activity [ORCID]      | review record      | ORCID records THAT  |
   |                       |                    | a review occurred;  |
   |                       |                    | Reviewed-By:        |
   |                       |                    | records WHAT the    |
   |                       |                    | review was.  Both   |
   |                       |                    | can coexist on the  |
   |                       |                    | same review act.    |
   +-----------------------+--------------------+---------------------+
   | CRediT contributor    | Author-side        | Orthogonal.  CRediT |
   | roles [CREDIT]        | contribution       | describes what      |
   |                       | taxonomy           | authors did;        |
   |                       |                    | Review-Stance:      |
   |                       |                    | describes what      |
   |                       |                    | reviewers said.  No |
   |                       |                    | overlap.            |
   +-----------------------+--------------------+---------------------+
   | DOI attribution [DOI] | Persistent         | Complementary.  A   |



Morrison                Expires 19 November 2026               [Page 17]

Internet-Draft             Reviewed-By Trailer                  May 2026


   |                       | identifier for the | Review-Of: trailer  |
   |                       | artefact           | MAY carry a DOI     |
   |                       |                    | alongside or        |
   |                       |                    | instead of a        |
   |                       |                    | content hash where  |
   |                       |                    | the DOI resolves to |
   |                       |                    | an immutable        |
   |                       |                    | content manifest.   |
   +-----------------------+--------------------+---------------------+
   | COPE ethics guidance  | Normative ethical  | Orthogonal.  COPE   |
   | [COPE]                | framework for peer | specifies duties;   |
   |                       | review             | this document       |
   |                       |                    | specifies           |
   |                       |                    | attribution         |
   |                       |                    | grammar.            |
   |                       |                    | Implementations     |
   |                       |                    | conforming to both  |
   |                       |                    | are recommended.    |
   +-----------------------+--------------------+---------------------+
   | eLife publish-review- | Open-review        | Complementary.  The |
   | curate                | editorial model    | eLife model         |
   |                       |                    | benefits from       |
   |                       |                    | portable reviewer   |
   |                       |                    | identity; Reviewed- |
   |                       |                    | By: provides the    |
   |                       |                    | portability without |
   |                       |                    | requiring platform  |
   |                       |                    | lock-in.            |
   +-----------------------+--------------------+---------------------+
   | arXiv trackbacks      | Informal linkage   | Complementary.      |
   | [ARXIV]               | between reviews    | Trackbacks can      |
   |                       | and pre-prints     | carry Reviewed-By:  |
   |                       |                    | blocks as machine-  |
   |                       |                    | readable review     |
   |                       |                    | records, upgrading  |
   |                       |                    | informal trackback  |
   |                       |                    | to cryptographic    |
   |                       |                    | attribution.        |
   +-----------------------+--------------------+---------------------+
   | Co-Authored-By:       | Informal AI co-    | Inadmissible in     |
   | Claude                | authorship         | review slots.  AI   |
   |                       | convention         | drafting assistance |
   |                       |                    | on a review SHOULD  |
   |                       |                    | be disclosed via    |
   |                       |                    | the Drafted-With:   |
   |                       |                    | trailer of          |
   |                       |                    | [COMMITS], not via  |
   |                       |                    | co-authorship.      |



Morrison                Expires 19 November 2026               [Page 18]

Internet-Draft             Reviewed-By Trailer                  May 2026


   +-----------------------+--------------------+---------------------+

                                 Table 2

   Cryptographically-bound pseudonymous review - a Sovereign handle
   whose underlying party is concealed and whose review acts remain
   fully verifiable - is novel to this specification and has no analogue
   in prior peer-review attribution infrastructure.  ORCID records
   publisher-attested facts about named identities; CRediT describes
   author contributions; DOI identifies artefacts.  None of the three
   expresses the cryptographically-bound pseudonymous-reviewer role that
   peer review has relied on for a century but has had no portable
   attribution grammar for.  That grammar is the load-bearing
   contribution of this document.

14.  Acknowledgments

   The author thanks colleagues at Alter Meridian Pty Ltd for the
   framing of sovereign-portable reputation as the governance wedge, and
   the eLife open-review community and the arXiv operators whose prior
   work on open peer review has made the grammar here possible.
   Additional contributors will be named at review time.

15.  References

15.1.  Normative References

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

   [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
   Encodings", RFC 4648, October 2006.

   [RFC5234] Crocker, D. and P.  Overell, "Augmented BNF for Syntax
   Specifications: ABNF", STD 68, RFC 5234, January 2008.

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

   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
   Key Words", BCP 14, RFC 8174, May 2017.

   [COMMITS] Morrison, B., "Identity-Attributed Git Commits via Tier-
   Structured Trailers", draft-morrison-identity-attributed-commits,
   work in progress.






Morrison                Expires 19 November 2026               [Page 19]

Internet-Draft             Reviewed-By Trailer                  May 2026


   [MCPDNS] Morrison, B., "Discovery of Model Context Protocol Servers
   via DNS TXT Records", draft-morrison-mcp-dns-discovery, work in
   progress.

15.2.  Informative References

   [RFC7942] Sheffer, Y. and A.  Farrel, "Improving Awareness of Running
   Code: The Implementation Status Section", BCP 205, RFC 7942, July
   2016.

   [CREDIT] National Information Standards Organization, "CRediT
   (Contributor Roles Taxonomy), NISO Z39.104-2022",
   https://credit.niso.org/, 2022.

   [ORCID] ORCID, Inc., "ORCID Public API", https://info.orcid.org/
   documentation/, 2023.

   [COPE] Committee on Publication Ethics, "Core Practices and
   Guidance", https://publicationethics.org/core-practices, 2019.

   [ELIFE-OPENREVIEW] eLife Sciences Publications, Ltd., "eLife's
   Publish-Review-Curate Model", https://elifesciences.org/about/peer-
   review, 2023.

   [ARXIV] Cornell University, "arXiv.org - An Open-Access Archive",
   https://arxiv.org/, 1991.

   [DOI] International DOI Foundation, "The DOI Handbook",
   https://www.doi.org/the-identifier/resources/handbook/, 2020.

   [ANTHROPIC-COAUTHOR] Anthropic, "Co-Authored-By: Claude - convention
   for AI-assisted commits".

16.  Author's Address

   Blake Morrison Alter Meridian Pty Ltd

   Email: blake@truealter.com URI: https://truealter.com

17.  References

17.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.




Morrison                Expires 19 November 2026               [Page 20]

Internet-Draft             Reviewed-By Trailer                  May 2026


   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [COMMITS]  Morrison, B., "Identity-Attributed Git Commits via Tier-
              Structured Trailers", 2026,
              <https://datatracker.ietf.org/doc/draft-morrison-identity-
              attributed-commits/>.

   [MCPDNS]   Morrison, B., "Discovery of Model Context Protocol Servers
              via DNS TXT Records", 2026,
              <https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-
              discovery/>.

17.2.  Informative References

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

   [CREDIT]   National Information Standards Organization, "CRediT
              (Contributor Roles Taxonomy), NISO Z39.104-2022", 2022,
              <https://credit.niso.org/>.

   [ORCID]    ORCID, Inc., "ORCID Public API", 2023,
              <https://info.orcid.org/documentation/>.

   [COPE]     Committee on Publication Ethics, "Committee on Publication
              Ethics - Core Practices and Guidance", 2019,
              <https://publicationethics.org/core-practices>.






Morrison                Expires 19 November 2026               [Page 21]

Internet-Draft             Reviewed-By Trailer                  May 2026


   [ELIFE-OPENREVIEW]
              eLife Sciences Publications, Ltd., "eLife's Publish-
              Review-Curate Model", 2023,
              <https://elifesciences.org/about/peer-review>.

   [ARXIV]    Cornell University, "arXiv.org - An Open-Access Archive",
              1991, <https://arxiv.org/>.

   [DOI]      International DOI Foundation, "The DOI Handbook", 2020,
              <https://www.doi.org/the-identifier/resources/handbook/>.

   [ANTHROPIC-COAUTHOR]
              Anthropic, "Co-Authored-By: Claude - convention for AI-
              assisted commits", 2025,
              <https://docs.anthropic.com/claude/docs/co-authored-by-
              convention>.

Author's Address

   Blake Morrison
   Alter Meridian Pty Ltd
   Email: blake@truealter.com





























Morrison                Expires 19 November 2026               [Page 22]
