Controlling User Interaction #228
Conversation
There was a problem hiding this comment.
IMHO the PR content is not aligned with our conclusion proposal in #215 (comment).
- It is up to the operator to make a decision when consent collection is needed or not,
- based on the scope(s)/purpose declared by the API client and aligned with local legislation, ensuring that all operators under the same regulatory framework adopt a consistent approach.
- Currently, CAMARA only considers network-based authentication in the Authorization Code Flow. Therefore, access tokens are issued for the network authenticated identifier.
- CAMARA does not prevent the telco/MNO/API producer from using additional authentication methods as part of the in-band consent capture process when consent is needed.
I miss the second and third bullets. The information in the PR is fair, but generic, so I don't see how it fixes #215, which specifically refers to the authentication method in the auth code flow.
|
This a two part PR please see #228 that hopefully leads to a consistent approach. |
|
While I am generally in agreement with the information provided in this PR, I believe that this particular data does not address the issue raised in #215 or clarify the core problem being discussed in that thread. This provides additional clarification on user consent capture and prompt parameters usage. We may agree to include this clarification with specific wording in this PR, but I believe PR #229 is the most suitable for providing the required clarification on the Auth code flow and auth method for CAMARA, including the suggested conclusion in the profile document. |
Co-authored-by: Eric Murray <[email protected]>
Co-authored-by: Jesús Peña García-Oliva <[email protected]>
|
|
||
| It is up to the operator to make a decision when consent collection is needed or not, based on the scope(s)/purpose declared by the API Consumer and aligned with local legislation, ensuring that all operators under the same regulatory framework adopt a **consistent** approach. | ||
|
|
||
| The API Consumer can use the `prompt` parameter value `consent` to ask the API Provider for End-User Consent collection. |
There was a problem hiding this comment.
| The API Consumer can use the `prompt` parameter value `consent` to ask the API Provider for End-User Consent collection. | |
| The API Consumer MAY use the `prompt` parameter value `consent` to ask the API Provider for End-User Consent collection. |
|
|
||
| The `prompt` parameter is defined in [OIDC section 3.1.2.1](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest). | ||
|
|
||
| OIDC specifies that the `prompt` parameter is [mandatory to implement for all OpenId Providers](https://openid.net/specs/openid-connect-core-1_0.html#ServerMTI). |
There was a problem hiding this comment.
This sentence might be misleading for API consumers, as an API provider can "implement" support for prompt=consent simply by always returning an error and not seeking End User consent at all. Only prompt=none has any defined behaviour that the API provider MUST implement.
I would remove this sentence.
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
This PR repeats the CIBA and OIDC standards thus clarifying e.g. that prompt=none should be used if the API Consumer does not want user interaction.
User Interaction is controlled in OIDC by the authentication request parameter
promptwhich is mandatory to implement.Update: removed fixes
This PR was created to clarify part of the sub-topics discussed in #215
Update: Please see #229