Signing and encryption key Wallet -> Issuer flow (PID): proof of possession context

[AniaAlex]

@mikaelfrykholm @slistrom

Concepts of Signing and Encryption

Proof of possession

wallet -> issuer: wallet ephemeral key for encryption: valid per session:

"Wallet": send me some secret data and here is my ephemeral key to encrypt the message you will send me back. I store it in my db and it is valid for this session, when i receive the data from you, I expect it to be ENCRYPTED with THIS ephemeral key: public part of it. In addition, I am SIGNING the response token with my long term Private key and set the kid in the header so you can validate MY SIGNATURE.

"Issuer": ok , i am ENCRYPTING the data with your key and set it in cnf attribute to show WHAT key i have used to ENCRYPT the message. When you receive the message, you can use your EPHEMERAL private key to decrypt the data and make sure that I used for this the EPHEMERAL key you expected from me. In addition, i am SIGNING the token with my long term private key and set it in the header so you can validate the signature.

So basically in all openid4v the party that INITIATES the request sends the ephemeral key for ENCRYPTION?

@masv3971 @matskramer is this understanding correct?

or it is binding only? meaning: including the key into cnf parameter is enough?

https://datatracker.ietf.org/doc/html/rfc7800#section-3

if this is binding only i assume the further steps:

1. JWT with cnf claim is received by verifier;
2. Verifier extracts the public key;
3. Verifier sends a challenge;
4. Wallet signs the challenge with their private key sends back to verifier;
5. Verifier verifies the signature against the key in cnf;
6. If valid → proof of possession confirmed