Potential side-channel at TLS-terminating intermediaries due to plaintext error responses?

while reviewing the credential issuance flow, I may have noticed an architectural detail and wanted to get your thoughts to see if this could be considered a potential privacy leak. It seems that while successful credential responses are securely encrypted at the application layer (as opaque JWEs), error responses (like credential_request_denied) are explicitly required to be sent in plaintext. If a deployment uses a TLS-terminating intermediary (such as a CDN, Reverse Proxy or API Gateway), this intermediary can still easily deduce whether a user's request was approved or rejected just by looking at whether the response is encrypted or plaintext. I understand this might be an intended design choice for routing or debugging, but could this be considered a decision-state information leak in split-trust environments? I would much appreciate to hear your perspectives on this. Thank you in advance.

Start by reviewing the credential issuance flow described in the issue, focusing on encrypted successful credential responses versus plaintext error responses through TLS-terminating intermediaries. Determine whether this difference reveals approval or rejection state in split-trust deployments; done requires a documented security assessment and a clear design decision.