Consent Info/Consent URL API DRAFT proposal

[jpengar]

What type of PR is this?

• enhancement/feature

What this PR does / why we need it:

This PR is intended to provide a draft proposal for what the Consent URL or Consent Info API could look like (adding the functionality indicated by Ericsson/Vonage @Elisabeth-Ericsson @chrishowell).

This PR is not intended to be merged, as if we were to proceed with the API specification in CAMARA, I understand that the API should go into its own repository to have its own release management and where the fine-grained details of the design could be discussed.

This DRAFT proposal may help to resolve the API approval discussions in Issue #224. However, the proposal already contains a good level of detail and is aligned with the Sprin25 Commonalities and ICM guidelines (just for reference).

Which issue(s) this PR fixes:

Is related to Issue #224

Special notes for reviewers:

• Importantly, this API does NOT delegate consent capture to a third party but rather empowers the API Consumer to present the API Provider's consent capture URL at the most opportune time and place. The actual consent capture occurs within the API Provider's secure environment, ensuring the user's authentication with the API Provider.
• This API adds a layer of flexibility to the consent collection process, allowing API Consumers to more seamlessly integrate and customise the consent experience, without intending to replace existing CAMARA OIDC/CIBA flows. Instead, it complements these flows by providing more options for when and how consent is captured.

Changelog input

consent-info draft proposal

Additional documentation

#224
camaraproject/APIBacklog#68
camaraproject/APIBacklog#67

[HuubAppelboom]

Looks good to me!

[AxelNennker]

Does the (end-)user have to be authenticated when the API provider opens the browser with the Consent URL provided by the API?

[AxelNennker]

And here OIDC Authorization Code flow is started, right?

[jpengar]

Not really.

[AxelNennker]

What happens then? The Consent API does involve personal data, and if personal data is involved ICM info.description mandates three-legged access tokens.

[jpengar]

Actually it states:

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.

And as mentioned in #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). While a three-legged access token could also be used, user consent is not required in this case.

Moreover, the nature of the information handled by this API is essentially the same as that processed in OIDC Authorization Code Flow and CIBA. Requiring user consent here would be analogous to mandating consent for Auth Code or CIBA, which is not the case.

[AxelNennker]

And as mentioned in #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). While a three-legged access token could also be used, user consent is not required in this case.

First, would you be able to share Telefónica's privacy assessment? I assume, that that assessment has very specific preconditions that have to be met. A blanket "every API consumer can get personal information, the consent status, in all cases for all APIs seem unlikely to me.

I think that Consent URL API is very different to all other CAMARA APIs as it provides "meta" information on other CAMARA APIs.
Does every API Consumer get access to this client credentials based Consent URL/Info API?

In CAMARA usually only some API Consumers get access to client credentials based flows.
https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md#client-credentials-flow

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).

Getting the personal information, here whether the User did grant consent, or revoked it, should not be available to all API consumers.

If an API Consumer bought two CAMARA APIs e.g. sim-swap with purpose dpv:FraudPreventionAndDetection and device-location with purpose dpv:PersonalisedAdvertising, does the API Consumer get client credentials flow access to Consent URL API for both?

Device-location for advertising is something for that privacy-aware user probably do not grant their consent.
But maybe during app onboarding they checked one checkbox to quickly, but then the end-user visits the CSP's privacy transparency board and remove their consent.
Then those users would be negatively surprised if the API consumer can silently learn from the CSP that they revoked their consent and are now pestered with marketing messages to come back and grant consent again.
I think that the current consent status is personal information and any API accessing that personal information needs its own consent.

If the API consumer needs consent for Consent URL/Info API, then using OIDC Authorization Code flow in the firest place is simpler.
If the API consumer does not need consent for Consenet URL/Info API because of the purpose of the API consent status is asked for, then likely consent is not needed for that API anyway.

Additionally, introducing Consent URL API is a privacy-disaster-to-happen because of mistakes being made during API consumer onboarding.

[MarkCornall]

I do not see how this should be client credentials. It should be 3 legged and work across aggregators, Federators and Operators. CAMARA scope is across all. Usage of 2 leg flows where user information is processed should use 3 leg flows. There will be some markets where consent will be needed.

[HuubAppelboom]

@MarkCornall @AxelNennker With this kind of reasoning you end up in an endless loop, that you have to ask user consent to see whether user consent has changed. Also. the reasoning that three legged flow is mandatory for all cases where personal information is being processed because of the GDPR does not hold. The GDPR does not dictate a three legged flow; for cases where user consent is required, the controller needs to ensure that informed user consent is required. You have a similar case with for example the Telco Finder: here personal data is being processed before any user consent has been obtained, and this is done based on legitimate interest. During onboarding of the API Consumer, you must validate that the legitimate interest is there, and that the API Consumer will not abuse the API. That is business as usual.

[HuubAppelboom]

Does the (end-)user have to be authenticated when the API provider opens the browser with the Consent URL provided by the API?

Yes, but I would entirely leave that up to to the Telco how to capture the consent, and whether you need to login on to that url immediately.

For example, if we are talking about a fixed line, it could also be a link to a webpage with an instruction like call number xyz and when you hear the IVR, press 1 for consent, or 2 to withdraw consent.

In the Netherlands we have for example also a website which is used by all telco's to capture consent for listing in the telephone directories (and some more stuff). What could happen is the Consent URL is a simple instruction page explaining how to go to that website and enter the consent. That website uses partly Number Verify, partly SMS, and partly an IVR, because it is used for fixed and mobile numbers. For some use cases it may end up here (the consent collection), for other use cases it may end up in a selfcare environment of the telco, or in an IVR, or even in a TV screen.

[AxelNennker]

Does the (end-)user have to be authenticated when the API provider opens the browser with the Consent URL provided by the API?

Yes, but I would entirely leave that up to to the Telco how to capture the consent, and whether you need to login on to that url immediately.

For example, if we are talking about a fixed line, it could also be a link to a webpage with an instruction like call number xyz and when you hear the IVR, press 1 for consent, or 2 to withdraw consent.

In the Netherlands we have for example also a website which is used by all telco's to capture consent for listing in the telephone directories (and some more stuff). What could happen is the Consent URL is a simple instruction page explaining how to go to that website and enter the consent. That website uses partly Number Verify, partly SMS, and partly an IVR, because it is used for fixed and mobile numbers. For some use cases it may end up here (the consent collection), for other use cases it may end up in a selfcare environment of the telco, or in an IVR, or even in a TV screen.

Then OIDC Authorization Code Flow just redirects to those webpages with those instructions. There is no need for a special Consent URL API because the consent url is always the same fixed one. In other words the OIDC Authorization Code Flow authentication request url is the consent url.

[AxelNennker]

I think that because Consent URL API is different to normal CAMARA apis it is good that we are discussing it in ICM.
Thinking about how Consent URL API might be implemented, I come up with implementation requirements that are directed at the API provider. For normal CAMARA APIs the yaml file is addressing the API consumer, while in ICM we are addressing both the API consumer and the API provider or better the Authorization Server implementation.
The proposed API is closer to the Authorization Server, while normal APIs are closer to the resource server.

[AxelNennker]

I propose to split the proposed yaml file into two: consent_url.yaml and consent_info.yaml

I think the current proposed consent-info.yaml mixes several API functions into one path, which feels wrong and probably rubs against Commonalities API guidelines.

I created #271
But still think that Consent URL API is not needed because consent management can be achieve by user OIDC Authorizatin Code flow with prompt=consent.

[jpengar]

I propose to split the proposed yaml file into two: consent_url.yaml and consent_info.yaml

I think the current proposed consent-info.yaml mixes several API functions into one path, which feels wrong and probably rubs against Commonalities API guidelines.

I created #271 But still think that Consent URL API is not needed because consent management can be achieve by user OIDC Authorizatin Code flow with prompt=consent.

@AxelNennker Thank you for your detailed input. I'd like to point out that we already have an active PR and API proposal that incorporates feedback from several WG participants - including suggestions from Ericsson and Vonage. The original proposal focused solely on a Consent URL API, but based on community feedback we have broadened the scope accordingly. However, anything can be discussed. From Telefónica's point of view, it's ok to consider only the Consent URL functionality, as that was our original proposal. But it should be agreed in any case.

To keep the discussion focused and avoid fragmentation, it would be best if you could provide your feedback on this existing PR. Splitting the YAML file into two separate files and opening additional PRs could complicate the conversation and dilute the collective decision-making process.

So I would kindly ask you to refrain from opening additional PRs and keep the discussion here.

Thanks again for your input!

[jpengar]

I think the current proposed consent-info.yaml mixes several API functions into one path, which feels wrong and probably rubs against Commonalities API guidelines.

@AxelNennker Regarding your concern about mixing multiple API functions in one path, I'd like to clarify that the current design is fully compliant with the Commonalities API guidelines. The endpoint is designed with a clear, focused purpose: to provide the required consent information, along with additional fields based on the consent state. Splitting the functionality into two separate endpoints was considered, but this would require the API client to make two calls - especially when capturing consent - which is less efficient. Our goal was to streamline the process while still providing all the necessary information in a single, well-defined call.

Thanks for your feedback!

[AxelNennker]

In the API proposal's example "phoneNumber" is a required part of VerifyConsentStatusRequestBody, but if the response is always going to be the following, regardless of the specific phoneNumber, should then the phoneNumber never be in the request body in the first place?

The request body example is this:

{
  "phoneNumber": "+123456789",
  "scopes": [
    "location-verification:verify"
  ],
  "purpose": "dpv:FraudPreventionAndDetection",
  "requestCaptureUrl": true
}

And the response is this:

{
  "consentRequired": false
}

Maybe there should be a second path that never contains personal information, e.g. phoneNumber, in the request body?
The path could then be protected by client-credentials.

I propose to split the proposed yaml file into two: consent_url.yaml and consent_info.yaml
I think the current proposed consent-info.yaml mixes several API functions into one path, which feels wrong and probably rubs against Commonalities API guidelines.
I created #271 But still think that Consent URL API is not needed because consent management can be achieve by user OIDC Authorizatin Code flow with prompt=consent.

@AxelNennker Thank you for your detailed input. I'd like to point out that we already have an active PR and API proposal that incorporates feedback from several WG participants - including suggestions from Ericsson and Vonage. The original proposal focused solely on a Consent URL API, but based on community feedback we have broadened the scope accordingly. However, anything can be discussed. From Telefónica's point of view, it's ok to consider only the Consent URL functionality, as that was our original proposal. But it should be agreed in any case.

To keep the discussion focused and avoid fragmentation, it would be best if you could provide your feedback on this existing PR. Splitting the YAML file into two separate files and opening additional PRs could complicate the conversation and dilute the collective decision-making process.

So I would kindly ask you to refrain from opening additional PRs and keep the discussion here.

Thanks again for your input!

I created the PR because I do not know how a review can add a new file to an existing PR.
Creating a new one was the ways forward that "worked".

I think both Consent URL API and Consent Info API are Authorization Server APIs and not normal APIs.
If we have a new API that is two-legged only then the yaml file should clearly state that and describe that that API does not process personal information. I understand that Consent URL API is a two-legged API. I wonder whether the phoneNumber parameter should be optional then and maybe omitted.

I think Consent Info API is processing personal information and is/should/must most probably be three-legged. Which then raises the question what Consent Info API provides what ICM cannot define into OIDC ACF without changing the OIDC ACF protocol.

[AxelNennker]

The Concent URL API proposal describes the following use cases:

Current use cases validating the service:

1. Consent capture during end-user onboarding: The developer, when registering the user in a digital or physical procedure, can take advantage of the presence of the end-user during the process to pre-capture the consent for the set of APIs that the user is later going to require.
2. Consent capture in application notification: Developers can push a notification in their app so that customers can access directly to the consent capture process in this easy-to-access place.
3. Consent capture campaigns: Applications can create campaigns by email or other channels to capture the consent for substantial chunks of their user base.

re 1: this is a typical front end flow scenario. When the end-user is onboarding to API Consumer, then they create an account with API consumer and then API Consumer tells the end-user they want to use "CAMARA API" and that the end-user must consent because otherwise API-Consumer's service can't be provided. The API Consumer then redirects the end-user's browser or webview in a mobile application to OIDC Authorization Code Flow and the end-user grants consent.

re 2: this is a typical front end flow scenario: The API Consumer's mobile app receives the notification and the mobile app opens either a webview in the app to OIDC Authorization Code Flow or opens the mobile browser. In both cases, webview or mobile browser, the end-user might already be logged-in to the API provider.

re 3: this is a typical front end flow scenario: The emails contains a link to the API Consumer's campaign page. The end-user authenticates to the API Consumer and is asked for consent using OIDC ACF.

What would be an use case or scenario that cannot be done with OIDC ACF?
GDPR demands that consent is granted by a data-subject (end-user) and Consent must be freely given, specific, informed and unambiguous.

[AxelNennker]

What changed to when you (@jpengar ) wrote in this comment?

In any case, so far there is no need to expose a Consent API to third party clients as a CAMARA API with CRUD operations on consent records. Consent must be obtained through operator channels (there is no delegated consent) and only operators internally manage user consents (e.g. check if a consent record exists, create a new consent record if it is captured from the user, etc).

Consent must still be obtained through operator channels - We are using OIDC Authorization Code Flow or CIBA for that.

The flow is determined at API Consumer Onboarding time. In some cases consent might never be needed and two-legged flow might be legal. CAMARA then uses OIDC ACF to identify the subscriber and if the subscriber can reasonably be equated with the end-user determines that consent does not need to be collected during OIDC ACF. CAMARA thus uses OIDC ACF basically as a two-legged flow.
I think using CIBA in a similar manner, is probably not possible without sending a message. Please see CIBA privacy.

[jpengar]

What changed to when you (@jpengar ) wrote in this comment?

In any case, so far there is no need to expose a Consent API to third party clients as a CAMARA API with CRUD operations on consent records. Consent must be obtained through operator channels (there is no delegated consent) and only operators internally manage user consents (e.g. check if a consent record exists, create a new consent record if it is captured from the user, etc).

Consent must still be obtained through operator channels - We are using OIDC Authorization Code Flow or CIBA for that.

The flow is determined at API Consumer Onboarding time. In some cases consent might never be needed and two-legged flow might be legal. CAMARA then uses OIDC ACF to identify the subscriber and if the subscriber can reasonably be equated with the end-user determines that consent does not need to be collected during OIDC ACF. CAMARA thus uses OIDC ACF basically as a two-legged flow. I think using CIBA in a similar manner, is probably not possible without sending a message. Please see CIBA privacy.

@AxelNennker There is nothing in Telefónica's Consent URL proposal that contradicts the statement you just copied above completely out of context by the way (which is a comment on a question from 2023 about having a CRUD Consent Management API that would allow third parties to manage consents on behalf of the API provider and thus delegate consent management, which is NOT what is being proposed here).

Please take a look at PR description:
#266 (comment)

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

The only thing added in this PR to Telefónica's original proposal (camaraproject/APIBacklog#68) is the ability to get the consent status (which is far from being a CRUD API and which is NOT a consent management API, not a consent delegation API). It has been added taking into account feedback from other participants, and of course for discussion. As said before, #266 (comment), from Telefónica's point of view it's ok to consider only the Consent URL functionality, as that was our original proposal. But it should be agreed in any case.

[jpengar]

I wonder whether the phoneNumber parameter should be optional then and maybe omitted.

No. The API consumer needs to identify the user whose consent is to be captured with the obtained consent capture URL.

[jpengar]

The flow is determined at API Consumer Onboarding time. In some cases consent might never be needed and two-legged flow might be legal. CAMARA then uses OIDC ACF to identify the subscriber and if the subscriber can reasonably be equated with the end-user determines that consent does not need to be collected during OIDC ACF. CAMARA thus uses OIDC ACF basically as a two-legged flow.

Please read the agreed CAMARA statement carefully again, because it does not say the same thing as you say above:

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.

And to be clear, I'm NOT mandating or requiring this API to be used specifically consumed in two-legged mode. What I have said here, #266 (comment), is that 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 in CAMARA for an API to be consumed using 2-legged access tokens (client credentials grant). While a 3-legged access token could also be used, user consent is not required in this case. Period, nothing more.

That's why the API DRAFT proposal so far sticks to the info.description template defined by ICM.

[AxelNennker]

You clarified that Consent URL API is not about delegated consent. I do not doubt that.

I still do not see use case or scenarios where Consent URL API helps.
For weeks I proposed use case and scenarios where Consent URL might help which in the end could all be done by OIDC ACF.

@jpengar wrote:

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 control the user experience entirely. 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.

Why are "fully decoupled" or out-of-band mechanisms a benefit? For the end-user to grant consent, there must be interaction with the end-user. The end-user is on a browser or mobile application and OIDC ACF can be used?

Please provide a use case where OIDC ACF is inferior to Consent URL API.
Claiming that some is better does not make it so. Please explain.

[jpengar]

You clarified that Consent URL API is not about delegated consent. I do not doubt that.

I still do not see use case or scenarios where Consent URL API helps. For weeks I proposed use case and scenarios where Consent URL might help which in the end could all be done by OIDC ACF.

@jpengar wrote:

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 control the user experience entirely. 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.

Why are "fully decoupled" or out-of-band mechanisms a benefit? For the end-user to grant consent, there must be interaction with the end-user. The end-user is on a browser or mobile application and OIDC ACF can be used?

Please provide a use case where OIDC ACF is inferior to Consent URL API. Claiming that some is better does not make it so. Please explain.

@AxelNennker To be honest, as you say, the same discussion has been going on for weeks (if not months) (the requested clarifications have been provided in the past and we all seem to be unable to agree or change our minds). So, instead of going round in circles, I would like to hear the opinions of other CAMARA participants on the subject, which also need to be taken into account. And whether the majority of WG participants want to continue with the API proposal or not.

[HuubAppelboom]

A use case where you can not use OIDC ACF is for where you have terminals that don't have a web interface, for example a fixed line phone. ACF can only work if you have a selfcare environment for that phone, but that is not always the case / users may not be using that.

[AxelNennker]

Is the reason for proposing a new Consent API that current MNO implementations insist on network-based authentication and some MNOs did not implement asking for consent?

OIDC Authorization Code Flow was designed to be an authentication and consent protocol, why not use it?

[AxelNennker]

Does the (end-)user have to be authenticated when the API provider opens the browser with the Consent URL provided by the API?

Yes, but I would entirely leave that up to to the Telco how to capture the consent, and whether you need to login on to that url immediately.

For example, if we are talking about a fixed line, it could also be a link to a webpage with an instruction like call number xyz and when you hear the IVR, press 1 for consent, or 2 to withdraw consent.

In the Netherlands we have for example also a website which is used by all telco's to capture consent for listing in the telephone directories (and some more stuff). What could happen is the Consent URL is a simple instruction page explaining how to go to that website and enter the consent. That website uses partly Number Verify, partly SMS, and partly an IVR, because it is used for fixed and mobile numbers. For some use cases it may end up here (the consent collection), for other use cases it may end up in a selfcare environment of the telco, or in an IVR, or even in a TV screen.

@HuubAppelboom Yes, only the Telco should capture user consent. That is what OIDC Authorization Code Flow was designed for.

I do not understand what "and whether you need to login on to that url immediately." means.

If consent is needed, then the User has to be authenticated because e.g. GDPR requires the data-subject to grant consent and that Consent must be freely given, specific, informed and unambiguous.
An end-user who is not logged-in cannot give consent nor can they opt-out nor can the opt-out status be checked.
Some User authentication has to happen.

[AxelNennker]

I wonder whether the phoneNumber parameter should be optional then and maybe omitted.

No. The API consumer needs to identify the user whose consent is to be captured with the obtained consent capture URL.

Why? The API provider must authenticate the User whose consent is to be captured.

The Consent URL API must not reveal personal information about the User and the best way to ensure that is that the Consent URL does not depend on the User at all.

If e.g. the consent capture url returned by Consent URL API would be https://ageover80.mno.com/authorize?login_hint=tel:+123456789 then the Consent URL API leaked private data. Better Consent URL API does not know the phone number.
And if the end-user is later authenticated anyway at capture URL then we could have use OIDF Authentication Code Flow from the beginning.

[jpengar]

I wonder whether the phoneNumber parameter should be optional then and maybe omitted.

No. The API consumer needs to identify the user whose consent is to be captured with the obtained consent capture URL.

Why? The API provider must authenticate the User whose consent is to be captured.

The Consent URL API must not reveal personal information about the User and the best way to ensure that is that the Consent URL does not depend on the User at all.

If e.g. the consent capture url returned by Consent URL API would be https://ageover80.mno.com/authorize?login_hint=tel:+123456789 then the Consent URL API leaked private data. Better Consent URL API does not know the phone number. And if the end-user is later authenticated anyway at capture URL then we could have use OIDF Authentication Code Flow from the beginning.

The API consumer must provide the API provider with the identity of the user for whom consent is required. The API provider will then generate a consent URL for that combination of user identity, purpose and scope(s). I don't know why you assume a consent URL format like https://ageover80.mno.com/authorize?login_hint=tel:+123456789... In any case, each API provider could apply their own security considerations and mechanisms to the consent URL according to their requirements. But in Telefónica (say), for example, we could use a temporary and non-predictable URL that could look like https://ob-url.com?jwt=xxx...yyy...zzz, which does not provide any user information.

[chrishowell]

Is there a reason why we couldn't allow a list of scope/purposes on this API? It would be nice to be able to have a single call to obtain all of the statuses at once, and/or receive the consent URL to collect consent for all of those scope/purposes?
Of course the response should then have a status per scope/purpose combination, but then a single consent capture URL.

[chrishowell]

I think this comment can be discussed when we review the actual API spec, rather than whether the API should exist; I am/Vonage is in agreement that this API is required and is much more suitable/scaleable than using Auth Code (prompt=none) for this purpose.

[AxelNennker]

@jpengar

The API consumer must provide the API provider with the identity of the user for whom consent is required. The API provider will then generate a consent URL for that combination of user identity, purpose and scope(s). I don't know why you assume a consent URL format like https://ageover80.mno.com/authorize?login_hint=tel:+123456789... In any case, each API provider could apply their own security considerations and mechanisms to the consent URL according to their requirements. But in Telefónica (say), for example, we could use a temporary and non-predictable URL that could look like https://ob-url.com?jwt=xxx...yyy...zzz, which does not provide any user information.

I am not assuming that the capture URL looks like https://ageover80.mno.com/... That is an example how Consent URL API could misused or (accidentally) implemented wrong. That is an example where the capture URL is leaking information about the user. That is only possible if the user identifier is part of the API request. If the API request does not contain an user identifier then this cannot happen.

Still, (again) what is the use case for Consent Capture URL what cannot be done with OIDC Authorization Code flow?

[AxelNennker]

A use case where you can not use OIDC ACF is for where you have terminals that don't have a web interface, for example a fixed line phone. ACF can only work if you have a selfcare environment for that phone, but that is not always the case / users may not be using that.

At some point in time the user of the fixed line phone is using the Internet - with or without a Consent URL API.
That is the time when OIDC Authorization Code flow is used. That is the time when the user authenticates using their user authentication credentials the CSP provided. That is the normal OpenId Connect flow.

Even if some insist on network-based authentication for OIDC ACF.
The Authorization Server is there to help the user and to enable the API Consumer to use our APIs.
The API Provider and the Authorization Server should always allow the end-user to authenticate and provide their consent.

[HuubAppelboom]

A use case where you can not use OIDC ACF is for where you have terminals that don't have a web interface, for example a fixed line phone. ACF can only work if you have a selfcare environment for that phone, but that is not always the case / users may not be using that.

At some point in time the user of the fixed line phone is using the Internet - with or without a Consent URL API. That is the time when OIDC Authorization Code flow is used. That is the time when the user authenticates using their user authentication credentials the CSP provided. That is the normal OpenId Connect flow.

Even if some insist on network-based authentication for OIDC ACF. The Authorization Server is there to help the user and to enable the API Consumer to use our APIs. The API Provider and the Authorization Server should always allow the end-user to authenticate and provide their consent.

@AxelNennker The more I think about this, I still do not see any reason why a web interface is the only interface through which user consent can be acquired, and why CAMARA should restrict itself to consent acquisition through a web interface, especially when we are talking about API's which are normally run in the background with the CIBA protocol.

For example, in case you need to acquire consent for example for a Scam Signal API, you may want to do this through about any interface by why end users interact with the Telco. An online selfcare environment can be very important for that, but if you have a goal to reach 99% of the population, you may want to use other channels as well in which users are alos authenticated. Just to name a few:

• when the customer is visiting a shop for a servicequestion, the sales rep may alsoask them whether want to have it turned on. I don't think it is very customer friendly to aks customersto login through a web interface in the shop, when you ahve already authenticated them by their ID card
• on the phone, when a customer has been autneticated, you can also ask for permission to switch a service on
• interaction by SMS; this can be very useful if you have a promotion for a servicethrough main stream mass media (TV, Radio, newspapers, or when you have an SMS campaign
• same for a campaign through chat channels / RCS
• turning a service on by using an IVR
• or activating a service by short code on the phone, similar to call diversion

All these interactions without using a web interface, and are usually very instrumental in getting conversion up. We should support any interface for consent collection (as long as the user is sufficiently authenticated). Also to my experience, lost of users have lost their selfcare password a long time ago, and are not daily active in the selfacre portalof their telco. If you want to be successfull in consent collection, you should also include channels which are easy and relevant for users. So, can you explain why you think a web interface for consent collection is a must ???

[jpengar]

FYI, these are the updates in 216fa03:

• Identifying the phone number from the access token: Updated the info.description section to align with CAMARA Commonalities guidelines, as done in other CAMARA APIs. The API can be consumed with both two-legged and three-legged access tokens, making phoneNumber optional in the request.
• Response body updates: Modified to accommodate multiple consents. For instance, if the scope list corresponds to multiple APIs, more than one user consent may be required.
• Updated examples: Refined request and response body examples to provide better clarity.

[MarkCornall]

As previously said I do not support this being deployed as a 2-legged flow. It is personal information. You are asking about the status of an API that requires consent (or you wouldn't call the API) you retrieve information on consent status. This all points to a 3-legged flow being necessary.

[HuubAppelboom]

@MarkCornall Hi Mark, for many use cases (like an anti-fraud check during a transaction), 3 legged flow is much too slow. that will not work.

In any case, both the API Consumer and the API Provider should be aware of the consent status for that particular user in combination with combination with the API Cosnumer's application. Why would it be needed to be kept a secret what the consent status is for that API Consumer ??