Fall24: ICM r0.2.0 clarification: Signed Request Object is optional

[mhfoo]

Problem description

Referring to ICM Issue 128 and 2024-06-19 ICM Minutes

The agreement was not to make signed request object as a mandatory requirement for CAMARA Fall24 meta-release, for the authorization code flow.

The signed request object is part of the OpenID Connect specifications, under section 6 Passing Request Parameters as JWTs and operators have the option to implement signed request object for the authorization code flow, as part of their security posture requirement.

In the CAMARA Fall24 meta-release, ICM r0.2.0, there are no explicit statements that mention signed request object are not allowed for the authorization code flow.

Context: For number verification in the fraud prevention and detection use case, we do not prompt the end customer (of the mobile service) for consent when auth code flow is initiated; consent is obtained prior. Hence it is "silent authentication" using network authentication.

I would like to clarify that the above understanding is correct. Please advise.

Expected action
Clarification from ICM working group, @jpengar @AxelNennker

Additional context
To clarify certification by GSMA for the auth code flows.

[jpengar]

Expected action
Clarification from @jpengar @AxelNennker

@mhfoo This is a working group, I think the expected action shouldn't be "Clarification from @jpengar @AxelNennker" 😅

The signed request object is part of the OpenID Connect specifications, under section 6 Passing Request Parameters as JWTs and operators have the option to implement signed request object for the authorization code flow, as part of their security posture requirement.

In the CAMARA Fall24 meta-release, ICM r0.2.0, there are no explicit statements that mention signed request object are not allowed for the authorization code flow.

This issue you report is related to #194, which discusses pretty much the same thing. Please take a look there (Auth code is also mentioned in the discussion, not just CIBA).
If #194 is enough, I would suggest not to have more than one issue for the same topic, or to have parallel discussions in more than one issue. Maybe we can close this one and finish the discussion of this signed request topic there.

[mhfoo]

@jpengar Thank you for reply.

I have updated the expected action to mentioned the ICM working group.

Please help to advise from your understanding. This is regarding the current documentation of ICM r0.2.0

I understand ICM r0.2.0 allow operators the freedom to implement sign request object for /authorize endpoint.

[jpengar]

@mhfoo IMHO, the problem we have with signed auth requests (and possibly with other features of the OIDC standard) is that since the CAMARA-Security-Interoperability.md does not provide any specific guidance nor limitation, it is left open to interpretation of the OIDC standard whether an API provider needs to implement both unsigned and signed requests.

In the ICM 28/08 meeting minutes you can see how different WG participants had different opinions.

In the end, the API consumer is affected by this uncertainty, because the API client would have to implement both options (signed and unsigned), since potentially some API providers could mandate signed requests (if they have security requirements to do so) and others might not have implemented it. This affects interoperability.

In the end, the OIDC profile should be updated to add a clear statement on this issue, describing whatever final decision we make in the working group on whether or not to mandate signed request.

[mhfoo]

@mhfoo IMHO, the problem we have with signed auth requests (and possibly with other features of the OIDC standard) is that since the CAMARA-Security-Interoperability.md does not provide any specific guidance nor limitation, it is left open to interpretation of the OIDC standard whether an API provider needs to implement both unsigned and signed requests.

In the ICM 28/08 meeting minutes you can see how different WG participants had different opinions.

In the end, the API consumer is affected by this uncertainty, because the API client would have to implement both options (signed and unsigned), since potentially some API providers could mandate signed requests (if they have security requirements to do so) and others might not have implemented it. This affects interoperability.

In the end, the OIDC profile should be updated to add a clear statement on this issue, describing whatever final decision we make in the working group on whether or not to mandate signed request.

@trehman-gsma 👆🏻

[jpengar]

@mhfoo The existing situation for Fall24 should be clear from the comments above. Do you think we can close this issue now and work on a solution for Spring25 (#194 & #205)?