fix: issuance PAR req jti

[peppelinux]

the PAR request is a JWS which its reuse (replay attack) must be prevented

This PR adds jti in the PAR request JWS

[asharif1990]

I forgot to add the JWS claims in the PAR request. However, the Nonce will provide the exact reply detection mechanism to avoid the PAR replay. In any case, we can have the "jti" as well as it is a good practice for the JWS. Probably, we can add the following missing headers of the JWS: "iss", "aud", "exp", and "iat".

[fmarino-ipzs]

nonce and jti parameters have different purposes. Typically the jti is chosen by the authentication server, while nonce is given by the client. Given this, we probably should add the nonce parameter instead of jti, am I missing something?

[asharif1990]

nonce and jti parameters have different purposes. Typically the jti is chosen by the authentication server, while nonce is given by the client. Given this, we probably should add the nonce parameter instead of jti, am I missing something?

So, as the PAR request is created and signed by the Wallet Instance, in this case, the Wallet Instance itself can add the jti parameter in the payload as well. The scenario that you are referring to is for the case of releasing ID Token and Access Token that are released by the server, so, in that case, the jti value will be set by the server.

[peppelinux]

@asharif1990 are you suggesting to use nonce instead of jti?

[fmarino-ipzs]

Sorry I was wrong about that, I meant to say use jti instead of nonce. The purpose of the nonce is to create a binding to a token as pointed out by @asharif1990 in the case of Access Token or ID Token. I'm not sure we really need the nonce here. The Access Token in our case is bound to the c_nonce parameter. The jti is for a replay attack. The only concern about this is that in this case it is difficult to have a collision resistant jti since it is given by the client. What do you think?

[asharif1990]

@asharif1990 are you suggesting to use nonce instead of jti?

I think nonce may provide the same countermeasure because it is transaction specific. However, the more standard way of doing it for the JWS is jti. my recommendation is to keep both.

[asharif1990]

Sorry I was wrong about that, I meant to say use jti instead of nonce. The purpose of the nonce is to create a binding to a token as pointed out by @asharif1990 in the case of Access Token or ID Token. I'm not sure we really need the nonce here. The Access Token in our case is bound to the c_nonce parameter. The jti is for a replay attack. The only concern about this is that in this case it is difficult to have a collision resistant jti since it is given by the client. What do you think?

I am totally okay with jti as I mentioned in the above comment. I think it shouldn't be a problem. If you are not using a problematic algorithm to create this random string, shouldn't be any problem.

[peppelinux]

following a chat with @fmarino-ipzs we agreed that we should investigate better what would be the impacts of a reply of that request

in this pr we have proposed jti as a mitigation following the BCP, but we didn't have any analysis about the implication or the impact of a reply attack in that endpoint.

there's the perception that we don't have any relevant risk due to a reply of that request, further analysis are required

[peppelinux]

Here my considerations

• jti Is not collision resistant and must be identified uniquely together with its issuer

• the nonce binds a request to a response

• an adversary should stay in the middle to intercept the request and hijack the victim to a different request_uri, in that case It simply replay the nonce since It Is well known during the auditing

This makes to me that jti aside with its issuer Is collision resistant and prevents that the request might be replayed

While the nonce is required when a request or any Response May be replayed, in particular when the transation is async and over different endpoints

[grausof]

LGTM