From 64e4c5f5cc30d564502458b633a8c8c40847712a Mon Sep 17 00:00:00 2001 From: Christopher Allen Date: Tue, 3 Feb 2026 02:46:55 -0800 Subject: [PATCH 01/16] Add BCR-2026-006: Signature Context Predicates Proposes Known Values for signature context: signingAs, onBehalfOf, delegatedBy, delegationChain. Applies to all signature types. Community range 1020-1023. Seeking rough consensus; willing to use 100000+ if community prefers. Signed-off-by: Christopher Allen --- papers/bcr-2026-006-signature-context.md | 380 +++++++++++++++++++++++ 1 file changed, 380 insertions(+) create mode 100644 papers/bcr-2026-006-signature-context.md diff --git a/papers/bcr-2026-006-signature-context.md b/papers/bcr-2026-006-signature-context.md new file mode 100644 index 0000000..8f4e0c4 --- /dev/null +++ b/papers/bcr-2026-006-signature-context.md @@ -0,0 +1,380 @@ +# Signature Context Predicates + +## BCR-2026-006 + +**Β© 2026 Blockchain Commons** + +Authors: Christopher Allen
+Date: February 2, 2026 + +--- + +## Abstract + +This document specifies Known Value predicates for expressing the context and capacity in which signatures are made in Gordian Envelopes. These predicates apply to ALL signature types β€” self-attestations, peer endorsements, and binding agreements β€” enabling clear expression of signing role, delegation, and authority chains. + +This BCR depends on [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md) for lifecycle management. + +## Status: Pre-Registration Proposal + +πŸ“™ **Research** β€” This BCR proposes new Known Values and is seeking community review. + +### Registration Intent + +We propose registering these predicates in the **Community Assigned (specification required)** range (1000-1999) as defined in [BCR-2023-002](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md). + +This range is currently unassigned. We are seeking **rough consensus** from the Gordian developer community before claiming these codepoints. If the community determines these predicates: +- Do not merit the 1000-1999 range, or +- Should use different codepoint assignments + +We will register in the **Community Assigned (first come-first served)** range (100000+) instead. + +### Request for Community Review + +We invite feedback on: +- Whether these predicates fill genuine gaps in the Known Value registry +- Whether the 1000-1999 range is appropriate for this vocabulary +- Any conflicts or overlaps with existing ontologies +- Suggested refinements to predicate definitions + +Please submit feedback via: +- [Gordian Developer Community Discussions](https://github.com/BlockchainCommons/Gordian-Developer-Community/discussions) +- Pull requests to this specification + +## Introduction + +### Problem Statement + +When an entity signs an assertion in a Gordian Envelope, the signature captures *that* the signature was made, but not: +- **In what capacity** the signer is acting +- **On whose behalf** the signer may be acting +- **What chain of delegation** authorizes the signature + +These questions apply to ALL signature types: +- **Self-attestations** β€” claims about oneself +- **Peer endorsements** β€” claims about others +- **Binding agreements** β€” bilateral contracts where both parties sign + +Without vocabulary to express signature context, relying parties cannot evaluate the authority behind a signature. + +### Why "Signature Context" Not "Endorsement Authority" + +Earlier drafts named this concern "Endorsement Authority," but [XID-Quickstart Tutorial 09](https://github.com/BlockchainCommons/XID-Quickstart) clarifies that self-attestation, peer endorsement, and binding agreement are DIFFERENT signature types. The predicates in this BCR apply to ALL of them, not just endorsements. + +"Signature Context" accurately describes what these predicates capture: the context and capacity in which any signature is made. + +### Solution + +This specification defines four predicates for signature context: + +1. **`signingAs`** β€” The capacity or role in which the signer is acting +2. **`onBehalfOf`** β€” The party the signer represents (if any) +3. **`delegatedBy`** β€” Who granted the signer's authority +4. **`delegationChain`** β€” The full chain of delegation (for multi-hop) + +### Relationship to Principal Authority + +This BCR and [BCR-2026-007: Principal Authority Predicates](bcr-2026-007-principal-authority.md) address related but distinct concerns: + +| Concern | BCR | Question Answered | +|---------|-----|-------------------| +| **Signature Context** | This BCR (006) | "In what capacity is this signature made?" | +| **Principal Authority** | BCR-2026-007 | "Who directs and takes responsibility for this work?" | + +**Signature Context** is about the signature itself β€” role, delegation, authority chain. + +**Principal Authority** is about the work β€” who directed it, whose judgment shaped it, who stands behind it. + +A document may have: +- `principalAuthority` identifying who directed the work +- `signingAs` on signatures indicating the capacity of each signer + +Both may be present. Neither implies the other. + +## Terminology + +**Signature Context**: The capacity, role, and authority chain under which a signature is made. + +**Signing Capacity**: The role or function in which a signer acts (e.g., "CEO", "Legal Representative", "Witness"). + +**Delegation**: Authorization from one party to another to sign on their behalf. + +**Delegation Chain**: A sequence of delegations from an original authority to the current signer. + +**Known Value**: A registered predicate identifier in the Gordian Envelope system. See [BCR-2023-002](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md). + +## Referenced Specifications + +### BCR-2026-005: General Assertion Predicates + +| Codepoint | Predicate | Usage in This Context | +|-----------|-----------|----------------------| +| 1000 | `supersedes` | Updating delegation assertions | +| 1001 | `revocationReason` | Documenting why delegation was revoked | +| 21 | `validFrom` | When signing authority becomes effective | +| 22 | `validUntil` | When signing authority expires | + +## Proposed Known Value Assignments + +All proposed codepoints are in the **Community Assigned (specification required)** range (1000-1999). + +### Signature Context (1020-1023) + +--- + +#### 1020: `signingAs` + +**Type**: property +**Definition**: The capacity or role in which the signer is acting. +**Domain**: Signature or signed assertion +**Range**: Text or Known Value for role +**Usage**: Clarifies the function the signer is performing. + +``` +{ + CID(corporate-agreement) [ + 'signature': { + XID(alice) [ + 'signingAs': "Chief Executive Officer" + ] + } + ] +} +``` + +**Notes**: +- Applies to any signature type (attestation, endorsement, agreement) +- Does not grant authority β€” only describes claimed capacity +- Relying parties must evaluate whether the claimed capacity is valid + +--- + +#### 1021: `onBehalfOf` + +**Type**: property +**Definition**: The party the signer represents when making this signature. +**Domain**: Signature or signed assertion +**Range**: XID, DID, or identifier of the represented party +**Usage**: Indicates the signer is acting for another entity. + +``` +{ + CID(vendor-contract) [ + 'signature': { + XID(legal-counsel) [ + 'signingAs': "Legal Representative" + 'onBehalfOf': XID(acme-corp) + ] + } + ] +} +``` + +**Notes**: +- The signer asserts they have authority to represent the named party +- Does not itself prove authority β€” see `delegatedBy` for authority chain +- Common in corporate, legal, and organizational contexts + +--- + +#### 1022: `delegatedBy` + +**Type**: property +**Definition**: The entity that granted the signer's authority to sign. +**Domain**: Signature context +**Range**: XID, DID, or identifier of the delegating party +**Usage**: Documents the immediate source of signing authority. + +``` +{ + CID(approval-document) [ + 'signature': { + XID(department-head) [ + 'signingAs': "Authorized Approver" + 'delegatedBy': XID(cfo) + ] + } + ] +} +``` + +**Notes**: +- For single-hop delegation, `delegatedBy` is sufficient +- For multi-hop delegation, use `delegationChain` +- The delegation may be standing (ongoing) or contextual (one-time) + +--- + +#### 1023: `delegationChain` + +**Type**: property +**Definition**: The full chain of delegation from original authority to current signer. +**Domain**: Signature context +**Range**: Ordered list of XIDs/DIDs representing the delegation path +**Usage**: Documents multi-hop delegation for complex authority structures. + +``` +{ + CID(field-authorization) [ + 'signature': { + XID(field-agent) [ + 'signingAs': "Field Representative" + 'delegationChain': [XID(board), XID(ceo), XID(regional-director)] + ] + } + ] +} +``` + +**Notes**: +- Chain is ordered from original authority to immediate delegator +- The signer is implicitly at the end of the chain +- Use for audit trails and authority verification +- Simpler cases can use `delegatedBy` alone + +--- + +## Usage Patterns + +### Self-Attestation with Capacity + +A person signing a claim about themselves, in a specific capacity: + +``` +{ + CID(skill-claim) [ + 'subject': XID(alice) + 'hasSkill': "Rust programming" + 'signature': { + XID(alice) [ + 'signingAs': "Individual" + ] + } + ] +} +``` + +### Peer Endorsement with Capacity + +Someone endorsing another person, in a professional capacity: + +``` +{ + CID(endorsement) [ + 'subject': XID(bob) + 'endorses': "Project management skills" + 'signature': { + XID(alice) [ + 'signingAs': "Former Supervisor" + 'disclosedBias': "Worked together for 3 years" + ] + } + ] +} +``` + +### Corporate Agreement + +A binding agreement signed by representatives: + +``` +{ + CID(service-agreement) [ + 'parties': [XID(acme-corp), XID(widgets-inc)] + 'terms': CID(agreement-terms) + 'signature': { + XID(alice) [ + 'signingAs': "CEO" + 'onBehalfOf': XID(acme-corp) + ] + } + 'signature': { + XID(bob) [ + 'signingAs': "Authorized Representative" + 'onBehalfOf': XID(widgets-inc) + 'delegatedBy': XID(widgets-ceo) + ] + } + ] +} +``` + +### Multi-Hop Delegation + +Field authorization with full audit trail: + +``` +{ + CID(emergency-authorization) [ + 'authorizes': "Emergency procurement up to $50,000" + 'signature': { + XID(field-manager) [ + 'signingAs': "Emergency Coordinator" + 'onBehalfOf': XID(corporation) + 'delegationChain': [XID(board), XID(ceo), XID(coo), XID(regional-vp)] + ] + } + ] +} +``` + +### Combined with Principal Authority + +Using both Signature Context and Principal Authority predicates: + +``` +{ + CID(ai-generated-report) [ + 'principalAuthority': XID(research-director) + 'processDisclosure': "Generated by AI under human direction" + 'signature': { + XID(research-director) [ + 'signingAs': "Principal Investigator" + 'onBehalfOf': XID(research-institute) + ] + } + ] +} +``` + +## Security Considerations + +### Signature Context Claims Are Assertions + +The predicates in this BCR express **claims by the signer**. Relying parties must: +- Verify the signer's identity +- Evaluate whether the claimed capacity (`signingAs`) is plausible +- Verify the delegation chain if authority is claimed +- Consider the context and stakes of the assertion + +### Delegation Verification + +The presence of `delegatedBy` or `delegationChain` does not prove valid delegation. Verification requires: +- Checking that each delegator had authority to delegate +- Confirming the delegation was active at signing time +- Validating any scope or constraint limitations + +### Capacity vs. Authority + +`signingAs` describes claimed capacity, not granted authority. A signature claiming `signingAs: "CEO"` does not prove the signer is a CEO. External verification is required for high-stakes contexts. + +### Chain Integrity + +For `delegationChain`, each link should be independently verifiable. A broken or unverifiable link invalidates the claimed authority from that point forward. + +## References + +- [BCR-2023-002: Known Value Registry](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md) +- [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md) +- [XID-Quickstart Tutorial 09: Binding Agreements](https://github.com/BlockchainCommons/XID-Quickstart) +- [Gordian Envelope Specification](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-001-envelope.md) + +## Related BCRs + +- **BCR-2026-005: General Assertion Predicates** β€” Lifecycle predicates used by this BCR +- **BCR-2026-007: Principal Authority Predicates** β€” Authority over work (complementary concern) + +--- + +*BCR-2026-006: Signature Context Predicates* +*Draft - February 2, 2026* From 9b5a4a210233b1558603218a6190e2e348b8d657 Mon Sep 17 00:00:00 2001 From: Christopher Allen Date: Wed, 4 Feb 2026 00:22:56 -0800 Subject: [PATCH 02/16] Rename delegation predicates to conferral terminology MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - delegatedBy β†’ conferredBy - delegationChain β†’ conferralChain - Updated terminology section with conferral definition - Updated all examples and usage patterns - Changed "key-level" to "cryptographic signing privileges" Rationale: "Conferral" avoids collision with cryptographic delegation (XID delegate predicate), OAuth grants, and access control terminology. Signed-off-by: Christopher Allen --- papers/bcr-2026-006-signature-context.md | 123 +++++++++++++---------- 1 file changed, 70 insertions(+), 53 deletions(-) diff --git a/papers/bcr-2026-006-signature-context.md b/papers/bcr-2026-006-signature-context.md index 8f4e0c4..5d6500a 100644 --- a/papers/bcr-2026-006-signature-context.md +++ b/papers/bcr-2026-006-signature-context.md @@ -11,7 +11,7 @@ Date: February 2, 2026 ## Abstract -This document specifies Known Value predicates for expressing the context and capacity in which signatures are made in Gordian Envelopes. These predicates apply to ALL signature types β€” self-attestations, peer endorsements, and binding agreements β€” enabling clear expression of signing role, delegation, and authority chains. +This document specifies Known Value predicates for expressing the context and capacity in which signatures are made in Gordian Envelopes. These predicates apply to ALL signature types β€” self-attestations, peer endorsements, and binding agreements β€” enabling clear expression of signing role, authority conferral, and authority chains. This BCR depends on [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md) for lifecycle management. @@ -48,7 +48,7 @@ Please submit feedback via: When an entity signs an assertion in a Gordian Envelope, the signature captures *that* the signature was made, but not: - **In what capacity** the signer is acting - **On whose behalf** the signer may be acting -- **What chain of delegation** authorizes the signature +- **What chain of authority** authorizes the signature These questions apply to ALL signature types: - **Self-attestations** β€” claims about oneself @@ -69,8 +69,8 @@ This specification defines four predicates for signature context: 1. **`signingAs`** β€” The capacity or role in which the signer is acting 2. **`onBehalfOf`** β€” The party the signer represents (if any) -3. **`delegatedBy`** β€” Who granted the signer's authority -4. **`delegationChain`** β€” The full chain of delegation (for multi-hop) +3. **`conferredBy`** β€” Who granted the signer's authority +4. **`conferralChain`** β€” The full chain of authority conferral (for multi-hop) ### Relationship to Principal Authority @@ -81,7 +81,7 @@ This BCR and [BCR-2026-007: Principal Authority Predicates](bcr-2026-007-princip | **Signature Context** | This BCR (006) | "In what capacity is this signature made?" | | **Principal Authority** | BCR-2026-007 | "Who directs and takes responsibility for this work?" | -**Signature Context** is about the signature itself β€” role, delegation, authority chain. +**Signature Context** is about the signature itself β€” role, conferral, authority chain. **Principal Authority** is about the work β€” who directed it, whose judgment shaped it, who stands behind it. @@ -97,9 +97,9 @@ Both may be present. Neither implies the other. **Signing Capacity**: The role or function in which a signer acts (e.g., "CEO", "Legal Representative", "Witness"). -**Delegation**: Authorization from one party to another to sign on their behalf. +**Conferral**: The grant of authority from one party to another to act or sign on their behalf. This term is used instead of "delegation" to distinguish from cryptographic delegation (XID `delegate` predicate) which grants cryptographic signing privileges. -**Delegation Chain**: A sequence of delegations from an original authority to the current signer. +**Conferral Chain**: A sequence of authority conferrals from an original authority to the current signer. **Known Value**: A registered predicate identifier in the Gordian Envelope system. See [BCR-2023-002](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md). @@ -109,8 +109,8 @@ Both may be present. Neither implies the other. | Codepoint | Predicate | Usage in This Context | |-----------|-----------|----------------------| -| 1000 | `supersedes` | Updating delegation assertions | -| 1001 | `revocationReason` | Documenting why delegation was revoked | +| 1000 | `supersedes` | Updating authority conferral assertions | +| 1001 | `revocationReason` | Documenting why authority was revoked | | 21 | `validFrom` | When signing authority becomes effective | | 22 | `validUntil` | When signing authority expires | @@ -132,8 +132,8 @@ All proposed codepoints are in the **Community Assigned (specification required) ``` { - CID(corporate-agreement) [ - 'signature': { + Digest(corporate-agreement) [ + 'signed': { XID(alice) [ 'signingAs': "Chief Executive Officer" ] @@ -159,8 +159,8 @@ All proposed codepoints are in the **Community Assigned (specification required) ``` { - CID(vendor-contract) [ - 'signature': { + Digest(vendor-contract) [ + 'signed': { XID(legal-counsel) [ 'signingAs': "Legal Representative" 'onBehalfOf': XID(acme-corp) @@ -172,26 +172,26 @@ All proposed codepoints are in the **Community Assigned (specification required) **Notes**: - The signer asserts they have authority to represent the named party -- Does not itself prove authority β€” see `delegatedBy` for authority chain +- Does not itself prove authority β€” see `conferredBy` for authority chain - Common in corporate, legal, and organizational contexts --- -#### 1022: `delegatedBy` +#### 1022: `conferredBy` **Type**: property **Definition**: The entity that granted the signer's authority to sign. **Domain**: Signature context -**Range**: XID, DID, or identifier of the delegating party +**Range**: XID, DID, or identifier of the conferring party **Usage**: Documents the immediate source of signing authority. ``` { - CID(approval-document) [ - 'signature': { + Digest(approval-document) [ + 'signed': { XID(department-head) [ 'signingAs': "Authorized Approver" - 'delegatedBy': XID(cfo) + 'conferredBy': XID(cfo) ] } ] @@ -199,27 +199,28 @@ All proposed codepoints are in the **Community Assigned (specification required) ``` **Notes**: -- For single-hop delegation, `delegatedBy` is sufficient -- For multi-hop delegation, use `delegationChain` -- The delegation may be standing (ongoing) or contextual (one-time) +- For single-hop authority conferral, `conferredBy` is sufficient +- For multi-hop conferral, use `conferralChain` +- The conferral may be standing (ongoing) or contextual (one-time) +- "Conferral" is used instead of "delegation" to distinguish from cryptographic delegation (XID `delegate` predicate) --- -#### 1023: `delegationChain` +#### 1023: `conferralChain` **Type**: property -**Definition**: The full chain of delegation from original authority to current signer. +**Definition**: The full chain of authority conferral from original authority to current signer. **Domain**: Signature context -**Range**: Ordered list of XIDs/DIDs representing the delegation path -**Usage**: Documents multi-hop delegation for complex authority structures. +**Range**: Ordered list of XIDs/DIDs representing the conferral path +**Usage**: Documents multi-hop authority conferral for complex authority structures. ``` { - CID(field-authorization) [ - 'signature': { + Digest(field-authorization) [ + 'signed': { XID(field-agent) [ 'signingAs': "Field Representative" - 'delegationChain': [XID(board), XID(ceo), XID(regional-director)] + 'conferralChain': [XID(board), XID(ceo), XID(regional-director)] ] } ] @@ -227,10 +228,10 @@ All proposed codepoints are in the **Community Assigned (specification required) ``` **Notes**: -- Chain is ordered from original authority to immediate delegator +- Chain is ordered from original authority to immediate conferrer - The signer is implicitly at the end of the chain - Use for audit trails and authority verification -- Simpler cases can use `delegatedBy` alone +- Simpler cases can use `conferredBy` alone --- @@ -242,10 +243,10 @@ A person signing a claim about themselves, in a specific capacity: ``` { - CID(skill-claim) [ + Digest(skill-claim) [ 'subject': XID(alice) 'hasSkill': "Rust programming" - 'signature': { + 'signed': { XID(alice) [ 'signingAs': "Individual" ] @@ -260,10 +261,10 @@ Someone endorsing another person, in a professional capacity: ``` { - CID(endorsement) [ + Digest(endorsement) [ 'subject': XID(bob) 'endorses': "Project management skills" - 'signature': { + 'signed': { XID(alice) [ 'signingAs': "Former Supervisor" 'disclosedBias': "Worked together for 3 years" @@ -279,39 +280,39 @@ A binding agreement signed by representatives: ``` { - CID(service-agreement) [ + Digest(service-agreement) [ 'parties': [XID(acme-corp), XID(widgets-inc)] - 'terms': CID(agreement-terms) - 'signature': { + 'terms': Digest(agreement-terms) + 'signed': { XID(alice) [ 'signingAs': "CEO" 'onBehalfOf': XID(acme-corp) ] } - 'signature': { + 'signed': { XID(bob) [ 'signingAs': "Authorized Representative" 'onBehalfOf': XID(widgets-inc) - 'delegatedBy': XID(widgets-ceo) + 'conferredBy': XID(widgets-ceo) ] } ] } ``` -### Multi-Hop Delegation +### Multi-Hop Authority Conferral Field authorization with full audit trail: ``` { - CID(emergency-authorization) [ + Digest(emergency-authorization) [ 'authorizes': "Emergency procurement up to $50,000" - 'signature': { + 'signed': { XID(field-manager) [ 'signingAs': "Emergency Coordinator" 'onBehalfOf': XID(corporation) - 'delegationChain': [XID(board), XID(ceo), XID(coo), XID(regional-vp)] + 'conferralChain': [XID(board), XID(ceo), XID(coo), XID(regional-vp)] ] } ] @@ -324,10 +325,10 @@ Using both Signature Context and Principal Authority predicates: ``` { - CID(ai-generated-report) [ + Digest(ai-generated-report) [ 'principalAuthority': XID(research-director) 'processDisclosure': "Generated by AI under human direction" - 'signature': { + 'signed': { XID(research-director) [ 'signingAs': "Principal Investigator" 'onBehalfOf': XID(research-institute) @@ -344,14 +345,14 @@ Using both Signature Context and Principal Authority predicates: The predicates in this BCR express **claims by the signer**. Relying parties must: - Verify the signer's identity - Evaluate whether the claimed capacity (`signingAs`) is plausible -- Verify the delegation chain if authority is claimed +- Verify the conferral chain if authority is claimed - Consider the context and stakes of the assertion -### Delegation Verification +### Authority Conferral Verification -The presence of `delegatedBy` or `delegationChain` does not prove valid delegation. Verification requires: -- Checking that each delegator had authority to delegate -- Confirming the delegation was active at signing time +The presence of `conferredBy` or `conferralChain` does not prove valid authority conferral. Verification requires: +- Checking that each conferrer had authority to confer +- Confirming the conferral was active at signing time - Validating any scope or constraint limitations ### Capacity vs. Authority @@ -360,19 +361,35 @@ The presence of `delegatedBy` or `delegationChain` does not prove valid delegati ### Chain Integrity -For `delegationChain`, each link should be independently verifiable. A broken or unverifiable link invalidates the claimed authority from that point forward. +For `conferralChain`, each link should be independently verifiable. A broken or unverifiable link invalidates the claimed authority from that point forward. + +## Open Questions + +### Q1: Integration with BCR-2024-009 Signature Metadata + +[BCR-2024-009](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-009-signature-metadata.md) defines a pattern for attaching metadata to signatures using double-signing: the outer signature signs both the original content and the metadata on the inner Signature object. + +**Question**: Should the signature context predicates in this BCR (`signingAs`, `onBehalfOf`, `conferredBy`, `conferralChain`) be applied: + +1. **As assertions on the signer XID** (as shown in current examples) β€” simpler but metadata is separate from signature +2. **As metadata on the Signature object** (per BCR-2024-009) β€” cryptographically bound but requires double-signing +3. **Either pattern depending on use case** β€” with guidance on when to use each + +We invite community feedback on the recommended integration pattern. See [GitHub issue #158](https://github.com/BlockchainCommons/Research/issues/158) for discussion. ## References - [BCR-2023-002: Known Value Registry](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md) +- [BCR-2024-009: Signature Metadata](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-009-signature-metadata.md) - [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md) - [XID-Quickstart Tutorial 09: Binding Agreements](https://github.com/BlockchainCommons/XID-Quickstart) - [Gordian Envelope Specification](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-001-envelope.md) ## Related BCRs +- **BCR-2024-009: Signature Metadata** β€” Established pattern for attaching metadata to signatures using double-signing. Signature context predicates should be applied using this pattern. - **BCR-2026-005: General Assertion Predicates** β€” Lifecycle predicates used by this BCR -- **BCR-2026-007: Principal Authority Predicates** β€” Authority over work (complementary concern) +- **BCR-2026-007: Principal Authority Predicates** β€” Authority over work (complementary; uses matching `conferral*` terminology) --- From 0631fc68f70a12b5bc97b9e70d2a49635f1e64bd Mon Sep 17 00:00:00 2001 From: Christopher Allen Date: Wed, 4 Feb 2026 00:27:05 -0800 Subject: [PATCH 03/16] Move conferral predicates to BCR-2026-007 Consolidating all authority conferral predicates in one place: - Removed conferredBy (1022) and conferralChain (1023) from this BCR - BCR-006 now focused on signing context only: signingAs, onBehalfOf - BCR-2026-007 now has all conferral predicates (1040-1045) This avoids having conferral terminology split across two BCRs. Signed-off-by: Christopher Allen --- papers/bcr-2026-006-signature-context.md | 113 +++-------------------- 1 file changed, 12 insertions(+), 101 deletions(-) diff --git a/papers/bcr-2026-006-signature-context.md b/papers/bcr-2026-006-signature-context.md index 5d6500a..e571068 100644 --- a/papers/bcr-2026-006-signature-context.md +++ b/papers/bcr-2026-006-signature-context.md @@ -11,7 +11,7 @@ Date: February 2, 2026 ## Abstract -This document specifies Known Value predicates for expressing the context and capacity in which signatures are made in Gordian Envelopes. These predicates apply to ALL signature types β€” self-attestations, peer endorsements, and binding agreements β€” enabling clear expression of signing role, authority conferral, and authority chains. +This document specifies Known Value predicates for expressing the context and capacity in which signatures are made in Gordian Envelopes. These predicates apply to ALL signature types β€” self-attestations, peer endorsements, and binding agreements β€” enabling clear expression of signing role and representation. This BCR depends on [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md) for lifecycle management. @@ -65,12 +65,12 @@ Earlier drafts named this concern "Endorsement Authority," but [XID-Quickstart T ### Solution -This specification defines four predicates for signature context: +This specification defines two predicates for signature context: 1. **`signingAs`** β€” The capacity or role in which the signer is acting 2. **`onBehalfOf`** β€” The party the signer represents (if any) -3. **`conferredBy`** β€” Who granted the signer's authority -4. **`conferralChain`** β€” The full chain of authority conferral (for multi-hop) + +For authority conferral chains (who granted signing authority), see [BCR-2026-007: Principal Authority Predicates](bcr-2026-007-principal-authority.md) which defines `conferredBy` and `conferralChain`. ### Relationship to Principal Authority @@ -81,7 +81,7 @@ This BCR and [BCR-2026-007: Principal Authority Predicates](bcr-2026-007-princip | **Signature Context** | This BCR (006) | "In what capacity is this signature made?" | | **Principal Authority** | BCR-2026-007 | "Who directs and takes responsibility for this work?" | -**Signature Context** is about the signature itself β€” role, conferral, authority chain. +**Signature Context** is about the signature itself β€” the role and representation claims. **Principal Authority** is about the work β€” who directed it, whose judgment shaped it, who stands behind it. @@ -97,10 +97,6 @@ Both may be present. Neither implies the other. **Signing Capacity**: The role or function in which a signer acts (e.g., "CEO", "Legal Representative", "Witness"). -**Conferral**: The grant of authority from one party to another to act or sign on their behalf. This term is used instead of "delegation" to distinguish from cryptographic delegation (XID `delegate` predicate) which grants cryptographic signing privileges. - -**Conferral Chain**: A sequence of authority conferrals from an original authority to the current signer. - **Known Value**: A registered predicate identifier in the Gordian Envelope system. See [BCR-2023-002](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md). ## Referenced Specifications @@ -118,7 +114,7 @@ Both may be present. Neither implies the other. All proposed codepoints are in the **Community Assigned (specification required)** range (1000-1999). -### Signature Context (1020-1023) +### Signature Context (1020-1021) --- @@ -172,69 +168,11 @@ All proposed codepoints are in the **Community Assigned (specification required) **Notes**: - The signer asserts they have authority to represent the named party -- Does not itself prove authority β€” see `conferredBy` for authority chain +- Does not itself prove authority β€” see BCR-2026-007 for `conferredBy` and `conferralChain` - Common in corporate, legal, and organizational contexts --- -#### 1022: `conferredBy` - -**Type**: property -**Definition**: The entity that granted the signer's authority to sign. -**Domain**: Signature context -**Range**: XID, DID, or identifier of the conferring party -**Usage**: Documents the immediate source of signing authority. - -``` -{ - Digest(approval-document) [ - 'signed': { - XID(department-head) [ - 'signingAs': "Authorized Approver" - 'conferredBy': XID(cfo) - ] - } - ] -} -``` - -**Notes**: -- For single-hop authority conferral, `conferredBy` is sufficient -- For multi-hop conferral, use `conferralChain` -- The conferral may be standing (ongoing) or contextual (one-time) -- "Conferral" is used instead of "delegation" to distinguish from cryptographic delegation (XID `delegate` predicate) - ---- - -#### 1023: `conferralChain` - -**Type**: property -**Definition**: The full chain of authority conferral from original authority to current signer. -**Domain**: Signature context -**Range**: Ordered list of XIDs/DIDs representing the conferral path -**Usage**: Documents multi-hop authority conferral for complex authority structures. - -``` -{ - Digest(field-authorization) [ - 'signed': { - XID(field-agent) [ - 'signingAs': "Field Representative" - 'conferralChain': [XID(board), XID(ceo), XID(regional-director)] - ] - } - ] -} -``` - -**Notes**: -- Chain is ordered from original authority to immediate conferrer -- The signer is implicitly at the end of the chain -- Use for audit trails and authority verification -- Simpler cases can use `conferredBy` alone - ---- - ## Usage Patterns ### Self-Attestation with Capacity @@ -293,31 +231,13 @@ A binding agreement signed by representatives: XID(bob) [ 'signingAs': "Authorized Representative" 'onBehalfOf': XID(widgets-inc) - 'conferredBy': XID(widgets-ceo) ] } ] } ``` -### Multi-Hop Authority Conferral - -Field authorization with full audit trail: - -``` -{ - Digest(emergency-authorization) [ - 'authorizes': "Emergency procurement up to $50,000" - 'signed': { - XID(field-manager) [ - 'signingAs': "Emergency Coordinator" - 'onBehalfOf': XID(corporation) - 'conferralChain': [XID(board), XID(ceo), XID(coo), XID(regional-vp)] - ] - } - ] -} -``` +For documenting authority chains (who granted signing authority), see BCR-2026-007's `conferredBy` and `conferralChain` predicates. ### Combined with Principal Authority @@ -345,23 +265,14 @@ Using both Signature Context and Principal Authority predicates: The predicates in this BCR express **claims by the signer**. Relying parties must: - Verify the signer's identity - Evaluate whether the claimed capacity (`signingAs`) is plausible -- Verify the conferral chain if authority is claimed +- Verify authority claims using BCR-2026-007 predicates if needed - Consider the context and stakes of the assertion -### Authority Conferral Verification - -The presence of `conferredBy` or `conferralChain` does not prove valid authority conferral. Verification requires: -- Checking that each conferrer had authority to confer -- Confirming the conferral was active at signing time -- Validating any scope or constraint limitations - ### Capacity vs. Authority `signingAs` describes claimed capacity, not granted authority. A signature claiming `signingAs: "CEO"` does not prove the signer is a CEO. External verification is required for high-stakes contexts. -### Chain Integrity - -For `conferralChain`, each link should be independently verifiable. A broken or unverifiable link invalidates the claimed authority from that point forward. +For authority chain verification, see BCR-2026-007 which defines `conferredBy` and `conferralChain`. ## Open Questions @@ -369,7 +280,7 @@ For `conferralChain`, each link should be independently verifiable. A broken or [BCR-2024-009](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-009-signature-metadata.md) defines a pattern for attaching metadata to signatures using double-signing: the outer signature signs both the original content and the metadata on the inner Signature object. -**Question**: Should the signature context predicates in this BCR (`signingAs`, `onBehalfOf`, `conferredBy`, `conferralChain`) be applied: +**Question**: Should the signature context predicates in this BCR (`signingAs`, `onBehalfOf`) be applied: 1. **As assertions on the signer XID** (as shown in current examples) β€” simpler but metadata is separate from signature 2. **As metadata on the Signature object** (per BCR-2024-009) β€” cryptographically bound but requires double-signing @@ -389,7 +300,7 @@ We invite community feedback on the recommended integration pattern. See [GitHub - **BCR-2024-009: Signature Metadata** β€” Established pattern for attaching metadata to signatures using double-signing. Signature context predicates should be applied using this pattern. - **BCR-2026-005: General Assertion Predicates** β€” Lifecycle predicates used by this BCR -- **BCR-2026-007: Principal Authority Predicates** β€” Authority over work (complementary; uses matching `conferral*` terminology) +- **BCR-2026-007: Principal Authority Predicates** β€” Authority relationships including `conferredBy` and `conferralChain` for documenting authority chains --- From 9f5a1f85d06553065d6384d562f77483ada73d82 Mon Sep 17 00:00:00 2001 From: Christopher Allen Date: Wed, 4 Feb 2026 01:12:24 -0800 Subject: [PATCH 04/16] Remove supersedes references (moved to structural predicates BCR) --- papers/bcr-2026-006-signature-context.md | 1 - 1 file changed, 1 deletion(-) diff --git a/papers/bcr-2026-006-signature-context.md b/papers/bcr-2026-006-signature-context.md index e571068..34fa363 100644 --- a/papers/bcr-2026-006-signature-context.md +++ b/papers/bcr-2026-006-signature-context.md @@ -105,7 +105,6 @@ Both may be present. Neither implies the other. | Codepoint | Predicate | Usage in This Context | |-----------|-----------|----------------------| -| 1000 | `supersedes` | Updating authority conferral assertions | | 1001 | `revocationReason` | Documenting why authority was revoked | | 21 | `validFrom` | When signing authority becomes effective | | 22 | `validUntil` | When signing authority expires | From 9b9653f0444fe0005401e6fd4d3fe2412f194f88 Mon Sep 17 00:00:00 2001 From: Christopher Allen Date: Wed, 4 Feb 2026 13:29:02 -0800 Subject: [PATCH 05/16] =?UTF-8?q?Rewrite=20and=20renumber:=20BCR-2026-006?= =?UTF-8?q?=20=E2=86=92=20BCR-2026-004=20Signing=20Event=20Attestations?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Major rewrite establishing the mental model for signing events: RENAMED: bcr-2026-006-signature-context.md β†’ bcr-2026-004-signing-event-attestations.md Key changes: - Lead with insight: signed proves key, not identity or intent - Define precisely what a cryptographic signature proves - Document double-signing pattern for binding attestations to signatures - Use "attestations" terminology consistently (replaces "context") - Clarify dates are self-asserted claims, not timestamps (proofs) - Document key separation scenarios (by purpose, by device, third-party) - Distinguish Gordian ecosystem (XIDs/Clubs) from broader use (URIs/DIDs) - Remove incorrect BCR-2024-009 attribution for double-signing pattern - Codepoints 300-301 in Reserved range (was Community range) This BCR is renumbered to 004 as it establishes foundational concepts needed by other BCRs and requires only internal approval. Signed-off-by: Christopher Allen --- ...bcr-2026-004-signing-event-attestations.md | 457 ++++++++++++++++++ papers/bcr-2026-006-signature-context.md | 307 ------------ 2 files changed, 457 insertions(+), 307 deletions(-) create mode 100644 papers/bcr-2026-004-signing-event-attestations.md delete mode 100644 papers/bcr-2026-006-signature-context.md diff --git a/papers/bcr-2026-004-signing-event-attestations.md b/papers/bcr-2026-004-signing-event-attestations.md new file mode 100644 index 0000000..0cb0994 --- /dev/null +++ b/papers/bcr-2026-004-signing-event-attestations.md @@ -0,0 +1,457 @@ +# Signing Event Attestations + +## BCR-2026-004 + +**Β© 2026 Blockchain Commons** + +Authors: Christopher Allen
+Date: February 4, 2026 + +--- + +## Abstract + +In Gordian Envelope, the `signed` predicate is purely cryptographic — it proves that a specific private key was used to sign specific content. Nothing more. A signature alone doesn't prove who possesses the key, when signing occurred, or what the signature means. + +To express these facts about a signing event, signers must explicitly attest them using predicates bound to the signature via the double-signing pattern. This BCR: + +1. **Establishes the mental model** — signatures prove keys signed, not identity or intent +2. **Documents the double-signing pattern** — how to cryptographically bind attestations to signatures +3. **Defines two novel predicates** — `signer` (300) links to the signer's identity; `signedOnBehalfOf` (301) optionally identifies another XID the signer represents +4. **References XAdES standards** — `xades:ClaimedRole` and `xades:CommitmentType` for additional attestation types + +## Status: Draft + +## Introduction + +### Signed Proves Key, Not Identity + +In Gordian Envelope, the `signed` predicate is a **purely cryptographic operation**. 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.** + +That's it. Given the public key and the content, anyone can verify this mathematical relationship. If the content changes by even one bit, verification fails. If a different private key signed, verification fails. + +A signature does **not** prove: +- **Who** possesses or possessed the private key +- **Whether** the key has been compromised, shared, or delegated +- **When** the signing operation occurred +- **Why** the signing happened or what it means +- **That** the signer read, understood, or agreed to the content + +``` +{ + Digest(contract) +} 'signed': Signature(key-abc123) +``` + +This proves the private key for `abc123` signed the contract digest. It does not prove Alice controls that key, that Alice is CEO, that Alice signed on behalf of Acme Corp, or even that Alice has ever seen the contract. + +### Identical Signatures Can Mean Different Things + +Compare two scenarios: + +**Scenario A**: Alice's personal key signs a document. The signature proves the key signed. + +**Scenario B**: Alice, as CEO, signs a contract on behalf of Acme Corp as approval. + +Both produce cryptographically identical signatures. The difference is what the signer attests — who Alice is, what role she's acting in, and what her signature means. + +To express these attestations in Gordian Envelope, we need: +1. Explicit predicates linking signatures to identity documents (XIDs) +2. Predicates expressing representation relationships +3. A pattern for cryptographically binding attestations to signatures + +### Solution + +This specification defines: + +1. **Two novel predicates** for signing event attestations: + - `signer` — Links a signature to the signer's XID document + - `signedOnBehalfOf` — (Optional) Identifies another XID that the signer represents + +2. **References to XAdES standards** for additional attestation types: + - `xades:ClaimedRole` — The capacity in which the signer is acting + - `xades:CommitmentType` — The purpose or meaning of the signature + +3. **The double-signing pattern** for cryptographically binding attestations to signatures + +## The Double-Signing Pattern + +### Problem: Attestations Must Be Bound to Signatures + +Simply adding assertions alongside a signature doesn't cryptographically bind them: + +``` +// WRONG: Attestations not bound to signature +{ + Digest(contract) +} 'signed': Signature(alice) + 'signer': XID(alice) // Not signed! + 'signedOnBehalfOf': XID(acme) // Anyone could add this +``` + +These attestations could be added or modified by anyone after Alice signed. + +### Solution: Wrap and Sign Twice + +The double-signing pattern solves this: + +1. **Inner wrap and sign**: Sign the content +2. **Add attestations**: Attach signing event attestations to the inner signed envelope +3. **Outer wrap and sign**: Sign again, binding the attestations + +``` +{ + { + Digest(contract) + } 'signed': Signature(alice) + [ + 'signer': XID(alice) + 'signedOnBehalfOf': XID(acme-corp) + 'xades:ClaimedRole': "Chief Executive Officer" + 'xades:CommitmentType': "approval" + ] +} 'signed': Signature(alice) +``` + +Now the outer signature cryptographically binds Alice's identity, representation, role, and commitment type to her inner signature on the contract. + +### Inner Signs Content, Outer Binds Attestations + +The inner signature proves: "This key signed this content." + +The outer signature proves: "This key asserts these attestations about that signature." + +Typically both signatures use the same key — Alice making attestations about her own signature. But they need not be the same: + +- **Same key**: Self-asserted attestations. Alice claims her own identity, role, and intent. +- **Different key**: May be key separation or third-party assertion: + - **By purpose**: Alice uses distinct keys for different operations — one authorized only for git commits, another for contract signing, another for routine approvals + - **By device**: Alice uses distinct keys on different devices — phone, laptop, hardware token — each with its own authorization scope + - **Third-party**: A different identity is attesting facts about Alice's signature. If this is a formal counter-signature (notary, witness, approver), see the Counter-Signatures section below. If not a counter-signature, third-party attestations are generally not recommended — the signer should make their own attestations. Exception: hardware attestations where a secure element attests security properties of the signing operation. + + The `signer` predicate points to the XID where key purposes and devices are documented, allowing relying parties to determine which case applies. + +### What Belongs in Signing Event Attestations + +The signing event attestations should contain **only the signer's own claims about the signing event**: + +| Signing Event Attestations | Does NOT Belong | +|---------------------------|-----------------| +| `signer` — who I am | Third-party role certifications | +| `signedOnBehalfOf` — who I represent (if applicable) | Third-party authority attestations | +| `xades:ClaimedRole` — my claimed capacity (if applicable) | Endorsements of the signer | +| `xades:CommitmentType` — what this signature means (if applicable) | Credentials about the signer | + +Third-party attestations about the signer (certifying their role, endorsing their authority, etc.) belong in the **signer's XID document**, not in the signing event attestations. The `signer` predicate points to where those third-party attestations live. + +This separation ensures: +1. Signing event attestations contain only self-asserted claims about the signing event +2. Third-party attestations are discoverable via the XID reference +3. Relying parties know which claims are self-asserted vs. third-party certified + +### Dates Are Not Timestamps + +A signer can include a date in their signing event attestations — this is acceptable and sometimes useful. But it's critical to understand: **a date is not a timestamp**. + +A date in signing event attestations is a **self-asserted claim**, not a proof. The signer claims "I signed this on February 4, 2026" — but the only thing the signature actually proves is that the key signed the content. The date is just another attestation. + +For **provable timestamps**, you need a third-party timestamp authority to counter-sign the envelope. The timestamp authority's signature proves the content existed at a specific time — because the authority couldn't have signed something that didn't exist yet. + +This is the same mental model issue: people assume a date inside a signed envelope proves when it was signed. It doesn't. Only a counter-signature from a trusted timestamp authority provides that proof. + +**Note**: Lifecycle predicates like `validFrom` and `validUntil` belong in the main attestation (see BCR-2026-005), not in the signing event attestations. A signing event records facts about the act of signing; validity periods are properties of the content being signed. + +Timestamp authority patterns (similar to RFC 3161 TSA or blockchain anchoring) are outside the scope of this BCR. See BCR-2026-011 (Anchor Predicates) for cryptographic event log attestation patterns. + +## Counter-Signatures (Multi-Party) + +When multiple parties sign with attestations, each applies the double-signing pattern: + +``` +{ + // Alice's double-signed envelope + { + { + Digest(contract) + } 'signed': Signature(alice) + [ + 'signer': XID(alice) + 'signedOnBehalfOf': XID(acme-corp) + 'xades:ClaimedRole': "CEO" + 'xades:CommitmentType': "approval" + ] + } 'signed': Signature(alice) + + // Bob's attestations (counter-signature) + [ + 'signer': XID(bob) + 'signedOnBehalfOf': XID(widgets-inc) + 'xades:ClaimedRole': "Authorized Representative" + 'xades:CommitmentType': "approval" + ] +} 'signed': Signature(bob) +``` + +Bob's outer signature binds his attestations to his counter-signature on Alice's already-signed envelope. + +## Terminology + +**Signing Event**: The act of a private key producing a signature over specific content. The cryptographic operation itself — distinct from any claims about who performed it or why. + +**Signing Event Attestations**: Claims made by the signer about the signing event — who they are (`signer`), who they represent (`signedOnBehalfOf`), in what capacity (`xades:ClaimedRole`), and the signature's purpose (`xades:CommitmentType`). These are self-asserted claims, not cryptographic proofs. + +**Double-Signing Pattern**: The technique of wrapping and signing twice to cryptographically bind attestations to an inner signature. The inner signature proves the key signed; the outer signature proves the key asserts the attestations. + +**XID Document**: An eXtensible IDentifier document containing identity information, key bindings, key purposes, and other assertions about an identity. + +**XAdES**: XML Advanced Electronic Signatures, an ETSI standard defining signature properties including claimed roles and commitment types. + +## Proposed Known Value Assignments + +This BCR proposes additions to the **Reserved** range (256-999) as defined in [BCR-2023-002](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md). + +The proposed codepoints (300-301) are placed above the compact 2-byte range (0-255) to preserve those precious codepoints for the most fundamental predicates. Signing event attestations are important but not as frequent as core predicates, and 3-byte encoding is acceptable for attestations that appear once per signature. + +### Signing Event Attestations (300-301) + +--- + +#### 300: `signer` + +**Type**: property +**Definition**: Links a signature to a document identifying the signer. +**Domain**: Signing event attestations (on inner signed envelope) +**Range**: Identity reference (may be ELIDED for privacy) +**Usage**: Establishes who made the signature, as opposed to which key made it. + +``` +{ + { + Digest(document) + } 'signed': Signature(key-abc123) + [ + 'signer': XID(alice) + ] +} 'signed': Signature(key-abc123) +``` + +**Notes**: +- A signature proves a key signed; `signer` links to the identity behind the key +- The identity reference can be elided while preserving the attestation structure +- Without `signer`, relying parties must resolve key→identity through other means +- **Gordian ecosystem**: Within XIDs, Clubs, and GSTP, this predicate references an XID or Club +- **Broader use**: Gordian Envelope supports other identity reference formats (URIs, DIDs, etc.) for interoperability with external systems + +--- + +#### 301: `signedOnBehalfOf` + +**Type**: property +**Definition**: (Optional) Identifies another entity that the signer represents when making this signature. +**Domain**: Signing event attestations (on inner signed envelope) +**Range**: Identity reference +**Usage**: Indicates the signer is acting for another entity. + +``` +{ + { + Digest(vendor-contract) + } 'signed': Signature(alice-key) + [ + 'signer': XID(alice) + 'signedOnBehalfOf': XID(acme-corp) + ] +} 'signed': Signature(alice-key) +``` + +**Notes**: +- **Optional** — Only include when the signer is acting on behalf of another party (e.g., employee signing for company, agent signing for principal). Omit when signing in personal capacity. +- This is a claim by the signer — verification requires checking delegation authority +- For authority chain documentation, see BCR-2026-006's `conferredBy` and `conferralChain` predicates +- Common in corporate, legal, and organizational contexts +- **Gordian ecosystem**: Within XIDs, Clubs, and GSTP, this predicate references an XID or Club +- **Broader use**: Gordian Envelope supports other identity reference formats (URIs, DIDs, etc.) for interoperability with external systems + +--- + +## Referenced Standards + +This BCR references predicates from the XAdES standard for signature properties that are not novel to Gordian Envelope. + +### xades:ClaimedRole + +**Standard**: ETSI TS 101 903 (XAdES) +**Definition**: The capacity or role in which the signer is acting, as claimed by the signer. +**Range**: Text describing the role (e.g., "CEO", "Legal Representative", "Witness") +**Usage**: Describes the function the signer is performing. + +``` +[ + 'signer': XID(alice) + 'xades:ClaimedRole': "Chief Executive Officer" +] +``` + +**Notes**: +- This is a claimed role, not a certified role — it is self-asserted +- For certified roles backed by certificate chains, see XAdES CertifiedRoles +- Gordian Envelope supports text values; implementations may use Known Values for common roles + +### xades:CommitmentType + +**Standard**: ETSI TS 101 903 (XAdES) +**Definition**: The purpose or meaning of the signature — what the signer is committing to. +**Range**: Text or identifier describing the commitment type +**Usage**: Distinguishes different signature purposes (approval, acknowledgment, witness, etc.) + +``` +[ + 'signer': XID(alice) + 'xades:CommitmentType': "approval" +] +``` + +**Notes**: +- Gordian Envelope does not limit values to XAdES OID constants +- Common values include: "approval", "acknowledgment", "witness", "receipt", "origin" +- For XAdES OID interoperability, see Appendix A + +--- + +## Usage Patterns + +### Complete Signature with Attestations + +``` +{ + { + Digest(contract) + } 'signed': Signature(alice-key) + [ + 'signer': XID(alice) + 'signedOnBehalfOf': XID(acme-corp) + 'xades:ClaimedRole': "CEO" + 'xades:CommitmentType': "approval" + ] +} 'signed': Signature(alice-key) +``` + +### Minimal Signature with Identity Only + +``` +{ + { + Digest(document) + } 'signed': Signature(alice-key) + [ + 'signer': XID(alice) + ] +} 'signed': Signature(alice-key) +``` + +### Privacy-Preserving with Elided Signer + +``` +{ + { + Digest(document) + } 'signed': Signature(...) + [ + 'signer': ELIDED + 'xades:CommitmentType': "witness" + ] +} 'signed': Signature(...) +``` + +The signature structure is preserved, the commitment type is visible, but the signer identity is elided. + +## Relationship to Other Specifications + +### Double-Signing Pattern + +This BCR formally documents the double-signing pattern for signing event attestations. While the technique of wrapping and signing twice has been used informally in Gordian Envelope examples, this specification establishes the best practices and defines the predicates for expressing signing event attestations. + +### BCR-2026-006: Principal Authority Predicates + +| Concern | BCR | Question Answered | +|---------|-----|-------------------| +| **Signing Event Attestations** | This BCR (004) | "What are the facts about this signing event?" | +| **Principal Authority** | BCR-2026-006 | "Who directed and takes responsibility for this work?" | + +A document may have: +- `principalAuthority` identifying who directed the work +- Signing event attestation predicates indicating who signed and how + +Both may be present. Neither implies the other. + +### XID Key Operations + +| Codepoint | Predicate | Purpose | +|-----------|-----------|---------| +| 63 | `delegate` | Grants cryptographic signing privileges to another key | +| 300 | `signer` | Links a signature to an identity (XID document) | +| 301 | `signedOnBehalfOf` | Indicates representation relationship | + +`delegate` is a key-level operation (key A can sign for key B). `signer` and `signedOnBehalfOf` are identity-level operations (person Alice signed for organization Acme). + +## Security Considerations + +### Attestations Are Self-Asserted + +The predicates in this BCR express **claims by the signer**. Relying parties must: +- Verify the signature cryptographically +- Resolve the XID reference to confirm identity +- Evaluate whether the claimed role and representation are plausible +- Verify authority claims using BCR-2026-006 predicates if needed + +### Double-Signing Integrity + +Both signatures should use the same key. If the outer signature uses a different key: +- It becomes a counter-signature (third-party assertion about the inner signature) +- The attestations become that third party's claims about the signer +- This may be intentional (notarization) or a verification failure + +### Elision and Attestations + +When `signer` is elided: +- The signature remains cryptographically valid +- The signing key is visible (in the Signature) +- The identity behind the key is hidden +- Other attestations (role, commitment) may remain visible + +This enables privacy-preserving signatures where identity is disclosed selectively. + +## References + +- [BCR-2023-002: Known Value Registry](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md) +- [ETSI TS 101 903: XAdES](https://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.02_60/ts_101903v010402p.pdf) +- [Gordian Envelope Specification](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-001-envelope.md) + +## Related BCRs + +- **BCR-2026-005: General Assertion Predicates** — Lifecycle predicates (`validFrom`, `validUntil`) +- **BCR-2026-006: Principal Authority Predicates** — Authority relationships (`conferredBy`, `conferralChain`) + +--- + +## Appendix A: XAdES Commitment Type OIDs + +For systems requiring XAdES interoperability, the following OID values are defined by ETSI TS 101 903: + +| Commitment Type | OID | +|-----------------|-----| +| Proof of origin | 1.2.840.113549.1.9.16.6.1 | +| Proof of receipt | 1.2.840.113549.1.9.16.6.2 | +| Proof of delivery | 1.2.840.113549.1.9.16.6.3 | +| Proof of sender | 1.2.840.113549.1.9.16.6.4 | +| Proof of approval | 1.2.840.113549.1.9.16.6.5 | +| Proof of creation | 1.2.840.113549.1.9.16.6.6 | + +Gordian Envelope implementations may use these OIDs or equivalent text values. The `xades:CommitmentType` predicate is not limited to these values. + +--- + +*BCR-2026-004: Signing Event Attestations* +*Draft - February 4, 2026* diff --git a/papers/bcr-2026-006-signature-context.md b/papers/bcr-2026-006-signature-context.md deleted file mode 100644 index 34fa363..0000000 --- a/papers/bcr-2026-006-signature-context.md +++ /dev/null @@ -1,307 +0,0 @@ -# Signature Context Predicates - -## BCR-2026-006 - -**© 2026 Blockchain Commons** - -Authors: Christopher Allen
-Date: February 2, 2026 - ---- - -## Abstract - -This document specifies Known Value predicates for expressing the context and capacity in which signatures are made in Gordian Envelopes. These predicates apply to ALL signature types β€” self-attestations, peer endorsements, and binding agreements β€” enabling clear expression of signing role and representation. - -This BCR depends on [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md) for lifecycle management. - -## Status: Pre-Registration Proposal - -πŸ“™ **Research** β€” This BCR proposes new Known Values and is seeking community review. - -### Registration Intent - -We propose registering these predicates in the **Community Assigned (specification required)** range (1000-1999) as defined in [BCR-2023-002](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md). - -This range is currently unassigned. We are seeking **rough consensus** from the Gordian developer community before claiming these codepoints. If the community determines these predicates: -- Do not merit the 1000-1999 range, or -- Should use different codepoint assignments - -We will register in the **Community Assigned (first come-first served)** range (100000+) instead. - -### Request for Community Review - -We invite feedback on: -- Whether these predicates fill genuine gaps in the Known Value registry -- Whether the 1000-1999 range is appropriate for this vocabulary -- Any conflicts or overlaps with existing ontologies -- Suggested refinements to predicate definitions - -Please submit feedback via: -- [Gordian Developer Community Discussions](https://github.com/BlockchainCommons/Gordian-Developer-Community/discussions) -- Pull requests to this specification - -## Introduction - -### Problem Statement - -When an entity signs an assertion in a Gordian Envelope, the signature captures *that* the signature was made, but not: -- **In what capacity** the signer is acting -- **On whose behalf** the signer may be acting -- **What chain of authority** authorizes the signature - -These questions apply to ALL signature types: -- **Self-attestations** β€” claims about oneself -- **Peer endorsements** β€” claims about others -- **Binding agreements** β€” bilateral contracts where both parties sign - -Without vocabulary to express signature context, relying parties cannot evaluate the authority behind a signature. - -### Why "Signature Context" Not "Endorsement Authority" - -Earlier drafts named this concern "Endorsement Authority," but [XID-Quickstart Tutorial 09](https://github.com/BlockchainCommons/XID-Quickstart) clarifies that self-attestation, peer endorsement, and binding agreement are DIFFERENT signature types. The predicates in this BCR apply to ALL of them, not just endorsements. - -"Signature Context" accurately describes what these predicates capture: the context and capacity in which any signature is made. - -### Solution - -This specification defines two predicates for signature context: - -1. **`signingAs`** β€” The capacity or role in which the signer is acting -2. **`onBehalfOf`** β€” The party the signer represents (if any) - -For authority conferral chains (who granted signing authority), see [BCR-2026-007: Principal Authority Predicates](bcr-2026-007-principal-authority.md) which defines `conferredBy` and `conferralChain`. - -### Relationship to Principal Authority - -This BCR and [BCR-2026-007: Principal Authority Predicates](bcr-2026-007-principal-authority.md) address related but distinct concerns: - -| Concern | BCR | Question Answered | -|---------|-----|-------------------| -| **Signature Context** | This BCR (006) | "In what capacity is this signature made?" | -| **Principal Authority** | BCR-2026-007 | "Who directs and takes responsibility for this work?" | - -**Signature Context** is about the signature itself β€” the role and representation claims. - -**Principal Authority** is about the work β€” who directed it, whose judgment shaped it, who stands behind it. - -A document may have: -- `principalAuthority` identifying who directed the work -- `signingAs` on signatures indicating the capacity of each signer - -Both may be present. Neither implies the other. - -## Terminology - -**Signature Context**: The capacity, role, and authority chain under which a signature is made. - -**Signing Capacity**: The role or function in which a signer acts (e.g., "CEO", "Legal Representative", "Witness"). - -**Known Value**: A registered predicate identifier in the Gordian Envelope system. See [BCR-2023-002](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md). - -## Referenced Specifications - -### BCR-2026-005: General Assertion Predicates - -| Codepoint | Predicate | Usage in This Context | -|-----------|-----------|----------------------| -| 1001 | `revocationReason` | Documenting why authority was revoked | -| 21 | `validFrom` | When signing authority becomes effective | -| 22 | `validUntil` | When signing authority expires | - -## Proposed Known Value Assignments - -All proposed codepoints are in the **Community Assigned (specification required)** range (1000-1999). - -### Signature Context (1020-1021) - ---- - -#### 1020: `signingAs` - -**Type**: property -**Definition**: The capacity or role in which the signer is acting. -**Domain**: Signature or signed assertion -**Range**: Text or Known Value for role -**Usage**: Clarifies the function the signer is performing. - -``` -{ - Digest(corporate-agreement) [ - 'signed': { - XID(alice) [ - 'signingAs': "Chief Executive Officer" - ] - } - ] -} -``` - -**Notes**: -- Applies to any signature type (attestation, endorsement, agreement) -- Does not grant authority β€” only describes claimed capacity -- Relying parties must evaluate whether the claimed capacity is valid - ---- - -#### 1021: `onBehalfOf` - -**Type**: property -**Definition**: The party the signer represents when making this signature. -**Domain**: Signature or signed assertion -**Range**: XID, DID, or identifier of the represented party -**Usage**: Indicates the signer is acting for another entity. - -``` -{ - Digest(vendor-contract) [ - 'signed': { - XID(legal-counsel) [ - 'signingAs': "Legal Representative" - 'onBehalfOf': XID(acme-corp) - ] - } - ] -} -``` - -**Notes**: -- The signer asserts they have authority to represent the named party -- Does not itself prove authority β€” see BCR-2026-007 for `conferredBy` and `conferralChain` -- Common in corporate, legal, and organizational contexts - ---- - -## Usage Patterns - -### Self-Attestation with Capacity - -A person signing a claim about themselves, in a specific capacity: - -``` -{ - Digest(skill-claim) [ - 'subject': XID(alice) - 'hasSkill': "Rust programming" - 'signed': { - XID(alice) [ - 'signingAs': "Individual" - ] - } - ] -} -``` - -### Peer Endorsement with Capacity - -Someone endorsing another person, in a professional capacity: - -``` -{ - Digest(endorsement) [ - 'subject': XID(bob) - 'endorses': "Project management skills" - 'signed': { - XID(alice) [ - 'signingAs': "Former Supervisor" - 'disclosedBias': "Worked together for 3 years" - ] - } - ] -} -``` - -### Corporate Agreement - -A binding agreement signed by representatives: - -``` -{ - Digest(service-agreement) [ - 'parties': [XID(acme-corp), XID(widgets-inc)] - 'terms': Digest(agreement-terms) - 'signed': { - XID(alice) [ - 'signingAs': "CEO" - 'onBehalfOf': XID(acme-corp) - ] - } - 'signed': { - XID(bob) [ - 'signingAs': "Authorized Representative" - 'onBehalfOf': XID(widgets-inc) - ] - } - ] -} -``` - -For documenting authority chains (who granted signing authority), see BCR-2026-007's `conferredBy` and `conferralChain` predicates. - -### Combined with Principal Authority - -Using both Signature Context and Principal Authority predicates: - -``` -{ - Digest(ai-generated-report) [ - 'principalAuthority': XID(research-director) - 'processDisclosure': "Generated by AI under human direction" - 'signed': { - XID(research-director) [ - 'signingAs': "Principal Investigator" - 'onBehalfOf': XID(research-institute) - ] - } - ] -} -``` - -## Security Considerations - -### Signature Context Claims Are Assertions - -The predicates in this BCR express **claims by the signer**. Relying parties must: -- Verify the signer's identity -- Evaluate whether the claimed capacity (`signingAs`) is plausible -- Verify authority claims using BCR-2026-007 predicates if needed -- Consider the context and stakes of the assertion - -### Capacity vs. Authority - -`signingAs` describes claimed capacity, not granted authority. A signature claiming `signingAs: "CEO"` does not prove the signer is a CEO. External verification is required for high-stakes contexts. - -For authority chain verification, see BCR-2026-007 which defines `conferredBy` and `conferralChain`. - -## Open Questions - -### Q1: Integration with BCR-2024-009 Signature Metadata - -[BCR-2024-009](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-009-signature-metadata.md) defines a pattern for attaching metadata to signatures using double-signing: the outer signature signs both the original content and the metadata on the inner Signature object. - -**Question**: Should the signature context predicates in this BCR (`signingAs`, `onBehalfOf`) be applied: - -1. **As assertions on the signer XID** (as shown in current examples) β€” simpler but metadata is separate from signature -2. **As metadata on the Signature object** (per BCR-2024-009) β€” cryptographically bound but requires double-signing -3. **Either pattern depending on use case** β€” with guidance on when to use each - -We invite community feedback on the recommended integration pattern. See [GitHub issue #158](https://github.com/BlockchainCommons/Research/issues/158) for discussion. - -## References - -- [BCR-2023-002: Known Value Registry](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md) -- [BCR-2024-009: Signature Metadata](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-009-signature-metadata.md) -- [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md) -- [XID-Quickstart Tutorial 09: Binding Agreements](https://github.com/BlockchainCommons/XID-Quickstart) -- [Gordian Envelope Specification](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-001-envelope.md) - -## Related BCRs - -- **BCR-2024-009: Signature Metadata** β€” Established pattern for attaching metadata to signatures using double-signing. Signature context predicates should be applied using this pattern. -- **BCR-2026-005: General Assertion Predicates** β€” Lifecycle predicates used by this BCR -- **BCR-2026-007: Principal Authority Predicates** β€” Authority relationships including `conferredBy` and `conferralChain` for documenting authority chains - ---- - -*BCR-2026-006: Signature Context Predicates* -*Draft - February 2, 2026* From e1f6bcf99d81ea4b07d9959bb7e0bb5a724b4966 Mon Sep 17 00:00:00 2001 From: Christopher Allen Date: Wed, 4 Feb 2026 14:09:30 -0800 Subject: [PATCH 06/16] Add rationale: signature schemes that hide public keys Some signature schemes don't embed or allow recovery of the public key: - EdDSA/Ed25519: key hashed in Fiat-Shamir transform - BBS+: zero-knowledge proofs are unlinkable - Longfellow: designed to hide signer identity This is a key technical rationale for why the signer predicate is necessary - in these schemes there's no key to "look up" from the signature alone. Signed-off-by: Christopher Allen --- papers/bcr-2026-004-signing-event-attestations.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/papers/bcr-2026-004-signing-event-attestations.md b/papers/bcr-2026-004-signing-event-attestations.md index 0cb0994..3cede0c 100644 --- a/papers/bcr-2026-004-signing-event-attestations.md +++ b/papers/bcr-2026-004-signing-event-attestations.md @@ -240,7 +240,12 @@ The proposed codepoints (300-301) are placed above the compact 2-byte range (0-2 **Notes**: - A signature proves a key signed; `signer` links to the identity behind the key - The identity reference can be elided while preserving the attestation structure -- Without `signer`, relying parties must resolve keyβ†’identity through other means +- **Why `signer` is necessary**: Not all signature schemes embed the public key in the signature or allow key recovery: + - **EdDSA/Ed25519**: Public key cannot be recovered from signature (hashed in Fiat-Shamir transform) + - **BBS+**: Zero-knowledge proofs are unlinkable β€” verifiers cannot determine which key/signature created the proof + - **Longfellow and similar ZK schemes**: Designed specifically to hide signer identity from the cryptographic artifact + + 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. - **Gordian ecosystem**: Within XIDs, Clubs, and GSTP, this predicate references an XID or Club - **Broader use**: Gordian Envelope supports other identity reference formats (URIs, DIDs, etc.) for interoperability with external systems @@ -428,6 +433,8 @@ This enables privacy-preserving signatures where identity is disclosed selective - [BCR-2023-002: Known Value Registry](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md) - [ETSI TS 101 903: XAdES](https://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.02_60/ts_101903v010402p.pdf) - [Gordian Envelope Specification](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-001-envelope.md) +- [The BBS Signature Scheme (IETF Draft)](https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html) β€” Zero-knowledge proofs with unlinkable signatures +- [The Longfellow Zero-knowledge Scheme (IETF Draft)](https://datatracker.ietf.org/doc/html/draft-google-cfrg-libzk-01) β€” Privacy-preserving credential verification ## Related BCRs From 626aedb0a702a86613bb43a2cbb3fb21eabf6533 Mon Sep 17 00:00:00 2001 From: Christopher Allen Date: Wed, 4 Feb 2026 14:34:12 -0800 Subject: [PATCH 07/16] =?UTF-8?q?Rename:=20attestations=20=E2=86=92=20asse?= =?UTF-8?q?rtions=20in=20BCR-2026-004?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "Assertion" is the technical term for Envelope predicate-object pairs. Existing BCRs (2024-009, 2024-010, 2025-004) consistently use this term. BCRs are technical specifications; technical terminology is appropriate. Signed-off-by: Christopher Allen --- ... bcr-2026-004-signing-event-assertions.md} | 96 +++++++++---------- 1 file changed, 48 insertions(+), 48 deletions(-) rename papers/{bcr-2026-004-signing-event-attestations.md => bcr-2026-004-signing-event-assertions.md} (77%) diff --git a/papers/bcr-2026-004-signing-event-attestations.md b/papers/bcr-2026-004-signing-event-assertions.md similarity index 77% rename from papers/bcr-2026-004-signing-event-attestations.md rename to papers/bcr-2026-004-signing-event-assertions.md index 3cede0c..2b44e87 100644 --- a/papers/bcr-2026-004-signing-event-attestations.md +++ b/papers/bcr-2026-004-signing-event-assertions.md @@ -1,4 +1,4 @@ -# Signing Event Attestations +# Signing Event Assertions ## BCR-2026-004 @@ -16,9 +16,9 @@ In Gordian Envelope, the `signed` predicate is purely cryptographic β€” it prove To express these facts about a signing event, signers must explicitly attest them using predicates bound to the signature via the double-signing pattern. This BCR: 1. **Establishes the mental model** β€” signatures prove keys signed, not identity or intent -2. **Documents the double-signing pattern** β€” how to cryptographically bind attestations to signatures +2. **Documents the double-signing pattern** β€” how to cryptographically bind assertions to signatures 3. **Defines two novel predicates** β€” `signer` (300) links to the signer's identity; `signedOnBehalfOf` (301) optionally identifies another XID the signer represents -4. **References XAdES standards** β€” `xades:ClaimedRole` and `xades:CommitmentType` for additional attestation types +4. **References XAdES standards** β€” `xades:ClaimedRole` and `xades:CommitmentType` for additional assertion types ## Status: Draft @@ -57,33 +57,33 @@ Compare two scenarios: Both produce cryptographically identical signatures. The difference is what the signer attests β€” who Alice is, what role she's acting in, and what her signature means. -To express these attestations in Gordian Envelope, we need: +To express these assertions in Gordian Envelope, we need: 1. Explicit predicates linking signatures to identity documents (XIDs) 2. Predicates expressing representation relationships -3. A pattern for cryptographically binding attestations to signatures +3. A pattern for cryptographically binding assertions to signatures ### Solution This specification defines: -1. **Two novel predicates** for signing event attestations: +1. **Two novel predicates** for signing event assertions: - `signer` β€” Links a signature to the signer's XID document - `signedOnBehalfOf` β€” (Optional) Identifies another XID that the signer represents -2. **References to XAdES standards** for additional attestation types: +2. **References to XAdES standards** for additional assertion types: - `xades:ClaimedRole` β€” The capacity in which the signer is acting - `xades:CommitmentType` β€” The purpose or meaning of the signature -3. **The double-signing pattern** for cryptographically binding attestations to signatures +3. **The double-signing pattern** for cryptographically binding assertions to signatures ## The Double-Signing Pattern -### Problem: Attestations Must Be Bound to Signatures +### Problem: Assertions Must Be Bound to Signatures Simply adding assertions alongside a signature doesn't cryptographically bind them: ``` -// WRONG: Attestations not bound to signature +// WRONG: Assertions not bound to signature { Digest(contract) } 'signed': Signature(alice) @@ -91,15 +91,15 @@ Simply adding assertions alongside a signature doesn't cryptographically bind th 'signedOnBehalfOf': XID(acme) // Anyone could add this ``` -These attestations could be added or modified by anyone after Alice signed. +These assertions could be added or modified by anyone after Alice signed. ### Solution: Wrap and Sign Twice The double-signing pattern solves this: 1. **Inner wrap and sign**: Sign the content -2. **Add attestations**: Attach signing event attestations to the inner signed envelope -3. **Outer wrap and sign**: Sign again, binding the attestations +2. **Add assertions**: Attach signing event assertions to the inner signed envelope +3. **Outer wrap and sign**: Sign again, binding the assertions ``` { @@ -117,57 +117,57 @@ The double-signing pattern solves this: Now the outer signature cryptographically binds Alice's identity, representation, role, and commitment type to her inner signature on the contract. -### Inner Signs Content, Outer Binds Attestations +### Inner Signs Content, Outer Binds Assertions The inner signature proves: "This key signed this content." -The outer signature proves: "This key asserts these attestations about that signature." +The outer signature proves: "This key asserts these assertions about that signature." -Typically both signatures use the same key β€” Alice making attestations about her own signature. But they need not be the same: +Typically both signatures use the same key β€” Alice making assertions about her own signature. But they need not be the same: -- **Same key**: Self-asserted attestations. Alice claims her own identity, role, and intent. +- **Same key**: Self-asserted assertions. Alice claims her own identity, role, and intent. - **Different key**: May be key separation or third-party assertion: - **By purpose**: Alice uses distinct keys for different operations β€” one authorized only for git commits, another for contract signing, another for routine approvals - **By device**: Alice uses distinct keys on different devices β€” phone, laptop, hardware token β€” each with its own authorization scope - - **Third-party**: A different identity is attesting facts about Alice's signature. If this is a formal counter-signature (notary, witness, approver), see the Counter-Signatures section below. If not a counter-signature, third-party attestations are generally not recommended β€” the signer should make their own attestations. Exception: hardware attestations where a secure element attests security properties of the signing operation. + - **Third-party**: A different identity is attesting facts about Alice's signature. If this is a formal counter-signature (notary, witness, approver), see the Counter-Signatures section below. If not a counter-signature, third-party assertions are generally not recommended β€” the signer should make their own assertions. Exception: hardware assertions where a secure element attests security properties of the signing operation. The `signer` predicate points to the XID where key purposes and devices are documented, allowing relying parties to determine which case applies. -### What Belongs in Signing Event Attestations +### What Belongs in Signing Event Assertions -The signing event attestations should contain **only the signer's own claims about the signing event**: +The signing event assertions should contain **only the signer's own claims about the signing event**: -| Signing Event Attestations | Does NOT Belong | +| Signing Event Assertions | Does NOT Belong | |---------------------------|-----------------| | `signer` β€” who I am | Third-party role certifications | -| `signedOnBehalfOf` β€” who I represent (if applicable) | Third-party authority attestations | +| `signedOnBehalfOf` β€” who I represent (if applicable) | Third-party authority assertions | | `xades:ClaimedRole` β€” my claimed capacity (if applicable) | Endorsements of the signer | | `xades:CommitmentType` β€” what this signature means (if applicable) | Credentials about the signer | -Third-party attestations about the signer (certifying their role, endorsing their authority, etc.) belong in the **signer's XID document**, not in the signing event attestations. The `signer` predicate points to where those third-party attestations live. +Third-party assertions about the signer (certifying their role, endorsing their authority, etc.) belong in the **signer's XID document**, not in the signing event assertions. The `signer` predicate points to where those third-party assertions live. This separation ensures: -1. Signing event attestations contain only self-asserted claims about the signing event -2. Third-party attestations are discoverable via the XID reference +1. Signing event assertions contain only self-asserted claims about the signing event +2. Third-party assertions are discoverable via the XID reference 3. Relying parties know which claims are self-asserted vs. third-party certified ### Dates Are Not Timestamps -A signer can include a date in their signing event attestations β€” this is acceptable and sometimes useful. But it's critical to understand: **a date is not a timestamp**. +A signer can include a date in their signing event assertions β€” this is acceptable and sometimes useful. But it's critical to understand: **a date is not a timestamp**. -A date in signing event attestations is a **self-asserted claim**, not a proof. The signer claims "I signed this on February 4, 2026" β€” but the only thing the signature actually proves is that the key signed the content. The date is just another attestation. +A date in signing event assertions is a **self-asserted claim**, not a proof. The signer claims "I signed this on February 4, 2026" β€” but the only thing the signature actually proves is that the key signed the content. The date is just another assertion. For **provable timestamps**, you need a third-party timestamp authority to counter-sign the envelope. The timestamp authority's signature proves the content existed at a specific time β€” because the authority couldn't have signed something that didn't exist yet. This is the same mental model issue: people assume a date inside a signed envelope proves when it was signed. It doesn't. Only a counter-signature from a trusted timestamp authority provides that proof. -**Note**: Lifecycle predicates like `validFrom` and `validUntil` belong in the main attestation (see BCR-2026-005), not in the signing event attestations. A signing event records facts about the act of signing; validity periods are properties of the content being signed. +**Note**: Lifecycle predicates like `validFrom` and `validUntil` belong in the main assertion (see BCR-2026-005), not in the signing event assertions. A signing event records facts about the act of signing; validity periods are properties of the content being signed. -Timestamp authority patterns (similar to RFC 3161 TSA or blockchain anchoring) are outside the scope of this BCR. See BCR-2026-011 (Anchor Predicates) for cryptographic event log attestation patterns. +Timestamp authority patterns (similar to RFC 3161 TSA or blockchain anchoring) are outside the scope of this BCR. See BCR-2026-011 (Anchor Predicates) for cryptographic event log assertion patterns. ## Counter-Signatures (Multi-Party) -When multiple parties sign with attestations, each applies the double-signing pattern: +When multiple parties sign with assertions, each applies the double-signing pattern: ``` { @@ -184,7 +184,7 @@ When multiple parties sign with attestations, each applies the double-signing pa ] } 'signed': Signature(alice) - // Bob's attestations (counter-signature) + // Bob's assertions (counter-signature) [ 'signer': XID(bob) 'signedOnBehalfOf': XID(widgets-inc) @@ -194,15 +194,15 @@ When multiple parties sign with attestations, each applies the double-signing pa } 'signed': Signature(bob) ``` -Bob's outer signature binds his attestations to his counter-signature on Alice's already-signed envelope. +Bob's outer signature binds his assertions to his counter-signature on Alice's already-signed envelope. ## Terminology **Signing Event**: The act of a private key producing a signature over specific content. The cryptographic operation itself β€” distinct from any claims about who performed it or why. -**Signing Event Attestations**: Claims made by the signer about the signing event β€” who they are (`signer`), who they represent (`signedOnBehalfOf`), in what capacity (`xades:ClaimedRole`), and the signature's purpose (`xades:CommitmentType`). These are self-asserted claims, not cryptographic proofs. +**Signing Event Assertions**: Claims made by the signer about the signing event β€” who they are (`signer`), who they represent (`signedOnBehalfOf`), in what capacity (`xades:ClaimedRole`), and the signature's purpose (`xades:CommitmentType`). These are self-asserted claims, not cryptographic proofs. -**Double-Signing Pattern**: The technique of wrapping and signing twice to cryptographically bind attestations to an inner signature. The inner signature proves the key signed; the outer signature proves the key asserts the attestations. +**Double-Signing Pattern**: The technique of wrapping and signing twice to cryptographically bind assertions to an inner signature. The inner signature proves the key signed; the outer signature proves the key asserts the assertions. **XID Document**: An eXtensible IDentifier document containing identity information, key bindings, key purposes, and other assertions about an identity. @@ -212,9 +212,9 @@ Bob's outer signature binds his attestations to his counter-signature on Alice's This BCR proposes additions to the **Reserved** range (256-999) as defined in [BCR-2023-002](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md). -The proposed codepoints (300-301) are placed above the compact 2-byte range (0-255) to preserve those precious codepoints for the most fundamental predicates. Signing event attestations are important but not as frequent as core predicates, and 3-byte encoding is acceptable for attestations that appear once per signature. +The proposed codepoints (300-301) are placed above the compact 2-byte range (0-255) to preserve those precious codepoints for the most fundamental predicates. Signing event assertions are important but not as frequent as core predicates, and 3-byte encoding is acceptable for assertions that appear once per signature. -### Signing Event Attestations (300-301) +### Signing Event Assertions (300-301) --- @@ -222,7 +222,7 @@ The proposed codepoints (300-301) are placed above the compact 2-byte range (0-2 **Type**: property **Definition**: Links a signature to a document identifying the signer. -**Domain**: Signing event attestations (on inner signed envelope) +**Domain**: Signing event assertions (on inner signed envelope) **Range**: Identity reference (may be ELIDED for privacy) **Usage**: Establishes who made the signature, as opposed to which key made it. @@ -239,7 +239,7 @@ The proposed codepoints (300-301) are placed above the compact 2-byte range (0-2 **Notes**: - A signature proves a key signed; `signer` links to the identity behind the key -- The identity reference can be elided while preserving the attestation structure +- The identity reference can be elided while preserving the assertion structure - **Why `signer` is necessary**: Not all signature schemes embed the public key in the signature or allow key recovery: - **EdDSA/Ed25519**: Public key cannot be recovered from signature (hashed in Fiat-Shamir transform) - **BBS+**: Zero-knowledge proofs are unlinkable β€” verifiers cannot determine which key/signature created the proof @@ -255,7 +255,7 @@ The proposed codepoints (300-301) are placed above the compact 2-byte range (0-2 **Type**: property **Definition**: (Optional) Identifies another entity that the signer represents when making this signature. -**Domain**: Signing event attestations (on inner signed envelope) +**Domain**: Signing event assertions (on inner signed envelope) **Range**: Identity reference **Usage**: Indicates the signer is acting for another entity. @@ -327,7 +327,7 @@ This BCR references predicates from the XAdES standard for signature properties ## Usage Patterns -### Complete Signature with Attestations +### Complete Signature with Assertions ``` { @@ -376,18 +376,18 @@ The signature structure is preserved, the commitment type is visible, but the si ### Double-Signing Pattern -This BCR formally documents the double-signing pattern for signing event attestations. While the technique of wrapping and signing twice has been used informally in Gordian Envelope examples, this specification establishes the best practices and defines the predicates for expressing signing event attestations. +This BCR formally documents the double-signing pattern for signing event assertions. While the technique of wrapping and signing twice has been used informally in Gordian Envelope examples, this specification establishes the best practices and defines the predicates for expressing signing event assertions. ### BCR-2026-006: Principal Authority Predicates | Concern | BCR | Question Answered | |---------|-----|-------------------| -| **Signing Event Attestations** | This BCR (004) | "What are the facts about this signing event?" | +| **Signing Event Assertions** | This BCR (004) | "What are the facts about this signing event?" | | **Principal Authority** | BCR-2026-006 | "Who directed and takes responsibility for this work?" | A document may have: - `principalAuthority` identifying who directed the work -- Signing event attestation predicates indicating who signed and how +- Signing event assertion predicates indicating who signed and how Both may be present. Neither implies the other. @@ -403,7 +403,7 @@ Both may be present. Neither implies the other. ## Security Considerations -### Attestations Are Self-Asserted +### Assertions Are Self-Asserted The predicates in this BCR express **claims by the signer**. Relying parties must: - Verify the signature cryptographically @@ -415,16 +415,16 @@ The predicates in this BCR express **claims by the signer**. Relying parties mus Both signatures should use the same key. If the outer signature uses a different key: - It becomes a counter-signature (third-party assertion about the inner signature) -- The attestations become that third party's claims about the signer +- The assertions become that third party's claims about the signer - This may be intentional (notarization) or a verification failure -### Elision and Attestations +### Elision and Assertions When `signer` is elided: - The signature remains cryptographically valid - The signing key is visible (in the Signature) - The identity behind the key is hidden -- Other attestations (role, commitment) may remain visible +- Other assertions (role, commitment) may remain visible This enables privacy-preserving signatures where identity is disclosed selectively. @@ -460,5 +460,5 @@ Gordian Envelope implementations may use these OIDs or equivalent text values. T --- -*BCR-2026-004: Signing Event Attestations* +*BCR-2026-004: Signing Event Assertions* *Draft - February 4, 2026* From 773afa0696c06b4d6da158fe4e3f48dba8134132 Mon Sep 17 00:00:00 2001 From: Christopher Allen Date: Wed, 4 Feb 2026 14:39:42 -0800 Subject: [PATCH 08/16] Add terminology note: assertion vs attestation Clarifies that "assertion" is Envelope vocabulary (predicate-object pair) while "attestation" is general vocabulary (act of declaring/testifying). The signer *attests* to facts; these are expressed as *assertions*. Signed-off-by: Christopher Allen --- papers/bcr-2026-004-signing-event-assertions.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/papers/bcr-2026-004-signing-event-assertions.md b/papers/bcr-2026-004-signing-event-assertions.md index 2b44e87..3ba71ba 100644 --- a/papers/bcr-2026-004-signing-event-assertions.md +++ b/papers/bcr-2026-004-signing-event-assertions.md @@ -198,9 +198,11 @@ Bob's outer signature binds his assertions to his counter-signature on Alice's a ## Terminology +**Assertion vs Attestation**: In Gordian Envelope, *assertion* is the technical term for a predicate-object pair attached to a subject β€” this is Envelope vocabulary. *Attestation* refers to the act of formally declaring or testifying to facts β€” this is general vocabulary. In this BCR: the signer *attests* to facts about the signing event; these attestations are expressed as *assertions* in the Envelope structure. + **Signing Event**: The act of a private key producing a signature over specific content. The cryptographic operation itself β€” distinct from any claims about who performed it or why. -**Signing Event Assertions**: Claims made by the signer about the signing event β€” who they are (`signer`), who they represent (`signedOnBehalfOf`), in what capacity (`xades:ClaimedRole`), and the signature's purpose (`xades:CommitmentType`). These are self-asserted claims, not cryptographic proofs. +**Signing Event Assertions**: The Envelope assertions containing the signer's attestations about the signing event β€” who they are (`signer`), who they represent (`signedOnBehalfOf`), in what capacity (`xades:ClaimedRole`), and the signature's purpose (`xades:CommitmentType`). These are self-asserted claims, not cryptographic proofs. **Double-Signing Pattern**: The technique of wrapping and signing twice to cryptographically bind assertions to an inner signature. The inner signature proves the key signed; the outer signature proves the key asserts the assertions. From fbbe5c010ab06b5ba44ff2fbbc2c6436b159d814 Mon Sep 17 00:00:00 2001 From: Christopher Allen Date: Wed, 4 Feb 2026 14:52:01 -0800 Subject: [PATCH 09/16] Adopt BCR-2024-009 pattern, document both signing patterns Primary: signature-with-assertions (signer's own assertions) Secondary: wrapped signing (third-party assertions) References BCR-2024-009 as structural foundation. All examples updated to new structure. Signed-off-by: Christopher Allen --- .../bcr-2026-004-signing-event-assertions.md | 309 ++++++++++++------ 1 file changed, 201 insertions(+), 108 deletions(-) diff --git a/papers/bcr-2026-004-signing-event-assertions.md b/papers/bcr-2026-004-signing-event-assertions.md index 3ba71ba..6be8253 100644 --- a/papers/bcr-2026-004-signing-event-assertions.md +++ b/papers/bcr-2026-004-signing-event-assertions.md @@ -13,10 +13,10 @@ Date: February 4, 2026 In Gordian Envelope, the `signed` predicate is purely cryptographic β€” it proves that a specific private key was used to sign specific content. Nothing more. A signature alone doesn't prove who possesses the key, when signing occurred, or what the signature means. -To express these facts about a signing event, signers must explicitly attest them using predicates bound to the signature via the double-signing pattern. This BCR: +To express these facts about a signing event, signers must explicitly attest them using predicates bound to the signature. This BCR: 1. **Establishes the mental model** β€” signatures prove keys signed, not identity or intent -2. **Documents the double-signing pattern** β€” how to cryptographically bind assertions to signatures +2. **Documents two signing patterns** β€” signature-with-assertions (primary) and wrapped signing (for third-party assertions) 3. **Defines two novel predicates** β€” `signer` (300) links to the signer's identity; `signedOnBehalfOf` (301) optionally identifies another XID the signer represents 4. **References XAdES standards** β€” `xades:ClaimedRole` and `xades:CommitmentType` for additional assertion types @@ -74,9 +74,11 @@ This specification defines: - `xades:ClaimedRole` β€” The capacity in which the signer is acting - `xades:CommitmentType` β€” The purpose or meaning of the signature -3. **The double-signing pattern** for cryptographically binding assertions to signatures +3. **Two signing patterns** for cryptographically binding assertions: + - **Signature-with-assertions** (primary) β€” signer's own assertions about their signing act + - **Wrapped signing** β€” third-party assertions about already-signed content -## The Double-Signing Pattern +## Binding Assertions to Signatures ### Problem: Assertions Must Be Bound to Signatures @@ -86,56 +88,103 @@ Simply adding assertions alongside a signature doesn't cryptographically bind th // WRONG: Assertions not bound to signature { Digest(contract) -} 'signed': Signature(alice) - 'signer': XID(alice) // Not signed! - 'signedOnBehalfOf': XID(acme) // Anyone could add this +} [ + 'signed': Signature + 'signer': XID(alice) // Not signed! + 'signedOnBehalfOf': XID(acme) // Anyone could add this +] ``` These assertions could be added or modified by anyone after Alice signed. -### Solution: Wrap and Sign Twice +### Pattern 1: Signature-with-Assertions (Primary) + +For a signer's own assertions about their signing act, use the signature-with-assertions pattern from [BCR-2024-009](bcr-2024-009-signature-metadata.md): + +1. **Sign the content**: Produce a Signature +2. **Create assertion envelope**: Make the Signature the subject, add assertions +3. **Sign the assertion envelope**: Bind assertions to the signature +4. **Attach to content**: Use the signed assertion envelope as the `'signed'` object + +``` +{ + Digest(contract) +} [ + 'signed': { + Signature [ + 'signer': XID(alice) + 'signedOnBehalfOf': XID(acme-corp) + 'xades:ClaimedRole': "Chief Executive Officer" + 'xades:CommitmentType': "approval" + ] + } [ + 'signed': Signature + ] +] +``` + +The Signature object carries its own assertions, wrapped and signed. This is a self-contained unit: "Alice's signature, with Alice's assertions about that signature, bound together." -The double-signing pattern solves this: +**Verification**: Both signatures must verify against the same public key. The inner signature covers the content; the outer signature covers the assertion envelope. -1. **Inner wrap and sign**: Sign the content -2. **Add assertions**: Attach signing event assertions to the inner signed envelope -3. **Outer wrap and sign**: Sign again, binding the assertions +**Key separation**: Alice may use different keys from her XID β€” one for signing content, another for signing the assertion envelope. Both must be Alice's keys. The `signer` predicate points to the XID where key purposes are documented. + +### Pattern 2: Wrapped Signing (Third-Party Assertions) + +When a **third party** needs to add assertions to already-signed content β€” such as a timestamp authority, notary, or witness β€” use wrapped signing: + +1. **Start with signed content**: Content already signed by original signer +2. **Wrap**: Make the signed content the subject of a new envelope +3. **Add third-party assertions**: Attach assertions about the signed content +4. **Sign**: Third party signs, binding their assertions ``` { + // Alice's signed content (using Pattern 1) { Digest(contract) - } 'signed': Signature(alice) + } [ + 'signed': { + Signature [ + 'signer': XID(alice) + ] + } ['signed': Signature] + ] [ - 'signer': XID(alice) - 'signedOnBehalfOf': XID(acme-corp) - 'xades:ClaimedRole': "Chief Executive Officer" - 'xades:CommitmentType': "approval" + // Timestamp authority's assertions about Alice's signed content + 'anchoredAt': 2026-02-04T12:00:00Z + 'anchoredBy': XID(timestamp-authority) ] -} 'signed': Signature(alice) +} [ + 'signed': { + Signature [ + 'signer': XID(timestamp-authority) + 'xades:CommitmentType': "timestamp" + ] + } ['signed': Signature] +] ``` -Now the outer signature cryptographically binds Alice's identity, representation, role, and commitment type to her inner signature on the contract. - -### Inner Signs Content, Outer Binds Assertions - -The inner signature proves: "This key signed this content." +The timestamp authority wraps Alice's signed content, adds timestamp assertions, and signs. The TSA's assertions are about Alice's content, not about the TSA's own signing act. -The outer signature proves: "This key asserts these assertions about that signature." +### When to Use Each Pattern -Typically both signatures use the same key β€” Alice making assertions about her own signature. But they need not be the same: +| Pattern | Use When | Who Asserts | About What | +|---------|----------|-------------|------------| +| Signature-with-assertions | Signer's own claims | The signer | Their signing act | +| Wrapped signing | Third-party claims | Another party | The signed content | -- **Same key**: Self-asserted assertions. Alice claims her own identity, role, and intent. -- **Different key**: May be key separation or third-party assertion: - - **By purpose**: Alice uses distinct keys for different operations β€” one authorized only for git commits, another for contract signing, another for routine approvals - - **By device**: Alice uses distinct keys on different devices β€” phone, laptop, hardware token β€” each with its own authorization scope - - **Third-party**: A different identity is attesting facts about Alice's signature. If this is a formal counter-signature (notary, witness, approver), see the Counter-Signatures section below. If not a counter-signature, third-party assertions are generally not recommended β€” the signer should make their own assertions. Exception: hardware assertions where a secure element attests security properties of the signing operation. +**Examples of wrapped signing**: +- Timestamp authority adds `anchoredAt` to prove when content existed +- Notary adds witnessing assertions to signed documents +- Endorser adds endorsement to someone else's signed work +- Fair witness adds observation assertions - The `signer` predicate points to the XID where key purposes and devices are documented, allowing relying parties to determine which case applies. +**Do not use wrapped signing** for a signer's own assertions about their signing β€” use signature-with-assertions instead. ### What Belongs in Signing Event Assertions -The signing event assertions should contain **only the signer's own claims about the signing event**: +Signing event assertions (on the Signature object) should contain **only the signer's own claims about their signing act**: | Signing Event Assertions | Does NOT Belong | |---------------------------|-----------------| @@ -144,12 +193,15 @@ The signing event assertions should contain **only the signer's own claims about | `xades:ClaimedRole` β€” my claimed capacity (if applicable) | Endorsements of the signer | | `xades:CommitmentType` β€” what this signature means (if applicable) | Credentials about the signer | -Third-party assertions about the signer (certifying their role, endorsing their authority, etc.) belong in the **signer's XID document**, not in the signing event assertions. The `signer` predicate points to where those third-party assertions live. +Third-party assertions belong elsewhere: +- **About the signer** (certifying role, endorsing authority): In the signer's XID document +- **About the signed content** (timestamps, notarization): Using the wrapped signing pattern This separation ensures: -1. Signing event assertions contain only self-asserted claims about the signing event -2. Third-party assertions are discoverable via the XID reference -3. Relying parties know which claims are self-asserted vs. third-party certified +1. Signing event assertions are always self-asserted by the signer +2. Third-party identity assertions are discoverable via the XID reference +3. Third-party content assertions use a distinct structural pattern +4. Relying parties can distinguish self-asserted vs. third-party claims by structure ### Dates Are Not Timestamps @@ -165,36 +217,69 @@ This is the same mental model issue: people assume a date inside a signed envelo Timestamp authority patterns (similar to RFC 3161 TSA or blockchain anchoring) are outside the scope of this BCR. See BCR-2026-011 (Anchor Predicates) for cryptographic event log assertion patterns. -## Counter-Signatures (Multi-Party) +## Multi-Party Signatures -When multiple parties sign with assertions, each applies the double-signing pattern: +### Parallel Signatures (Independent Signers) + +When multiple parties independently sign the same content, each adds their signature-with-assertions: ``` { - // Alice's double-signed envelope - { - { - Digest(contract) - } 'signed': Signature(alice) - [ + Digest(contract) +} [ + // Alice's signature with her assertions + 'signed': { + Signature [ 'signer': XID(alice) 'signedOnBehalfOf': XID(acme-corp) 'xades:ClaimedRole': "CEO" 'xades:CommitmentType': "approval" ] - } 'signed': Signature(alice) + } ['signed': Signature] + + // Bob's signature with his assertions + 'signed': { + Signature [ + 'signer': XID(bob) + 'signedOnBehalfOf': XID(widgets-inc) + 'xades:ClaimedRole': "Authorized Representative" + 'xades:CommitmentType': "approval" + ] + } ['signed': Signature] +] +``` - // Bob's assertions (counter-signature) - [ - 'signer': XID(bob) - 'signedOnBehalfOf': XID(widgets-inc) - 'xades:ClaimedRole': "Authorized Representative" - 'xades:CommitmentType': "approval" +Each signature is independent. Alice and Bob both signed the contract; neither signed over the other's signature. + +### Counter-Signatures (Sequential Signing) + +When a party signs **over** another's signed content β€” witnessing, notarizing, or approving β€” use wrapped signing: + +``` +{ + // Alice's signed content + { + Digest(contract) + } [ + 'signed': { + Signature [ + 'signer': XID(alice) + 'xades:CommitmentType': "approval" + ] + } ['signed': Signature] ] -} 'signed': Signature(bob) +} [ + // Bob counter-signs Alice's signed content + 'signed': { + Signature [ + 'signer': XID(bob) + 'xades:CommitmentType': "witness" + ] + } ['signed': Signature] +] ``` -Bob's outer signature binds his assertions to his counter-signature on Alice's already-signed envelope. +Bob's signature covers Alice's complete signed envelope. This proves Bob witnessed Alice's signature β€” he couldn't have signed something that didn't exist. ## Terminology @@ -204,7 +289,9 @@ Bob's outer signature binds his assertions to his counter-signature on Alice's a **Signing Event Assertions**: The Envelope assertions containing the signer's attestations about the signing event β€” who they are (`signer`), who they represent (`signedOnBehalfOf`), in what capacity (`xades:ClaimedRole`), and the signature's purpose (`xades:CommitmentType`). These are self-asserted claims, not cryptographic proofs. -**Double-Signing Pattern**: The technique of wrapping and signing twice to cryptographically bind assertions to an inner signature. The inner signature proves the key signed; the outer signature proves the key asserts the assertions. +**Signature-with-Assertions Pattern**: The technique of making a Signature the subject of an envelope, adding assertions, wrapping, and signing again. Binds the signer's own assertions to their signature. See [BCR-2024-009](bcr-2024-009-signature-metadata.md). + +**Wrapped Signing Pattern**: The technique of wrapping already-signed content, adding assertions, and signing. Used when a third party adds assertions about signed content (timestamps, notarization, witnessing). **XID Document**: An eXtensible IDentifier document containing identity information, key bindings, key purposes, and other assertions about an identity. @@ -224,19 +311,20 @@ The proposed codepoints (300-301) are placed above the compact 2-byte range (0-2 **Type**: property **Definition**: Links a signature to a document identifying the signer. -**Domain**: Signing event assertions (on inner signed envelope) +**Domain**: Signing event assertions (on the Signature subject) **Range**: Identity reference (may be ELIDED for privacy) **Usage**: Establishes who made the signature, as opposed to which key made it. ``` { - { - Digest(document) - } 'signed': Signature(key-abc123) - [ - 'signer': XID(alice) - ] -} 'signed': Signature(key-abc123) + Digest(document) +} [ + 'signed': { + Signature [ + 'signer': XID(alice) + ] + } ['signed': Signature] +] ``` **Notes**: @@ -257,20 +345,21 @@ The proposed codepoints (300-301) are placed above the compact 2-byte range (0-2 **Type**: property **Definition**: (Optional) Identifies another entity that the signer represents when making this signature. -**Domain**: Signing event assertions (on inner signed envelope) +**Domain**: Signing event assertions (on the Signature subject) **Range**: Identity reference **Usage**: Indicates the signer is acting for another entity. ``` { - { - Digest(vendor-contract) - } 'signed': Signature(alice-key) - [ - 'signer': XID(alice) - 'signedOnBehalfOf': XID(acme-corp) - ] -} 'signed': Signature(alice-key) + Digest(vendor-contract) +} [ + 'signed': { + Signature [ + 'signer': XID(alice) + 'signedOnBehalfOf': XID(acme-corp) + ] + } ['signed': Signature] +] ``` **Notes**: @@ -295,7 +384,7 @@ This BCR references predicates from the XAdES standard for signature properties **Usage**: Describes the function the signer is performing. ``` -[ +Signature [ 'signer': XID(alice) 'xades:ClaimedRole': "Chief Executive Officer" ] @@ -314,7 +403,7 @@ This BCR references predicates from the XAdES standard for signature properties **Usage**: Distinguishes different signature purposes (approval, acknowledgment, witness, etc.) ``` -[ +Signature [ 'signer': XID(alice) 'xades:CommitmentType': "approval" ] @@ -333,52 +422,55 @@ This BCR references predicates from the XAdES standard for signature properties ``` { - { - Digest(contract) - } 'signed': Signature(alice-key) - [ - 'signer': XID(alice) - 'signedOnBehalfOf': XID(acme-corp) - 'xades:ClaimedRole': "CEO" - 'xades:CommitmentType': "approval" - ] -} 'signed': Signature(alice-key) + Digest(contract) +} [ + 'signed': { + Signature [ + 'signer': XID(alice) + 'signedOnBehalfOf': XID(acme-corp) + 'xades:ClaimedRole': "CEO" + 'xades:CommitmentType': "approval" + ] + } ['signed': Signature] +] ``` ### Minimal Signature with Identity Only ``` { - { - Digest(document) - } 'signed': Signature(alice-key) - [ - 'signer': XID(alice) - ] -} 'signed': Signature(alice-key) + Digest(document) +} [ + 'signed': { + Signature [ + 'signer': XID(alice) + ] + } ['signed': Signature] +] ``` ### Privacy-Preserving with Elided Signer ``` { - { - Digest(document) - } 'signed': Signature(...) - [ - 'signer': ELIDED - 'xades:CommitmentType': "witness" - ] -} 'signed': Signature(...) + Digest(document) +} [ + 'signed': { + Signature [ + 'signer': ELIDED + 'xades:CommitmentType': "witness" + ] + } ['signed': Signature] +] ``` The signature structure is preserved, the commitment type is visible, but the signer identity is elided. ## Relationship to Other Specifications -### Double-Signing Pattern +### BCR-2024-009: Signatures with Metadata -This BCR formally documents the double-signing pattern for signing event assertions. While the technique of wrapping and signing twice has been used informally in Gordian Envelope examples, this specification establishes the best practices and defines the predicates for expressing signing event assertions. +This BCR defines the vocabulary for signing event assertions using the structural pattern established in [BCR-2024-009](bcr-2024-009-signature-metadata.md). BCR-2024-009 defined the technique of attaching metadata to signatures; this BCR specifies the predicates to use. ### BCR-2026-006: Principal Authority Predicates @@ -408,23 +500,23 @@ Both may be present. Neither implies the other. ### Assertions Are Self-Asserted The predicates in this BCR express **claims by the signer**. Relying parties must: -- Verify the signature cryptographically +- Verify both signatures cryptographically (inner on content, outer on assertion envelope) +- Confirm both signatures use the same public key (for self-asserted assertions) - Resolve the XID reference to confirm identity - Evaluate whether the claimed role and representation are plausible - Verify authority claims using BCR-2026-006 predicates if needed -### Double-Signing Integrity +### Signature-with-Assertions Integrity -Both signatures should use the same key. If the outer signature uses a different key: -- It becomes a counter-signature (third-party assertion about the inner signature) -- The assertions become that third party's claims about the signer -- This may be intentional (notarization) or a verification failure +For self-asserted signing event assertions, both signatures must verify against the same key. If they use different keys: +- For **signature-with-assertions**: This is a verification failure β€” someone tampered with the assertion envelope +- For **wrapped signing**: This is expected β€” the wrapper is a different party (TSA, notary, etc.) ### Elision and Assertions When `signer` is elided: -- The signature remains cryptographically valid -- The signing key is visible (in the Signature) +- Both signatures remain cryptographically valid +- The signing key may still be visible (in the Signature) - The identity behind the key is hidden - Other assertions (role, commitment) may remain visible @@ -433,6 +525,7 @@ This enables privacy-preserving signatures where identity is disclosed selective ## 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) β€” Structural pattern for signature-with-assertions - [ETSI TS 101 903: XAdES](https://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.02_60/ts_101903v010402p.pdf) - [Gordian Envelope Specification](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-001-envelope.md) - [The BBS Signature Scheme (IETF Draft)](https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html) β€” Zero-knowledge proofs with unlinkable signatures From b9a44ce835e87ddcc221cf4febb1643e08ff6f47 Mon Sep 17 00:00:00 2001 From: Christopher Allen Date: Wed, 4 Feb 2026 15:10:37 -0800 Subject: [PATCH 10/16] BCR-004: Prose cleanup and envelope-cli validation - Reduce document from ~560 to ~289 lines - Remove verbose explanations, keep direct statements - Validate all examples with envelope-cli: - Signature-with-assertions pattern (BCR-2024-009 style) - Wrapped signing for third-party assertions - Parallel signatures - Counter-signatures - Both inner and outer signatures verify correctly Signed-off-by: Christopher Allen --- .../bcr-2026-004-signing-event-assertions.md | 423 ++++-------------- 1 file changed, 76 insertions(+), 347 deletions(-) diff --git a/papers/bcr-2026-004-signing-event-assertions.md b/papers/bcr-2026-004-signing-event-assertions.md index 6be8253..3b5496e 100644 --- a/papers/bcr-2026-004-signing-event-assertions.md +++ b/papers/bcr-2026-004-signing-event-assertions.md @@ -11,100 +11,67 @@ Date: February 4, 2026 ## Abstract -In Gordian Envelope, the `signed` predicate is purely cryptographic β€” it proves that a specific private key was used to sign specific content. Nothing more. A signature alone doesn't prove who possesses the key, when signing occurred, or what the signature means. - -To express these facts about a signing event, signers must explicitly attest them using predicates bound to the signature. This BCR: - -1. **Establishes the mental model** β€” signatures prove keys signed, not identity or intent -2. **Documents two signing patterns** β€” signature-with-assertions (primary) and wrapped signing (for third-party assertions) -3. **Defines two novel predicates** β€” `signer` (300) links to the signer's identity; `signedOnBehalfOf` (301) optionally identifies another XID the signer represents -4. **References XAdES standards** β€” `xades:ClaimedRole` and `xades:CommitmentType` for additional assertion types +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 signers to attest these facts, bound to their signatures using the pattern from BCR-2024-009. ## Status: Draft ## Introduction -### Signed Proves Key, Not Identity +### What Signatures Prove -In Gordian Envelope, the `signed` predicate is a **purely cryptographic operation**. A cryptographic signature proves exactly one thing: +A signature proves exactly one thing: -> **The private key corresponding to a specific public key was used to produce this signature over this specific content.** +> **The private key for a specific public key produced this signature over this content.** -That's it. Given the public key and the content, anyone can verify this mathematical relationship. If the content changes by even one bit, verification fails. If a different private key signed, verification fails. - -A signature does **not** prove: -- **Who** possesses or possessed the private key -- **Whether** the key has been compromised, shared, or delegated -- **When** the signing operation occurred -- **Why** the signing happened or what it means -- **That** the signer read, understood, or agreed to the 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(key-abc123) +} 'signed': Signature ``` -This proves the private key for `abc123` signed the contract digest. It does not prove Alice controls that key, that Alice is CEO, that Alice signed on behalf of Acme Corp, or even that Alice has ever seen the contract. - -### Identical Signatures Can Mean Different Things +This proves the key signed. It does not prove Alice controls that key, that she is CEO, or that she signed for Acme Corp. -Compare two scenarios: +### The Problem -**Scenario A**: Alice's personal key signs a document. The signature proves the key signed. +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: -**Scenario B**: Alice, as CEO, signs a contract on behalf of Acme Corp as approval. - -Both produce cryptographically identical signatures. The difference is what the signer attests β€” who Alice is, what role she's acting in, and what her signature means. - -To express these assertions in Gordian Envelope, we need: -1. Explicit predicates linking signatures to identity documents (XIDs) -2. Predicates expressing representation relationships -3. A pattern for cryptographically binding assertions to signatures +1. Predicates linking signatures to identity (XIDs) +2. Predicates expressing representation +3. A pattern binding assertions to signatures ### Solution -This specification defines: +This BCR defines: -1. **Two novel predicates** for signing event assertions: - - `signer` β€” Links a signature to the signer's XID document - - `signedOnBehalfOf` β€” (Optional) Identifies another XID that the signer represents +- `signer` (300) β€” links signature to signer's identity +- `signedOnBehalfOf` (301) β€” identifies who the signer represents +- References `xades:ClaimedRole` and `xades:CommitmentType` from XAdES -2. **References to XAdES standards** for additional assertion types: - - `xades:ClaimedRole` β€” The capacity in which the signer is acting - - `xades:CommitmentType` β€” The purpose or meaning of the signature - -3. **Two signing patterns** for cryptographically binding assertions: - - **Signature-with-assertions** (primary) β€” signer's own assertions about their signing act - - **Wrapped signing** β€” third-party assertions about already-signed content +Two patterns bind assertions to signatures: +- **Signature-with-assertions** β€” signer's own assertions (primary) +- **Wrapped signing** β€” third-party assertions ## Binding Assertions to Signatures -### Problem: Assertions Must Be Bound to Signatures +### The Problem -Simply adding assertions alongside a signature doesn't cryptographically bind them: +Assertions alongside a signature aren't cryptographically bound: ``` -// WRONG: Assertions not bound to signature +// WRONG: Anyone could add these assertions { Digest(contract) } [ 'signed': Signature - 'signer': XID(alice) // Not signed! - 'signedOnBehalfOf': XID(acme) // Anyone could add this + 'signer': XID(alice) ] ``` -These assertions could be added or modified by anyone after Alice signed. +### Pattern 1: Signature-with-Assertions -### Pattern 1: Signature-with-Assertions (Primary) - -For a signer's own assertions about their signing act, use the signature-with-assertions pattern from [BCR-2024-009](bcr-2024-009-signature-metadata.md): - -1. **Sign the content**: Produce a Signature -2. **Create assertion envelope**: Make the Signature the subject, add assertions -3. **Sign the assertion envelope**: Bind assertions to the signature -4. **Attach to content**: Use the signed assertion envelope as the `'signed'` object +For a signer's own assertions, use the pattern from BCR-2024-009: make the Signature the subject, add assertions, wrap, sign. ``` { @@ -114,44 +81,29 @@ For a signer's own assertions about their signing act, use the signature-with-as Signature [ 'signer': XID(alice) 'signedOnBehalfOf': XID(acme-corp) - 'xades:ClaimedRole': "Chief Executive Officer" + 'xades:ClaimedRole': "CEO" 'xades:CommitmentType': "approval" ] - } [ - 'signed': Signature - ] + } ['signed': Signature] ] ``` -The Signature object carries its own assertions, wrapped and signed. This is a self-contained unit: "Alice's signature, with Alice's assertions about that signature, bound together." - -**Verification**: Both signatures must verify against the same public key. The inner signature covers the content; the outer signature covers the assertion envelope. - -**Key separation**: Alice may use different keys from her XID β€” one for signing content, another for signing the assertion envelope. Both must be Alice's keys. The `signer` predicate points to the XID where key purposes are documented. +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 (Third-Party Assertions) +### Pattern 2: Wrapped Signing -When a **third party** needs to add assertions to already-signed content β€” such as a timestamp authority, notary, or witness β€” use wrapped signing: - -1. **Start with signed content**: Content already signed by original signer -2. **Wrap**: Make the signed content the subject of a new envelope -3. **Add third-party assertions**: Attach assertions about the signed content -4. **Sign**: Third party signs, binding their assertions +For third-party assertions (timestamps, notarization), wrap the signed content, add assertions, sign: ``` { - // Alice's signed content (using Pattern 1) { Digest(contract) } [ 'signed': { - Signature [ - 'signer': XID(alice) - ] + Signature ['signer': XID(alice)] } ['signed': Signature] ] [ - // Timestamp authority's assertions about Alice's signed content 'anchoredAt': 2026-02-04T12:00:00Z 'anchoredBy': XID(timestamp-authority) ] @@ -165,111 +117,60 @@ When a **third party** needs to add assertions to already-signed content β€” suc ] ``` -The timestamp authority wraps Alice's signed content, adds timestamp assertions, and signs. The TSA's assertions are about Alice's content, not about the TSA's own signing act. - -### When to Use Each Pattern - -| Pattern | Use When | Who Asserts | About What | -|---------|----------|-------------|------------| -| Signature-with-assertions | Signer's own claims | The signer | Their signing act | -| Wrapped signing | Third-party claims | Another party | The signed content | - -**Examples of wrapped signing**: -- Timestamp authority adds `anchoredAt` to prove when content existed -- Notary adds witnessing assertions to signed documents -- Endorser adds endorsement to someone else's signed work -- Fair witness adds observation assertions - -**Do not use wrapped signing** for a signer's own assertions about their signing β€” use signature-with-assertions instead. - -### What Belongs in Signing Event Assertions - -Signing event assertions (on the Signature object) should contain **only the signer's own claims about their signing act**: - -| Signing Event Assertions | Does NOT Belong | -|---------------------------|-----------------| -| `signer` β€” who I am | Third-party role certifications | -| `signedOnBehalfOf` β€” who I represent (if applicable) | Third-party authority assertions | -| `xades:ClaimedRole` β€” my claimed capacity (if applicable) | Endorsements of the signer | -| `xades:CommitmentType` β€” what this signature means (if applicable) | Credentials about the signer | +The third party's signature binds their assertions about the already-signed content. -Third-party assertions belong elsewhere: -- **About the signer** (certifying role, endorsing authority): In the signer's XID document -- **About the signed content** (timestamps, notarization): Using the wrapped signing pattern +### When to Use Each -This separation ensures: -1. Signing event assertions are always self-asserted by the signer -2. Third-party identity assertions are discoverable via the XID reference -3. Third-party content assertions use a distinct structural pattern -4. Relying parties can distinguish self-asserted vs. third-party claims by structure +| Pattern | Who Asserts | About What | +|---------|-------------|------------| +| Signature-with-assertions | Signer | Their signing act | +| Wrapped signing | Third party | Signed content | -### Dates Are Not Timestamps +Examples of wrapped signing: timestamp authorities, notaries, witnesses, endorsers. -A signer can include a date in their signing event assertions β€” this is acceptable and sometimes useful. But it's critical to understand: **a date is not a timestamp**. +### Dates vs Timestamps -A date in signing event assertions is a **self-asserted claim**, not a proof. The signer claims "I signed this on February 4, 2026" β€” but the only thing the signature actually proves is that the key signed the content. The date is just another assertion. - -For **provable timestamps**, you need a third-party timestamp authority to counter-sign the envelope. The timestamp authority's signature proves the content existed at a specific time β€” because the authority couldn't have signed something that didn't exist yet. - -This is the same mental model issue: people assume a date inside a signed envelope proves when it was signed. It doesn't. Only a counter-signature from a trusted timestamp authority provides that proof. - -**Note**: Lifecycle predicates like `validFrom` and `validUntil` belong in the main assertion (see BCR-2026-005), not in the signing event assertions. A signing event records facts about the act of signing; validity periods are properties of the content being signed. - -Timestamp authority patterns (similar to RFC 3161 TSA or blockchain anchoring) are outside the scope of this BCR. See BCR-2026-011 (Anchor Predicates) for cryptographic event log assertion patterns. +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 (Independent Signers) +### Parallel Signatures -When multiple parties independently sign the same content, each adds their signature-with-assertions: +Multiple parties independently signing the same content: ``` { Digest(contract) } [ - // Alice's signature with her assertions 'signed': { Signature [ 'signer': XID(alice) - 'signedOnBehalfOf': XID(acme-corp) - 'xades:ClaimedRole': "CEO" 'xades:CommitmentType': "approval" ] } ['signed': Signature] - - // Bob's signature with his assertions 'signed': { Signature [ 'signer': XID(bob) - 'signedOnBehalfOf': XID(widgets-inc) - 'xades:ClaimedRole': "Authorized Representative" 'xades:CommitmentType': "approval" ] } ['signed': Signature] ] ``` -Each signature is independent. Alice and Bob both signed the contract; neither signed over the other's signature. - -### Counter-Signatures (Sequential Signing) +### Counter-Signatures -When a party signs **over** another's signed content β€” witnessing, notarizing, or approving β€” use wrapped signing: +A party signing over another's signed content: ``` { - // Alice's signed content { Digest(contract) } [ 'signed': { - Signature [ - 'signer': XID(alice) - 'xades:CommitmentType': "approval" - ] + Signature ['signer': XID(alice)] } ['signed': Signature] ] } [ - // Bob counter-signs Alice's signed content 'signed': { Signature [ 'signer': XID(bob) @@ -279,128 +180,63 @@ When a party signs **over** another's signed content β€” witnessing, notarizing, ] ``` -Bob's signature covers Alice's complete signed envelope. This proves Bob witnessed Alice's signature β€” he couldn't have signed something that didn't exist. +Bob's signature covers Alice's complete signed envelope. ## Terminology -**Assertion vs Attestation**: In Gordian Envelope, *assertion* is the technical term for a predicate-object pair attached to a subject β€” this is Envelope vocabulary. *Attestation* refers to the act of formally declaring or testifying to facts β€” this is general vocabulary. In this BCR: the signer *attests* to facts about the signing event; these attestations are expressed as *assertions* in the Envelope structure. +**Assertion**: Envelope term for a predicate-object pair. **Attestation**: The act of declaring facts. Signers *attest*; attestations are expressed as *assertions*. -**Signing Event**: The act of a private key producing a signature over specific content. The cryptographic operation itself β€” distinct from any claims about who performed it or why. +**Signing Event**: A key producing a signature over content. -**Signing Event Assertions**: The Envelope assertions containing the signer's attestations about the signing event β€” who they are (`signer`), who they represent (`signedOnBehalfOf`), in what capacity (`xades:ClaimedRole`), and the signature's purpose (`xades:CommitmentType`). These are self-asserted claims, not cryptographic proofs. +**Signing Event Assertions**: Assertions on a Signature subject β€” who signed, representing whom, in what capacity, for what purpose. -**Signature-with-Assertions Pattern**: The technique of making a Signature the subject of an envelope, adding assertions, wrapping, and signing again. Binds the signer's own assertions to their signature. See [BCR-2024-009](bcr-2024-009-signature-metadata.md). +## Known Value Assignments -**Wrapped Signing Pattern**: The technique of wrapping already-signed content, adding assertions, and signing. Used when a third party adds assertions about signed content (timestamps, notarization, witnessing). +Proposed for the Reserved range (256-999) per BCR-2023-002. -**XID Document**: An eXtensible IDentifier document containing identity information, key bindings, key purposes, and other assertions about an identity. +### 300: `signer` -**XAdES**: XML Advanced Electronic Signatures, an ETSI standard defining signature properties including claimed roles and commitment types. - -## Proposed Known Value Assignments - -This BCR proposes additions to the **Reserved** range (256-999) as defined in [BCR-2023-002](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md). - -The proposed codepoints (300-301) are placed above the compact 2-byte range (0-255) to preserve those precious codepoints for the most fundamental predicates. Signing event assertions are important but not as frequent as core predicates, and 3-byte encoding is acceptable for assertions that appear once per signature. - -### Signing Event Assertions (300-301) - ---- - -#### 300: `signer` - -**Type**: property -**Definition**: Links a signature to a document identifying the signer. -**Domain**: Signing event assertions (on the Signature subject) -**Range**: Identity reference (may be ELIDED for privacy) -**Usage**: Establishes who made the signature, as opposed to which key made it. +Links a signature to a document identifying the signer. ``` -{ - Digest(document) -} [ - 'signed': { - Signature [ - 'signer': XID(alice) - ] - } ['signed': Signature] +Signature [ + 'signer': XID(alice) ] ``` -**Notes**: -- A signature proves a key signed; `signer` links to the identity behind the key -- The identity reference can be elided while preserving the assertion structure -- **Why `signer` is necessary**: Not all signature schemes embed the public key in the signature or allow key recovery: - - **EdDSA/Ed25519**: Public key cannot be recovered from signature (hashed in Fiat-Shamir transform) - - **BBS+**: Zero-knowledge proofs are unlinkable β€” verifiers cannot determine which key/signature created the proof - - **Longfellow and similar ZK schemes**: Designed specifically to hide signer identity from the cryptographic artifact - - 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. -- **Gordian ecosystem**: Within XIDs, Clubs, and GSTP, this predicate references an XID or Club -- **Broader use**: Gordian Envelope supports other identity reference formats (URIs, DIDs, etc.) for interoperability with external systems +A signature proves a key signed; `signer` links to identity. Required because some schemes (EdDSA, BBS+, Longfellow) don't embed or allow recovery of the public key. ---- +Within the Gordian ecosystem (XIDs, Clubs, GSTP), references an XID or Club. Gordian Envelope also supports URIs and DIDs. -#### 301: `signedOnBehalfOf` +### 301: `signedOnBehalfOf` -**Type**: property -**Definition**: (Optional) Identifies another entity that the signer represents when making this signature. -**Domain**: Signing event assertions (on the Signature subject) -**Range**: Identity reference -**Usage**: Indicates the signer is acting for another entity. +Optional. Identifies who the signer represents. ``` -{ - Digest(vendor-contract) -} [ - 'signed': { - Signature [ - 'signer': XID(alice) - 'signedOnBehalfOf': XID(acme-corp) - ] - } ['signed': Signature] +Signature [ + 'signer': XID(alice) + 'signedOnBehalfOf': XID(acme-corp) ] ``` -**Notes**: -- **Optional** β€” Only include when the signer is acting on behalf of another party (e.g., employee signing for company, agent signing for principal). Omit when signing in personal capacity. -- This is a claim by the signer β€” verification requires checking delegation authority -- For authority chain documentation, see BCR-2026-006's `conferredBy` and `conferralChain` predicates -- Common in corporate, legal, and organizational contexts -- **Gordian ecosystem**: Within XIDs, Clubs, and GSTP, this predicate references an XID or Club -- **Broader use**: Gordian Envelope supports other identity reference formats (URIs, DIDs, etc.) for interoperability with external systems - ---- +Only include when acting for another party. This is a claim β€” verification requires checking delegation authority (see BCR-2026-006). ## Referenced Standards -This BCR references predicates from the XAdES standard for signature properties that are not novel to Gordian Envelope. - ### xades:ClaimedRole -**Standard**: ETSI TS 101 903 (XAdES) -**Definition**: The capacity or role in which the signer is acting, as claimed by the signer. -**Range**: Text describing the role (e.g., "CEO", "Legal Representative", "Witness") -**Usage**: Describes the function the signer is performing. +From ETSI TS 101 903. The capacity in which the signer acts. Self-asserted. ``` Signature [ 'signer': XID(alice) - 'xades:ClaimedRole': "Chief Executive Officer" + 'xades:ClaimedRole': "CEO" ] ``` -**Notes**: -- This is a claimed role, not a certified role β€” it is self-asserted -- For certified roles backed by certificate chains, see XAdES CertifiedRoles -- Gordian Envelope supports text values; implementations may use Known Values for common roles - ### xades:CommitmentType -**Standard**: ETSI TS 101 903 (XAdES) -**Definition**: The purpose or meaning of the signature β€” what the signer is committing to. -**Range**: Text or identifier describing the commitment type -**Usage**: Distinguishes different signature purposes (approval, acknowledgment, witness, etc.) +From ETSI TS 101 903. The purpose of the signature. ``` Signature [ @@ -409,139 +245,34 @@ Signature [ ] ``` -**Notes**: -- Gordian Envelope does not limit values to XAdES OID constants -- Common values include: "approval", "acknowledgment", "witness", "receipt", "origin" -- For XAdES OID interoperability, see Appendix A - ---- - -## Usage Patterns - -### Complete Signature with Assertions - -``` -{ - Digest(contract) -} [ - 'signed': { - Signature [ - 'signer': XID(alice) - 'signedOnBehalfOf': XID(acme-corp) - 'xades:ClaimedRole': "CEO" - 'xades:CommitmentType': "approval" - ] - } ['signed': Signature] -] -``` - -### Minimal Signature with Identity Only - -``` -{ - Digest(document) -} [ - 'signed': { - Signature [ - 'signer': XID(alice) - ] - } ['signed': Signature] -] -``` - -### Privacy-Preserving with Elided Signer - -``` -{ - Digest(document) -} [ - 'signed': { - Signature [ - 'signer': ELIDED - 'xades:CommitmentType': "witness" - ] - } ['signed': Signature] -] -``` - -The signature structure is preserved, the commitment type is visible, but the signer identity is elided. - -## Relationship to Other Specifications - -### BCR-2024-009: Signatures with Metadata - -This BCR defines the vocabulary for signing event assertions using the structural pattern established in [BCR-2024-009](bcr-2024-009-signature-metadata.md). BCR-2024-009 defined the technique of attaching metadata to signatures; this BCR specifies the predicates to use. - -### BCR-2026-006: Principal Authority Predicates - -| Concern | BCR | Question Answered | -|---------|-----|-------------------| -| **Signing Event Assertions** | This BCR (004) | "What are the facts about this signing event?" | -| **Principal Authority** | BCR-2026-006 | "Who directed and takes responsibility for this work?" | - -A document may have: -- `principalAuthority` identifying who directed the work -- Signing event assertion predicates indicating who signed and how - -Both may be present. Neither implies the other. - -### XID Key Operations - -| Codepoint | Predicate | Purpose | -|-----------|-----------|---------| -| 63 | `delegate` | Grants cryptographic signing privileges to another key | -| 300 | `signer` | Links a signature to an identity (XID document) | -| 301 | `signedOnBehalfOf` | Indicates representation relationship | - -`delegate` is a key-level operation (key A can sign for key B). `signer` and `signedOnBehalfOf` are identity-level operations (person Alice signed for organization Acme). +Common values: approval, acknowledgment, witness, receipt, origin. ## Security Considerations -### Assertions Are Self-Asserted - -The predicates in this BCR express **claims by the signer**. Relying parties must: -- Verify both signatures cryptographically (inner on content, outer on assertion envelope) -- Confirm both signatures use the same public key (for self-asserted assertions) -- Resolve the XID reference to confirm identity -- Evaluate whether the claimed role and representation are plausible -- Verify authority claims using BCR-2026-006 predicates if needed - -### Signature-with-Assertions Integrity - -For self-asserted signing event assertions, both signatures must verify against the same key. If they use different keys: -- For **signature-with-assertions**: This is a verification failure β€” someone tampered with the assertion envelope -- For **wrapped signing**: This is expected β€” the wrapper is a different party (TSA, notary, etc.) +Signing event assertions are claims by the signer. Relying parties must verify both signatures, confirm they use the same key, resolve the XID, and evaluate plausibility. -### Elision and Assertions +For signature-with-assertions, different keys indicate tampering. For wrapped signing, different keys are expected. -When `signer` is elided: -- Both signatures remain cryptographically valid -- The signing key may still be visible (in the Signature) -- The identity behind the key is hidden -- Other assertions (role, commitment) may remain visible - -This enables privacy-preserving signatures where identity is disclosed selectively. +When `signer` is elided, signatures remain valid but identity is hidden. ## 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) β€” Structural pattern for signature-with-assertions +- [BCR-2024-009: Signatures with Metadata](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-009-signature-metadata.md) - [ETSI TS 101 903: XAdES](https://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.02_60/ts_101903v010402p.pdf) -- [Gordian Envelope Specification](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-001-envelope.md) -- [The BBS Signature Scheme (IETF Draft)](https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html) β€” Zero-knowledge proofs with unlinkable signatures -- [The Longfellow Zero-knowledge Scheme (IETF Draft)](https://datatracker.ietf.org/doc/html/draft-google-cfrg-libzk-01) β€” Privacy-preserving credential verification +- [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-005: General Assertion Predicates** β€” Lifecycle predicates (`validFrom`, `validUntil`) -- **BCR-2026-006: Principal Authority Predicates** β€” Authority relationships (`conferredBy`, `conferralChain`) +- BCR-2026-005: General Assertion Predicates +- BCR-2026-006: Principal Authority Predicates --- ## Appendix A: XAdES Commitment Type OIDs -For systems requiring XAdES interoperability, the following OID values are defined by ETSI TS 101 903: - | Commitment Type | OID | |-----------------|-----| | Proof of origin | 1.2.840.113549.1.9.16.6.1 | @@ -551,8 +282,6 @@ For systems requiring XAdES interoperability, the following OID values are defin | Proof of approval | 1.2.840.113549.1.9.16.6.5 | | Proof of creation | 1.2.840.113549.1.9.16.6.6 | -Gordian Envelope implementations may use these OIDs or equivalent text values. The `xades:CommitmentType` predicate is not limited to these values. - --- *BCR-2026-004: Signing Event Assertions* From 92ef862d960defbeacc61434b7edf244694da67c Mon Sep 17 00:00:00 2001 From: Christopher Allen Date: Wed, 4 Feb 2026 15:56:30 -0800 Subject: [PATCH 11/16] Expand Security Considerations with verification requirements Signed-off-by: Christopher Allen --- .../bcr-2026-004-signing-event-assertions.md | 27 ++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/papers/bcr-2026-004-signing-event-assertions.md b/papers/bcr-2026-004-signing-event-assertions.md index 3b5496e..8552317 100644 --- a/papers/bcr-2026-004-signing-event-assertions.md +++ b/papers/bcr-2026-004-signing-event-assertions.md @@ -249,11 +249,32 @@ Common values: approval, acknowledgment, witness, receipt, origin. ## Security Considerations -Signing event assertions are claims by the signer. Relying parties must verify both signatures, confirm they use the same key, resolve the XID, and evaluate plausibility. +### Verification Requirements -For signature-with-assertions, different keys indicate tampering. For wrapped signing, different keys are expected. +For signature-with-assertions pattern, verifiers MUST: -When `signer` is elided, signatures remain valid but identity is hidden. +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: +- Resolve the XID to verify the claimed identity +- Evaluate whether 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. ## References From f2a66fa05d537179640f22442bad1aaf6729840d Mon Sep 17 00:00:00 2001 From: Christopher Allen Date: Wed, 4 Feb 2026 15:57:12 -0800 Subject: [PATCH 12/16] Use relative link for BCR-2024-009 reference Signed-off-by: Christopher Allen --- papers/bcr-2026-004-signing-event-assertions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/papers/bcr-2026-004-signing-event-assertions.md b/papers/bcr-2026-004-signing-event-assertions.md index 8552317..5c989e9 100644 --- a/papers/bcr-2026-004-signing-event-assertions.md +++ b/papers/bcr-2026-004-signing-event-assertions.md @@ -274,7 +274,7 @@ When `signer` is elided, signatures remain valid but identity is hidden. This en ### Implementation -For API guidance and reference implementation, see BCR-2024-009. +For API guidance and reference implementation, see [BCR-2024-009](bcr-2024-009-signature-metadata.md). ## References From 8cd14a8e2f1e439840d05ec9f93743d5cca41aed Mon Sep 17 00:00:00 2001 From: Christopher Allen Date: Wed, 4 Feb 2026 16:00:52 -0800 Subject: [PATCH 13/16] Add Wolf McNally and Shannon Appelcline as authors Signed-off-by: Christopher Allen --- papers/bcr-2026-004-signing-event-assertions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/papers/bcr-2026-004-signing-event-assertions.md b/papers/bcr-2026-004-signing-event-assertions.md index 5c989e9..9baf886 100644 --- a/papers/bcr-2026-004-signing-event-assertions.md +++ b/papers/bcr-2026-004-signing-event-assertions.md @@ -4,7 +4,7 @@ **Β© 2026 Blockchain Commons** -Authors: Christopher Allen
+Authors: Christopher Allen, Wolf McNally, Shannon Appelcline
Date: February 4, 2026 --- From ae522100365423d9d2b7e2af4d6ae39821c8b48f Mon Sep 17 00:00:00 2001 From: Christopher Allen Date: Wed, 4 Feb 2026 18:15:04 -0800 Subject: [PATCH 14/16] =?UTF-8?q?Update=20codepoints:=20signer=20300?= =?UTF-8?q?=E2=86=92800,=20signedOnBehalfOf=20301=E2=86=92801?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Codepoints 300-303 are already assigned (asset, Bitcoin, Ethereum, Tezos). Moving to 800-801 for 3-byte CBOR encoding on decade boundary. Signed-off-by: Christopher Allen --- papers/bcr-2026-004-signing-event-assertions.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/papers/bcr-2026-004-signing-event-assertions.md b/papers/bcr-2026-004-signing-event-assertions.md index 9baf886..faa149a 100644 --- a/papers/bcr-2026-004-signing-event-assertions.md +++ b/papers/bcr-2026-004-signing-event-assertions.md @@ -45,8 +45,8 @@ Alice signing personally and Alice signing as CEO for Acme Corp produce identica This BCR defines: -- `signer` (300) β€” links signature to signer's identity -- `signedOnBehalfOf` (301) β€” identifies who the signer represents +- `signer` (800) β€” links signature to signer's identity +- `signedOnBehalfOf` (801) β€” identifies who the signer represents - References `xades:ClaimedRole` and `xades:CommitmentType` from XAdES Two patterns bind assertions to signatures: @@ -194,7 +194,7 @@ Bob's signature covers Alice's complete signed envelope. Proposed for the Reserved range (256-999) per BCR-2023-002. -### 300: `signer` +### 800: `signer` Links a signature to a document identifying the signer. @@ -208,7 +208,7 @@ A signature proves a key signed; `signer` links to identity. Required because so Within the Gordian ecosystem (XIDs, Clubs, GSTP), references an XID or Club. Gordian Envelope also supports URIs and DIDs. -### 301: `signedOnBehalfOf` +### 801: `signedOnBehalfOf` Optional. Identifies who the signer represents. From 017505208731c4a3d38eb6f9d4eeb5db57d84f5d Mon Sep 17 00:00:00 2001 From: Christopher Allen Date: Thu, 5 Feb 2026 10:21:12 -0800 Subject: [PATCH 15/16] Rename to BCR-2026-XXX temporary designation Per Wolf's recommendation: use temporary letter designations. Actual BCR numbers will be assigned at merge time. Updated all internal cross-references to XXX format. Signed-off-by: Christopher Allen --- ...ons.md => bcr-2026-xxx-signing-event-assertions.md} | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) rename papers/{bcr-2026-004-signing-event-assertions.md => bcr-2026-xxx-signing-event-assertions.md} (98%) diff --git a/papers/bcr-2026-004-signing-event-assertions.md b/papers/bcr-2026-xxx-signing-event-assertions.md similarity index 98% rename from papers/bcr-2026-004-signing-event-assertions.md rename to papers/bcr-2026-xxx-signing-event-assertions.md index faa149a..0a4a3db 100644 --- a/papers/bcr-2026-004-signing-event-assertions.md +++ b/papers/bcr-2026-xxx-signing-event-assertions.md @@ -1,6 +1,6 @@ # Signing Event Assertions -## BCR-2026-004 +## BCR-2026-XXX **Β© 2026 Blockchain Commons** @@ -219,7 +219,7 @@ Signature [ ] ``` -Only include when acting for another party. This is a claim β€” verification requires checking delegation authority (see BCR-2026-006). +Only include when acting for another party. This is a claim β€” verification requires checking delegation authority (see BCR-2026-XXX). ## Referenced Standards @@ -287,8 +287,8 @@ For API guidance and reference implementation, see [BCR-2024-009](bcr-2024-009-s ## Related BCRs -- BCR-2026-005: General Assertion Predicates -- BCR-2026-006: Principal Authority Predicates +- BCR-2026-XXX: General Assertion Predicates +- BCR-2026-XXX: Principal Authority Predicates --- @@ -305,5 +305,5 @@ For API guidance and reference implementation, see [BCR-2024-009](bcr-2024-009-s --- -*BCR-2026-004: Signing Event Assertions* +*BCR-2026-XXX: Signing Event Assertions* *Draft - February 4, 2026* From 75e98b7e9e358af8ff646295d0fed750f0343490 Mon Sep 17 00:00:00 2001 From: Christopher Allen Date: Thu, 5 Feb 2026 14:35:40 -0800 Subject: [PATCH 16/16] Update for Signature Qualifiers compatibility - Focus BCR on signer identity binding; defer metadata to Signature Qualifiers - Add 'Relationship to Signature Qualifiers' section - Replace xades:ClaimedRole/CommitmentType with sig:signerRole/sig:commitment - Add explicit Subject/Object documentation in predicate definitions - Add distinction note for signer vs sig:signerRole - Remove XAdES appendix (now handled by Signature Qualifiers) - Update terminology to align with progressive trust vocabulary Signed-off-by: Christopher Allen --- .../bcr-2026-xxx-signing-event-assertions.md | 124 ++++++++++-------- 1 file changed, 69 insertions(+), 55 deletions(-) diff --git a/papers/bcr-2026-xxx-signing-event-assertions.md b/papers/bcr-2026-xxx-signing-event-assertions.md index 0a4a3db..84de9c5 100644 --- a/papers/bcr-2026-xxx-signing-event-assertions.md +++ b/papers/bcr-2026-xxx-signing-event-assertions.md @@ -5,13 +5,15 @@ **Β© 2026 Blockchain Commons** Authors: Christopher Allen, Wolf McNally, Shannon Appelcline
-Date: February 4, 2026 +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 signers to attest these facts, bound to their signatures using the pattern from BCR-2024-009. +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 @@ -43,16 +45,26 @@ Alice signing personally and Alice signing as CEO for Acme Corp produce identica ### Solution -This BCR defines: +This BCR defines two predicates for **signer identity binding**: -- `signer` (800) β€” links signature to signer's identity +- `signer` (800) β€” links signature to signer's identity document - `signedOnBehalfOf` (801) β€” identifies who the signer represents -- References `xades:ClaimedRole` and `xades:CommitmentType` from XAdES 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 @@ -81,8 +93,14 @@ For a signer's own assertions, use the pattern from BCR-2024-009: make the Signa Signature [ 'signer': XID(alice) 'signedOnBehalfOf': XID(acme-corp) - 'xades:ClaimedRole': "CEO" - 'xades:CommitmentType': "approval" + 'sig:signerRole': '' [ + 'isA': 'sig:Role' + 'sig:roleName': "CEO" + ] + 'sig:commitment': '' [ + 'isA': 'sig:Commitment' + 'sig:commitmentType': 'sig:Approved' + ] ] } ['signed': Signature] ] @@ -111,7 +129,10 @@ For third-party assertions (timestamps, notarization), wrap the signed content, 'signed': { Signature [ 'signer': XID(timestamp-authority) - 'xades:CommitmentType': "timestamp" + 'sig:commitment': '' [ + 'isA': 'sig:Commitment' + 'sig:commitmentType': 'sig:Attested' + ] ] } ['signed': Signature] ] @@ -145,13 +166,19 @@ Multiple parties independently signing the same content: 'signed': { Signature [ 'signer': XID(alice) - 'xades:CommitmentType': "approval" + 'sig:commitment': '' [ + 'isA': 'sig:Commitment' + 'sig:commitmentType': 'sig:Approved' + ] ] } ['signed': Signature] 'signed': { Signature [ 'signer': XID(bob) - 'xades:CommitmentType': "approval" + 'sig:commitment': '' [ + 'isA': 'sig:Commitment' + 'sig:commitmentType': 'sig:Approved' + ] ] } ['signed': Signature] ] @@ -174,7 +201,10 @@ A party signing over another's signed content: 'signed': { Signature [ 'signer': XID(bob) - 'xades:CommitmentType': "witness" + 'sig:commitment': '' [ + 'isA': 'sig:Commitment' + 'sig:commitmentType': 'sig:Witnessed' + ] ] } ['signed': Signature] ] @@ -184,7 +214,9 @@ 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*. +**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. @@ -198,58 +230,52 @@ Proposed for the Reserved range (256-999) per BCR-2023-002. Links a signature to a document identifying the signer. +**Subject**: Signature
+**Object**: Identity document (XID, DID, or URI) + ``` Signature [ 'signer': XID(alice) ] ``` -A signature proves a key signed; `signer` links to identity. Required because some schemes (EdDSA, BBS+, Longfellow) don't embed or allow recovery of the public key. +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), references an XID or Club. Gordian Envelope also supports URIs and DIDs. +Within the Gordian ecosystem (XIDs, Clubs, GSTP), `signer` references an XID or Club. Gordian Envelope also supports DIDs and other URIs. -### 801: `signedOnBehalfOf` - -Optional. Identifies who the signer represents. +**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) - 'signedOnBehalfOf': XID(acme-corp) + 'signer': XID(alice) // WHO signed (identity) + 'sig:signerRole': '' [ // WHAT capacity (role) + 'isA': 'sig:Role' + 'sig:roleName': "CEO" + ] ] ``` -Only include when acting for another party. This is a claim β€” verification requires checking delegation authority (see BCR-2026-XXX). - -## Referenced Standards +### 801: `signedOnBehalfOf` -### xades:ClaimedRole +Optional. Identifies who the signer represents. -From ETSI TS 101 903. The capacity in which the signer acts. Self-asserted. +**Subject**: Signature
+**Object**: Identity document (XID, DID, or URI) of the represented entity ``` Signature [ 'signer': XID(alice) - 'xades:ClaimedRole': "CEO" + 'signedOnBehalfOf': XID(acme-corp) ] ``` -### xades:CommitmentType - -From ETSI TS 101 903. The purpose of the signature. - -``` -Signature [ - 'signer': XID(alice) - 'xades:CommitmentType': "approval" -] -``` +Only include when acting for another party. This is a claim, not fact β€” evaluation requires checking delegation authority (see BCR-2026-XXX Principal Authority). -Common values: approval, acknowledgment, witness, receipt, origin. +**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 -### Verification Requirements +### Cryptographic Verification Requirements For signature-with-assertions pattern, verifiers MUST: @@ -263,9 +289,9 @@ For wrapped signing (third-party assertions), different keys are expected β€” th ### Claims vs Proof -Signing event assertions are claims by the signer, not proof. Relying parties must: -- Resolve the XID to verify the claimed identity -- Evaluate whether claims (role, representation) are plausible +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 @@ -280,7 +306,7 @@ For API guidance and reference implementation, see [BCR-2024-009](bcr-2024-009-s - [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) -- [ETSI TS 101 903: XAdES](https://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.02_60/ts_101903v010402p.pdf) +- [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) @@ -289,21 +315,9 @@ For API guidance and reference implementation, see [BCR-2024-009](bcr-2024-009-s - BCR-2026-XXX: General Assertion Predicates - BCR-2026-XXX: Principal Authority Predicates - ---- - -## Appendix A: XAdES Commitment Type OIDs - -| Commitment Type | OID | -|-----------------|-----| -| Proof of origin | 1.2.840.113549.1.9.16.6.1 | -| Proof of receipt | 1.2.840.113549.1.9.16.6.2 | -| Proof of delivery | 1.2.840.113549.1.9.16.6.3 | -| Proof of sender | 1.2.840.113549.1.9.16.6.4 | -| Proof of approval | 1.2.840.113549.1.9.16.6.5 | -| Proof of creation | 1.2.840.113549.1.9.16.6.6 | +- BCR-2026-XXX: Signature Qualifiers β€” complementary; provides `sig:signerRole`, `sig:commitment`, `sig:signingTime`, etc. --- *BCR-2026-XXX: Signing Event Assertions* -*Draft - February 4, 2026* +*Draft β€” February 5, 2026*