Context
We are building a language server that authenticates against external systems. Credentials (bearer tokens, username/password pairs) need to be provided by the user via the language client (e.g. VS Code) and transmitted to the language server via a custom LSP extension.
Problem
The vscode-languageclient library (and likely other client implementations) supports enabling a low-level JSON-RPC traffic trace, which can log the full payload of every request, response, and notification to an output channel (in VS Code, via "<id>.trace.server": "verbose" setting). This means any credentials passed as parameters in a custom extension request would appear in plain text in that output, which is a serious security issue.
We searched the specification and found no way to mark a parameter or an entire request/notification as sensitive, to signal that its content must be redacted or suppressed in such trace outputs.
Question / Request
Is there an existing convention or workaround for this that we may have missed?
If not, is this something worth addressing in the spec? For example via:
- a way to mark a parameter / notification / request as sensitive
- a client capability that the server can inspect to determine whether the client guarantees redaction of sensitive parameters in traces. This would allow the server to gracefully disable functionality that requires sensitive data when talking to a client that cannot provide that guarantee
Context
We are building a language server that authenticates against external systems. Credentials (bearer tokens, username/password pairs) need to be provided by the user via the language client (e.g. VS Code) and transmitted to the language server via a custom LSP extension.
Problem
The
vscode-languageclientlibrary (and likely other client implementations) supports enabling a low-level JSON-RPC traffic trace, which can log the full payload of every request, response, and notification to an output channel (in VS Code, via"<id>.trace.server": "verbose"setting). This means any credentials passed as parameters in a custom extension request would appear in plain text in that output, which is a serious security issue.We searched the specification and found no way to mark a parameter or an entire request/notification as sensitive, to signal that its content must be redacted or suppressed in such trace outputs.
Question / Request
Is there an existing convention or workaround for this that we may have missed?
If not, is this something worth addressing in the spec? For example via: