[S2S] Potential edge cases in S2S profile regarding E2E encryption and nonce audience binding

While reviewing the new Server-to-Server (S2S) profile draft, we may have noticed a potential edge case regarding the E2E encryption mechanism between the Wallet Client and the Issuer. The text mentions that the Wallet Client creates an encryption key and signs it with the WSK, but in the /credential/get endpoint schema, walletEncryptionKey is passed as a KeyData object without a mandatory signature field or explicit issuer validation steps. When we modeled this architecture in ProVerif, the results suggested that a compromised or semi-trusted Wallet Server could silently substitute this public key with its own, potentially allowing the intermediary to decrypt the credential and bypass the E2E confidentiality goals. Could there be a missing mandatory cryptographic binding or signature validation step in the schema to prevent this?

Additionally, we observed a similar potential behavior with the replay protection mechanism in the /verification/initiate endpoint. The Wallet Client signs a Wallet Server-generated sessionId to produce the verificationNonce, but this signature doesn't seem to include an explicit audience binding (such as the target Issuer's URL). Our ProVerif model indicated that an untrusted Wallet Server might be able to trick the client into signing a sessionId and then replay this valid signature to initiate a session with an entirely different, legitimate Issuer. We were wondering if incorporating an explicit audience claim into the signed payload might be considered to prevent such cross-issuer replay attacks?

Read the S2S profile draft sections for /credential/get and /verification/initiate, focusing on the walletEncryptionKey KeyData schema and the signed verificationNonce payload. Compare those requirements with the reported ProVerif model results. Done means determining whether mandatory key-signature validation and issuer audience binding are specified clearly enough to prevent the described attacks.