Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
sebdewet opened this issue Mar 12, 2024 · 6 comments · Fixed by #170
Closed

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

sebdewet opened this issue Mar 12, 2024 · 6 comments · Fixed by #170
Labels
enhancement New feature or request v0.2-candidate Custom label for issues that are candidates to be fixed in v0.2 (if needed)

Comments

@sebdewet
Copy link
Collaborator

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)

opt-out

@sebdewet sebdewet added the enhancement New feature or request label Mar 12, 2024
@AxelNennker
Copy link
Collaborator

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
Copy link
Collaborator Author

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
Copy link
Collaborator

jpengar commented Mar 26, 2024

@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)

@hdamker hdamker added the v0.2-candidate Custom label for issues that are candidates to be fixed in v0.2 (if needed) label May 8, 2024
@jpengar
Copy link
Collaborator

jpengar commented May 28, 2024

@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
Copy link
Collaborator Author

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

@jpengar
Copy link
Collaborator

jpengar commented May 30, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request v0.2-candidate Custom label for issues that are candidates to be fixed in v0.2 (if needed)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants