28 lines
1.4 KiB
Markdown
28 lines
1.4 KiB
Markdown
# Bridge providers receive authenticated caller identity
|
|
|
|
Bridge payloads are guest-controlled. A provider that uses a payload field as
|
|
an ownership namespace lets one plugin impersonate another plugin and mutate
|
|
or claim its managed records. The consumer-to-host `BridgeInvokeRequest`
|
|
cannot safely carry identity because the consumer constructs that message.
|
|
|
|
Decision: the host derives the caller plugin from the loaded module or native
|
|
plugin registration. It passes that identity to the provider in
|
|
`BridgeCallRequest.caller_plugin` and, for Go providers, through
|
|
`plugin.WithBridgeCallerPlugin`. Providers read it with
|
|
`plugin.BridgeCallerPlugin` and fail closed when an ownership-sensitive call
|
|
has no authenticated caller.
|
|
|
|
The new host-to-provider protobuf field is additive. Older providers ignore
|
|
it. New ownership-sensitive providers intentionally reject calls from older
|
|
hosts that cannot authenticate a caller. Hosts must never copy a caller name
|
|
from opaque bridge payloads or a consumer-authored capability field.
|
|
|
|
Consequences:
|
|
|
|
- Providers can derive durable ownership from an authenticated principal.
|
|
- Bridge payload schemas do not need security-sensitive source fields.
|
|
- Native and Wasm providers observe the same caller context contract.
|
|
|
|
Keywords: plugin bridge, caller identity, authentication, ownership,
|
|
BridgeCallRequest, WithBridgeCallerPlugin, Wasm, confused deputy
|