- edited description
op_state in pre-authz
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 whenpre-authorized_code
is present
I’m surprised why op_state
MUST 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.
Comments (8)
-
reporter -
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.
-
I am ok with removing
MUST NOT be used in Authorization Code flow when
pre-authorized_code
is present
-
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.
-
- changed status to open
-
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).
-
I think this should be solved alongside
#1734 -
- changed status to resolved
PR #373 merged
- Log in to comment