feat(core): propagate technical caller bearer token

[GabrieleBocchi]

Goal

Make the technical-caller bearer token a mandatory, request-scoped input at the Core Permission Provider boundary.

Related ADRs

ADR 0001, ADR 0002, ADR 0004, ADR 0006, ADR 0007, ADR 0008.

Scope

• Add TechnicalCallerBearerToken as the Core representation of the raw technical-caller bearer token.
• Require the bearer token in every selected-target PermissionProviderRequest.
• Expose the token only through the Permission Provider request boundary.
• Preserve the raw token value exactly without parsing, validation, normalization, or transformation.
• Extend deterministic Core tests for Provider input propagation and Send + Sync compatibility.

Out of scope

JWT authentication and validation, inbound HTTP, Generic REST Provider implementation, HTTP transport, Provider configuration, orchestration, routing changes, Target Adapter changes, observability implementation, and runtime/OCI work.

Implementation

Introduce the opaque Core type:

pub struct TechnicalCallerBearerToken(String);

with the deliberately minimal API:

pub fn new(value: String) -> Self;
pub fn as_str(&self) -> &str;

TechnicalCallerBearerToken::new preserves the supplied value unchanged. Core does not authenticate, parse, validate, normalize, or otherwise interpret the token.

PermissionProviderRequest now requires:

• synchronized-user IdentityContext;
• independently selected LogicalTarget;
• TechnicalCallerBearerToken;
• SynchronizationContext.

The bearer token is borrowed by the Provider request and remains separate from synchronized-user identity, routing state, desired state, synchronization context, and Target Adapter inputs.

Dependencies

None.

Review guide

Focus on:

• the minimal public API of TechnicalCallerBearerToken;
• mandatory bearer-token presence on selected-target Provider requests;
• exact preservation of the supplied raw token value;
• separation between technical-caller credentials and synchronized-user identity;
• least-privilege exposure only at the Permission Provider boundary;
• preservation of Core runtime neutrality and existing LogicalTarget semantics.

Architecture invariants

The technical caller and synchronized end user remain distinct concepts.

PermissionSync retains LogicalTarget for selected-target routing and orchestration.

The technical-caller bearer token is available to the Permission Provider but is not part of IdentityContext, SynchronizationContext, desired state, or TargetAdapterRequest.

Core remains transport-neutral and does not perform JWT or HTTP processing.

Tests

• Verify TechnicalCallerBearerToken preserves the supplied value exactly.
• Verify a PermissionProvider receives identity, logical target, bearer token, deadline, and cancellation context.
• Verify TechnicalCallerBearerToken satisfies the existing Send + Sync boundary requirements.
• Update existing Provider request tests for the new mandatory input.
• Preserve existing object-safety, deadline/cancellation, Adapter, desired-state, and error-redaction coverage.

Security considerations

TechnicalCallerBearerToken intentionally provides no ordinary formatting, cloning, serialization, dereferencing, or generic string-conversion API.

The raw bearer value is exposed deliberately through as_str() for Permission Provider use and must be treated as sensitive.

The type does not claim authenticated provenance: the future inbound authentication boundary remains responsible for constructing it from a successfully authenticated caller credential.

No bearer token is propagated to Target Adapters through the Core API.

Follow-ups

Implement the Generic REST Permission Provider against ADR 0008 using the bearer token exposed by PermissionProviderRequest.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 4b159998-76ef-4849-8042-3b7d59610539

📥 Commits

Reviewing files that changed from the base of the PR and between 5de0cfc and 5865b0f.

📒 Files selected for processing (3)

• crates/permissionsync-core/src/lib.rs
• crates/permissionsync-core/src/ports.rs
• crates/permissionsync-core/src/technical_caller.rs

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The core crate adds TechnicalCallerBearerToken, re-exports it, and includes it in PermissionProviderRequest. The token preserves its raw value and is tested for provider propagation, sensitivity constraints, and Send + Sync.

Changes

Technical caller token propagation

Layer / File(s)	Summary
Technical caller token contract crates/permissionsync-core/src/technical_caller.rs, crates/permissionsync-core/src/lib.rs	Defines and re-exports TechnicalCallerBearerToken. The type preserves the supplied bearer value without normalization.
Provider request token input crates/permissionsync-core/src/ports.rs	Adds the token to PermissionProviderRequest, requires it in new, and exposes it through technical_caller_bearer_token.
Provider propagation validation crates/permissionsync-core/src/ports.rs, crates/permissionsync-core/src/technical_caller.rs	Tests raw token preservation, provider observation, request construction, and Send + Sync support.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Merge Risk: ⚪ Minimal · up to 5865b

Permission providers now receive the request-scoped technical caller bearer token unchanged while it remains separate from user identity and target-adapter inputs. The updated contract and propagation coverage indicate no remaining merge-blocking risk.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description includes all required template sections and clearly documents the goal, scope, implementation, architecture invariants, tests, security considerations, and follow-ups.
Title check	✅ Passed	The title clearly and concisely describes the main change: propagating the technical caller bearer token through the Core boundary.
Docstring Coverage	✅ Passed	Docstring coverage is 80.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 15 functions across 3 files.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/core-provider-bearer-token

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[gitar-bot]

Code Review ✅ Approved

Introduces TechnicalCallerBearerToken as a mandatory, request-scoped input to the Core Permission Provider boundary, with a minimal opaque API that preserves the raw token value unchanged. Bearer token is now required on every selected-target PermissionProviderRequest and exposed only at the Provider boundary, keeping it separate from synchronized-user identity and Target Adapter inputs. No issues found.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

---

Important

Your trial ends in 6 days — upgrade now to keep code review, CI analysis, auto-apply, custom automations, and more.

_{Was this helpful? React with 👍 / 👎 | Gitar}

[Copilot]

🟢 Approval recommended

No unresolved review issues were identified.

Pull request overview

Adds a transport-neutral, request-scoped technical-caller bearer token to the Core Permission Provider boundary.

Changes:

• Introduces an opaque raw-token type.
• Makes the token mandatory in PermissionProviderRequest.
• Adds propagation, preservation, and Send + Sync coverage.

File summaries

File	Summary
crates/permissionsync-core/src/technical_caller.rs	Defines the opaque bearer-token type and preservation test.
crates/permissionsync-core/src/ports.rs	Adds mandatory token propagation and request tests.
crates/permissionsync-core/src/lib.rs	Registers and re-exports the new type.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.