Validation of dpop_jkt on PAR endpoint

[pey-lun-hsieh-gt]

I realised that dpop_jkt parameter, while accepted on PAR, is not validated if provided on its own without DPoP header? Is that intended and why?

Because by the specs, one can provide either dpop_jkt parameter OR the DPoP header. So if only the former is provided, we should validate the value early instead of leaving the validation to later at Token endpoint?

[panva]

I realised that dpop_jkt parameter, while accepted on PAR, is not validated if provided on its own without DPoP header?

dpop_jkt is validated at the PAR endpoint to match the DPoP Proof JWT's jwk thumbprint, what other kind of validation do you think is needed when only dpop_jkt is provided?

[pey-lun-hsieh-gt]

Hi! Thank you for the really quick response! Understand that we need the presence of DPoP in the header to validate if the dpop_jkt value is correct cryptographically.
What are your thoughts on performing syntactic validation of the dpop_jkt value at this point? E.g. type, length. Do you think it will be meaning here for early feedback?

[panva]

Since it's ultimately going to be rejected at the Token Endpoint I don't find it's early validation to be 43 base64url-alphabet characters meaningful.

[pey-lun-hsieh-gt]

Got it! Thank you!