Clarity on the use of login_hint

[shilpa-padgaonkar]

Problem description
The Camara OIDC profile includes text on login_hint format.

Can we interpret this section as :

• login_hint is applicable for both Authorization Code Flow and CIBA flow and
• it is mandatory to use login_hint for both grant_types

Expected behaviour
Confirm or provide different interpretation of the above understanding and document this clearly in the profile.

Alternative solution

Additional context

[eric-murray]

I don't see the value of login_hint for Authorisation Code Flow when the network itself can identify the end user subscription. If that parameter is present in the authentication request, it must be ignored.

[jpengar]

CAMARA OIDC profile definition on login_hint refers to CIBA flow. The profile makes the login_hint parameter REQUIRED and it only allows the use of login_hint for CAMARA among the hint options specified in the CIBA standard: login_hint_token, id_token_hint or login_hint.

And in particular, for CIBA login_hint, defines the format described in: Format of login_hint

If this is not properly understood from a document reader perspective, the document content could be improved to address this issue in the next release along with other backlogged text improvements already raised in the WG.

CC @AxelNennker @sebdewet

[AxelNennker]

CAMARA OIDC profile definition on login_hint refers to CIBA flow. The profile makes the login_hint parameter REQUIRED and it only allows the use of login_hint for CAMARA among the hint options specified in the CIBA standard: login_hint_token, id_token_hint or login_hint.

And in particular, for CIBA login_hint, defines the format described in: Format of login_hint

If this is not properly understood from a document reader perspective, the document content could be improved to address this issue in the next release along with other backlogged text improvements already raised in the WG.

The format of login_hint is intentionally outside the flows and just specifies the format.
The specification of the format is the same for all flows that have a login_hint.

In OIDC, login_hint is a hint, intended to indicate to the openid provider, which user identifier to prefill into a HTML form and there into a text field that holds the user identifier.
OpenId does not specify how the user authentication is performed, if the user authentication is username/password then login_hint is intended to be the prefilled value of username. The user can edit the username and login using a different one if they know credentials for that username / user identifier. login_hint is a convenience for the user who then do not have to remember the username.

To quote OIDC:

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.

Camara does not specify anything more than the format of login_hint.

In CIBA login_hint hints to the authorization server which user to contact e.g. by sending an SMS to the value of login_hint. Otherwise how should the CSP know whom to contact?

To answer @shilpa-padgaonkar 's questions

• Is login_hint applicable for both Authorization Code Flow and CIBA flow? yes as per OIDC and CIBA spec.
• Is it mandatory to use login_hint for both grant_types? no But in CIBA there needs to be one hint, and because Camara only allows login_hint and not id_token_hint and not token_hint, and from that it follows that login_hint is mandatory for CIBA in Camara.

[AxelNennker]

I don't see the value of login_hint for Authorisation Code Flow when the network itself can identify the end user subscription. If that parameter is present in the authentication request, it must be ignored.

@eric-murray login_hint is a hint and "The use of this parameter is left to the OP's discretion".
If "the network" can identify the subscription then the authorization server might ignore the hint.
Or not.
If the client sends information that helps the user pick a username then the authorization server might honor that.
Of course if there is some username choice.
If the authorization server insists it know better then the "left to the OP's discretion" part comes into play.

Camara and OIDC and CIBA, in general, leaves the (user) authentication method open. If the user authentication is username password, then login_hint makes sense.

NumberVerification insists on network authentication. For NumberVerification login_hint does probably make not much sense and the authorization server can ignore it. No need to specify anything, because the standards leaves this to the OP's discretion.

If an API has an use-case where login_hint is required, then the API should specify that in its "authentication section".

[AxelNennker]

@shilpa-padgaonkar can we close this?

[eric-murray]

login_hint is a hint and "The use of this parameter is left to the OP's discretion".
If "the network" can identify the subscription then the authorization server might ignore the hint.
Or not.

In general, yes, but for CAMARA, no. The authorisation server must ignore any login_hint in the authorisation code flow authentication request. The login_hint can only be tel: or ipport:. But the device IP/port will anyway be in the data packet received by the /authorize endpoint, and the device phone number will either be in a header added by the network operator, or derived directly from the public IP / port. There is no value in the login_hint itself.

If an API wants to add a use case that requires, for example, username / password to be provided in the login_hint, they will run up against the restriction that v0.2.0 of the ICM guidelines do not allow this. We should avoid the situation that APIs specify requirements that are not compliant with ICM guidelines without first making some attempt to modify the guidelines.

[AxelNennker]

@eric-murray

But the device IP/port will anyway be in the data packet received by the /authorize endpoint, and the device phone number will either be in a header added by the network operator, or derived directly from the public IP / port.

Where is this written?

I think this assumes a flow that is maybe assumed by the majority of the MNOs but not necessarily true.

Imaging a client sending an authorization code flow request to the authorization server and the AZ allows the user to authenticate with username/password, and the user gives their consent to QoD for their phone number, and then an access token is created, and then that access token is used in e.g. QoD by API consumer, and the CSP is fulfilling the QoD API request. Maybe the user has exactly one phone number to which QoD is applicable or the AZ asked for consent for all of the user's phonenumbers or allows the user to choose for which they grant QoD consent.

Why should we/Camara restrict ourselves to network authentication?

More and more user stories use the term Communication Service Provider which I think is a good thing because CSP can be more than MNO. How the CSP authenticates their user is up to them. Maybe the CSP is providing Internet access and there is not even a phonenumber but a network identifier. Still the CSP might offer QoD. Maybe that CSP is using email addresses as user identifiers - we would adapt login_hint format then. That would apply then to CIBA as well.

I think forbidding login_hint for authorization code flow is unnecessary. It is just a hint anyway.

I think Camara is about network APIs, which is not restricted to mobile networks. But even for mobile networks non-network-authentication can make sense.

[sfnuser]

While I agree with @AxelNennker on the idea that using login_hint on both flows gives flexibility, I believe it needs to be clarified in ICM guidelines as proposed by @eric-murray. For CIBA flow, it is implied as there is no other option and with Authorization Code Flow, it is not the case. What if some CSPs handle login_hint and some ignore it? The purpose of the CAMARA Security and Interoperability Profile is to avoid such situations. We already clarify usage of optional parameters like acr_values and it shouldn't be an issue to clarify it's usage in the profile if there is a clear demand.

[eric-murray]

@AxelNennker

But the device IP/port will anyway be in the data packet received by the /authorize endpoint, and the device phone number will either be in a header added by the network operator, or derived directly from the public IP / port.

Where is this written?

IP packets have a well defined structure specified by IETF. Hopefully it is a reasonable assumption that the client is using TCP/IP or UDP/IP. Header enrichment is "defined" as an option by Mobile Connect (IDY.04), but implementation itself is not standardised.

Why should we/Camara restrict ourselves to network authentication?

CAMARA already do restrict the authorisation code flow to network based authentication, where it is clearly defined in our own guidelines that network based authentication must be used.

I think forbidding login_hint for authorization code flow is unnecessary. It is just a hint anyway.

That's not what I said. I did not propose forbidding the use of login_hint in the authorisation code flow. I said, if present, it must be ignored. An error must not be generated just because it is present. But I do not see any use for login_hint in the authorisation code flow that is compliant with our current guidelines.

[shilpa-padgaonkar]

My 2 cents on this:

I do not agree that our Camara profile or the guideline doc restricts authorization code flow to use only the network based authentication.

From the APIs perspective, only the number verify API spec explicitly mentions "Network-Based Authentication".

I agree that the guideline doc explains the frontend flow with network based authentication, but I see this as follows:
Since number verify was the only API which was already certain about using only the frontend flow, and it uses network based auth, this is what is explained in the guidelines doc.
This does not imply that other APIs which could use authorization code flow cannot use other authentication methods supported by OIDC.

I see no statement in both guideline doc or the profile which explicitly says that amongst the authentication methods allowed by OIDC, in Camara we ONLY allow network based authentication.

[jpengar]

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.

[shilpa-padgaonkar]

Since the original issue was created to discuss a completely different point, I have opened a new issue for this topic as it is an important discussion and needs its own dedicated issue #215

[AxelNennker]

.... But I do not see any use for login_hint in the authorisation code flow that is compliant with our current guidelines.

@eric-murray

Do you agree that when consent is needed that then user authentication is needed?

Do you agree that for user consent the operator must authenticate the user?

Do you agree that network-based authentication does authenticate the subscriber?

Do you agree that network-base authentication does NOT authenticate the user?
Example: I have several subscriptions with TGD which are used by family members. Network-based authentication and any consent based on it without user authentication would mean that I, the subscriber, consented which is not true if a family member uses my subscription.

Do you agree that consent must be collected by the operator?

OIDC provides user authentication as shown in the authentication code flow in CAMARA-API-access-and-user-consent.md

The standard OIDC authorization code flow parameter login_hint can be used by the operator in this step.
That is the step where the use of login_hintin authorization code flow is compliant with our current guidelines.

The parameter login_hint allows the operator to implement the best user interface.

BTW: if the API consumer does not want a user interaction then they can use the standard OIDC parameter prompt=none to indicate that.

[eric-murray]

@AxelNennker

So you talk about "user authentication" and "user consent", but we have an agreed definition of "user" as follows:

User: the client/subscriber of the telco operator, identified by a unique user identifier (e.g. subject identifier sub in OpenID Connect terminology). The user is the resource owner. Usually the user corresponds to the end user, but this is not always the case. For example, a parent may be the user of a mobile subscription for their children.

So I have a feeling that you really mean "end user". Inconsistent use of terminology makes it really hard to follow these discussions.

That is the step where the use of login_hint in authorization code flow is compliant with our current guidelines.

Our current specification limits login_hint to be either tel: or ipport:. So, assuming you mean "end user consent", I don't see how either of these options used in the authorisation code flow can identify an end user who is different to the user. But I'm happy to be corrected. And both tel: and ipport: can be identified by network-based authentication, so including login_hint to the /authorize endpoint call adds no information.

If the answer is to introduce new options for login_hint (such as endusername), then that is a change to our current specification.

[AxelNennker]

@AxelNennker

So you talk about "user authentication" and "user consent", but we have an agreed definition of "user" as follows:

User: the client/subscriber of the telco operator, identified by a unique user identifier (e.g. subject identifier sub in OpenID Connect terminology). The user is the resource owner. Usually the user corresponds to the end user, but this is not always the case. For example, a parent may be the user of a mobile subscription for their children.

So I have a feeling that you really mean "end user". Inconsistent use of terminology makes it really hard to follow these discussions.

That is the step where the use of login_hint in authorization code flow is compliant with our current guidelines.

Our current specification limits login_hint to be either tel: or ipport:. So, assuming you mean "end user consent", I don't see how either of these options used in the authorisation code flow can identify an end user who is different to the user. But I'm happy to be corrected. And both tel: and ipport: can be identified by network-based authentication, so including login_hint to the /authorize endpoint call adds no information.

If the answer is to introduce new options for login_hint (such as endusername), then that is a change to our current specification.

OIDC speaks about end-users never about subscribers.

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.

GDPR uses the term data subject in the sense of "person" that is "end-user".
So, whenever consent is needed then user means end-user.

A data-subject as defined by "Art. 4 GDPR Definitions":

‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

If you forbid end-user authentication in CAMARA then we would lose a huge percentage business.

CAMARA-API-access-and-user-consent.md refers to OIDC and OIDC means end-user authentication.

I claim that CAMARA-API-access-and-user-consent.md thus enables login_hint because that is OIDC Core spec.

[eric-murray]

OIDC speaks about end-users never about subscribers.

But CAMARA have a glossary, and that defines "User" in terms of a telco subscriber. As CAMARA have an approved glossary, we should use it. If it needs to be modified or extended, that should be done rather than ignoring it and using alternative definitions.

I claim that CAMARA-API-access-and-user-consent.md thus enables login_hint because that is OIDC Core spec.

I agree. I never claimed it was not allowed, only that it served no purpose as currently defined. The prefixes for login_hint are limited by the interoperability profile to tel: and ipport:. Whilst a sensible implementation would just ignore unrecognised or useless values, there is nothing to say it is wrong for an implementation to throw an invalid_request error if login_hint uses a different prefix.

So an API consumer (client) using "non-standard" values for login_hint may cause interoperability issues. If you want to use additional identifiers for login_hint, you really need to introduce them into CAMARA.

Alternatively, add a rule that any login_hint prefix not recognised by an implementation should be ignored and not rejected with an error. That way, an API provider can use whatever values for login_hint that they can persuade the application provider to include. If an API provider ignores it and is consequently breaching GDPR, I don't see that as being either CAMARA's nor any other API provider's problem.

[HuubAppelboom]

@eric-murray @AxelNennker @Elisabeth-Ericsson all,

At KPN we are currently using the login_hint for 2 purposes:

First of all, we use it as an extra security measure to prevent that end users can start 2 simultaneous authorization code flow number verifcation sessions. One of them has the right sim, the other one (a fraudster) doesn't, but in our implementation may try to eavesdrop on the communication of the right sim. If we spot 2 simultaneous session with the same msisdn, we abort the flow with an error. To make this work, you need to put the msisdn in the login_hint.

We also use it to signal that a particular session is a session for a sandbox withouth a real sim card.

[eric-murray]

Thanks @HuubAppelboom

The issue where this was being discussed for authorisation code flow was #232, but I will answer here.

For both these use cases, I assume you are using login_hint="tel:<MSISDN>", so "CAMARA compliant". But neither are CAMARA use cases, and so an implementation should still be allowed (by CAMARA) to ignore such a login_hint.

For the first, the scenario is not clear. Is this is a MITM scenario, or has the fraudster connected via the customer's device (e.g. if they enabled Wi-Fi tethering), or are they running some rogue app on the customer's device that is somehow intercepting the genuine authorisation request? The suggestion is MITM, but the \authorize endpoint should be TLS protected (or soon, if not already), and such interception should then not be possible.

For the second, Vodafone have a "non-prod" /authorize endpoint, so sandboxed requests do not (or should not) use our production endpoint. In any case, the header enrichment, and hence the flow, would fail if reaching our production endpoint from any device other than one of our UEs.

[HuubAppelboom]

@eric-murray For the first case we are still using header enrichment, for which a MITM attacker intercepts traffic between the customer device and the heather enrichment service in the home network. The phone number in the login_hint should be the one the end user claims to have. Please note that the attacker could be anywhere, especially in a roaming situation. We have this now for header enrichment, and it won't be needed if we move to a 100% TLS solution, but it could be also useful for other MITM scenarios. Why would a user be doing simultaneous number verifications ?

In our sandbox scenario, we can let developers test from any device without sim cards, and they get the same account credentials as when they move to production with real sim cards (by us flipping a switch).

[jpengar]

@Elisabeth-Ericsson @HuubAppelboom @eric-murray @AxelNennker

I would like to make one comment regarding the use of login_hint, which was the original issue at hand. Telefónica does indeed support and utilise login_hint in Auth code flow for our own internal uses cases (as we do for other standard features and/or authentication flows not mentioned or specified by CAMARA). However, I would like to reiterate that our discussion here is focused on the multi-operator use cases defined by CAMARA. For those use cases, the CAMARA documentation does not address the use of login_hint in the authentication code flow (considered not needed when using network-based auth). The discussion of login_hint has always been in the context of CIBA. The objective of CAMARA is to define the behaviour to be applied in multi-operator scenarios in order to guarantee the highest level of interoperability. This is the reason why we decided to create a CAMARA profile in the first place.

This is the current status quo, but new discussions are underway about the possibility of incorporating login_hint into the Auth code flow in CAMARA (such as new issue #232 in the context of operator token) for Spring25 or future releases. This could result in the creation of new CAMARA definitions for login_hint in the auth code flow, or it may not.

@shilpa-padgaonkar If you agree that login_hint was not previously addressed in the context of auth code flow, this should be sufficient to close this issue. Let us then proceed to discuss in the new issues whether CAMARA is required to consider the login hint in the authentication code flow (and how), or not, in accordance with the WG opinion.