Reading the threads below did not solve the issue:
Called workflow seems not to have an access to secrets within the repository the called workflow is stored (even if they are organizational secrets). Although a called workflow accepts inputs and secrets, it does not serve a common use case where the called workflow encapsulates the implementation.
As an example, when a called workflow encapsulates the logic of publishing a package to organizational NPM registry, the called workflow needs an NPM token in order to authenticate with NPM (and maybe some other environment variables). The NPM token can be stored as a secrets (in the repository of the called workflow file) and each caller workflow does not need to know neither how the called workflow is publishing a package, nor maintaining its own NPM token.
Rather then passing NPM token from the caller workflow to the called workflow, how do you suggest handling such use case?
Plus, how can the called workflow access the event which triggered the caller workflow. E.g.
$GITHUB_EVENT_PATH from caller workflow to the called workflow is problematic since having
env.GITHUB_EVENT_PATH in the with expression is not interpolated correctly).