op_state in pre-authz

[Oliver Terbu]

The OpenID for CI spec currently says:

If the client receives a value for this parameter, it MUST include it in the subsequent Authentication Request to the Credential Issuer as the op_state parameter value. MUST NOT be used in Authorization Code flow when pre-authorized_code is present

I’m surprised why op_stateMUST not be used with pre-authz flow. Why do we need this normative text? In OpenID and OAuth2, normally additional parameters are ignored if not expected or understood. This could also apply to op_state in case of an pre-authz flow.

Can we remove the following sentence?

MUST NOT be used in Authorization Code flow when pre-authorized_code is present

Otherwise we should probably also define that this results in error.

[Torsten Lodderstedt]

I guess we should clarify that the request may contain both, `opstate` and `pre-authzorizedcode`, but each of them serves a purpose only with a certain request type. `op_state` is intended to be used with the authz request whereas `pre-authorized_code` is intended to be used at the token endpoint.

If the client sends pre-authz code to the authorization endpoint, the AS must ignore it (as you already described). This is covered by RFC 6749 already.

[Kristina Yasuda]

I am ok with removing

MUST NOT be used in Authorization Code flow when pre-authorized_code is present

‌

[Kristina Yasuda]

Torsten to do a PR, Kristina agreed op_state and pre-authorized code are used in different grants, but not both in the same flow.

I think we should clarify that the wallet must have a policy what to do when it receives both op_state and pre-authorized code.

We should also probably clarify that it is wallet’s proactive decision to send authorization request - if the Issuer does not receive authorization request, it would never know why - including when Issuer sent only either op_state and pre-authorized code, but the walelt only supports one.

[Torsten Lodderstedt]

The issuer may not know what wallet will receive the request thus cannot make any assumptions about its capabilities. If the wallet, for example, only supports the grant type code, it would need to perform an authorization request, even if the IIIR contains a pre-authorized code. Issuers wanting to support a broad variety of wallet might therefore consider to send both, pre-authorized code and op_state, in the same request (containing or referring the same data set).

[Kristina Yasuda]

I think this should be solved alongside #1734

[Kristina Yasuda]

PR #373 merged