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"