Skip to content

BCR-2026-XXX: Signing Event Assertions #151

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ChristopherA wants to merge 16 commits into
base: master
Choose a base branch
from
+323 −0
Open

BCR-2026-XXX: Signing Event Assertions #151

Changes from all commits
Commits
Show all changes
16 commits
Select commit Hold shift + click to select a range
64e4c5f
Add BCR-2026-006: Signature Context Predicates
ChristopherA Feb 3, 2026
9b5a4a2
Rename delegation predicates to conferral terminology
ChristopherA Feb 4, 2026
0631fc6
Move conferral predicates to BCR-2026-007
ChristopherA Feb 4, 2026
9f5a1f8
Remove supersedes references (moved to structural predicates BCR)
ChristopherA Feb 4, 2026
9b9653f
Rewrite and renumber: BCR-2026-006 → BCR-2026-004 Signing Event Attes…
ChristopherA Feb 4, 2026
e1f6bcf
Add rationale: signature schemes that hide public keys
ChristopherA Feb 4, 2026
626aedb
Rename: attestations → assertions in BCR-2026-004
ChristopherA Feb 4, 2026
773afa0
Add terminology note: assertion vs attestation
ChristopherA Feb 4, 2026
fbbe5c0
Adopt BCR-2024-009 pattern, document both signing patterns
ChristopherA Feb 4, 2026
b9a44ce
BCR-004: Prose cleanup and envelope-cli validation
ChristopherA Feb 4, 2026
92ef862
Expand Security Considerations with verification requirements
ChristopherA Feb 4, 2026
f2a66fa
Use relative link for BCR-2024-009 reference
ChristopherA Feb 4, 2026
8cd14a8
Add Wolf McNally and Shannon Appelcline as authors
ChristopherA Feb 5, 2026
ae52210
Update codepoints: signer 300→800, signedOnBehalfOf 301→801
ChristopherA Feb 5, 2026
0175052
Rename to BCR-2026-XXX temporary designation
ChristopherA Feb 5, 2026
75e98b7
Update for Signature Qualifiers compatibility
ChristopherA Feb 5, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
323 changes: 323 additions & 0 deletions papers/bcr-2026-xxx-signing-event-assertions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,323 @@
# Signing Event Assertions

## BCR-2026-XXX

**© 2026 Blockchain Commons**

Authors: Christopher Allen, Wolf McNally, Shannon Appelcline<br/>
Date: February 5, 2026

---

## Abstract

A cryptographic signature proves a key signed content. It does not prove who holds the key, when signing occurred, or what the signature means. This BCR defines predicates for **signer identity binding** — linking signatures to identity documents (XIDs/DIDs) — using the pattern from BCR-2024-009.

For signature metadata (time, place, role, commitment, policy), see BCR-2026-XXX Signature Qualifiers.

## Status: Draft

## Introduction

### What Signatures Prove

A signature proves exactly one thing:

> **The private key for a specific public key produced this signature over this content.**

A signature does not prove who holds the key, whether the key was compromised or delegated, when signing occurred, why it happened, or that the signer agreed to anything.

```
{
Digest(contract)
} 'signed': Signature
```

This proves the key signed. It does not prove Alice controls that key, that she is CEO, or that she signed for Acme Corp.

### The Problem

Alice signing personally and Alice signing as CEO for Acme Corp produce identical signatures. The difference is what Alice attests about her signing act. To express this in Gordian Envelope:

1. Predicates linking signatures to identity (XIDs)
2. Predicates expressing representation
3. A pattern binding assertions to signatures

### Solution

This BCR defines two predicates for **signer identity binding**:

- `signer` (800) — links signature to signer's identity document
- `signedOnBehalfOf` (801) — identifies who the signer represents

Two patterns bind assertions to signatures:
- **Signature-with-assertions** — signer's own assertions (primary)
- **Wrapped signing** — third-party assertions

### Relationship to Signature Qualifiers

This BCR and BCR-2026-XXX Signature Qualifiers are complementary:

| BCR | Focus | Predicates |
|-----|-------|------------|
| **This BCR** | Signer identity binding | `signer`, `signedOnBehalfOf` |
| Signature Qualifiers | Signature metadata | `sig:signerRole`, `sig:commitment`, `sig:signingTime`, etc. |

Signature Qualifiers derives from XAdES, an international standard we do not control. XAdES handles identity via `SigningCertificate` (X.509-specific). This BCR fills the gap for identity-agnostic systems using XIDs and DIDs.

## Binding Assertions to Signatures

### The Problem

Assertions alongside a signature aren't cryptographically bound:

```
// WRONG: Anyone could add these assertions
{
Digest(contract)
} [
'signed': Signature
'signer': XID(alice)
]
```

### Pattern 1: Signature-with-Assertions

For a signer's own assertions, use the pattern from BCR-2024-009: make the Signature the subject, add assertions, wrap, sign.

```
{
Digest(contract)
} [
'signed': {
Signature [
'signer': XID(alice)
'signedOnBehalfOf': XID(acme-corp)
'sig:signerRole': '' [
'isA': 'sig:Role'
'sig:roleName': "CEO"
]
'sig:commitment': '' [
'isA': 'sig:Commitment'
'sig:commitmentType': 'sig:Approved'
]
]
} ['signed': Signature]
]
```

The inner signature covers content. The outer signature binds assertions to the inner signature. Both must verify against the same key.

### Pattern 2: Wrapped Signing

For third-party assertions (timestamps, notarization), wrap the signed content, add assertions, sign:

```
{
{
Digest(contract)
} [
'signed': {
Signature ['signer': XID(alice)]
} ['signed': Signature]
]
[
'anchoredAt': 2026-02-04T12:00:00Z
'anchoredBy': XID(timestamp-authority)
]
} [
'signed': {
Signature [
'signer': XID(timestamp-authority)
'sig:commitment': '' [
'isA': 'sig:Commitment'
'sig:commitmentType': 'sig:Attested'
]
]
} ['signed': Signature]
]
```

The third party's signature binds their assertions about the already-signed content.

### When to Use Each

| Pattern | Who Asserts | About What |
|---------|-------------|------------|
| Signature-with-assertions | Signer | Their signing act |
| Wrapped signing | Third party | Signed content |

Examples of wrapped signing: timestamp authorities, notaries, witnesses, endorsers.

### Dates vs Timestamps

A date in signing assertions is a claim, not proof. For provable timestamps, a third party must counter-sign — they couldn't sign content that didn't exist.

## Multi-Party Signatures

### Parallel Signatures

Multiple parties independently signing the same content:

```
{
Digest(contract)
} [
'signed': {
Signature [
'signer': XID(alice)
'sig:commitment': '' [
'isA': 'sig:Commitment'
'sig:commitmentType': 'sig:Approved'
]
]
} ['signed': Signature]
'signed': {
Signature [
'signer': XID(bob)
'sig:commitment': '' [
'isA': 'sig:Commitment'
'sig:commitmentType': 'sig:Approved'
]
]
} ['signed': Signature]
]
```

### Counter-Signatures

A party signing over another's signed content:

```
{
{
Digest(contract)
} [
'signed': {
Signature ['signer': XID(alice)]
} ['signed': Signature]
]
} [
'signed': {
Signature [
'signer': XID(bob)
'sig:commitment': '' [
'isA': 'sig:Commitment'
'sig:commitmentType': 'sig:Witnessed'
]
]
} ['signed': Signature]
]
```

Bob's signature covers Alice's complete signed envelope.

## Terminology

**Assertion**: Envelope term for a predicate-object pair.

**Attestation**: The act of declaring facts. Signers *attest*; attestations are expressed as *assertions*.

**Signing Event**: A key producing a signature over content.

**Signing Event Assertions**: Assertions on a Signature subject — who signed, representing whom, in what capacity, for what purpose.

## Known Value Assignments

Proposed for the Reserved range (256-999) per BCR-2023-002.

### 800: `signer`

Links a signature to a document identifying the signer.

**Subject**: Signature<br/>
**Object**: Identity document (XID, DID, or URI)

```
Signature [
'signer': XID(alice)
]
```

A signature proves a key signed; `signer` links to identity. Useful in all scenarios, but required when signature schemes (EdDSA, BBS+, Longfellow) don't embed the public key or allow its recovery from the signature.

Within the Gordian ecosystem (XIDs, Clubs, GSTP), `signer` references an XID or Club. Gordian Envelope also supports DIDs and other URIs.

**Distinction from `sig:signerRole`**: This predicate's object is an **identity document**. The `sig:signerRole` predicate's object is a **role description**. Both may appear on the same signature:

```
Signature [
'signer': XID(alice) // WHO signed (identity)
'sig:signerRole': '' [ // WHAT capacity (role)
'isA': 'sig:Role'
'sig:roleName': "CEO"
]
]
```

### 801: `signedOnBehalfOf`

Optional. Identifies who the signer represents.

**Subject**: Signature<br/>
**Object**: Identity document (XID, DID, or URI) of the represented entity

```
Signature [
'signer': XID(alice)
'signedOnBehalfOf': XID(acme-corp)
]
```

Only include when acting for another party. This is a claim, not fact — evaluation requires checking delegation authority (see BCR-2026-XXX Principal Authority).

**Note**: This predicate expresses representation without requiring any specific authority framework. A signer may represent another entity without formal delegation (e.g., a family member acting for an incapacitated person).

## Security Considerations

### Cryptographic Verification Requirements

For signature-with-assertions pattern, verifiers MUST:

1. Verify the outer signature (on wrapped signature-with-assertions)
2. Verify the inner signature (on content)
3. Confirm both signatures use the **same public key**

If both signatures are valid but use different keys, the envelope has been tampered with — someone added assertions to another party's signature.

For wrapped signing (third-party assertions), different keys are expected — the third party's key signs the outer envelope.

### Claims vs Proof

Signing event assertions are claims by the signer, not proof. Relying parties must evaluate to affirm that:
- The XID resolves to the claimed identity
- All claims (role, representation) are plausible
- Check delegation chains if `signedOnBehalfOf` is present

### Elision

When `signer` is elided, signatures remain valid but identity is hidden. This enables selective disclosure while preserving cryptographic verification.

### Implementation

For API guidance and reference implementation, see [BCR-2024-009](bcr-2024-009-signature-metadata.md).

## References

- [BCR-2023-002: Known Value Registry](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md)
- [BCR-2024-009: Signatures with Metadata](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-009-signature-metadata.md)
- [BCR-2026-XXX: Signature Qualifiers](bcr-2026-xxx-signature-qualifiers.md)
- [Gordian Envelope Specification](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-003-envelope.md)
- [BBS Signature Scheme](https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html)
- [Longfellow ZK Scheme](https://datatracker.ietf.org/doc/html/draft-google-cfrg-libzk-01)

## Related BCRs

- BCR-2026-XXX: General Assertion Predicates
- BCR-2026-XXX: Principal Authority Predicates
- BCR-2026-XXX: Signature Qualifiers — complementary; provides `sig:signerRole`, `sig:commitment`, `sig:signingTime`, etc.

---

*BCR-2026-XXX: Signing Event Assertions*
*Draft — February 5, 2026*