Does not support JSON Canonicalization Scheme

[stalniy]

Description

This library currently does not implement the JSON Canonicalization Scheme (JCS) as defined in RFC 8785. As a result, it cannot be reliably used for token signing or signature verification, since JSON objects with the same semantic content can be serialized in different key orders. For example:

{ "a": 1, "b": 2 }
{ "b": 2, "a": 1 }

Although these two representations describe identical data, their serialized byte forms differ. This discrepancy can cause signature validation failures - particularly in cross-language environments where tokens are generated in one language (e.g., JavaScript, Python, or PHP) and verified in Go.

To ensure interoperability and security, the library should follow the canonicalization rules described in RFC 8785. At a minimum, object keys should be consistently sorted prior to serialization.

Implementing JCS or providing an option to enable canonical encoding would significantly improve the library’s reliability for cryptographic operations and multi-language compatibility.

[oxisto]

Description

This library currently does not implement the JSON Canonicalization Scheme (JCS) as defined in RFC 8785. As a result, it cannot be reliably used for token signing or signature verification, since JSON objects with the same semantic content can be serialized in different key orders. For example:

{ "a": 1, "b": 2 }
{ "b": 2, "a": 1 }
Although these two representations describe identical data, their serialized byte forms differ. This discrepancy can cause signature validation failures - particularly in cross-language environments where tokens are generated in one language (e.g., JavaScript, Python, or PHP) and verified in Go.

To ensure interoperability and security, the library should follow the canonicalization rules described in RFC 8785. At a minimum, object keys should be consistently sorted prior to serialization.

Implementing JCS or providing an option to enable canonical encoding would significantly improve the library’s reliability for cryptographic operations and multi-language compatibility.

Description

This library currently does not implement the JSON Canonicalization Scheme (JCS) as defined in RFC 8785. As a result, it cannot be reliably used for token signing or signature verification, since JSON objects with the same semantic content can be serialized in different key orders. For example:

{ "a": 1, "b": 2 }
{ "b": 2, "a": 1 }
Although these two representations describe identical data, their serialized byte forms differ. This discrepancy can cause signature validation failures - particularly in cross-language environments where tokens are generated in one language (e.g., JavaScript, Python, or PHP) and verified in Go.

To ensure interoperability and security, the library should follow the canonicalization rules described in RFC 8785. At a minimum, object keys should be consistently sorted prior to serialization.

Implementing JCS or providing an option to enable canonical encoding would significantly improve the library’s reliability for cryptographic operations and multi-language compatibility.

Interesting point. Do you know if Go has already built in support for that? I would avoid implementing this on our own. We basically take the JSON payload as we get it from the JSON encoder and don’t really modify it.

[stalniy]

In this repo, you can find links to implementations in different languages. It also has Golang implementation.

[oxisto]

In this repo, you can find links to implementations in different languages. It also has Golang implementation.

Unfortunately we do have a strict no dependencies rule in this repo so relying on a third party code is not an option for us. We do have some considerations about external JSON libraries but we are sort of stuck on this PR since it mutated into something unmaintainable.

The easiest way to achieve what you want is to provide a custom JSONEncode function for a custom claims structure and then call the transformer in this. This should be fairly straightforward.

Thinking about this some more: Can you expand how non-canonical payload would hinder signature validation. Yes different payload that is semantically the same produces different tokens, but you should not really rely on the final token format but do proper cryptographic validation based on the signature / key material.