Do we solve the 33% bloat problem?

[TelegramSam]

This adds complexity but avoids messaging size increase when passing already encrypted info. Thoughts?

[kdenhartog]

I think the main point in question for me is whether the complexity of having to support the external property in the JWE and the additional processing logic is worth the inefficiency. The main reason for bringing this up is because the majority of use cases that I've implemented to date rely on only a single hop mediator and are sent over HTTP which doesn't have issues with large JSON bodies being posted. Even when we've started exploring the usage of offline scenarios where bluetooth is in use, we found that because the phone is able to use bluetooth to setup a wifi-aware endpoint we weren't necessarily faced with limitations on message size.

So, In my mind I don't see many scenarios where this codepath is the best method to solve a problem when considering the implementation complexity and the likely tradeoff of no longer being able to use off the shelf JOSE libraries even though this should be standards compliant based on the commonly shared interpretation between this group of section 4.3 in RFC 7516.

The main scenario where I see this codepath as being the only viable solution is when a mediator is using a QR code as a transport method to pickup a message and forward it on, but realistically how often is that going to happen? Are there other usecases I'm missing where the size of a message is a concern and a multi-hop strategy is employed where many levels of encryption are employed in a way where the problem is so pervasive that we believe every implementation should support this feature?

I'm certainly open to being convinced, but in all of the scenarios I can come up with I find that the additional implementation complexity is not worth the efficiency gains because there's almost always different architectural design choices that can be made so that the limited message size requirement can be removed.

[TelegramSam]

Discussed in WG Call 20210419. Answer is no, we will not attempt to solve the 33% bloat problem at this time. Reasons included delaying the spec, future work on a binary format that avoids this issue.