On Tue, Mar 2, 2021 at 12:44 PM Larry Masinter <LMM@xxxxxxx> wrote:
There is a working group WPACK which could have taken on the problem of how to package HTML, embedded image, _javascript_ libraries in a way that could be interpreted in a sandboxed environment. Maybe what they are doing could be retargeted for such a purpose?
No.
And here is my objection to the current IETF approach of 'focused' WGs: They are more likely to produce an output but it is very likely to be an output that it would be better hadn't been created in the first place.
What I needed for my work is a packaging format that supports:
1) Incremental Encryption
2) Incremental Integrity
3) Authentication
What Google needed for their immediate commercial needs was a simple archive technology that zips up a few Web page components delivered over HTTP/TLS. So they wrote a very narrow spec that only addressed their use case and then came to IETF to get it blessed as a niche solution. But it is a solution that was designed with absolutely no thought to the wider problem. They didn't want to consider the wider problem at all.
This is how PKIX got in the state it has. Instead of considering revocation from a high level standpoint and building a scalable solution we had a 'make do' solution which led to another incremental solution which was again curtailed and... That is how we ended up with five separate assertion types in PKIX. TAXI which became the basis for XKMS and SAML was an attempt to simplify and get back to basics.
What I fully expect will happen of course is that at some point we will want to introduce DARE into IETF. Security of Data at Rest is starting to become an enterprise concern. And of course there will be people asking 'why not build it on WPACK' and 'why not use CBOR' and the answer will be that there are very specific requirements that apply to DARE which the people working on those systems told me are out of scope and they do not want to consider.
Oh and the reason DARE is designed the way it is is for backwards compatibility with a different set of standards. JSON-B is a strict superset of JSON encoding so that every valid JSON document is also JSON-B. You need a separate serializer to make use of JSON-B encoding but a single decoder will decode both and also the compressed version and the version with binary encodings for extended binary data types.
Using DARE for HTML packaging is easy because I designed it to support HTML packaging even though I had absolutely no need for that at the time I did the work. Why did I design that spec to meet a use case I don't care about? Well if you want your spec to support unexpected and new use cases you cannot imagine, you had better start by meeting the use cases you can.
The SAML TC had a use cases sub-committee that spent hours arguing over which use cases to include. Some of that argument was productive because it resulted in a better statement of the use case. But a lot of it was pointless discussion of whether a use case was important enough to generate a requirement and I didn't care whether it was important enough, I worked out a way to meet the requirement regardless.
