> 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

Reply via email to