Clarification about passing issuer and authorization server state

Authorization Code flow defines an issuer_state parameter that is to be sent back by the Wallet to the AS in an Authorization Request and Pre-Authorized Code flow defines a pre-authorized_code parameter to be sent back by the Wallet to the AS in a Token Request.

issuer_state: OPTIONAL. String value identifying a certain processing context at the Credential Issuer. A value for this parameter is typically passed in a Credential Offer from the Credential Issuer to the Wallet (see Section 4.1). This request parameter is used to pass the issuer_state value back to the Credential Issuer.
pre-authorized_code: REQUIRED. The code representing the Credential Issuer's authorization for the Wallet to obtain Credentials of a certain type. This code MUST be short lived and single use. If the Wallet decides to use the Pre-Authorized Code Flow, this parameter value MUST be included in the subsequent Token Request with the Pre-Authorized Code Flow.

While it seems logical that the pre-authorized code is handled by the AS, it is not so obvious why the issuer state is to be sent to the AS in an Authorization Request instead of to the Issuer itself.

Also, it is surprising that there is no way for the Issuer to provide an issuer_state in the Pre-Authorized Code flow. One could think of the pre-authorized code as a handle to some kind of a pre-authorized Authorization Request that itself holds an issuer state, but the spec makes no mention of this and the way for the Issuer to obtain the code is unspecified.

I think the state references carried through Credential Offer parameters should be clarified and reworked:

• The Issuer State:
  • should be usable in both Authorization Code and Pre-Authorized Code flows,
  • should become a parameter of the Credential Offer,
  • should be made an optional parameter of the Credential Request,
  • should be removed from the Authorization Request,
  • should be used solely by the Issuer to retrieve some internal state relative to a specific Credential Offer, independently of the Authorization flow.
• The Pre-Authorized Code:
  • should remain as-is in the Credential Offer and the Token Request,
  • should be used solely by the Authorization Server to retrieve the Authentication context required to issue a Token Response,
  • should be issued to the Issuer by the Authorization Server, by means remaining out of scope of this specification.

Maybe this would clarify and separate the roles of the AS and the Issuer.

Start by reviewing the OpenID4VCI sections cited in the issue for Authorization Code, Pre-Authorized Code, Credential Offer, and Credential Request handling, then read the discussion thread. Done requires a maintainer decision on the issuer-state and pre-authorized-code semantics and corresponding specification updates.