Let me copy here my position on this matter, which I expressed in the other issue mentioned:

The CAMARA-API-access-and-user-consent.md document actually predates the profile document (https://github.com/camaraproject/IdentityAndConsentManagement/releases/tag/v0.1.0) and reflects the consensus of the working group on authN/authZ flows. It has normative value because it was the first implementation reference for CAMARA and was later refined with the profile to address logical ambiguities that arose during implementation.

In particular, the use of network authentication in the auth code flow has always been specified in this document and explicitly mentioned. While the profile itself is generic and doesn't mandate a specific authentication method - just as OIDC doesn't - the groundwork has been clearly laid.

Importantly, the idea of using auth code without network authentication was not initially considered, as it was felt that this would degrade the end-user experience and be unacceptable to most service providers. The developers wanted to avoid breaking the flow, and in the absence of an on-net scenario with network authentication, CIBA is the alternative.

If other authentication methods are to be considered, this should be formally proposed in a new issue and discussed for inclusion in upcoming or future meta-releases.

DT's position on authentication by the API provider in Camara is that the API provider is in control of user authentication.

ICM created a (security and) interoperability profile that exactly specifies what API Consumers and API producers need to agree upon to create an interoperable solution. If something is not specified in the interoperability profile, then we are back to OIDC, CIBA and OAuth2.

All Camara subprojects leave authentication to the authorization server. Notable exception is the NumberVerify API which demands network-based authentication.

Under GDPR consent must be freely given, specific, informed, and unambiguous.
It is DT's position that consent cannot be given "silently" with user authentication being only network-authentication. The API provider must authenticate the user, otherwise we do not know who the user is. The API provider must "inform" the user so that the consent can be freely given, specific, informed and unambiguous. There must be a user interaction otherwise the consent cannot be informed.

DT's position on consent collection is that we do not allow delegated consent. The consent must be collected by the API provider.

From https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md

This document is the CAMARA Security and Interoperability Profile. To ensure interoperability and increased security, this technical specification restricts some options available in OIDC and CIBA, but does not change these standards.

From https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md

This document defines guidelines for operator exposure platform to manage CAMARA API access and user consent to comply with GDPR or equivalent requirements in an easy way, introducing the concept of "purpose" in CAMARA APIs access.

Edit: removed a sentence

Both kind of documents have in common that if the document does not talks about something, then the base-standards still apply.

@Jesus Thanks for your comments

I don’t believe the claim is that network-based authentication in the auth code flow is not documented in the CAMARA-API-access-and-user-consent.md. Rather, I want to emphasize that this does not automatically rule out non-network-based authentication.

For example, we have clearly stated that only poll mode is permitted, even though CIBA allows clients to use three modes. Similarly, we state that clients should not use the acr_values parameter. IMHO, if CAMARA intends to restrict something permitted by the standard, it should be explicitly stated.

However, the more important question from my side is, if an Application Service Provider (ASP) is willing to use the auth code flow with authentication methods other than network-based, and if the Mobile Network Operator (MNO) can support this, what are the reasons for CAMARA to forbid it?

Hi @shilpa-padgaonkar

So my understanding is that this is only about authorisation code flow? Or does this issue include CIBA?

To me, the questions to be addressed are:

• Does the "CAMARA Security and Interoperability Profile" document currently allow other authentication mechanisms?
• Do we (CAMARA) want to allow other authentication mechanisms?

On the first point, I would say yes, that document does, with the caveat that login_hint, if used, must be tel or ipport (so not much use for authentication). But if the authorisation server wants to redirect the client to some authentication or consent page first before returning the code, maybe even respecting the prompt or display parameters, why not have a go? So long as the authorisation server is not requiring some non-compliant parameter use, that shouldn't stop other authorisation servers using network-based authentication should the client be dealing with different authentication servers.

But the issue is "interoperability". Could an API provider using these "alternative" end user authentication methods break a client implementation if that client then tried to authenticate against a different authentication server? I don't see that would be the case, though if anyone has any examples of how that might break the client implementation, that would be important information.

But the end user experience would be different - with some end users getting pop-ups or redirects to some authentication page or whatever, whereas others get nothing at all. And application developers might have an issue ensuring all these different approaches work "nicely" with their app.

So that will inform the second question - how consistent do we want to make the end user and application developer experience across different API providers, even if everything still "works" as far as calling the API is concerned.

The common definition of a specification is that it is normative and guidelines are informative.

Both kind of documents have in common that if the document does not talks about something, then the base-standards still apply.

It's not valid to assume whether something is normative or informative solely based on the document being labeled as a specification or guideline. For instance, the CAMARA-API-access-and-user-consent.md defines a info.description field template, which was reviewed and approved by the TSC, and is absolutely mandatory for all CAMARA API specifications. Another great example of normative content within a guidelines document is the API-design-guidelines.md in the Commonalities WG, which contains a variety of normative definitions.

I don’t believe the claim is that network-based authentication in the auth code flow is not documented in the CAMARA-API-access-and-user-consent.md. Rather, I want to emphasize that this does not automatically rule out non-network-based authentication.

For example, we have clearly stated that only poll mode is permitted, even though CIBA allows clients to use three modes. Similarly, we state that clients should not use the acr_values parameter. IMHO, if CAMARA intends to restrict something permitted by the standard, it should be explicitly stated.

However, the more important question from my side is, if an Application Service Provider (ASP) is willing to use the auth code flow with authentication methods other than network-based, and if the Mobile Network Operator (MNO) can support this, what are the reasons for CAMARA to forbid it?

As for network authentication, the original requirement from App Providers was that they would not accept any deviation in behavior—avoiding operator screens if possible, and ensuring consistent behavior across operators.

This is why the Auth code flow includes network-based authentication and the agreed technical ruleset treats this as the only authentication option.

CAMARA-API-access-and-user-consent.md was approved by the WG and officially released in version 0.1.0, before the profile document. Notably, the profile itself does not specify the authentication mechanisms (nor do the OIDC/CIBA standards), but CAMARA-API-access-and-user-consent.md did limit the use to network-based authentication as agreed by the WG.

If there’s a desire to open the Auth Code flow to other authentication mechanisms, it's not just about determining whether a document is normative or not. Even if CAMARA doesn’t explicitly prohibit alternative methods, it also doesn’t specify them—so interoperability cannot be guaranteed. You would need to propose an issue for CAMARA to define the support and interoperability model for any other authentication method(s) you are considering.

For example, CAMARA would need to define the behavior when dealing with 3-legged tokens that don’t identify a device or phone number, which is currently not defined. Developers would need to know how to handle this, particularly in cases where the API request does not include a device object or phone number due to the use of a 3-legged access token. Keep in mind that CAMARA has continued to work based on the assumption of network-based authentication, which enables the association of 3-legged tokens with a device or phone number (in case of CIBA login_hint is always a phoneNumber or an IP address). And based on that has defined https://github.com/camaraproject/Commonalities/blob/main/documentation/API-design-guidelines.md#appendix-a-infodescription-template-for-device-identification-from-access-token for Fall24 or we are discussing camaraproject/Commonalities#259 for Spring25.

Opening up the Auth Code flow to other authentication methods could introduce scenarios such as user/password-based authentication, where the access token may be linked only to the user, not a specific device or phone number. A single user could have multiple phone numbers under their subscription, with no clear way for the API to determine which device or number the request applies to.

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.

CAMARA-Security-Interoperability.md is a specification that specifies what is needed to ensure security and interoperability on top of OICD and CIBA.

CAMARA-Security-Interoperability.md does not restrict the telco to use a specific authentication method. If the API consumer wants no user interaction they can use prompt=none. The prompt parameter is basic OIDC and CAMARA-Security-Interoperability.md does not mention it. Which is another example of OICD that is not changed by CAMARA-Security-Interoperability.md. API consumers can use prompt as defined by OIDC.

What is not restricted is allowed as long as it is OIDC.

CAMARA-API-access-and-user-consent.md is a guideline that shows how some flows could be implemented if network-based authentication is used.

If the telco is forbidden to use other authentication methods than network-based authentication then there is no user consent in CAMARA in some cases and for some purposes.

The reasoning for this statement is that network-based authentication only just authenticates the subscriber.
Network-based authentication is not user authentication.
Example: If a child is the user, then the subscriber, the parent, may not consent to the child using the CAMARA API.
If a subscriber has more than one contract, then we do not know who the user is, and then there cannot be user consent.
We would exclude all family accounts from using CAMARA.
Another example: a business account where a company provides phones and subscriptions to the company employees. We (probably) need user consent, that is employee consent, which is not subscriber consent. I have a DT phone and would not consent to DT e.g. tracking my location. There is nothing in my contract that allows DT to track me.

ICM does not want to exclude family or business use cases.

So, it is good for us that no ICM document restricts the telco to use the authentication method the telco deems to be appropriate under the use case, purpose and law.

The common definition of a specification is that it is normative and guidelines are informative.
Both kind of documents have in common that if the document does not talks about something, then the base-standards still apply.

It's not valid to assume whether something is normative or informative solely based on the document being labeled as a specification or guideline. For instance, the CAMARA-API-access-and-user-consent.md defines a info.description field template, which was reviewed and approved by the TSC, and is absolutely mandatory for all CAMARA API specifications. Another great example of normative content within a guidelines document is the API-design-guidelines.md in the Commonalities WG, which contains a variety of normative definitions.

I'd like to treat separately the normative/not-normative aspect brought up by @AxelNennker, which is not part of the initial question raised by @shilpa-padgaonkar.
@shilpa-padgaonkar @AxelNennker please confirm that DT asserts that the CAMARA-API-access-and-user-consent.md document is not normative, as then there can be no further debate with a point of this magnitude, which challenges some of the basics written in CAMARA specs.
In that case I would not have a discussion in this thread about this but just a direct query to TSC to evaluate this aspect. @camaraproject/tsc-participants
Some, not all, implications of considering this document not normative:

• Before ICM v0.2.0, CAMARA in fact specified nothing, as this document was part of the deliverable. v0.1.0 of ICM was informative
• Any CAMARA member can search for a word e.g.: guidelines in a document to argument that is not normative. Note: cases exist both in Commonalities and in Release Management
• Some relevant TSC discussions ended with a conclusion to be written in an informative document. I refer to discussions and conclusion about guidelines to document securitySchemes/security and rules to define when to use 3-legged/2-legged (also discussed in GSMA).

Other login methods are valid (and necessary) when user consent needs to be captured

I wholeheartedly agree with the above, but I would remove the parentheses.

Other login methods and network-based authentication are not exclusive.

I do not agree with that the other authentication method MUST be followed by network-based authentication.

Example use case: The user bought a dog-tracker from a vendor and then a sim-card from a telco and the telco provides e.g. username/password for that SIM-card. Then the vendor can use OIDC authentication code flow to request an access token with login_hint=msisdn from the telco for the Camara location API, and the user uses their username/password and because there is just this SIM-card associated with that account (account-id = username maybe = msisdn) then there would be no need for network-based authentication. Which would not work anyway because the authentication device is different)

So, we agree that other authentication methods are valid and necessary although these other authentication methods are not mentioned in CAMARA-API-access-and-user-consent.md, right?

@diegogonmar I agree we should come back to the original issue.

Are other authentication methods allowed although they are not mentioned in ICM documents?
I think the answer is yes.

Other login methods are valid (and necessary) when user consent needs to be captured

Does CAMARA mandate network-based authentication?
I think the answer is no. I think network-based authentication is sometimes needed, but not always.
Please see the dog-tracker example. OAuth2 has the limited-input-capability-devices use case e.g. picture frame.
OAuth2 was created to enable this use-case. And because OIDC is based on OAuth2, CAMARA can build on that.

I think that login_hint is the intended way to convey from the API consumer to the authorization server who/what we are talking about. I think we might currently be missing a formal specification for this in CAMARA-Security-Interoperability.md.

OIDC says:

login_hint
OPTIONAL. Hint to the Authorization Server about the login identifier the End-User might use to log in (if necessary). This hint can be used by an RP if it first asks the End-User for their e-mail address (or other identifier) and then wants to pass that value as a hint to the discovered authorization service. It is RECOMMENDED that the hint value match the value used for discovery. This value MAY also be a phone number in the format specified for the phone_number Claim. The use of this parameter is left to the OP's discretion.

If the user has several subscriptions with the telco, we should specify that login_hint tel: is the way to convey which subscription the authentication request is about.

@AxelNennker can you please edit your comment (#215 (comment)) or reply to it to confirm that DT is no longer indicating that CAMARA-API-access-and-user-consent.md is not normative? I'd like to officialize that, sorry but just saying above that you agree that we should come back to original issue does not confirm the withdrawal of former statement. Thank you

Example use case: The user bought a dog-tracker from a vendor and then a sim-card from a telco and the telco provides e.g. username/password for that SIM-card. Then the vendor can use OIDC authentication code flow to request an access token with login_hint=msisdn from the telco for the Camara location API, and the user uses their username/password and because there is just this SIM-card associated with that account (account-id = username maybe = msisdn) then there would be no need for network-based authentication. Which would not work anyway because the authentication device is different)

If the authentication device is different from the consumption device, this is one of the main reasons to use CIBA flow instead. This is also mentioned in CAMARA-API-access-and-user-consent.md (CIBA ruleset):

If the authentication device is different from the consumption device, this is one of the main reasons to use CIBA flow instead. This is also mentioned in CAMARA-API-access-and-user-consent.md (CIBA ruleset):

IdentityAndConsentManagement/documentation/CAMARA-API-access-and-user-consent.md

Line 288 in 54c68c4

If some usecase/s for an API point to off-net scenarios and where consumption and authentication devices could be different, the Backend flow should be used.

@jpengar
There are two aspects regarding your comment that I want to address here:

1. I gave an example how authorization code flow might be the best choice for the client and in which we do not need network-based authentication and other authentication methods are sufficient. In the example the API provider needs to collect consent from the user before the API provider creates an access token for the tracker vendor (API consumer). The API provider authenticates the user and then the user grants access e.g. to CAMARA's DeviceLocation API for the dog-tracker. In the example the user is already on a device with high input capabilities and the device the API applies to is not identified by network-based authentication.

2. Yes, CIBA was designed to handle some use cases (CIBA examples) where consumption device and authentication device are different.
   That does not mean that all use cases with two devices are optimally handled by CIBA and it does not mean that the client MUST use CIBA.
   In CIBA the client offloads the task of contacting the authentication device to the communications provider. There is no need for that in this example because the user already is on the authentication device when registering the doc-tracker in either the vendor's website or the vendor's mobile app. I think that OIDC authorization code flow is the best fit for the example that enables the API consumer to use CAMARA's DeviceLocation API.

CAMARA-API-access-and-user-consent.md recommendation for CIBA is valid for consumption-device and authentication device use cases. The example does not fall into the category because the doc-tracker is no consumption device.

CIBA does not make sense in the example because the user is already on the authentication device.
Network-based authentication does not make sense in the example because the doc-tracker device is not communicating.

OIDC authorization code flow is the flow that is best in the example. As defined in OIDC the login_hint parameter contains the MSISDN the request is about.

So my understanding is that this is only about authorisation code flow? Or does this issue include CIBA?

@eric-murray
Yes, this issue is about authorization code flow, not about CIBA.
In CIBA the method how the MNO contacts the authentication device is for the MNO to decide.
In CIBA the MNO can send an SMS, MMS, RCS or a Push Notification. It is up to the MNO to decide which channel is best.
Also the MNO can decide whether the message contains a text and code, or a link, or whatever.

Operators can choose the consent capture mechanism that best suits their capabilities, preferences and needs

Our document https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md shows this in the sequence diagram between step 5 and 6
https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md#ciba-flow-backend-flow

Out Of Band Consent Capture (Push/SMS/other)

Comming back to OIDC authorization code flow and this issue.
https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md#authorization-code-flow-frontend-flow states refers to OIDC consent in the sequence diagram.

3.1.2.4. Authorization Server Obtains End-User Consent/Authorization

Once the End-User is authenticated, the Authorization Server MUST obtain an authorization decision before releasing information to the Relying Party. When permitted by the request parameters used, this MAY be done through an interactive dialogue with the End-User that makes it clear what is being consented to or by establishing consent via conditions for processing the request or other means (for example, via previous administrative consent). Sections 2 and 5.3 describe information release mechanisms.

I think that CAMARA-API-access-and-user-consent.md clearly states that the basis for End-User Consent is OIDC 3.1.2.4.

Scenario 2: Consent is required and not yet provided by user (Step 8)

The operator performs the consent capture following Section 3.1.2.4 of the OpenID Connect Core 1.0 specification. Since the authorization code grant involves the frontend, the consent can be captured directly from the user.
Once the user has given consent, the authorization code flow continues by redirecting to the API invoker redirect_uri (invoker_callback) and including the authorization code (OperatorCode).

I removed my comment as requested. The more important point is that CAMARA-API-access-and-user-consent.md deferres to OIDC core consent collection.

According to the solution agreed upon and documented in CAMARA-API-access-and-user-consent.md, as of today, CAMARA currently only considers network-based authentication in the Authorization Code Flow. Therefore, tokens are issued for the network authenticated identifier. Based on this, Telefónica proposes to close the issue with this conclusion.

We agree that, as part of the in-band consent capture (as per section 3.1.2.4 of the OIDC Core 1.0 specification), CAMARA does not prevent operators from using any additional authentication mechanisms deemed necessary to authenticate the user who owns the network-authenticated device e.g. such as a username/password prompt, if a higher level of assurance is required for the operator to capture consent.

This approach ensures that the access token obtained at the end of the flow accurately reflects the authenticated status of the user's network-authenticated device, preserves UX continuity, minimises unnecessary prompts, and meets OIDC security standards by defaulting to network authentication and requiring further user interaction only when necessary.

NOTE: As mentioned by @eric-murray in #191 (comment), the agreed definitions in https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md#glossary-of-terms-and-concepts are used, in particular the definition of user.

updated.

CAMARA does not restrict the telco/MNO/API producer to a single authentication method.
If we restrict the authentication to network-based authentication, then we exclude valuable business cases.

• if the subscriber has more than one subscription, then the MNO cannot be sure that the subscriber equals the user. CAMARA can do more because OIDC core standard is all about End-User authentication and End-User consent collection. If the End-User authenticates and gives their consent, we can issue an access token for the requested CAMARA API.
• if the subscription is a business contract then we would have to reject the request if we only have network-based authentication, because we do not know whether the user is the contract owner. With user authentication the contract owner can authenticate and consent can be collected.

CAMARA authorization code flow is based on OIDC authorization code flow with some interop and security specifications in CAMARA-Security-Interoperability.md.

If the API consumer does not want any user interaction, then they can use the OIDC standard parameter prompt=none in the OIDC authentication request.
It is then for the API producer to decide whether this is legal under e.g. GDPR or whether the data-subject has to be authenticated and grant consent.

Please have a look at Mandatory to Implement Features for All OpenID Providers:

Mandatory to Implement Features for All OpenID Providers

All OpenID Providers MUST implement the following features defined in this specification. This list augments the set of features that are already listed elsewhere as being "REQUIRED" or are described with a "MUST", and so is not, by itself, a comprehensive set of implementation requirements for OPs.

• Signing ID Tokens with RSA SHA-256
  OPs MUST support signing ID Tokens with the RSA SHA-256 algorithm (an alg value of RS256), unless the OP only supports returning ID Tokens from the Token Endpoint (as is the case for the Authorization Code Flow) and only allows Clients to register specifying none as the requested ID Token signing algorithm.
• Prompt Parameter
  OPs MUST support the prompt parameter, as defined in Section 3.1.2, including the specified user interface behaviors such as none and login.
• Display Parameter
  OPs MUST support the display parameter, as defined in Section 3.1.2. (Note that the minimum level of support required for this parameter is simply that its use must not result in an error.)
• Preferred Locales
  OPs MUST support requests for preferred languages and scripts for the user interface and for Claims via the ui_locales and claims_locales request parameters, as defined in Section 3.1.2. (Note that the minimum level of support required for these parameters is simply to have their use not result in errors.)
• Authentication Time
  OPs MUST support returning the time at which the End-User authenticated via the auth_time Claim, when requested, as defined in Section 2.
• Maximum Authentication Age
  OPs MUST support enforcing a maximum authentication age via the max_age parameter, as defined in Section 3.1.2.
• Authentication Context Class Reference
  OPs MUST support requests for specific Authentication Context Class Reference values via the acr_values parameter, as defined in Section 3.1.2. (Note that the minimum level of support required for this parameter is simply to have its use not result in an error.)

Also please have a look at OIDC definition of the prompt parameter which is mandatory to implement for all OpenId providers. Please note that OIDC uses "End-User"

• None https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint:~:text=returned%20if%20an-,End%2DUser,-is%20not%20already
• Login https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint:~:text=SHOULD%20prompt%20the-,End%2DUser,-for%20reauthentication.%20If
• Consent https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint:~:text=SHOULD%20prompt%20the-,End%2DUser,-for%20consent%20before
• Select_account https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint:~:text=SHOULD%20prompt%20the-,End%2DUser,-to%20select%20a

Consent according to GDPR is given by the data-subject. The glossary entry for "user" does not change that.

CAMARA APIs are much more attractive to API consumers if we follow the standards as specified in https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md

Thanks @jpengar

To understand your argument I would like to ask clarifying questions.

We agree that, as part of the in-band consent capture (as per section 3.1.2.4 of the OIDC Core 1.0 specification), CAMARA does not prevent operators from using any additional authentication mechanisms deemed necessary to authenticate the user who owns the network-authenticated device e.g. such as a username/password prompt, if a higher level of assurance is required for the operator to capture consent.

Does the operator decide whether end-user authentication and consent collection is needed? If there is prompt=none in the request then there is not end-user interaction and if the operator thinks that end-user interaction is needed then the operator returns an error to the prompt=none request.

Example use cases:
Are we all OK with that if network-based authentication identifies a business subscription that the MNO can then use other authentication methods?

Are we all OK with that if network-base authentication identifies a subscription where the contract holder has several subscriptions, that then the MNO can use other authentication methods?

I think the general point here is that the MNO decides about if and how end-user authentication and consent collection is done. With the exception that of prompt=none.

Network-base authentication identifies the device from which the request is being made from, but if the MNO decides that end-user interaction is needed then the MNO is not retricted by CAMARA how to implement that user interaction.

To your argument about consent collection: Does CAMARA restrict the MMN when to do consent collection?
Your argument is: If there is "in-band consent capture" the the MNO is free.
My question: Is the MNO also free to decide IF consent collection is needed?

Maybe we need a guideline/clarification in https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md?

With the following 3 comments:
#215 (comment), #215 (comment) and #215 (comment),

I can close the issue with the following concluding statement:

1. It is up to the operator to make a decision when consent collection is needed or not,
2. CAMARA does not restrict the telco/MNO/API producer from using additional authentication methods when consent is needed.

I can close the issue with the following concluding statement:

1. It is up to the operator to make a decision when consent collection is needed or not,
2. CAMARA does not restrict the telco/MNO/API producer from using additional authentication methods when consent is needed.

As agreed in yesterday's WG call (minutes), here is a proposed amendment to the issue conclusion that Telefónica is comfortable with:

• It is up to the operator to make a decision when consent collection is needed or not,
  • based on the scope(s)/purpose declared by the API client and aligned with local legislation, ensuring that all operators under the same regulatory framework adopt a consistent approach.
• Currently, CAMARA only considers network-based authentication in the Authorization Code Flow. Therefore, access tokens are issued for the network authenticated identifier.
• CAMARA does not prevent the telco/MNO/API producer from using additional authentication methods as part of the in-band consent capture process when consent is needed.

Are we all OK to close the issue as per the above conclusion?

Can we find a wording that the above also works for operator tokens?

Currently, CAMARA only considers network-based authentication in the Authorization Code Flow. Therefore, access tokens are issued for the network authenticated identifier.

Can we find a wording that the above also works for operator tokens?

This issue was originally intended to clarify the authentication method for the Auth Code flow as defined by CAMARA today. I don't see operator tokens in the scope of this issue discussion.

Also, the use of operator tokens is something that will be discussed and included in Spring25 and not in the current Fall24 meta-release. CAMARA has so far defined an additional possible value for the operator token as login_hint (besides MSISDN and IP), which CAMARA has so far only discussed for CIBA. The login_hint has never been discussed for the auth code flow, because it is not needed, since the subscription identity is known anyway from network-based authentication.

So I am still kindly asking the WG if this issue can be closed in the conclusion written above.