BCR-2026-XXX: Principal Authority Predicates

[ChristopherA]

Proposes Known Values for expressing principal-agent authority relationships in Gordian Envelopes.

Predicates defined:

• principalAuthority — The entity with authority over the work
• assertsDelegationFrom — Agent's claim of delegation from a principal
• delegationScope — Boundaries of delegated authority
• delegationConstraints — Specific limitations on the delegation

Codepoints: Community range 1040-1043

Enables clear attribution when authorship and responsibility are distinct, such as ghostwritten works or delegated creative authority.

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

[shannona]

I find this one confusing and it's all about "assertsDelegationFrom". It feels disconnected from the "principalAuthority" and in fact I don't understand why the principalAuthority isn't declaring (and signing!) delegation TO someone. That seems the direction the digital authorization should be, and it links all this together in a way that it feels like it isn't right now. (And if that doesn't exist, then it needs to be clearer in this document how to look up that delegation [e.g., go to their XID and look for a 'delegatedTo' Known Value or something]

You also already have 'delegatedBy' and 'delegateChain' in BCR-2026-006, which feels redundant.

[ChristopherA]

This points to a real tension in the design.

The reasoning behind assertsDelegationFrom was making the claim nature explicit — the agent is asserting delegation, not stating it as fact. This was meant to handle cases where delegation is contextual or per-task rather than standing. But that creates exactly the problem you're describing: if the principal holds authority, they should be the one signing the delegation. The current design makes verification indirect.

On the redundancy with BCR-006: that BCR emerged from working through the XID-Quickstart binding agreements tutorial. When drafting tutorial 09 on CLA signing, it became clear that someone might sign a CLA on behalf of their employer rather than personally — and that the signature context (in what capacity? representing whom?) was distinct from the authority relationship itself. That's where signingAs, onBehalfOf, and delegatedBy came from. The overlap with assertsDelegationFrom here wasn't intentional — BCR-006 handles "in what capacity is this signature made?" while BCR-007 was meant to handle "who directed this work?" But they've ended up covering similar ground.

There's also a trust model question here. XID edge assertions (BCR-2026-003) assume a peer-to-peer model where edges from source→target aren't really valid unless accepted by the target. But these predicates might also be used in issuer→subject scenarios like Verifiable Credentials, where there's no acceptance step — the issuer just makes a claim. I'd like these schemas to be usable in both contexts (and available as JSON-LD at assertions.info for people doing VC-style work). That may affect which direction the delegation should flow.

Some directions this could go:

1. Add delegatesTo — Principal declares and signs delegation TO an agent. The agent can then reference this signed delegation in their work. This makes the authorization flow match normal expectations (principal → agent) while keeping assertsDelegationFrom for cases where the agent needs to claim without a standing delegation record. Downside: now we have both directions, which raises the question of when to use which. Adds predicates rather than simplifying.

2. Consolidate with BCR-006 — Move assertsDelegationFrom, delegationScope, delegationConstraints to Signature Context. Keep only principalAuthority here as the minimal "whose work is this?" marker. All delegation vocabulary in one place, eliminates the redundancy. Downside: BCR-006 was scoped to signature context specifically — this might overload its purpose into general authority relationships. And BCR-007 becomes very thin.

3. Rename BCR-006 predicates — Find names that emphasize signing context vs work authority. Keeps both BCRs intact. Downside: the obvious renames (signatureAuthorizedBy, signatureAuthorizationChain) go the wrong direction — "signature" is cryptographic-specific, "authorized" gets confused with authentication. The original onBehalfOf works precisely because it's cryptographically agnostic. Hard to find better names that clarify without over-specifying.

4. Better documentation — At minimum, add a section explaining how to verify delegation claims: look for signed delegatesTo from the claimed principal, or treat the work-level signature as implicit acceptance. Downside: doesn't actually fix the design issue, just documents around it. Verification path remains indirect.

The consolidation option might be cleanest — it puts all delegation predicates in one BCR and makes this one minimal. What's your read?

[shannona]

Consolidation and the creation of both "delegatedTo" and "assertsDelegatedFrom" (name change purposeful) would be my suggestion.

[ChristopherA]

Terminology Update: "Conferral" replaces "Delegation"

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

Why the change

"Delegation" collides with multiple technical domains:

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

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

Changes in this PR

Old	New
assertsDelegationFrom	assertsConferralFrom
delegationScope	conferralScope
delegationConstraints	conferralConstraints

Also updated terminology sections, examples, added a Design Note explaining the choice, and changed "key-level privileges" to "cryptographic signing privileges".

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

[ChristopherA]

Predicate Consolidation: conferral predicates added from BCR-2026-006

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

BCR-2026-007 now defines all conferral predicates (1040-1045):

• principalAuthority (1040)
• assertsConferralFrom (1041)
• conferralScope (1042)
• conferralConstraints (1043)
• conferredBy (1044) — added from BCR-006
• conferralChain (1045) — added from BCR-006

BCR-2026-006 now defines only:

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

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

[ChristopherA]

Added: confersTo for bidirectional authority

Per @shannona's suggestion, added the principal→agent direction:

confersTo (1046): Principal declares and signs conferral TO an agent.

{
    Digest(authority-grant) [
        'confersTo': XID(agent-alice)
        'conferralScope': "Draft technical documentation"
        'signed': {
            XID(principal-bob) [
                'signingAs': "Project Lead"
            ]
        }
    ]
}

BCR-2026-007 now has bidirectional conferral:

• confersTo — Principal signs conferral TO agent (authoritative)
• assertsConferralFrom — Agent claims conferral FROM principal (claim)

Together they provide complete verification:

1. Agent claims: assertsConferralFrom: XID(principal)
2. Verifier checks: Does principal have signed confersTo: XID(agent)?

This addresses the concern about authorization flowing in the expected direction while keeping the agent's assertion capability for contextual/per-task conferrals.

[ChristopherA]

Per Wolf's feedback: removed { } envelope wrapping from examples that don't include signatures. Wrapping is only needed when showing signed envelopes.

[ChristopherA]

Renumbered: BCR-2026-007 → BCR-2026-006

File renamed: bcr-2026-007-principal-authority.md → bcr-2026-006-principal-authority.md

Also includes signature example fixes for consistency with BCR-2026-004:

• conferredBy and conferralChain examples simplified to unsigned assertions (signature not required for these predicates)
• confersTo example now uses proper double-signing pattern with signer predicate

Cross-references updated. Branch name preserved for PR history.

[ChristopherA]

Signature Pattern Update

Updated confersTo example to use the signature-with-assertions pattern from BCR-2024-009 (documented in BCR-2026-004).

Before (double-wrap):

{ { content } 'signed': Signature ['signer': XID] } 'signed': Signature

After (signature-with-assertions):

{ content } [ 'signed': { Signature ['signer': XID] } ['signed': Signature] ]

This aligns with the validated pattern in BCR-2026-004 where assertions are placed ON the Signature object, wrapped, and signed.