[Quality][High] Validate cross-contract authorization context

[Baskarayelu]

Objective

Define and enforce the caller/context relationship for all cross-contract privileged calls.

Why this matters

A downstream contract must not trust caller-supplied identity fields when an upstream contract is the authority.

This is a substantive production-quality improvement. It must change runtime behavior, security guarantees, correctness, reliability, or meaningful user functionality. It is not a documentation-only, formatting-only, or trivial dependency task.

Scope

Area: cross-contract trust boundaries

Starting points: docs/CROSS_CONTRACT_TRUST.md, docs/cross-contract-call-graph.md, contract crates

The contributor should verify the current implementation before changing it and keep the PR limited to this issue. Do not introduce unrelated refactors or weaken existing CI/security gates.

Acceptance criteria

• Each cross-contract call documents its trusted caller and authenticated subject.
• Direct user calls cannot impersonate an upstream contract.
• Forwarded authorization cannot be reused for another operation or target.
• Failures do not leave partial state in either contract.

Required validation

• Test direct spoofed calls and calls from the wrong contract.

• Test nested calls with mismatched subject/target fields.

• Add failure-atomicity coverage for cross-contract errors.

• The PR explains the failure mode, the chosen design, backward-compatibility impact, and rollback or migration considerations.

• The PR includes CI evidence and does not contain secrets, generated noise, unrelated cleanup, or disabled checks.

Contributor deliverables

• Open a focused feature branch and do not begin implementation until assigned.
• Reference this issue with Closes #<issue-number> or Fixes #<issue-number>.
• Check off every acceptance criterion in the PR with links to the relevant code and tests.
• Include a security/correctness note explaining why adversarial inputs cannot bypass the new guarantee.

Maintainer quality bar

The PR must be independently reviewable, preserve existing behavior outside this scope, exercise failure paths, and pass the repository's complete required CI/CD checks. Reward eligibility is not guaranteed by this issue or by merging.

[DevScoopee]

Hi, I have read and understood what needs to be done and can deliver. Kindly assign

[guptakumarranjeet150]

Hi maintainers,

I would love to take this on. My planned approach:

• Implement [Quality][High] Validate cross-contract authorization context with explicit require_auth checks, clean storage layouts, and robust Soroban contract logic.
• Add comprehensive unit tests verifying both happy-path invocations and unauthorized revert scenarios.

Looking forward to contributing—please feel free to assign!

[shobhamerabacha-star]

Hey team,

I would love to take this on. My planned approach:

• Implement [Quality][High] Validate cross-contract authorization context with explicit require_auth checks, clean storage layouts, and robust Soroban contract logic.
• Add comprehensive unit tests verifying both happy-path invocations and unauthorized revert scenarios.

Looking forward to contributing—please feel free to assign!