> On Oct 13, 2023, at 6:57 PM, Orie Steele <orie@transmute.industries> wrote: > > > riffing on this, if it's possible to use a "simple and safe parser on the > untrusted data", before using a "maybe safe / probably fast " parser on the > trusted data, maybe do that : ) > >> This is also not dissimilar to additional effort CBOR specs make to reduce >> optionality/variability in formats. That said, the vast majority of relying >> parties (e.g. all but one implementation) will likely use off-the-shelf JSON >> parsers for this data, which could very well be coming from a malicious >> client. > > So bad guys are going to get their malicious JSON to relying parties, and > relying parties are going to process the JSON (with the finest of JSON > parsers)... no matter what we say in SD-JWT ? : )
Just sayin’. The ‘deterministic’ CollectedClientData was added for one vendor, and AFAIK they are still the only vendor using that feature. In return, we got a much harder job evolving in the future, as we can’t use the ‘ignore what you don’t understand’ extensibility model typical of JSON data formats. > Must be nice to have a JSON parser that returns the last duplicate member... > but also doesn't have any active CVEs. I do wonder if timing had been different if JWS and JWT would have been based on I-JSON. This behavior is most likely described because JSON leaves it entirely non-deterministic. If I have two separate components parsing the data in a chain, I’ll either have one/both error out or both interpret the object the same way, vs having one operate on the first property value and the other operate on the second. -DW
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
