BCR-2026-004: Signing Event Assertions

[ChristopherA]

Proposes Known Values for expressing the context and capacity in which signatures are made.

Predicates defined:

• signingAs — Capacity or role in which the entity is signing
• onBehalfOf — Principal on whose behalf the signature is made
• delegatedBy — Entity that delegated the signing authority
• delegationChain — Reference to the full delegation audit trail

Codepoints: Community range 1020-1023

Applies to all signature types: self-attestations, peer endorsements, and binding agreements.

Seeking rough consensus; willing to use 100000+ range if community prefers.

[shannona]

LGTM.

[ChristopherA]

Terminology Update: "Conferral" replaces "Delegation"

Based on feedback about terminology collision, I've renamed the delegation predicates to use "conferral" instead.

Why the change

"Delegation" collides with multiple technical domains:

• Cryptographic delegation: XID delegate (63) predicate grants signing privileges
• OAuth: "authorization grant" / "delegation"
• Access control: delegation of permissions

"Conferral" is the formal legal term for granting authority ("confer authority upon") and has minimal collision with existing technical vocabulary.

Changes in this PR

Old	New
delegatedBy	conferredBy
delegationChain	conferralChain

Also updated terminology sections, examples, and changed "key-level privileges" to "cryptographic signing privileges".

BCR-2026-007 uses matching conferral* terminology for consistency.

[ChristopherA]

Predicate Consolidation: conferral predicates moved to BCR-2026-007

To avoid splitting authority conferral terminology across two BCRs, I've moved conferredBy and conferralChain from this BCR to BCR-2026-007.

BCR-2026-006 now defines only:

• signingAs (1020) — signing capacity/role
• onBehalfOf (1021) — who the signer represents

BCR-2026-007 now defines all conferral predicates:

• principalAuthority (1040)
• assertsConferralFrom (1041)
• conferralScope (1042)
• conferralConstraints (1043)
• conferredBy (1044) — moved from here
• conferralChain (1045) — moved from here

This keeps the authority relationship vocabulary in one place while BCR-006 focuses purely on signing context.

[ChristopherA]

Major Rewrite: BCR-2026-006 → BCR-2026-004 Signing Event Attestations

This PR has been substantially rewritten and renumbered.

Why Renumber to 004?

This BCR establishes foundational concepts (the signing mental model, double-signing pattern) that other BCRs in this suite depend on. It also:

• Uses Reserved range codepoints (300-301) requiring only internal approval
• Should be the first released as a foundation for the others

Key Changes

Mental Model Clarification:

• A cryptographic signature proves exactly one thing: "The private key corresponding to a specific public key was used to produce this signature over this specific content."
• It does NOT prove: who possesses the key, when signing occurred, why signing happened, or that the signer read/understood the content.

Terminology:

• Renamed from "Signature Context" to "Signing Event Attestations"
• Replaced "context" with "attestations" throughout for precision
• A "signing event" is the cryptographic operation; "signing event attestations" are claims about that event

Double-Signing Pattern:

• This BCR now formally documents the double-signing pattern
• Removed incorrect attribution to BCR-2024-009 (that spec doesn't define this pattern)
• Inner signature proves key signed content; outer signature binds attestations

New Content:

• Precise definition of what signatures prove (and don't prove)
• Key separation scenarios (by purpose, by device, third-party)
• Dates vs timestamps distinction (dates are claims, not proofs)
• Gordian ecosystem (XIDs/Clubs) vs broader use (URIs/DIDs)

Predicates:

• signer (300) — links signature to identity document
• signedOnBehalfOf (301) — (optional) identifies another XID the signer represents
• References XAdES ClaimedRole and CommitmentType for additional attestation types

File Changes

• Deleted: bcr-2026-006-signature-context.md
• Added: bcr-2026-004-signing-event-attestations.md

The branch name remains bcr-2026-006 to preserve PR history.

[ChristopherA]

Update (2026-02-04): Signature Scheme Rationale

Added technical rationale for why signer predicate is cryptographically necessary (not just semantically useful):

Why signer is necessary: Not all signature schemes embed the public key or allow key recovery:

• EdDSA/Ed25519: Public key cannot be recovered (hashed in Fiat-Shamir transform)
• BBS+: Zero-knowledge proofs are unlinkable — verifiers cannot determine which key created the proof
• Longfellow and similar ZK schemes: Designed specifically to hide signer identity

In these schemes, there is no public key to "look up" from the signature alone. The signer predicate provides the necessary link to identity that the cryptographic signature cannot.

Added references to BBS (IETF draft) and Longfellow (IETF draft) specifications.

[ChristopherA]

Update (2026-02-04): Terminology Change

Renamed from "Signing Event Attestations" to "Signing Event Assertions".

Rationale:

• "Assertion" is the technical term for Envelope predicate-object pairs
• Existing BCRs (2024-009, 2024-010, 2025-004) consistently use this terminology
• "Attestation" is a non-technical term meaning declaration/testimony
• BCRs are technical specifications; technical terminology is appropriate

The semantic intent is preserved — signers are still making formal declarations about signing events — but the vocabulary now aligns with established Envelope terminology.

[ChristopherA]

Update (2026-02-04): Adopted BCR-2024-009 Pattern

Major structural change: Now documents two signing patterns instead of just double-signing.

Pattern 1: Signature-with-Assertions (Primary)

For signer's own assertions about their signing act — uses BCR-2024-009's structure:

{
    Digest(contract)
} [
    'signed': {
        Signature [
            'signer': XID(alice)
            'xades:CommitmentType': "approval"
        ]
    } ['signed': Signature]
]

The Signature object carries its assertions, wrapped and signed as a self-contained unit.

Pattern 2: Wrapped Signing (Third-Party)

For third-party assertions about already-signed content (timestamps, notarization, witnessing):

{
    { signed-content }
    [
        'anchoredAt': 2026-02-04T12:00:00Z
    ]
} ['signed': { Signature [...] } ['signed': Sig]]

Third party wraps signed content, adds their assertions, signs.

Key Changes

• References BCR-2024-009 as structural foundation
• All examples updated to new structure
• Clear guidance on when to use each pattern
• Parallel vs counter-signature patterns documented

[ChristopherA]

Prose Cleanup & Validation Update

Changes:

• Reduced document from ~560 to ~289 lines
• Removed verbose AI-style explanations, kept direct statements
• Adopted BCR-2024-009 pattern as primary (signature-with-assertions)
• Kept wrapped signing as secondary pattern for third-party assertions

Envelope CLI Validation:
All examples tested and verified:

• ✓ Signature-with-assertions pattern
• ✓ Wrapped signing for third-party assertions
• ✓ Parallel signatures
• ✓ Counter-signatures
• ✓ Both inner and outer signatures verify correctly

Terminology:
Added terminology note distinguishing:

• Assertion (noun): Envelope vocabulary — a predicate-object pair
• Attestation (noun): The act of declaring facts
• Signers attest; their attestations are expressed as assertions

[ChristopherA]

Security Considerations Update

Expanded Security Considerations to be self-contained for verification:

Added:

• Explicit verification requirements (MUST verify both signatures, MUST be same key)
• What different keys mean for each pattern
• Claims vs proof distinction
• Pointer to BCR-2024-009 for API guidance and reference implementation

This ensures readers don't need to read BCR-2024-009 to understand verification requirements, while keeping implementation details in the appropriate spec.

[ChristopherA]

Ready for Final Review

Changes in This Update

• ✅ Addressed @shannona's feedback (prose cleanup, pattern clarification)
• ✅ Adopted BCR-2024-009 signature-with-assertions pattern as primary
• ✅ All examples validated with envelope-cli
• ✅ Expanded Security Considerations with explicit verification requirements
• ✅ Added authors: Wolf McNally, Shannon Appelcline

Checklist Before Merge

• @wolfmcnally final review
• XAdES predicates (xades:ClaimedRole, xades:CommitmentType) added to Known Value registry
• Merge

Post-Merge Tasks

• Update Research repo README.md with BCR-2026-004 entry
• Add forward reference in BCR-2024-009 pointing to this BCR for standard predicates

[ChristopherA]

Codepoint Update

Updated codepoints to avoid collision with existing registry:

Predicate	Old	New
signer	300	800
signedOnBehalfOf	301	801

Reason: Codepoints 300-303 are already assigned (asset, Bitcoin, Ethereum, Tezos).

New range: 800-801 provides 3-byte CBOR encoding on decade boundary.