Consent URL API vs OIDC consent collection

[AxelNennker]

Problem description
Telefónica created a PR in API backlog regarding a new API named Consent URL.

It is DT's position that Consent URL API is not needed because at the same point in time Consent URL API would be used by the API consumer the API consumer can alternatively request an access token which also leads to consent being collected.

Possible Outcome

• Does ICM recommend creating a consent API?
• Do we need something else than an API?
• Do we need nothing?

Additional Considerations

• CAMARA identity and consent management is based on OIDC and CIBA.
• The OIDC parameter prompt is mandatory to implement by all OpenId providers.
• Delegated Consent should/must be avoided.
• Consent collection MUST be controlled by the API provider.
• Consent collection in done according to Section 3.1.2.4 of the OIDC Core 1.0 spec
• Regarding consent collection CIBA also refers to Section 3.1.2.4 of the OIDC Core 1.0 spec.
• It is important to remark that in cases where personal user 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 3-legged access tokens becomes mandatory. This measure ensures that the API remains in strict compliance with user privacy preferences and regulatory obligations, upholding the principles of transparency and user-centric data control.

[HuubAppelboom]

@AxelNennker What is missing in above list is the mangement of the consent, for which the API provider is responsible.
This should consist of showing the end user what consent has been given for which API consumer, at which date, for which purpose, including the exact details of the consent. The API provider is also responsible for providing the user an option to withdraw the consent, and this should be as easy as how the consent was collected. As soon as the consent is withdrawn, all processing of the personal data should cease immediately.

In the ideal case, the end user should only give once consent for a case, and the text presented to the end user should inform him about both the processing that the API Provider will do, and the processing the API Consumer will do. It will also need to specify the purpose, so the end user can make an informed decision.

If you combine the above with the current specification, there are several issues that can occur. To name a couple:

1. When the end user withdraws user consent (in the interface that the API Provider is offering), the API Consumer is not notified that the consent has been withdrawn, and he will continue the processing with the already shared data (which should stop if you ask me).
2. When the end user witdraws consent, the API Consumer is not aware, and will trigger the next consent question (again) when he calls the API again. For the end user this will look really weird, I have just witdrawn consent, and now I am asked the same question again ?
3. When the end user has a subscription which is terminated at the API Consumer, the consent issued in the past to the API Provider is still in the consent database with the API Provider. This data point should be removed, or at least it should be marked that the subscription does not exsist anymore (and the data point should be removed eventually). Currently there is no interface for the API Consumer to let the API provider know that the consent is no longer relevant, so this will lead to a lot of unnecessary pollution in this database.

What I think is necessary to solve this:

• the API Consumer must also be check the current status of any consent given in the past, so they can cease any processing they are doing based on the consent.
• the API Consumer must also be able to remove the consent (or signal that it is no longer required, or is withdrawn)

[HuubAppelboom]

Another complexity I see is when the API used at onboarding is different than the one used during the customer life cycle, or when there are more than one API used in the case

Take for example the case of a dentist, that wants to send appointment reminders by SMS to its customers. To make sure the number being used is correct, he wants to use Number Verification at onboarding. There should only be one consent question (which would be something like "Do you want to receive appointment reminders by SMS, and do you agree to verify your number with your provider"). This is a typical consent use case, and the consent given should be valid for both API's.

How would this look like in the case of the OIDC consent collection? Can this be supported without asking consent twice ??

[jpengar]

Problem description
Telefónica created a PR in API backlog regarding a new API named camaraproject/APIBacklog#67.

It is DT's position that Consent URL API is not needed because at the same point in time Consent URL API would be used by the API consumer the API consumer can alternatively request an access token which also leads to consent being collected.

Possible Outcome

Does ICM recommend creating a consent API?
Do we need something else than an API?
Do we need nothing?

I fully agree that an Authorization Code or CIBA authentication flow can be initiated at any time, depending on the use case and the application's capabilities, to capture consent. In fact, consent capture doesn't need to happen precisely when the API is consumed.

The key benefit of the Consent URL API is that it offers a significant advantage by enabling a fully decoupled, out-of-band mechanism for consent capture. This API allows the application to fully control the user experience (and I'm not talking about the look and feel of the consent capture page here, which would be provided by the Operator). The application can generate a consent URL from the Operator, which the user must authenticate with. However, the application has the flexibility to deliver this URL to the user through the most appropriate channel or medium, tailored to the user's current context.

Importantly, this API does NOT delegate consent capture to a third party but rather empowers the third party (the application) to present the Operator's consent capture URL at the most opportune time and place. The actual consent capture occurs within the Operator's secure environment, ensuring the user's authentication with the Operator.

In uses cases for CAMARA, the Authorization Code flow has been defined to be used with network authentication (a.k.a. silent authentication), where user interaction was minimal. Partners have often raised concerns about the user experience, especially when the user is directed to an Operator portal for authentication or consent within the Authorization Code flow. Furthermore, the Authorization Code flow assumes the availability of a front-end device for the user, which isn't always the case.
While CIBA does provide an out-of-band method for user authentication and consent capture, it relies on the Operator reaching out to the user through channels under the Operator’s control, like SMS or push notifications (If the Operator Management application exists and is available to the target user). This approach can be limiting.

The Consent URL API adds a layer of flexibility to the consent collection process, allowing applications to integrate and customize the consent experience more seamlessly without intending to replace existing CAMARA OIDC flows. Instead, it enhances these flows by providing more options for when and how consent is captured.

[jpengar]

Additional Considerations

• CAMARA identity and consent management is based on OIDC and CIBA.

👍agree

• The OIDC parameter prompt is mandatory to implement by all OpenId providers.

👍agree

• Delegated Consent should/must be avoided.

👍100% agree. Consent URL API is not intended to delegate consent as explained above.

• Consent collection MUST be controlled by the API provider.

👍agree

• Consent collection in done according to Section 3.1.2.4 of the OIDC Core 1.0 spec

That's what's currently defined for Auth code Flow, yes. But Consent URL API would be an analogous procedure triggered independently of Auth Code Flow itself (or CIBA).

• Regarding consent collection CIBA also refers to Section 3.1.2.4 of the OIDC Core 1.0 spec.

Same. 👍agree

• It is important to remark that in cases where personal user 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 3-legged access tokens becomes mandatory. This measure ensures that the API remains in strict compliance with user privacy preferences and regulatory obligations, upholding the principles of transparency and user-centric data control.

👍agree

For me it is not about "Consent URL API vs OIDC consent collection" but "Consent URL API + OIDC consent collection"

[AxelNennker]

Why not just use the following OIDC authoriztation code flow request?

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

[sebdewet]

Hi, @jpengar could you provide a diagram for this API consent url ?
Is a use case could be to ask the user the consent before iniating a CIBA callflow ?

[AxelNennker]

During the TSC meeting we agreed that we should have a deadline for this ICM discussion, and that deadline would be the next ICM meeting.
I guess if we still don't agree then this goes back to TSC to decide what to do with this API proposal.

[AxelNennker]

Hi, @jpengar could you provide a diagram for this API consent url ? Is a use case could be to ask the user the consent before iniating a CIBA callflow ?

The API consumer can use OIDC authorization code flow to ask for consent even if they plan to use CIBA later.
The consent record would be registered in the API provider's consent DB.

Even for a CIBA-only API provider following the OIDC standard is a good idea, I think.

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

[jpengar]

Hi, @jpengar could you provide a diagram for this API consent url ? Is a use case could be to ask the user the consent before iniating a CIBA callflow ?

CC @jgarciahospital

@sebdewet In the API proposal to the API backlog, Jorge shared some slides describing potential uses cases: camaraproject/APIBacklog#67 (comment)

As shared offline, new slide set with detailed explanation and user stories has been included in this PR.
Out of Band Consent Capture URL v2

As mentioned in #224 (comment), the proposed Consent URL API provides a decoupled out-of-band mechanism for consent capture, enabling the API consumer to initiate a consent capture procedure at any time, including before obtaining an access token with OIDC/CIBA. This would be a standardised CAMARA consent capture procedure, complementary to OIDC and CIBA.

[jpengar]

Why not just use the following OIDC authoriztation code flow request?

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

As previously stated in #215 (comment), the current CAMARA definitions only consider network-based authentication in the Authorization Code Flow. In response to your proposed OIDC request with prompt=consent, CAMARA does not prevent the Operator from using additional authentication methods to authenticate the user who owns the network-authenticated device as part of the in-band consent capture process when consent is needed. However, network-based authentication will still be carried out. In the event that the user authenticated in the consent capture process does not correspond with the network-authenticated device, the authentication server must return an error. Therefore, this will require the execution of your proposed request from the user's consumption device. The consent URL API provides the flexibility to present the obtained consent URL in the optimal location for the user at that time.

[shilpa-padgaonkar]

DT's View on the Consent URL

The ICM working group was tasked with discussing and reaching a consensus on the consent URL issue. As part of this discussion, the group sought to address an underlying issue: "Is the auth code flow restricted to using network-based authentication?" This restriction was cited as one of the reasons why a consent URL is necessary.

DT believes that if the rationale for supporting the consent URL is that Camara restricts the auth code flow to network-based authentication, the focus should be on removing this Camara-induced limitation, while ensuring interoperability through clear and specific guidelines. Addressing this issue would be the first step towards a potential solution for the problem in line with the OIDC standards. However, current discussions on this matter are stalled, and we continue to affirm the existing restriction.

If the proposal suggests that the Consent URL is an additional mechanism to capture consent, DT sees the following issues:
Since the proposal involves consent, which is required by most Camara APIs, it must be a solution widely accepted to avoid fragmentation (eventually implemented by all operators). In such cases, Camara has consistently adhered to standards, as we cannot place the burden on all operators to implement solutions that deviate from the originally accepted standards.

Some examples of these decisions include:

• Not allowing "purpose" to be a custom request parameter.

• Modelling complex purpose-scope combinations were postponed, until they could possibly be designed using an accepted standard like RAR (Rich Authorization Request).

DT would actively support any solution that is part of an established standard or developed in collaboration with the OIDF (OpenID Foundation). However, we currently believe that the Consent URL proposal introduces a mechanism that is not part of the accepted standards in Camara. We are concerned that this approach may lead to fragmentation and interoperability challenges.

[AxelNennker]

I do not agree with

However, network-based authentication will still be carried out. In the event that the user authenticated in the consent capture process does not correspond with the network-authenticated device, the authentication server must return an error.

With the exception of NumberVerfication that explicitly identifies the device being used, all other APIs can be handled by the CSP in a way that the API provider does all it can to satisfy the API Consumer's needs.

Number Verification API performs real-time checks to verify the phone number of the mobile device being used to access a service provider (SP) service

This API provides the customer with the ability request and receive the information for a particular user, which on file (and verified) by the user's Operator in their own KYC records, in order for the SP to confirm the accuracy of the information and provide a specific service to the user.

Network-based authentication is a convenience function in KYC fill-in.
Why should we deny an authorization code flow off-net if the user authenticates and gives their consent and we send the information for the particular, authenticated user?

[AxelNennker]

@diegogonmar During the TSC meeting on 2024-12-05 you seem to put the focus of Consent URL API on scenarios that include a Target Device.

For a target device with no input-output capabilities (e.g. dog tracker with SIM) I imagine the following scenario.

• user buys target-device from vendor
• user buys target-device in MNO-shop in person and shop-agent adds target device to user's MMO account for which the user knows their MNO-login-credentials
• At home user visits vendor's website and creates a user account their
• user enters the target-device's phone number into vendors site
• The vendor's website redirects the user's browser to the aggregator's website starting an OIDC authorization code flow with signed request = {
  "prompt": "consent",
  "login_hint": "tel:<MSISDN-of-target-device>",
  ... scope, redirect_url, client_id, response_type, ...
  }
• The aggregator redirects to the MNO's authorization server
• The user authenticates using their MNO-login-credentials
• The MNO asks for consent for CAMARA DeviceLocation API for the MSISDN-of-target-device
• The user consents
• The MNO creates a OIDC code
• MNO redirects back
• API consumer gets code and retrieves access token
• vendor's website uses it to track the target device

[murthygorty]

FWIW, I too do not believe that we need a separate consent URL mechanism. Operators should be able to lean on existing 3-legged user-present user-absent flows to gather consent from subscribers.
cc: @gmuratk @mengan @RamTMO

[diegogonmar]

Thanks for example @AxelNennker, quite useful. The agreement in TSC was to move forward to create a focussed sub-team within ICM to discuss the most optimal solution. I understood that DT will evolve and enter into details of the OIDC based solution, right?

Your bullet list is fine, we need to enter into details. Few challenges were raised time ago, when talking about network auth: #215 (comment). Sadly no answer was provided, so those points were not addressed in that discussion, and some apply to the bullet list provided. Maybe you can elaborate a solution giving answer to those points.
Below I comment a couple of aspects regarding you example, you can check that some were already included in the challenges of the other thread

Regarding:
The vendor's website redirects the user's browser to the aggregator's website starting an OIDC authorization code flow with signed request = {
"prompt": "consent",
"login_hint": "tel:",
... scope, redirect_url, client_id, response_type, ...
}
The aggregator redirects to the MNO's authorization server
The user authenticates using their MNO-login-credentials

You propose login_hint to be something more than a hint but a "must authenticate user owner of this msisdn?". If so, override happens only with prompt=consent? Does login_hint take precedence on network_auth in case of mismatch between network-authenticated MSISDN and the one provided in login_hint?
If login_hint sent and consent already given, token is issued without user/password authentication? Based on what rules?

All of this should be addressed otherwise there is no interoperability, as currently CAMARA ICM instructs Operator to perform network auth in AuthCode. This proposal seems to override that behavior, but unless clear rules are defined (when to be overriden, how?), there will be no interoperability.

Regarding:
API consumer gets code and retrieves access token

Is this token issued for the person that used their credentials (may own N msisdns) or for the msisdn set in login_hint? Location API that will be used for this example is device based, so token issued for a person is useless. If accepted is risky! because consent was given to a given MSISDN, if token is issued for a person, may call Location API with a different MSISDN. Maybe you propose token issued for msisdn, so login is done for the msisdn although user/password is forced to collect consent?

This can be solved, but the whole mechanism need to be defined, don't you think? There are plenty of grey zones, where each operator may act different, e.g.: ignoring login_hint is perfectly possible and makes sense in case of Network Auth default behavior

So, rather than having a high-level example, would you make a full proposal addressing these and other points/challenges that may arise? I would appreciate a solution proposal to properly iterate on the points to be solved, taking group decisions.