search

italia / eudi-wallet-it-docs

Italian EUDI Wallet Technical Specifications
Creative Commons Zero v1.0 Universal
55 stars 18 forks source link

[Issuance] Proof of Possession of the public key in the PID #163

Closed peppelinux closed 6 months ago

peppelinux commented 10 months ago

During the continuous chat with NL collegues it was raised this issue:

If the PID is bound to a specific purpose key brought with the DPoP and the DPoP key is not attested by wallet solution (and then by Apple, Google ...) a bogus/hooked wallet instance may use a private key not stored in a secured environment.

The suggested approach is to use the holder key binding provided with the WIA and not some specific issued keys outside of the one attested by trusted third party.

fmarino-ipzs commented 10 months ago

I want to bring some useful points to the discussion:

  1. WIA generates the DPoP key pair, and the Wallet Solution MUST ensure the key management is secure enough. This is part of the capabilities that the Wallet Provider MUST attest.
  2. The PID Provider attests the new key after verifying the proof of possession of the key attested in the WIA.
  3. Even if the WIA is short-lived, there may be cases where more than one credential is required within the same request. This would lead to the fact that the credentials obtained would be bound to the same key (unlinkability issue?).
peppelinux commented 8 months ago

According to the impl experience we have in italy with openid4vci.

At the token endpoint the proof of possession of the client_assertion, containing the WTE with its proof of possession, is signed using the private key that is created during the setup phase to obtain the WTE.

For the DPoP we use different keys, for different scopes: The DPoP Proof JWT is signed using the private key for DPoP created by Wallet Instance for this scope.

We use the key binding of the credential using the public key related to the DPoP: The jwk value in the proof parameter MUST be equal to the public key referenced in the DPoP.

We believe that different keys must be used for different scopes and attestations. The DPoP is produced in a secure flow where the WTE is used in the authorization endpoint and with the token endpoitn as well, then a brand new key is used for the key binding of the issued attestation.

Having different keys for different attestation we solve the problem of the linkability/traceability of a PID with a WTE, where the WTE can be reused for the issuance of other attestations making these latter not linkable each other.