Refactor ClientAttestation JWT provisioning when ClientAuthentication.AttestationBased is used

[dzarras]

Closes #525

[dzarras]

@babisRoutis, @vafeini Could you take an quick look and provide initial comments?

This PR currently targets main but introduces breaking changes. We must consider which branch this refactor should land in. Currently release/0.11.0 contains changes related to TS3. Would it make sense to target release/0.11.0?

[dzarras]

@babisRoutis, @vafeini PR now targets release/0.12.0 and is ready for review.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[babisRoutis]

@vafeini , @dzarras

I have a specific change in mind, but I am not sure if we should implemented to this PR

The idea is to drop totally support for other client authentication methods besides ABCA.
Reason for this drastic change is the following:

Normally, DPoP is an orthogonal feature with regards to an Client Authentication Method. That is, they are unrelated.
This "normal" case is reflected to the our VCI Configuration.

On the other hand, we have some strong "signals" that this won't be the case for EUDIW.

• For starters there would be TS3 v1.5.1, and
• There would a next ABCA version

Both of these, contain the same requirement that puts a strong relation between ABCA and DPoP:

• The Client Instance Key is allocated per Authorization Server (protecting a Credential Issuer)
• The Client Instance Key is included to the Client Attestation JWT (or WIA), under cnf.jwk
• The private material of Client Instance Key, signs the Client Attestation PoP JWT
• The same is true for the DPoP.

This means, that DPoP configuration and ABCA can no longer remain independent of each other, to the configuration of our library.

Alternatively we may seek a solution in between. Effectively I see two options

Option 1:

• Support exclusively ABCA
• Unify Client Attestation PoP and DPoP options (under ABCA)

Option 2:

• Unify Client Attestation PoP and DPoP options (under ABCA)
• Keep the top-level DPoP options
• If ABCA, require empty top-level DPoP options (because ABCA will be used)
• If not ABCA, make the top-level options relevant

Let's discuss it please

[dzarras]

@vafeini , @dzarras

I have a specific change in mind, but I am not sure if we should implemented to this PR

The idea is to drop totally support for other client authentication methods besides ABCA. Reason for this drastic change is the following:

Normally, DPoP is an orthogonal feature with regards to an Client Authentication Method. That is, they are unrelated. This "normal" case is reflected to the our VCI Configuration.

On the other hand, we have some strong "signals" that this won't be the case for EUDIW.

• For starters there would be TS3 v1.5.1, and
• There would a next ABCA version

Both of these, contain the same requirement that puts a strong relation between ABCA and DPoP:

• The Client Instance Key is allocated per Authorization Server (protecting a Credential Issuer)
• The Client Instance Key is included to the Client Attestation JWT (or WIA), under cnf.jwk
• The private material of Client Instance Key, signs the Client Attestation PoP JWT
• The same is true for the DPoP.

This means, that DPoP configuration and ABCA can no longer remain independent of each other, to the configuration of our library.

Alternatively we may seek a solution in between. Effectively I see two options

Option 1:

• Support exclusively ABCA
• Unify Client Attestation PoP and DPoP options (under ABCA)

Option 2:

• Unify Client Attestation PoP and DPoP options (under ABCA)
• Keep the top-level DPoP options
• If ABCA, require empty top-level DPoP options (because ABCA will be used)
• If not ABCA, make the top-level options relevant

Let's discuss it please

I would tackle this in a separate PR to reduce the churn.

Given the library takes an EUDIW direction, I would go with Option 1.
Is there an EUDIW use-case where Option 2 could be applicable? (i.e. AuthenticationMethod.None + DPoP)