Secure issuance of pre-authorized code

The specification mentions the following:

The flow defined in this specification begins as the Credential Issuer generates a Credential Offer for certain Credential(s) and communicates it to the Wallet, for example, as a QR code or as a URI. The Credential Offer contains the Credential Issuer's URL, the information about the Credential(s) being offered, and the Pre-Authorized Code. [3.5. Pre-Authorized Code Flow]

While the specification does mention "This code MUST be short lived and single-use", it does not emphasize the criticality of the credential offer, and more specifically, the pre-authorized code, being delivered securely. The specification does offer an optional safeguard with tx_code, yet it is only recommended to send the Transaction Code via a separate channel.

I see the following issues with this content and wording:

1. Leaking the Credential offer compromises the entire flow and allows an attacker to retrieve the credential. This holds if none of the optional safeguards, such as tx_code, are in place. The specification fails to highlight the importance of a secure transmission.
   The specification does highlight the replay attack as an attack scenario: "prevent replay of this code by an attacker that, for example, scanned the QR code while standing behind the legitimate End-User". However, an attacker could also scan the QR code first, even if only standing behind the legitimate end-user. Furthermore, the specification does not highlight the severity of leaking the pre-authorized code.
   Finally, the wording frames the replay attack as the only attack vector. This does not hold true and should rather be listed as an example.
2. If the transaction code tx_code is sent on the same channel as the pre-authorized code, it adds no meaningful security guarantees.
   This nuance is not highlighted through the current text. Furthermore, the specification should either explicitly require that the tx_code be delivered over a separate, authenticated channel, or clearly warn implementers that sending both codes via the same channel defeats the purpose of the safeguard.

Start with sections 3.5 and 4.1.1 of the OpenID4VCI specification, including the existing pre-authorized code and tx_code guidance. Review how the text describes credential-offer delivery, replay, leakage, and separate-channel transmission. Done means the specification clearly explains the severity of leaking the offer or code and the security limits of sending tx_code on the same channel.