Allow to use operator_token (from TS43) to identify device on authentication request

[Elisabeth-Ericsson]

Problem description GSMA's TS.43 WG describes a process where an unprivileged 3rd-Party mobile app requests an operator token from the opertor's entitlement server. Operators have control over operator token issuance because of an TS.43 access_token that is validated at the entitlement server.

The operator token is an encrypted, selfcontained token which is usually encrypted to an entity that is dependent on clientId. The operatorToken can contain any information that is known by the Entitlement Server about the subscription.

The TS.43 flow works on any HTTPS connection e.g. on a Wifi connection in addition to On-Net scenarios.

Working with an operator token instead of MSISDN or device IP will add additional security.

As of today, the CIBA flow allows to pass a parameter called "login_hint_token", providing a potential mechanism for sending the operator token, however the AuthCode flow does not.

Possible evolution Adding the operator-token to the URL on the access token request on the /authorize and /bc-authorize request will allow to send in the operator token in a standard compliant way.

Alternative solution Another option would be to extend Authcode flow and CIBA flow with a new parameter, allowing to pass the operator_token. This parameter should be specific to the operator token and implicitly carry information about the format.

Additional context

[AxelNennker]

For reference, here is the link to the current version (11) of the TS.43 spec https://www.gsma.com/newsroom/wp-content/uploads//TS.43-v11.0-Service-Entitlement-Configuration.pdf

Section 14 Device App authentication with OperatorToken

[AxelNennker]

Hi @Elisabeth-Ericsson,

are the following examples for the two options you mention?

Option "new-parameter":

GET /authorize?
    response_type=code
    &scope=openid%20dpv%3AFraudPreventionAndDetection%20check-sim-swap%20retrieve-sim-swap-date
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
    &operator_token=eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
     OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
     ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
     Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
     mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
     1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
     6UklfCpIMfIjf7iGdXKHzg.
     48V1_ALb6US04U3b.
     5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
     SdiwkIr3ajwQzaBtQD_A.
     XFBoMYUZodetZdvTiFvSkQ
Host: server.example.com

Line-breaks for display purposes only. JWE copied from JWE-RFC.

Option "standard":

GET /authorize?
    response_type=code
    &scope=openid%20dpv%3AFraudPreventionAndDetection%20check-sim-swap%20retrieve-sim-swap-date
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
    &login_hint=eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
     OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
     ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
     Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
     mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
     1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
     6UklfCpIMfIjf7iGdXKHzg.
     48V1_ALb6US04U3b.
     5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
     SdiwkIr3ajwQzaBtQD_A.
     XFBoMYUZodetZdvTiFvSkQ
Host: server.example.com

OIDC defines login_hint as:

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.

Or use CIBA's login_hint_token?

login_hint_token OPTIONAL. A token containing information identifying the end-user for whom authentication is being requested. The particular details and security requirements for the login_hint_token as well as how the end-user is identified by its content are deployment or profile specific.

The operator token can contain any information the Entitlement Server knows after EAP-AKA.

Should this issue be named "Allow to use operator_token (from TS43) to identify device on authentication request" https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.7.1

[Elisabeth-Ericsson]

In the long run it would be good if we could use the operator token on the authentication request (authorization code request) as well as on the CIBA request.

It will be rather straight forward to use it on the authorization code request (in line with the two examples). It is not so straight forward, but even more beneficial on the CIBA request. It requires to pass the token from the UE to the application backend, which sends the request to the service provider, but now the target UE is authenticated.

So if we rename the issue, I'm afraid that the CIBA flow is out.

[AxelNennker]

In the long run it would be good if we could use the operator token on the authentication request (authorization code request) as well as on the CIBA request.

It will be rather straight forward to use it on the authorization code request (in line with the two examples). It is not so straight forward, but even more beneficial on the CIBA request. It requires to pass the token from the UE to the application backend, which sends the request to the service provider, but now the target UE is authenticated.

So if we rename the issue, I'm afraid that the CIBA flow is out.

I actually re-checked CIBA, and in both CIBA and OIDC the request is named "authentication request". https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.7.1 I think "authentication request" in the new name of this issue does not exclude CIBA.

CIBA example using login_hint_token and the same JWE as in the other examples

POST /bc-authorize HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded

   scope=openid%20email%20example-scope&
   client_notification_token=8d67dc78-7faa-4d41-aabd-67707b374255&
   binding_message=W4SCT&
   login_hint_token=eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
     OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
     ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
     Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
     mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
     1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
     6UklfCpIMfIjf7iGdXKHzg.
     48V1_ALb6US04U3b.
     5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
     SdiwkIr3ajwQzaBtQD_A.
     XFBoMYUZodetZdvTiFvSkQ&
   client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
   client-assertion-type%3Ajwt-bearer&
   client_assertion=eyJraWQiOiJsdGFjZXNidyIsImFsZyI6IkVTMjU2In0.eyJ
   pc3MiOiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHB
   zOi8vc2VydmVyLmV4YW1wbGUuY29tIiwianRpIjoiYmRjLVhzX3NmLTNZTW80RlN
   6SUoyUSIsImlhdCI6MTUzNzgxOTQ4NiwiZXhwIjoxNTM3ODE5Nzc3fQ.Ybr8mg_3
   E2OptOSsA8rnelYO_y1L-yFaF_j1iemM3ntB61_GN3APe5cl_-5a6cvGlP154XAK
   7fL-GaZSdnd9kg

I think "access token request" is wrong in the name and that "authentication request" covers all bases.

[Elisabeth-Ericsson]

renaming of issue done

[AxelNennker]

For completeness the CIBA-new-parameter variant of the example:

POST /bc-authorize HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded

   scope=openid%20email%20example-scope&
   client_notification_token=8d67dc78-7faa-4d41-aabd-67707b374255&
   binding_message=W4SCT&
   operator_token=eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
     OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
     ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
     Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
     mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
     1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
     6UklfCpIMfIjf7iGdXKHzg.
     48V1_ALb6US04U3b.
     5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
     SdiwkIr3ajwQzaBtQD_A.
     XFBoMYUZodetZdvTiFvSkQ&
   client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
   client-assertion-type%3Ajwt-bearer&
   client_assertion=eyJraWQiOiJsdGFjZXNidyIsImFsZyI6IkVTMjU2In0.eyJ
   pc3MiOiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHB
   zOi8vc2VydmVyLmV4YW1wbGUuY29tIiwianRpIjoiYmRjLVhzX3NmLTNZTW80RlN
   6SUoyUSIsImlhdCI6MTUzNzgxOTQ4NiwiZXhwIjoxNTM3ODE5Nzc3fQ.Ybr8mg_3
   E2OptOSsA8rnelYO_y1L-yFaF_j1iemM3ntB61_GN3APe5cl_-5a6cvGlP154XAK
   7fL-GaZSdnd9kg

We might or we might not treat the operator_token parameter as a "hint". To avoid contradicting parameters CIBA insists that there is exactly ONE hint. BUT the operator_token is authoritative when is comes to which device did the EAP-AKA SIM-authentication and the "hints" are the user identifier (not the subscription). So, it might make sense to have the operator token as a device identifier and the hint as a user identifier. E.g.: the consumption device is a (family) 5G-VR-headset with its own SIM-card and the user (kid) enters a smartphone mobile number (of their parent) to indicate which device is the authentication device. I made this use-case up on the fly - may contain traces of nuts.

[garciasolero]

For the CIBA flow, there is no need to add a new parameter outside the standard. We can use the login_hint parameter, which is already included in the profile, by defining a new operator_token (tentative) prefix.

An example of a bc-authorize call could be:

POST /bc-authorize HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded

   scope=openid%20example-scope&
   login_hint=operator_token:eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
     OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
     ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
     Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
     mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
     1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
     6UklfCpIMfIjf7iGdXKHzg.
     48V1_ALb6US04U3b.
     5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
     SdiwkIr3ajwQzaBtQD_A.
     XFBoMYUZodetZdvTiFvSkQ&
   client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
   client-assertion-type%3Ajwt-bearer&
   client_assertion=eyJraWQiOiJsdGFjZXNidyIsImFsZyI6IkVTMjU2In0.eyJ
   pc3MiOiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHB
   zOi8vc2VydmVyLmV4YW1wbGUuY29tIiwianRpIjoiYmRjLVhzX3NmLTNZTW80RlN
   6SUoyUSIsImlhdCI6MTUzNzgxOTQ4NiwiZXhwIjoxNTM3ODE5Nzc3fQ.Ybr8mg_3
   E2OptOSsA8rnelYO_y1L-yFaF_j1iemM3ntB61_GN3APe5cl_-5a6cvGlP154XAK
   7fL-GaZSdnd9kg

In this case. we think the hint in the AuthCode flow is unnecessary because once the application gets the operator’s token the user is already authenticated, and there is no further need to use this flow from the consumption device to authenticate. The application can use the CIBA flow directly instead of using a complex AuthCode flow through redirects with the user's browser.

[AxelNennker]

@garciasolero thank you for that proposal. I agree, we could use login_hint=operator_token:eyJhbGc... and be CIBA compliant.

In this case. we think the hint in the AuthCode flow is unnecessary because once the application gets the operator’s token the user is already authenticated, and there is no further need to use this flow from the consumption device to authenticate. The application can use the CIBA flow directly instead of using a complex AuthCode flow through redirects with the user's browser.

The primary authentication in AcquireOperatorToken is the authentication of the SIM-Card using EAP-AKA. Then the operator token can be used to get a Camara access token.

[AxelNennker]

Regarding login_hint=operator_token:eyJhbGc...

I think that all depends for what the operator token is used and I think that e.g. for MFA and the operator token being one of the factors we might be better of with a new parameter operator_token. There are certainly different options to explore. And use case: NumberVerification, Onboarding, Wallet Hardware-binding to SIM, silentauth2, wifiauth, ...

OpenId and CIBA were created to use the OAuth2 Authorization Framework as the basis for an User Authentication Framework. OIDC is hugely important today and a big success. But the work continues e.g. in FAPI. People struggling in OIDF WGs and IETF and GSMA (e.g. ASAC) specifying the next useful thing they can agree on.

This issue is about exploring the options of how to use the operator token in authentication request. I think a new parameter is a good idea, fully knowing that introducing one does have its cost and not all telcos and their vendors are too happy going that path.

@sebdewet objections on Orange's behalf regarding the purpose parameter come to mind. And in the end ICM decided not to introduce the purpose parameter. But we need to make progress and the operator token is really an operator asset that we should leverage. Maybe for the price of a new operator_token parameter.

[garciasolero]

@AxelNennker,

I agree that standards can evolve, but they tend not to do so in the short term. Moreover, some operators have already reported that there could be a problem because their solutions are based on frameworks/libraries that strictly implement the standards and do not allow them to extend the behaviour (e.g. adding new parameters). This problem could also occur in the client libraries used by the applications.