Agreed conclusion statement about auth method in Auth Code Flow

[jpengar]

What type of PR is this?

• documentation

What this PR does / why we need it:

This PR includes a statement explaining the conclusion reached in #215 in the profile document as part of the Spring25 meta-release to make it 100% clear. As agreed here.

Which issue(s) this PR fixes:

Fixes #215

Special notes for reviewers:

N/A

Changelog input

 Added a concluding statement about the authentication method required in the Auth Code flow.

Additional documentation

N/A

[diegogonmar]

LGTM

[murthygorty]

Looks great to me too, thank you!

[AxelNennker]

A question to clarify:

After this is merged the following request is still valid, right? Note the "prompt=consent".

GET /authorize?
    prompt=consent
    &response_type=code
    &scope=openid%20dpv%3AFraudPreventionAndDetection%20sim-swap%3Acheck%20sim-swap%3Aretrieve-date
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: server.example.com

[eric-murray]

@AxelNennker
Yes, that request would still be valid.

But the API provider could still ignore the request to prompt for in-band end user consent if the legal basis for processing the request did not require it. The API consumer cannot force the API provider to seek end user consent when that is not required. Prompting a fraudster to approve a SIM Swap check would defeat the purpose of that API.

[AxelNennker]

@AxelNennker Yes, that request would still be valid.

But the API provider could still ignore the request to prompt for in-band end user consent if the legal basis for processing the request did not require it. The API consumer cannot force the API provider to seek end user consent when that is not required. Prompting a fraudster to approve a SIM Swap check would defeat the purpose of that API.

I don't think consent collection started by a request with "prompt=consent" is in-band.

You are right regarding sim-swap, my mistake. I copied the example from our examples document and added prompt=consent.

We have this template text:

In cases where personal data is processed by the API and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of three-legged access tokens is mandatory. This ensures that the API remains in compliance with privacy regulations, upholding the principles of transparency and user-centric privacy-by-design.

I assume, that in some legislation for sim-swap the end-user probably does not have a right to opt-out. I agree that opting-out somewhat defeats the purpose of the sim-swap API but API Providers have to follow the law and if the law grants the users the right to opt-out then we have to implement that. Whether the API makes sense is our problem.
I think for numberverification users have the right to opt-out in some legislation.
Or for some other API, which we sell with some legitimate-use purpose, but still the users have the right to opt-out.
Or, regardless, of API, the users might have the right to opt-out.

In cases where personal data is processed by the API and users can exercise their rights to grant consent or revoke consent, the use of three-legged access tokens is mandatory and the API consumer can trigger end-user consent management by using the request parameter consent with the value consent. This ensures that the API remains in compliance with privacy regulations, upholding the principles of transparency and user-centric privacy-by-design.

Example with fictional API where users can exercise their rights:

GET /authorize?
    prompt=consent
    &response_type=code
    &scope=openid%20dpv%3AAccountManagement%20privacy-respecting-api
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: server.example.com

[AxelNennker]

use API provider instead of operator

[AxelNennker]

Side note off-topic: @hdamker says that our repos should dismiss code-owner-approvals if an PR is changed. Non-code-owner approvals are untouched.

[jpengar]

This PR should be a mere formality, as the agreement on the issue itself has already been concluded. The purpose of this PR is to implement the conclusion that has already been reached. The PR does not mention the 'prompt' parameter, nor does it define anything beyond it. @shilpa-padgaonkar Could you please review it?

[eric-murray]

I don't think consent collection started by a request with "prompt=consent" is in-band.

The proposed text uses the term "in-band", but without definition. I had assumed "in-band" meant the mechanism specified here. If that is not correct, "in-band" should be defined, or replaced with a reference to that diagram.

Regarding purposes for which the legal basis is "opt-out" consent, if an end user has not opted-out, then they have consented, and no consent confirmation is required for the API execution to proceed. They must (somehow) be made aware that they have the right to opt-out, and there must be a mechanism to allow that, but that does not have to be a pop-up on their phone saying "You have the right to opt-out from this application requesting your personal information. Would you like to opt-out now?".

[murthygorty]

A little broadly, as a tenet, I'm thinking..

• whenever a client makes a request to a provider be it OIDC or CIBA, some of the metadata are requests/suggestions. API Provider will use their legal basis and internal requirements to drive their end-user experience.

I realize it is not a specific statement, but it might help us in looking at fields like prompt, login_hint etc. no?

[shilpa-padgaonkar]

Based on the comment from @jpengar that this text does not influence the prompt parameter, changes in this PR LGTM.

Things were clarified