Abstract
This document defines a trailer grammar for sovereign-portable peer review as an extension of the identity-attributed commit grammar of draft-morrison-identity-attributed-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 that grammar. Because the signature covers the reviewer's role, the stance and the review target together, changing any of them after signing fails verification. The mechanism applies to git commits, document manifests, pre-prints, patent disclosures, and any other content-addressable artefact. A reviewer's signed reviews are bound to the reviewer's sovereign handle, not to a publisher's platform, and can be verified without the publisher. For anonymous peer review, the reviewer signs under a Sovereign handle whose underlying party is concealed through out-of-band key custody; the review act stays verifiable and the reviewer's identity is not disclosed. The grammar complements CRediT, ORCID, and DOI attribution; it does not replace them.
1. Introduction
1.1. Problem Statement
Peer review of scholarly, scientific, and technical artefacts is recorded by the publishers that run it, and their 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 existing mechanisms for attaching reviewer identity to a review are these:
- 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.
1.2. Design Goals
This document defines a review-trailer grammar with the following goals:
- 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. A review of version 1 of a manuscript therefore cannot be silently re-attributed to version 2. The same signature binds the reviewer's role and stance, and changing either invalidates it.
- 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. Some disciplines require anonymous peer review. The grammar supports pseudonymous review by permitting a Sovereign handle whose underlying party is concealed through out-of-band key custody. The review act stays verifiable and the reviewer's identity is not disclosed.
- 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.
1.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], and the review payload that their signature covers.
- 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:
- The ~handle identity primitive itself, defined by [MCPDNS] and incorporated by reference through [COMMITS].
- The normative tier taxonomy, 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.
2. Terminology
2.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.
2.2. Definitions
Handle A ~-prefixed identifier per [MCPDNS], as incorporated into [COMMITS]. Handles are the unit of identity addressing in this document. A handle that matches the handle-ref rule of [ALTER-URI] names the same subject as the alter: URI formed by prefixing it with alter:; the trailer value ~alice corresponds to alter:~alice. The trailer grammar of Section 4.1 carries the handle without the scheme name.
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.
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) of the canonicalised artefact being reviewed, or, for a git commit, its patch identifier. The hash binds the review to a specific artefact state and prevents silent re-attribution across revisions.
Patch Identifier The identifier of a git change as defined in [COMMITS]: the output of git patch-id --verbatim over the output of git diff-tree -p --root for the commit. This document does not restate the definition.
Review Payload The byte string defined in Section 5.2 that the reviewer's signature covers. It carries the role, the signer, the reviewer, the stance, and the Review-Of: value.
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.
3. 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 | ~cc-example-model-1, | | | signature | | ~cc-example-model-2 | +----------+---------------+----------------+----------------------+
Table 1
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:.
4. Trailer Grammar (Normative)
4.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 LF
review-stance-trailer = "Review-Stance:" SP stance-value LF
review-of-trailer = "Review-Of:" SP content-hash-ref LF
witnessed-by-trailer = "Witnessed-By:" SP sovereign-handle LF
; MAY be immediately followed by its own
; Identity-Signature:/Identity-Key-Id:
; pair; see Section 4.4 and Section 7
; step 5
review-handle = sovereign-handle
; sovereign-handle and handle-name per
; [COMMITS] Section 4.1
stance-value = "accept" / "reject" / "revise"
/ "endorse" / "dispute"
content-hash-ref = hash-algorithm ":" hash-value
hash-algorithm = "sha256" / "sha512" / "git-patch-id"
/ "git-sha1" / "git-sha256"
hash-value = 1*HEXDIG
; the Review Payload of Section 5.2 uses
; the lower-case form
The trailer rules end in LF, as git commit messages and the trailers of [COMMITS] do.
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.
4.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.
4.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.
4.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.
- Review-Stance: - At most one trailer per review block. A review takes exactly one stance at a time. Where the block carries no Review-Stance:, the Review Payload records the stance as none (Section 5.2). 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, and exactly one where the block carries an Identity-Signature:. 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. The relative order of different witnesses' groups is not semantically significant. Within a single witness's group, however, an Identity-Signature:/Identity-Key-Id: pair bound to that witness (see below) MUST immediately follow its Witnessed-By: trailer. A signature pair then binds to one witness without ambiguity even when several witnesses are present.
- Identity-Signature: and Identity-Key-Id: - These two trailers MUST appear together or not at all, per [COMMITS] Section 4.4. A pair immediately following a Reviewed-By: trailer binds to that Reviewed-By: trailer. Witness signatures MAY instead be recorded as a separate trailer block each rooted at a Reviewed-By: copy of the witness's own handle (verified as any other Reviewed-By: block, per Section 7), or as an Identity-Signature:/Identity-Key-Id: pair immediately following the corresponding Witnessed-By: trailer. A pair placed there binds to that witness directly and is verified per Section 7 step 5. The containing manifest is not part of this binding.
- Identity-Anchor: - OPTIONAL in this version of the specification. Implementations targeting transparency-log-anchored review attribution MUST emit it.
5. Signature Algorithm (Normative)
5.1. Algorithm
The signature algorithm is Ed25519 [RFC8032], reused unchanged from [COMMITS] Section 5. It is Ed25519 as defined in [RFC8032], over the Review Payload below as the message; Ed25519ph and Ed25519ctx MUST NOT be used.
5.2. Signed Payload
The signed payload is the Review Payload: the following five lines, each terminated by a single LF (0x0A), encoded as US-ASCII, with no other bytes before, between or after them.
reviewed-by-trailer-v1 LF role: <role> LF signer: <signer-handle> LF reviewer: <reviewer-handle> LF stance: <stance> LF review-of: <content-hash-ref> LF
The first line is a domain-separation prefix. Its value is the literal reviewed-by-trailer-v1. Because it is distinct from any payload prefix defined in [COMMITS], a signature made under one document cannot verify under the other.
The remaining lines are filled as follows.
- <role> is reviewer when the signature pair follows a Reviewed-By: trailer, and witness when it follows a Witnessed-By: trailer.
- <signer-handle> is the handle of the key holder producing the signature, spelled exactly as in the trailer, including the leading ~.
- <reviewer-handle> is the handle in the Reviewed-By: trailer of the same review block. For reviewer it equals the signer.
- <stance> is the value of the block's Review-Stance: trailer, or the literal none where the block has none.
- <content-hash-ref> is the value of the block's Review-Of: trailer, with the hash value in lower-case hexadecimal.
Signers and verifiers MUST build the Review Payload from the trailer values, not from any normalised or case-folded form of them, apart from the lower-casing of the hash value. The Ed25519 signature is computed over the payload bytes directly. The payload is not hashed first and is not hex-encoded.
The reviewed change is identified by the value in Review-Of:. For a git commit it is the commit's Patch Identifier, written git-patch-id:<hex>, the same basis the signature of [COMMITS] uses. For any other artefact it is the canonicalised-content digest named by the hash-algorithm. In both cases the payload carries the Review-Of: value, and with it both the algorithm and the digest.
5.3. Rationale for Signing the Role, Stance and Target Together
A signature over the content hash alone proves that a key holder signed that hash. It does not prove what the holder said about it. Under such a scheme the same signature value is valid for any role and any stance, so a Review-Stance: reject can be rewritten as accept, a Witnessed-By: pair can be replayed as a Reviewed-By: pair, and a Review-Of: that carries a different algorithm label over the same digest bytes is indistinguishable. The Review Payload closes this by putting every one of those values inside the signed bytes.
A review is a statement about content, not about commit history. Binding the review to the content hash, or for a git commit to its Patch Identifier, 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) and across a rebase or cherry-pick that leaves the change unchanged, as long as the canonicalisation or the patch identifier yields the same digest. Since the Patch Identifier of a git commit ignores the commit message, a review of a commit does not attest to the message text.
Manifest hashes (envelope digests of the publisher's submission record) are 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. A review stays portable between venues because the authority over what constitutes "canonical content" rests with the artefact's originator (the author) rather than with the publisher.
5.4. 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].
6. DNS Resolution (Normative Reference)
6.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, under the zone associated with the handle and never a zone read from its spelling. 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.
6.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 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.
7. 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, read the handle's tier from its lexical form per [COMMITS] Section 3, with no DNS lookup. 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 from the _alter record of the zone associated with the Reviewed-By: handle, per Section 6.1. c. Build the Review Payload of Section 5.2 with role reviewer, from the Reviewed-By:, Review-Stance: and Review-Of: trailers of the block as received. d. Verify the Ed25519 signature against that payload using the resolved public key.
A block that carries Identity-Signature: without Review-Of: is malformed and has no verifiable payload.
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 witness signatures, if present. For each Witnessed-By: trailer accompanied by its own bound Identity-Signature:/Identity-Key-Id: pair (per Section 4.4), the verifier MUST:
a. Extract the key-id from that pair's Identity-Key-Id: trailer. b. Resolve the corresponding public key from the _alter record of the zone associated with the witness handle, per Section 6.2. c. Build the Review Payload with role witness, the witness handle as signer, and the reviewer handle, stance and Review-Of: value of the same block, and verify the Ed25519 signature against it.
If a witness signature fails to verify, the verifier MUST mark that witness attestation as unverified and MUST NOT report it as a valid witness signature.
- 6. Verify content-hash binding. If Review-Of: is present, the verifier MUST recompute the content hash (for a git commit, the Patch Identifier) from the artefact as delivered and compare it to the value in Review-Of:, using the algorithm it names. Mismatch 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: over the Review Payload, 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.
8. Security Considerations
8.1. Reviewer Reputation Portability
Once a reviewer accumulates a signed review history on a sovereign ~handle, that history is 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.
Publishers remain the venue of record for the editorial decision process. They are no longer the venue of record for the reviewer's reputation.
8.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. Double-blind review therefore remains possible where a discipline requires it, and the signed review chain is still verifiable. 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.
8.3. Review Spam
A malicious sovereign MAY publish arbitrary signed reviews attributing nonsense stances to arbitrary artefact hashes. The protocol does not filter such reviews. Because they accumulate against the same sovereign key that carries the reviewer's legitimate work, the reputational cost falls on the reviewer's own handle. 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").
8.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.
8.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.
8.6. Role and Stance Rewriting
In revisions before -03 the signature covered the content hash only, so a reviewer's stance, the role of a Reviewed-By: or Witnessed-By: signature, and the Review-Of: label could be changed by anyone holding the block without invalidating the signature. The Review Payload of Section 5.2 covers all of them. A verifier MUST build the payload from the trailers as received and MUST NOT substitute defaults for absent ones other than the none stance defined there. A signature made under the earlier scheme does not verify under this one and is reported as unverified.
8.7. 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 9.5.
8.8. Key Custody at the Review-Signing Boundary
The same key-custody considerations as the "Key Custody at the Commit-Signing Boundary" section of [COMMITS] 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.
8.9. 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.
9. Privacy Considerations
9.1. Pseudonymous Review
Anonymous peer review is used where a discipline judges the costs of fully-attributed review (retaliation, seniority bias, disciplinary politics) to exceed its benefits. This document treats a pseudonymous Sovereign handle exactly as it treats any other Sovereign handle. 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.
9.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 publish the handle's envelope in a zone hosted by 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.
9.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. Retraction adds a block; it does not delete one.
10. IANA Considerations
10.1. Trailer Name Registration
If a git/document trailer name registry is established by IANA (see [COMMITS] Section 10.1), this document requests registration of the following additional trailer names with reference to this specification:
- Reviewed-By
- Review-Stance
- Review-Of
- Witnessed-By
The cryptographic trailers (Identity-Signature, Identity-Key-Id, Identity-Anchor) are registered by [COMMITS] and are not separately registered here.
10.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" [RFC8126]. Extensions to the vocabulary MUST justify why the existing five values are insufficient for the proposed use case.
10.3. No Other IANA Actions
This document requests no other IANA actions. The did:alter: identifier form, the identitylog:// URI scheme, and the Ed25519 signature encoding are all inherited from [COMMITS].
11. Relationship to Existing Standards
The review-trailer grammar coexists with existing peer-review attribution mechanisms and does not replace them.
+=======================+====================+=====================+ | 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 | | | 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. An |
| | | implementation can | | | | conform to both. | +-----------------------+--------------------+---------------------+ | eLife publish-review- | Open-review | Complementary. A | | curate | editorial model | review published | | | | under the eLife | | | | model can carry a | | | | Reviewed-By: block | | | | bound to the | | | | reviewer's handle. | +-----------------------+--------------------+---------------------+ | arXiv trackbacks | Informal linkage | Complementary. A | | [ARXIV] | between reviews | trackback can carry | | | and pre-prints | a Reviewed-By: | | | | block as a machine- | | | | readable, signed | | | | review record. | +-----------------------+--------------------+---------------------+ | Co-Authored-By: | Informal AI co- | Inadmissible in | | Claude | authorship | review slots. AI | | [ANTHROPIC-COAUTHOR] | convention | drafting assistance | | | | on a review SHOULD | | | | be disclosed via | | | | the Drafted-With: | | | | trailer of | | | | [COMMITS], not via | | | | co-authorship. | +-----------------------+--------------------+---------------------+
Table 2
Pseudonymous review under a Sovereign handle needs no tier or syntax of its own here (Section 2.2). ORCID records publisher-attested facts about named identities; CRediT describes author contributions; DOI identifies artefacts. None of the three carries a signed review act under a handle whose underlying party is concealed. The grammar in Section 4 covers that case.
12. Acknowledgments
The author thanks colleagues at Alter Meridian Pty Ltd for the framing of sovereign-portable reputation, and the eLife open-review community and the arXiv operators for their prior work on open peer review. Additional contributors will be named at review time.
13. Change Log
13.1. draft-morrison-reviewed-by-trailer-04
- Prose rewritten against the drafting rules: sentence-final "so" and "which" tails joined or split, and words broken across a line rejoined. No requirement changes.
- References to other drafts pin their current posted revisions.
- Editorial pass: the references to other drafts move to the revisions submitted alongside this one. Adds [RFC8126] for the registration policy named in the IANA section, rewords the Role and Stance Rewriting section so that it names the revision it refers to, and sets the did:alter: identifier form apart from URI schemes. No requirement changes.
13.2. draft-morrison-reviewed-by-trailer-03
- Change the signed payload. The -02 signature covered the content hash only, so a reviewer's stance, the role of a Reviewed-By: or Witnessed-By: signature, and the Review-Of: label could be altered without breaking it. Section 5.2 now defines a Review Payload, byte-exact, with a domain-separation prefix distinct from [COMMITS], that carries role, signer, reviewer, stance and the Review-Of: value. Section 5.3 gives the reasoning.
- Require Review-Of: wherever Identity-Signature: is present, and give a block with no Review-Stance: the payload stance none.
- Move the reviewed change of a git commit to its Patch Identifier, following the basis of draft-morrison-identity-attributed-commits-03, and add git-patch-id to hash-algorithm. Add Patch Identifier and Review Payload to Terminology. The definition of the Patch Identifier is in [COMMITS] and is not restated.
- Update the [COMMITS] reference to -03 and correct its section pointers: Section 8.4 is now 9.5, Section 9.1 is now 10.1, and the key-custody pointer is by section title.
- Add a Role and Stance Rewriting security consideration.
- Reword the closing paragraph of Relationship to Existing Standards and the Acknowledgments to plain statements of what the grammar covers.
- State how a handle corresponds to an alter: URI [ALTER-URI], and remove self-description and padding from the prose. No requirement changes.
- Replace the [ANTHROPIC-COAUTHOR] target, which no longer resolves, with the page that documents the Co-Authored-By trailer Claude Code adds by default.
- ABNF: take sovereign-handle and handle-name from [COMMITS] Section 4.1 and drop the local handle-label rule, as it admitted "_" and a leading digit. Trailer rules end in LF, as in [COMMITS].
- Read a handle's tier from its lexical form, with no DNS lookup, and take the zone a key is resolved under from the handle's association, never from its spelling, both as in [ALTER-URI]. The Instrument examples carry the cc- prefix.
14. 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>;.
[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", Work in Progress, Internet-Draft, draft-morrison-identity-attributed-commits-04, 2026, <https://datatracker.ietf.org/doc/draft-morrison-identity-attributed-commits/>;.
[MCPDNS] Morrison, B., "Discovery of Model Context Protocol Servers via DNS TXT Records", Work in Progress, Internet-Draft, draft-morrison-mcp-dns-discovery-09, 2026, <https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-discovery/>;.
15. Informative References
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>;.
[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>;.
[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, "Claude Code settings reference: attribution", 2026, <https://code.claude.com/docs/en/settings-reference#attribution>;.
[ALTER-URI] Morrison, B., "The 'alter' URI Scheme for Dispatchable ~handle References", Work in Progress, Internet-Draft, draft-morrison-alter-uri-scheme-05, 2026, <https://datatracker.ietf.org/doc/draft-morrison-alter-uri-scheme/>;.
Author's Address
Blake Morrison Alter Meridian Pty Ltd Email: blake@truealter.com