Management of opt-out with Implicit consent (legitimate Interest)

[sebdewet]

Problem description In the "CAMARA APIs access and user consent management" documentation, only two scenarios are discussed on consent management: • Scenario 1: User consent is not required or consent is already given (Step 7). • Scenario 2: Consent is required and not yet provided by user (Step 8)

Note that for performance and environment reasons (Orange is internally challenged on environmental topics), Orange France currently manages the "error": "access_denied", at the /authorize level and not the /token. Having the client_id, the scope and the redirect_uri seemed enough to secure this access.

Possible evolution We would like to add the scenario of consent being revoked in order to standardize behaviour. It would seem that the scenario of a consent refused when collecting consent is presented on flow 12, but is not detailed in the explanatory text below the sequence diagram (besides the numbers of the stages do not correspond to those of the diagram)

Here is a simplified sequence diagram on consent management on flows 8 to 12 under implied consent with opt-out (see uml diagram)

[AxelNennker]

How about this sequence?

The mobile app would ask their own backend for an access token. The backend would do client credentials flow and get an access token. The mobile app does auth code flow with login_hint_token=access-token (with PKCE 🙂 ) on-net. the access-token proves that the client is allowed to do legitimate interest. The AZ then does the consent revoked check and returns consent_required error if revoked. Else return code to mobile app, mobile app gets access token, mobile app uses access token at RS

[sebdewet]

Hi @AxelNennker, not sure to understand the goal of your sequence. The purpose here was just to add in access and consent management the part where there is a legitimate Interest and to manage the revoked consent, in the existing flow.

You would like to get another way to manage the implicit consent with opt-out, different from the other way to collect consent ?

[jpengar]

@sebdewet In the past, it has been raised that since the consent check is done within the unauthenticated auth code stage of the Authorisation Code flow, if an error is returned to /authorize request, it would be possible to find out whether the user had consented to an operation or even had ever accessed another app. That would constitute PII leakage.

From Telefónica, we are fine to revisit the documented flow and consider your proposed evolution to include an error in the /authorize response when consent is not provided by the user, when it is provided (opt-in) but then revoked (opt-out), or in the case of, as you suggest, an implicit consent scenario (such as legitimate interest), when consent is then revoked by the user (opt-out).

And to address potential PII leakage and protect the "/authorize" endpoint, we suggest using RFC9101, as we also proposed in https://github.com/camaraproject/IdentityAndConsentManagement/issues/128#issuecomment-1964442751

[jpengar]

@sebdewet In the past, it has been raised that since the consent check is done within the unauthenticated auth code stage of the Authorisation Code flow, if an error is returned to /authorize request, it would be possible to find out whether the user had consented to an operation or even had ever accessed another app. That would constitute PII leakage.

From Telefónica, we are fine to revisit the documented flow and consider your proposed evolution to include an error in the /authorize response when consent is not provided by the user, when it is provided (opt-in) but then revoked (opt-out), or in the case of, as you suggest, an implicit consent scenario (such as legitimate interest), when consent is then revoked by the user (opt-out).

And to address potential PII leakage and protect the "/authorize" endpoint, we suggest using RFC9101, as we also proposed in #128 (comment)

@sebdewet et all, any feedback on the above proposal? This is one of the issues we need to address as part of the Fall24 meta-release. If you like, and if it helps, I could incorporate the suggested changes into the flow. Would that be ok with you to resolve this issue?

But we should also discuss whether we need the support of RFC9101 to cover the potential PII leakage scenario reported by Vonage in the past. The decision to support of RFC9101 is also related to Issue #128.

[sebdewet]

I thought that we would have to resolve first the #128 before discussing about this subject ?

[jpengar]

I thought that we would have to resolve first the #128 before discussing about this subject ?

@sebdewet See my proposal in #170 for at least see if we can close issue #138 discussion and leave RFC9101 decision to be resolved as part of the #128 resolution.