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.

[AxelNennker]

I created #244 enabling API consumers to demand network-based authentication. API subprojects can make network-based authentication mandatory by mandating those parameters for that API.

I also suggest that APIs specify "prompt=none" if the do not want user-interaction.

NumberVerification currently assumes that OIDC authorization code flow with network-based authentication happens.
I think that API consumers of NumberVerrification MUST use prompt=none&acr_values=https://camaraproject.org/acr/networkbasedauthentication.

Please see also this issue in NumberVerification: camaraproject/NumberVerification#160

[AxelNennker]

I think we need consent for a future Consent URL API. Whether a User consented to an API is personal information in itself.
This gets us into a circular argument, right?
Has some Operator done a GDPR evaluation already?

Is the purpose of the request that gets consent for the Consent URL API the same as the purpose for the Consent URL API?

[Elisabeth-Ericsson]

Ericsson and Vonage support the idea of a consent info API which can be called by an application upfront to learn about the consent status for this application related to an MSISDN.
The API has one mandatory parameter - the MSISDN. Scope and purpose are optional.
The result of the API shall inform the application about the consent status for this MSISDN and also return a URL for consent capture.
The application can then evaluate the outcome and decide to bring up a consent capture dialog.
It is understood that such an API is similar to a NW API and thus might need user consent to be called.
Our proposal is to invoke the consent info API by applying a CIBA flow. I will add a sequence diagram to the discussion soon.

We do not think that going for an authorization code flow request with prompt = none or prompt = "consent" ONLY. It is not good enough to solve the majority of use cases. Reasoning is as follows:

1. If we decide to use the authorization code flow as one and only mechanism, then consequently ALL NW APIs will have to be called with auth code flow.
2. According to the standard, providing a prompt = consent forces the authZ server to bring up a consent dialog, whether there is sufficient consent or not.
3. FE flows will have lots of redirects and potentials for failure, especially if API market place/Developer portal and Aggregator are involved in the API invocation chain between ASP BE and ASP FE (sequence diagram will be added)
4. Very prominent use cases like device location for fleet management do not run the app on the target device of the API call. FE flow is therefore not suitable

We are not discarding an "in-flow" consent capture approach, where reasonable for the app, but ask to provide an additional optional option for an app to learn about the consent status and have the opportunity to bring up a consent capture dialog.

[AxelNennker]

regarding #215 (comment):

Take Telefónica as an example — Even though Telefónica supports other authentication mechanisms, they cannot yet be considered CAMARA-compliant because it’s not defined:

a) Should acr_values be ignored when using these other mechanisms? So far CAMARA defines that acr_values must be ignored under the previous assumption.
b) If another login method is applied, should I notify an aggregator or interoperable client so that "if Telefónica" scenarios manage the user experience (UX) accordingly?
c) How do I handle API calls involving the device object if the request does not include it, especially in cases of user/password authentication?
d) If the device connects via a mobile network, should I prioritize network-based login over other login methods? What happens if the network indicates MSISDN_A, but the user/password login shows MSISDN_B? Or if the user performs the user/password login on a device that does not belong to them?
e) Other login methods are valid (and necessary) when user consent needs to be captured, but they should always follow network-based authentication as a second step. This approach resolves point (d) because consent would be tied to the entity that performed the network-based authentication.

ad a) I created #244 to define ONE acr_value that allowes the API consumer to request network-based authentication.
Please comment on #244 I view that a first step.

ad b) I created #228 and #229 to define interoperable API consumer behaviour.
I think currently we should focus on NBA or not-NBA.

ad c) This is about the API request not a request to the AZ, just repeating this to state how I understand c)
If the OIDC ACF was used and NBA was done and end-user consent was collected, then the access token is associated with the subscription, regardless what end-user authentication was used. I think the end-user authentication method does not matter. The question is more which subscription is going to be associated with the access token, if network-authentication was NOT done. Some might think that this makes no sense, and I agree for some APIs it doesn't. But in the general OpenId-protected API it might and we must make sure that we agree on an interoperable AZ and consent collection behavior.

Questions:

• do we distinguish between private customer and business customers?
• do we return an error is we are not sure that the subscriber is the end-user? (age verification API, device location API tracking spouses, ...)
• ...

ad d) We have to define interoperable behaviour of the AZ.That also includes how to handle login_hint=tel:...
I suggest to define that if NBA was NOT done and the Operator launches consent collection then the value of login_hint should be "owned" by the end-user who authenticated and the consent should be associated with that telephone number.

ad e) Maybe, if the API requires NBA or if the API Consumer requested NBA. In OIDC ACF if consent is needed or requested the Operator can decide which device identifier the consent applies to.
If the end-user has exactly one contract with one device, the there is no problem. If the end-user has several contracts and several devices the Operator might allow the end-user to select one or use the login_hint to preselect one.

[Elisabeth-Ericsson]

Hi Axel,
I really think that we should separate the discussion on options for consent collection from the issue #244. these are connected but different topics.
One very important aspect we need to acknowledge is that if a FE flow is used (no matter which authentication method, network based or other) is chosen, we have a use case where User device ( UD) is equal to the target device (TD) of the upcoming API calls.
We cannot limit us to consent collection triggered from FE flows if we want to be able to understand the consent scenario for target devices which are NOT equal to the user device.

I want to take this from a generic use case perspective. My intention is to allow an app to learn about the consent status via a read operation executed on a CIBA flow. This is the consent Info API, Ericsson and Vonage are proposing. The result of this read operation should also indicate whether the Target Device named in the read operation is its own legal responsible. Then the app can judge whether it makes sense to bring up a consent capture dialog (if needed) or not.

Please let us ON PURPOSE do not mix the NBA discussion with this topic.

Using FE flow and NBA (or some other authentication) to learn the consent status is only feasible if UD = TD. This is what the FE flow is meant for in RFC 6749 independent of the authentication mechanism - at least this is my interpretation of the standard.

I do not neglect that for some use cases where UD = TD is definitively an option to use FE flow with prompt = none to check consent status. However, then the app would need to run the /authorize operation once again with prompt = consent to be redirected to the consent capture page. We (Ericsson/Vonage) do not think that this is a good user experience at all.

Can you please explain how we should solve use cases where UD and TD are not the same e.g. fleet management app using device location, find my pet, find grandma etc. using FE flows ?

[Elisabeth-Ericsson]

CAMARA ISSUE 224.pdf
The pdf file attached explains reasoning and need for 3rd option for consent collection. OIDC based consent collection is NOT enough to cope with use cases where user device (running the app) and target device of the API call are different.
Example for these use cases are: "Find my Pet", "Fleetmanagement".

[chrishowell]

1. Using tel: in a login_hint can cause a security issue where the ASP ships an auth code flow URL out to a device that has not provided the phone number thus potentially leaking additional personal data; CAMARA should not design a solution where this could happen.

2. Vonage fully supports the introduction of a Consent Info API to obtain the current consent status for an application and a given end-user; this API is vital for ASPs to prepare their UX for the use of Network APIs and efficiently make decisions server side.

3. As already stated above, the authentication code flow is currently positioned within the technical ruleset as the 'frontend flow' and should only be used when the API requires interaction with the target device - this is not the case for the vast majority of CAMARA APIs. Vonage does not want to see a proliferation of the authentication code flow, which is prohibitively slow.

4. The OIDC Authentication Code flow is intended to provide authorisation of an operation by the resource owner (the end user/mobile subscriber). In cases where the ASP wants to perform a pre-flight check for consent from their backend, or to obtain a consent collection URL to provide out-of-band consent capture (for example when the user first downloads the ASP's application, but the ASP is not yet intending to use any of the APIs), the authentication code flow is not appropriate - it is not designed to be called without the resource owner involved. The suggested approach of using prompt=none to test for consent and using a login_hint of a phone number, might theoretically provide a yes/no response for whether the CSP has a legal basis for allowing the call, but is an abuse of the authorisation code flow.

[HuubAppelboom]

Just to add to the discussion: we also have cases where there is simply no time to collect consent in the API Flow, because the end user is performing a transaction with for example a merchant, and the transaction needs to be finalized in 500 ms. If the user has not given prior consent for the API in question, the merchant would like to use a different method in stead, In the current flows the Telco always starts the consent collection in case consent has not been given in the past.

To enable these kind of flows, it is necessary that the merchants can see the status of consent before executing the API calls.

[AxelNennker]

Just to add to the discussion: we also have cases where there is simply no time to collect consent in the API Flow, because the end user is performing a transaction with for example a merchant, and the transaction needs to be finalized in 500 ms. If the user has not given prior consent for the API in question, the merchant would like to use a different method in stead, In the current flows the Telco always starts the consent collection in case consent has not been given in the past.

To enable these kind of flows, it is necessary that the merchants can see the status of consent before executing the API calls.

Those merchants can just send a request with "prompt=none" and they get back "consent_required" if it is required for the scope values/purpose.

If the user executed their rights to revoke consent, then the error consent_required must be returned in OIDC Authorization Code Flow.

If consent is required, then the API consumer get issue a OIDC Authorization Code Flow request with the same parameter but change the value of the prompt parameter from "none" to "consent".

What is the problem? The OIDC standards provides everything we need.

[HuubAppelboom]

@AxelNennker What about the CIBA flow? How would you indicate here that consent should not be gathered in the flow???

[Elisabeth-Ericsson]

To enable these kind of flows, it is necessary that the merchants can see the status of consent before executing the API calls.

I fully agree. This API is really meant to support exactly these use cases and allow an app to drive the consent collection in line with the needed user experience.

@axel: To understand your proposal correctly, I just repeat it here once again: You think that the only way for triggering consent collection is to do it from the FE flow. This means that

1. ALL APIs potentially subject to consent must be called via FE flow.
2. Only Use cases can be supported where user device and target device of API call are the same.

In addition we must be able to support use cases where user device and target device are different.

[AxelNennker]

@AxelNennker What about the CIBA flow? How would you indicate here that consent should not be gathered in the flow???

I think is not possible not to ask for end-user consent in CIBA without revealing the end-user's consent status for that API and scopes. Please see CIBA privacy #258

OIDC added user authentication and user consent to OAuth2, CIBA added backend initiated authentication and leverages the operators' ability to send an authentication message to the end-user's authentication device. This is an important asset operators have.

If CIBA does not send a message to the end-user's authentication device then CIBA degenerates to OAuth2 (two-legged flow) without User authentication and without user consent.

But ICM mandates three-legged access token if personal data is processed.

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.

It is not possible to indicate that consent should not be gathered in CIBA. Consent can even "not be checked" in CIBA prior to end-user authentication because "validate user identifier" can validate the format of the user identifier and whether that identifier "belongs" to the operator, but that step cannot and does not authenticate the User. Without user authentication there cannot be a consent gathering nor consent checking.

[HuubAppelboom]

@AxelNennker In the CIBA flow you can also trigger an out of band consent collection (for example by sending an SMS to an end user for a login to a site where the consent van be gathered).

Anyway, the current CIBA flow and Front End Flow are much too slow for case where the total processing time must be limited to 500 ms. That includes any other processing the merchant needs to do.

What would be a much better option is to be able to do a superfast <50ms check whether consent has been collected before entering a slow 3 legged flow. Especially because end users can also withdraw their consent through a selfcare portal of the telco to manage and withdraw user consent (which the merchant would not know).

[AxelNennker]

To understand your proposal correctly, I just repeat it here once again: You think that the only way for triggering consent collection is to do it from the FE flow. This means that

1. ALL APIs potentially subject to consent must be called via FE flow.

2. Only Use cases can be supported where user device and target device of API call are the same.

Ad 1)
With OIDC Authorization Code Flow we have standard that allows starting consent collection using prompt=consent. This OIDC ACF request can be send any time.

Consent Info status can be checked using and OIDC ACF request with prompt=none.

CIBA sends a message to the User's authentication device and user authentication and consent collection happen on the authentcation device.

So "no" to question 1. An API potentially subject to consent can use either OIDC Authorization Code (front-end flow) flow or CIBA (backend).

Ad 2)
CIBA was created to support where authentication device and consumption device are not the same.
The API provider gets a CIBA Authentication Request with e.g. login_hint=tel:MSISDN and then the API Provider send a message to the authentication device e.g.

• "<API consumer> is kindly asking that you grant your consent to . Please follow this link."
  "link" could be a OIDC Authorization Code Flow request with request_uri to save space in the message.
• "<API consumer> is kindly asking that you continue account creation on this mobile device. Please follow this link"

I guess the emphasis of 1) and 2) is on "target device", which you define in PR #256

With prompt=consent we have a standard Consent URL that can be called any time.
With prompt=none consent info/status can be checked at any time.
Why create something new?

What is missing from OIDC? What does a new API provide that OIDC does not provide?

[jpengar]

I think we need consent for a future Consent URL API. Whether a User consented to an API is personal information in itself. This gets us into a circular argument, right? Has some Operator done a GDPR evaluation already?

Is the purpose of the request that gets consent for the Consent URL API the same as the purpose for the Consent URL API?

@AxelNennker According to the assessment of Telefonica's legal team, the Consent URL API could be consumed on a "Legal Obligation" legal basis (without opt-in/opt-out) and would therefore meet the conditions agreed upon in CAMARA for an API to be consumed using 2-legged access tokens (Client Credentials grant).

[AxelNennker]

@AxelNennker According to the assessment of Telefonica's legal team, the Consent URL API could be consumed on a "Legal Obligation" legal basis (without opt-in/opt-out) and would therefore meet the conditions agreed upon in CAMARA for an API to be consumed using 2-legged access tokens (Client Credentials grant).

Can you share that legal review please?

[AxelNennker]

The simplest possible Consent URL API would always return the same Consent URL and would not need any client authentication at all, right? Maybe the client_id and redirect_uri would be based on the client_credentials

Consent URL API request:

GET /consenturl?state=af0ifjsldkj&scope="openid dpv:AntiFraud kyc:fill-in"
Authorization: Bearer ey...private_key_jwt

Consent URL API response:

HTTP/1.1 200 OK

https://host/authorize?prompt=consent&scope="openid dpv:AntiFraud kyc:fill-in"&client_id=s6BhdRkqt3&state=af0ifjsldkj&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

That implementation of Consent URL API does not include any personal data and no legal team would object to it.

[Elisabeth-Ericsson]

To Axel's comment above:

Ad 1) With OIDC Authorization Code Flow we have standard that allows starting consent collection using prompt=consent. This OIDC ACF request can be send any time.
Consent Info status can be checked using and OIDC ACF request with prompt=none.
CIBA sends a message to the User's authentication device and user authentication and consent collection happen on the authentcation device. ... So "no" to question 1. ........
With prompt=consent we have a standard Consent URL that can be called any time. With prompt=none consent info/status can be checked at any time. Why create something new?

What is missing from OIDC? What does a new API provide that OIDC does not provide?

For the use case of "User Device isNOTequal TargetDevice" you MUST not use OIDC Authorization Code Flow with prompt = none to check. This is simply not supported. The OIDC standard describes FE flow ONLY in the scenario where UD = TD.
Thus you cannot use OIDC Authorization code flow for checking if "User Device isNOTequal TargetDevice".

Regarding Axel's second comment:

The simplest possible Consent URL API would always return the same Consent URL and would not need any client authentication at >all, right? Maybe the client_id and redirect_uri would be based on the client_credentials

The Consent URL API must have MSISDN as input parameter, otherwise the system cannot determine the correct end point.
In addition, the Consent URL API is meant to return the consent URL only in case that consent for MSISDN & APP is missing. Only if this is the case, the consent URL will be returned.

[AxelNennker]

For the use case of "User Device isNOTequal TargetDevice" you MUST not use OIDC Authorization Code Flow with prompt = none to check. This is simply not supported. The OIDC standard describes FE flow ONLY in the scenario where UD = TD.

The OIDC standard does not know anything about devices.

In OIDC and CIBA the end-user authenticates and grants consent, or not.

Thus you cannot use OIDC Authorization code flow for checking if "User Device isNOTequal TargetDevice".

That depends how we specify how the the AZ treats the request parameters. As we did with "purpose as scope" CAMARA could define that login_hint=tel:MSISDN is treated as an indicator which device is probably the target device.
Currently we are quite restricted e.g. if the subscription identified by network-based authentication belongs to a subscriber with multiple contracts (e.g. Familiy use-case or business customer or ...)
It is currently undefined how the AZ reacts in these cases.
Some API providers might return an error, others might redirect to end-user authentication, consent collection. Consent collection can contain target device selection.

Example page after end-user authentication (with or without network-based authentication) single contract:
Dear <Firstname>,

<API Consumer> would like to locate your device <login hint value>.
Press OK if you grant consent. Press No if you won't allow this.

Example page after end-user authentication (with or without network-based authentication) multiple contracts:

Dear <Firstname>,

<API Consumer> would like to locate devices.

Please check the checkboxes of the devices:

• Dog Tracker with <MSISDN1>
• Spouse with <MSISDN2>
• Child with <MSISND3>

Please respect the privacy of these individuals.

Press OK if you grant consent. Press No if you won't allow this.

OpenId Connects assumes that the browser or webview might have access to Cookies reflecting the login-status at the OpenId Provider. "prompt=none" suggest to the OpenId Provider to use those Cookies.
That is one reason why e.g. AppAuth recommends to always use the system browser because the likelihood is good that the end-user is already authenticated to the OP.

Some CAMARA API require network-based authentication - e.g. NumberVerification
Others do not have that requirement.

[Elisabeth-Ericsson]

Hi Axel,
yes, I agree that OIDC does not talk about devices but clients. I used the terminology of devices for simplification. Please replace the terminology user device by "identification of the client running the app" or "identification of the endUser" and target device by "identification of the resource owner, whose resource is subject to an API call". This is much more precise.

I understand and agree that if we introduce further request parameters and transport information in the login_hint, we can tweak the protocol to transport more information, e.g. the identification of a resource owner (called target device). But this is really a little hack to me. The OIDC standard used login_hint and/or id_token_hint to identify the end user. Please see https://openid.net/specs/openid-connect-core-1_0.html.

So I agree that workaround is technically possible. But having this as the one and only CAMARA mechanism to test whether consent is needed seems not a good idea to me.

Also it introduces further burden on the authZ server implementations (local to the operators) and has lots of demands on the applications/application developers:

1. test for consent with FE flow and prompt = none and login_hint pointing to target device (not necessarily the same as the end user)
2. use FE flow again with prompt = consent, login_hint value unclear to configure consent
3. use another flow (FE flow/backend flow) for calling the API in two/three steps: get auth code/get access token & call API

I recommend to double check with application developers and Vonage to see whether such an approach is reasonable.

[iamdatanick]

If a user withdraws consent while off-network, how is all prior access revoked instantly, not just at the next network interaction?

[AxelNennker]

If a user withdraws consent while off-network, how is all prior access revoked instantly, not just at the next network interaction?

I think, off-net or on-net is not really the important distinction here, because the end-user can alter their consent whether they are on-net or off-net. An OIDC Authorization Code Flow request with "prompt=consent" can start the API Providers consent management system and consent can be changed, regardless of whether the connection is on-net of off-net. The end-user authenticates to the API Provider with the authentication method the end-user is used to and which they have chosen e.g. they configured Passkeys to be used for a secure and convenient way of authentication.

To your question: "how is all prior access revoked instantly"
Revoking access tokens, especially doing that "instantly", is quite expensive.

OAuth2 explicitly separats access token creation at the authorization server from access token validation at the resource server. The Resource Server is simpler than before OAuth2-times and only concerned with access token validation and scopes.
So, checking consent at the resource server would be an, expensive, option but that somewhat defeats the purpose of OAuth2 and OpenId Connect, I think.

Usually this problem is tackled by issuing short-lived access tokens and using refresh tokens.
The refresh request is send to the Authorization Server that then notices the withdrawn consent and either responds with an error, which leads to the API Consumer to request a new access token and refresh token.

Related to this topic is this RFC7009 OAuth 2.0 Token Revocation.

[AxelNennker]

I understand and agree that if we introduce further request parameters and transport information in the login_hint, we can tweak the protocol to transport more information, e.g. the identification of a resource owner (called target device). But this is really a little hack to me.

I do not intent to tweak login_hint, but we could agree in CAMARA that login_hint indicates the target device whether network-based authentication is done or not. The use of login_hintis left to the OP's discretion.
So, I think an agreement on login_hint is totally compliant to OIDC.

So I agree that workaround is technically possible. But having this as the one and only CAMARA mechanism to test whether consent is needed seems not a good idea to me.

Why is it (what?) the only CAMARA mechanism to test whether consent is needed?
OIDC provides "prompt=consent". Why not use it?

Also it introduces further burden on the authZ server implementations (local to the operators) and has lots of demands on the applications/application developers:

1. test for consent with FE flow and prompt = none and login_hint pointing to target device (not necessarily the same as the end user)

2. use FE flow again with prompt = consent, login_hint value unclear to configure consent

3. use another flow (FE flow/backend flow) for calling the API in two/three steps: get auth code/get access token & call API

I recommend to double check with application developers and Vonage to see whether such an approach is reasonable.

I do not see the problem with the OIDC standard and demands on application developers and authZ server implementations.
The OIDC standard is clear and provides a standard way to avoid user-interaction with prompt=none. And a standard way to ask for consent with "prompt=consent".
To the demand the API provider's authZ server implementation face, that demand/work has to be done somewhere anyway. Better to use an established standard, OIDC, than to invent something new, I think.

If the API Consumer uses an certified OpenId Provider then the prompt parameter is most likely already implemented, especially because implementing the prompt parameter is mandatory to implement for for all OpenId Providers.
See e.g. here https://connect2id.com/products/server/docs/api/authorization#prompt for a random OpenId Provider.

Network-based authentication is an asset CSPs bring to API business and it has to be implemented.
Currently we/CAMARA have defined no behavior for the Authorization Server if NBA finds a subscription identifier that has a contract owner with multiple accounts, e.g. a family account or a business account. The Authorization Server does not know whether the end-user is the subscriber, the contract owner of the subscription, and consent status cannot be determined for that data-subject/end-user. If consent status cannot be determined using network-based authentication, then - I think - an error MUST be returned. Some legislation might not care about this distinction between subscriber and end-user but, I think, GDPR does care. I think a end-user interaction cannot be avoided in these cases (family account or business account). An id_token_hint with a signed id_token, might be a way out.

Coming back to Consent URL API vs OIDC consent collection, if personal data is involved and consent is needed, then consent has to be managed and that end-user interaction has to be implemented somewhere by the API consumer. OIDC provides a standard protocol for end-user authentication and end-user consent. Why invent something new?

https://m.xkcd.com/927/

[AxelNennker]

Although prompt is MTI in OIDC the implemention is up to the OpenId Provider.
If the consent is not needed based on purpose, then prompt=consent does not force the OP to redirect to a consent collection page.

[AxelNennker]

Does the consent url api require consent?

[jpengar]

Does the consent url api require consent?

#224 (comment)

According to the assessment of Telefonica's legal team, the Consent URL API could be consumed on a "Legal Obligation" legal basis (without opt-in/opt-out) and would therefore meet the conditions agreed upon in CAMARA for an API to be consumed using 2-legged access tokens (Client Credentials grant).

[MarkCornall]

Would that be the case in all jurisdictions? eg Germany?
If I need to gather consent to call an API then surely I will need to gather consent to call an API that will gather that consent? No?
We also end up with the aggregator/federator routing issue on client credentials meaning that 3 legged should be used.

[AxelNennker]

Would that be the case in all jurisdictions? eg Germany? If I need to gather consent to call an API then surely I will need to gather consent to call an API that will gather that consent? No? We also end up with the aggregator/federator routing issue on client credentials meaning that 3 legged should be used.

The whole world is using OpenId Connect in all jurisdictions. The end-user is asked to authenticate, which they might do or not. The then authenticated end-user is granting their consent or not.
So, doing OIDC and CIBA with authentication is OK in all jurisdictions.
An API Consumer calling an API without User authentication is different and client credentials flows are only possible under some conditions.

The OAuth 2.0 Client Credentials grant type is used to obtain a 2-legged Access Token that does not represent a user. The grant-type can only be used if agreed between the API consumer and the API provider exposing the API, taking into account the declared purpose for accessing the API (cf. CAMARA API Specification - Authorization and authentication common guidelines).