The idea behind these test vectors is to test the PASETO implementation, not that implementation's JSON parser of choice.
As JSON has no standardised order for encoding a dictionary/map, it is easier to operate on the encoded string than adjust individual implementations to match behaviour exactly.
This is a breaking change so as to match the pattern already adopted in the footer and implicit-assertion keys, however this could be refactored as a non-breaking change by instead duplicating the data into a different key for the encoded form (e.g. payload-raw).
As currently proposed, implementations will need to make a minor adjustment to their test logic when updating their copy of these vectors (i.e. they will no longer need to re-encode the payload after extracting it).
This makes more sense for interoperability than the decoded object as a test vector. We can optionally include both so developers reading the JSON file can understand its intent.
The idea behind these test vectors is to test the PASETO implementation, not that implementation's JSON parser of choice. As JSON has no standardised order for encoding a dictionary/map, it is easier to operate on the encoded string than adjust individual implementations to match behaviour exactly.
This is a breaking change so as to match the pattern already adopted in the
footer
andimplicit-assertion
keys, however this could be refactored as a non-breaking change by instead duplicating the data into a different key for the encoded form (e.g.payload-raw
).As currently proposed, implementations will need to make a minor adjustment to their test logic when updating their copy of these vectors (i.e. they will no longer need to re-encode the
payload
after extracting it).Closes #10