EncryptedRequest - standardization

[jeremi]

I've noticed that we're considering using a custom encryption method for our HTTP POST requests: EncryptedRequest.

While the proposed solution seems feasible, I'd like to suggest an alternative: adopting the JSON Web Token (JWT) standard. JWT offers several benefits that make it a good choice for secure data transmission:

• Simplicity: JWT tokens are easy to generate, validate, and consume. They contain a header, payload, and signature, all concatenated with dots and base64Url encoded. This structure is straightforward to work with and well-supported in many programming languages.
• Standardization: JWT is a widely-accepted standard (RFC 7519) with a large community and many available libraries. Using JWT ensures compatibility with other systems and reduces the likelihood of encountering issues tied to proprietary encryption methods.
• Flexibility: JWT allows for different signing algorithms, such as HMAC, RSA, or ECDSA. This flexibility makes it suitable for a variety of use cases and security requirements.

Is there any reason why JWT might not be a good fit?

[vvujjini]

Thanks for pointing this @jeremi. It is good point and leverage the existing spec / standard to represent the encrypted data. I will sturdy little more and purpose a draft open api spec element for this for discussion.

@gsasikumar do you have any other thoughts to represent encrypted data element in a payload?

[gsasikumar]

@jeremi I think you are suggesting a JWE RFC 7516. I agree that we should rely on JWE. But would like to fix the "enc" to a small subset.

[jeremi]

Yes, you're right, @gsasikumar; I meant JWE.
Which algorithms do you suggest to fix the "enc" value? We should ensure that the chosen algorithms are widely supported in the most commonly used programming languages for seamless implementation.