[client_assertion_pop] JWTs concatenated and separated by ~ vs self-explanatory parameter names

[peppelinux]

In the current solution under development in Italy, the debate on the use of this wonderful draft has been alive for months.

From the experiences and positions collected there seems to be a general refusal to recognize as "beautiful" the concatenation of JWTs divided by the ~ character within the client_assertion parameter.

For those who don't know, the crime of ugliness does not yet exist in Italy but there is great sensitivity in the search for beauty even in implementations.

There are alternative ways to proof the PoP, like DPoP. Unfortunately convey large JWT in a HTTP header like DPoP may have impacts on the tuning of the httpd services that would require a specialized configuration to allow http headers larger than 4KB. This has relevant impacts in the cases where a JWT carries x5c or Federation trust chains within its headers, where a JWT could be more than 4KB.

Even if there are other specs that uses concatenation of JWTs using ~ as separator char, like SD-JWT. However SD-JWT tends to be self-contained artifact, general purpose and agnostic from the way it is transported. Then I'd tend to leave out SD-JWT from this thread.

Considering that this draft aims to extend RFC7521, I'd suggest to not use the concatenation two JWTs using ~ but the definition of a new parameter, that we may call client_assertion_pop to convey the client attestation PoP. This proposal suggests a good semantic with self-explanatory parameter names, in a modular way that aims to extend RFC7521 with explicit parameters as additional modules, that may be used where PoP is required.

[bc-pi]

[Giuseppe asked for my thoughts]
RFC7521 largely only envisioned a single assertion so building on it for the intended functionality of this draft isn't a perfect fit. The current approach of the client_assertion parameter value having the two tilde separated JWTs is fine, though, in my opinion. And I don't believe that defining new parameter for the Client Attestation PoP JWT would be a material improvement.

[peppelinux]

Then you definitively suggest to detect the client_assertion value format by filter with the client_assertion_type

[bc-pi]

Yeah, the value of the client_assertion_type is intended to indicate the format (and other aspects) of the client_assertion value.

[peppelinux]

Since an agreement was found about the adoption of the current specs as they are and without requesting any breaking change, this thread doesn't represent an issue anymore. Here the related PR that uses this specs as it is in the it wallet