New API Proposal - Consent URL API

[jgarciahospital]

Proposal to create a Consent URL API:

With the proposed API, the developer will be able to request for a consent capture process when they find it's more suitable, by specifying the scope(s) and purpose that they require to access data from a specific end-user.

The API takes advantage of the developer's knowledge of the customers, based on the use case that they manage, to trigger the consent capture process in the moment and channel that best fit with each customer, while ensuring that the privacy management and ownership remains in the operator. The process can be included in onboarding processes, where developer can gather the consent in advance getting ready by the moment the API(s) need to be called.

Related to #67

[sebdewet]

Hi,

This would be like operating with a delegated consent mode, which the partner would retrieve and then transmit to the operator.
I have several questions about this mode:

• how to manage the life cycle.
• Which identifier will match the user.
• How to ensure that the user who has given his consent is the one who is the first owner of the identifier for which consent will be stored (since it is not the partner who will authenticate the user from login/password belonging to the operator).
• What happens in case of revocation of consent? (the partner must display a consent page again?)

Consent is, imho, a very sensitive subject, and I always tend to be suspicious when it's delegated outside of the operator.

[AxelNennker]

I agree with @sebdewet that consent-URL API is delegated consent.
Delegated consent is something telcos rejected in the past, is questionable in GDPR and probably insecure because stealing the user's telco credentials can't be prevented.

[jgarciahospital]

HI @AxelNennker and @sebdewet, thanks for the feedback.

As included in the API template and also in the additional information, API proposal is not a consent delegation at all. Telefonica's position remains in the ownership of the telco for the privacy management, and this proposal is following this goal. In fact, its aim is to facilitate the flows for ensuring that operators and developers can integrate consent APIs easily, in comparison to other project where consent complexity has prevented the non-delegation.

In terms of concept, the API just triggers the creation of a consent portal url from the telco, that allows developer to provide it to the user (in a browser) for the user to access the consent portal of the telco, to be authenticated by the telco, provide the consent to the telco, and therefore the telco always remains as consent master, in concept and in legal terms. There is no delegation in this process.

In functional terms, API makes exactly the same as current AuthCode OIDC flow (where consent is not delegated, operator provides consent protal in the proper auth flow), but with the advantage of having this consent process separated from the API authentication and also capable of been managed in a different device than the one where the API is targeted, as right now authcode only allows network based authentication (see camaraproject/IdentityAndConsentManagement#215 (comment)).

[AxelNennker]

The root cause for the perceived need for consent URL API is, that you wrongly believe that network-based authentication is the only authentication methods that telcos are allowed to use. The telco can use any authentication method that is the best fit for the telco to fulfill e.g. its GDPR obligations.

Network-based authentication authenticates the subscriber and does not authenticate the user.
Without user interaction and user authentication there cannot be GDPR compliant consent.

If API Consumers want to avoid user authentication, then they should use prompt=none.
For some purposes and for some APIs that might be GDPR compliant (if the user has not opted-out).

This guideline https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md has no guideline regarding prompt.
This specification https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md does not restrict anything with regard to the OIDC's prompt parameter.
API consumers can use the flows allowed by CAMARA-Security-Interoperability.md and they can use the prompt parameter.

There is no need for consent URL API because whenever the API consumer wants consent to be collected, they can start e.g. OIDC authorization code flow and get a refresh_token. No need to immediately use the access_token. The telco decides which authentications method to use. (Just an example at TDG users can setup and are encouraged to setup passkey for their user authentication, which has a really nice and secure user experience. Users should be suspicious if TDG falls back to a different authentication method.)

One of OAuth2's signature use cases is the picture frame use case, which is what the consent URL API proposal mentions as one of its use cases. But limited-input devices are already handled by OAuth2 and OIDC is based on OAuth2, there is not need for the consent URL API.

API consumers can use OIDC as specified in CAMARA-Security-Interoperability.md already.

[Kevsy]

Could the newly published RFC for Grant Negotiation and Authorization Protocol help here? It was motivated by some of the shortcomings of OAUTH's legacy of requiring a user-with-browser, and instead aims to be more 'API friendly'.

[pjhac]

Hi @jgarciahospital (et al),

Disclaimer: I'm posting my personal views, not the ones from my company.

I would like to make a few assumptions to verify my understanding of your API proposal.

• the application, its used APIs and their related purposes have been previously onboarded and contracted between the application developer and the telco (possibly through a channel partner); the telco is therefore managing that part
• my telco allows me to manage my consent within my customer account area, located for example at mytelco.com/account, or from a page that is accessible from my account, and that needs my telco-provided credentials
• the URL returned by the API will point to said account page, but I'm able to access that page without needing your proposed API; in other words, your API makes it convenient to retrieve my telco account page, but using the API is not mandatory to manage my consent within my telco account page
• I will log in to that telco account page using my telco provided username and password
• since the application, APIs and purposes were onboarded before, I can even manage my consent without needing to have the app installed (very practical to manage my children devices applications before they install them); in other words, I don't need to have installed the application beforehand, the fact that the telco already onboarded its details (notably for legal reasons) is sufficient
• when the application is first used, if no consent was given within the telco account page (no consent provided means no consent at all), the application displays a message to the user like "please manage consent at your provider, here is the URL" and your API proposal will help to retrieve said URL for display; if on the other hand consent was already managed beforehand, then app will either work (consent given) or fail (consent rejected), and application may invite the user to change their mind by showing the URL to the telco account page using this API

Again, those are my personal views on it, how I think I understand your proposal, and how I try to map it to what I'd like to see, as a subscriber and app user, that app I'm willing to use and that does not try to mess with my consent and directs me right away to my telco account page to manage my consent by myself.

So, if those assumptions are correct (especially the ones where the consent is managed under my telco customer account page), then I see the interest in this API, this is a pointer to an out-of-band / out-of-app consent management page at telco level.

Lastly, seeing how consent is handled by Google when using a non-Google service with my Google credentials is done within the Google account page, is the reason I'm asking if you can confirm my assumptions, or not.

Thanks in advance !

PS: apologies for the frequent edits, I thought I wasn't clear enough, I hope I am now.

[jgarciahospital]

The root cause for the perceived need for consent URL API is, that you wrongly believe that network-based authentication is the only authentication methods that telcos are allowed to use. The telco can use any authentication method that is the best fit for the telco to fulfill e.g. its GDPR obligations.

Network-based authentication authenticates the subscriber and does not authenticate the user. Without user interaction and user authentication there cannot be GDPR compliant consent.

If API Consumers want to avoid user authentication, then they should use prompt=none. For some purposes and for some APIs that might be GDPR compliant (if the user has not opted-out).

This guideline https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md has no guideline regarding prompt. This specification https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md does not restrict anything with regard to the OIDC's prompt parameter. API consumers can use the flows allowed by CAMARA-Security-Interoperability.md and they can use the prompt parameter.

There is no need for consent URL API because whenever the API consumer wants consent to be collected, they can start e.g. OIDC authorization code flow and get a refresh_token. No need to immediately use the access_token. The telco decides which authentications method to use. (Just an example at TDG users can setup and are encouraged to setup passkey for their user authentication, which has a really nice and secure user experience. Users should be suspicious if TDG falls back to a different authentication method.)

One of OAuth2's signature use cases is the picture frame use case, which is what the consent URL API proposal mentions as one of its use cases. But limited-input devices are already handled by OAuth2 and OIDC is based on OAuth2, there is not need for the consent URL API.

API consumers can use OIDC as specified in CAMARA-Security-Interoperability.md already.

Thanks @shilpa-padgaonkar for the clarity in TSC meeting on the open discussion that remains for this API. As agreed, let's focus the discussion then in ICM as remain point is about authentication methods camaraproject/IdentityAndConsentManagement#215

[jgarciahospital]

Inline @pjhac

• the application, its used APIs and their related purposes have been previously onboarded and contracted between the application developer and the telco (possibly through a channel partner); the telco is therefore managing that part

Yes, onboarding is always a must to manage access in advance. That even appears in the user stories of the CAMARA APIs

• my telco allows me to manage my consent within my customer account area, located for example at mytelco.com/account, or from a page that is accessible from my account, and that needs my telco-provided credentials

Depends on each telco decision, but it's supposed that each of us should have this privacy portal where subscribers can manage their privacy (consents or any other lawful base that can be configured).

• the URL returned by the API will point to said account page, but I'm able to access that page without needing your proposed API; in other words, your API makes it convenient to retrieve my telco account page, but using the API is not mandatory to manage my consent within my telco account page

Yes, the problem is the customer journey. In an optimal scenario, when a developer first request an access token for an API that requires consent, CIBA flow includes a backchannel call where the operator can reach the customer, for instance via SMS or even triggering a notification in the carrier APP.
In case the carrier app is not installed, or que device where the user is interacting with the developer's app is not the same device that will be affected by the API, there is no way the telco can reach the user in a proper way. The proposal is allowing the developer to do it, since the user is indeed in the developers channel. Or developer owns a better channel, for instance a valid updated email.

• I will log in to that telco account page using my telco provided username and password
• since the application, APIs and purposes were onboarded before, I can even manage my consent without needing to have the app installed (very practical to manage my children devices applications before they install them); in other words, I don't need to have installed the application beforehand, the fact that the telco already onboarded its details (notably for legal reasons) is sufficient

Developer is not supposed to access the hole customer base of the telco, only those that are customers of the developer's app (now or future). Therefore, we cannot pre-onboard a consent requirement for an app on all of our customer base. We only know that the developer needs the consent from one of our subscriber when the developer properly request the access to that API.

That is why a dedicated app for the developer to start a specific consent flow for an specific API, APP and subscriber is recommendable to help on this flow.

• when the application is first used, if no consent was given within the telco account page (no consent provided means no consent at all), the application displays a message to the user like "please manage consent at your provider, here is the URL" and your API proposal will help to retrieve said URL for display; if on the other hand consent was already managed beforehand, then app will either work (consent given) or fail (consent rejected), and application may invite the user to change their mind by showing the URL to the telco account page using this API

In fact the proposal is the other way around:

1. If developer has started this out-of-band consent management before, the consent should have been provided before the APP first need to ask for the API.
2. If not, when developers triggers the CIBA token flow, the consent will be triggered following backchannel approach, and user may receive an SMS or need to open their customer management app. In authcode, consent portal URL can be directly shown in the auth flow.

Again, those are my personal views on it, how I think I understand your proposal, and how I try to map it to what I'd like to see, as a subscriber and app user, that app I'm willing to use and that does not try to mess with my consent and directs me right away to my telco account page to manage my consent by myself.

Let me know it the clarifications helped, mostly the part where a pre-consent onboarding is not a good solution.

So, if those assumptions are correct (especially the ones where the consent is managed under my telco customer account page), then I see the interest in this API, this is a pointer to an out-of-band / out-of-app consent management page at telco level.

Lastly, seeing how consent is handled by Google when using a non-Google service with my Google credentials is done within the Google account page, is the reason I'm asking if you can confirm my assumptions, or not.

In fact they do a similar flow. The app shows a Google management portal URL where consent and permissions can be configured by the customer, once logged with google credentials.

Thanks in advance !

PS: apologies for the frequent edits, I thought I wasn't clear enough, I hope I am now.

[jgarciahospital]

Could the newly published RFC for Grant Negotiation and Authorization Protocol help here? It was motivated by some of the shortcomings of OAUTH's legacy of requiring a user-with-browser, and instead aims to be more 'API friendly'.

Thanks @Kevsy We considered this is the past, and different pros/cons appeared. Let me review to formalize a position.

[pjhac]

Hi Jorge,

Thanks for the clarifications. For the part below:

In fact the proposal is the other way around:

1. If developer has started this `out-of-band` consent management before, the consent should have been provided before the APP first need to ask for the API.

2. If not, when developers triggers the CIBA token flow, the consent will be triggered following backchannel approach, and user may receive an SMS or need to open their customer management app. In authcode, consent portal URL can be directly shown in the auth flow.

I probably was rushing a little too fast there, and was expecting that since the consent is managed by the telco, the application performs the API call independently of the consent state, and if the API returns an error that indicates consent was not given, then I was expecting the app to directly pop a message to say "error, consent not given" and show the URL for the user to connect. So for 1. I think we're aligned, and for 2. I was thinking about a classical login/pass combo, I somehow overlooked the MFA part (to me, login would grant access to the telco portal, and display a message that App A with service API B tried to access data, and consent has to be given or refused, this is possible because the app made a call to the API, but the API on telco side refused to run). I don't think it changes anything though.

About this:

In an optimal scenario, when a developer first request an access token for an API that requires consent, CIBA flow includes a backchannel call where the operator can reach the customer, for instance via SMS or even triggering a notification in the carrier APP.

That's the part I think I missed -- I was just going for a classical auth flow, the app gets a token to call the API, then the API returns an error due to lack of consent, so app informs the user "you need to consent", the app calls your URL API to get the URL to the telco portal, tells the user "here is the URL, login to your telco portal", and then when the user tries to log in to their telco portal, the telco will use whatever means to auth the user (auth app, OTP...). The flow was probably not clear in my mind and it looks like I rushed a little through it, but in the end the URL API is still useful, even in other scenarios.