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

Elisabeth-Ericsson · 2024-04-15T08:13:55Z

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 · 2024-04-15T14:31:59Z

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 · 2024-05-29T07:28:57Z

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 · 2024-05-29T08:33:59Z

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 · 2024-05-29T12:55:17Z

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 · 2024-05-29T12:59:29Z

renaming of issue done

AxelNennker · 2024-05-29T13:10:17Z

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 · 2024-05-31T08:14:53Z

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 · 2024-05-31T09:23:43Z

@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 · 2024-05-31T11:34:48Z

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 · 2024-05-31T12:16:37Z

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

AxelNennker · 2024-09-09T11:41:13Z

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

Some code has to be developed anyway, when the login_hint is interpreted. But re-using login_hint is probably the easiest way forward. The Telekom Login team seems to prefer a new parameter for authorization code flow. For them this is more like multi-factor authentication. The operator token identifies the subscription and related data, while login_hint's intention is for user authentication.

To get this done we should use the fastest way forward, which is probably re-using login_hint.

We should write down use cases and user stories e.g. in NumberVerification.

shilpa-padgaonkar · 2024-09-11T17:52:13Z

Would like to add the requirement of trailing the operator token with @operator-domain-identifier cc@AxelNennker

AxelNennker · 2024-09-12T13:03:03Z

Getting more technical regarding the operator token generation:

One way to move forward is using appclips on iOS and instant apps on Android.
https://developer.apple.com/app-clips/
https://developer.apple.com/documentation/appclip
https://developer.android.com/topic/google-play-instant

App clips and instant apps are apps that don't need to be installed by the user.
App clips and instant apps are registered in the store console.

Additionally, the full app that creates the operator token should register an URL for itself.
https://developer.apple.com/documentation/xcode/supporting-associated-domains
https://developers.google.com/digital-asset-links/v1/getting-started

Any app that does EAP-AKA needs special permissions.
Some of the documentation is NDA, so I won't mention that here.
Here is some public documentation for Android:
https://developer.android.com/reference/android/telephony/TelephonyManager#getIccAuthentication(int,%20int,%20java.lang.String)

(Do not be confused by Apple's appclip codes and the appclip-code generation tools.
We need URLs and we could put those URLs into qrcodes but we not all use cases need qrcodes)

@mengan mentioned some of the above (e.g. "app clip") in NumberVerification camaraproject/NumberVerification#86
Operator Token is bigger than NumberVerification.
The operator token can contain any information the Entitlement Server knows about the subscription / SIM / eSIM.
Examples: IMSI, MSISDN, IMEI or derived identifiers or contract id for the subscription
Most of the time the operator token contains sensitive information which needs protection e.g. encryption.
Camara must therefore also define how the API consumer's public key for operator token encryption is registered at Camara onboarding time.

Of course, if you want to support operator tokens then you need an Entitlement Server that supports "AcquireOperatorToken".
https://www.gsma.com/newsroom/wp-content/uploads//TS.43-v11.0-Service-Entitlement-Configuration.pdf

Let's work together implementing operator tokens and defining in Camara how to use them for Camara APs!

chrishowell · 2024-09-12T17:08:23Z

This is all very exciting, and something that we have been talking about internally for quite some time, so thank you for introducing it!

iOS AppClips are extremely promising solution in providing a secure way of communicating between all parties as it reduces the friction of introducing the Operator into the flow (compared to a browser, embedded browser window, or a fully installed app). I think Android Instant Apps is going to require more thought though, because as far as I know Android is not willing to allow Instant Apps access to the Operator Tokens - however, it may still be a good way to request the end-user install the full Operator app.

We must be conscious of the Application Provider experience here; taking their customer out of their applications is hugely disruptive and if we're not careful it may be a prohibitive barrier to API adoption.

I'm assuming that the Operator would be unwilling to allow access to their Operator Token (or opaque substitute) without the Application Provider being authenticated (and end-user consent granted?), which would mean the Application Provider would need to know the Operator before token was requested in order to provide the appropriate auth.

An outstanding question is whether Apple/Android will allow the Operator to distribute the Operator Token to Application Providers if they're protecting it with a privileged SDK; it may be that the token needs to be swapped for an opaque token before being distributed.

A final thought... wouldn't it be nice if the output to this was an OIDC id_token, so it could be used as an id_token_hint in further auth flows? :D

AxelNennker · 2024-09-12T20:45:08Z

Yes, the API consumer must have a relationship with the carrier. That is what I meant with:

Camara must therefore also define how the API consumer's public key for operator token encryption is registered at Camara onboarding time.

TS.43 mentions this in Figure 60

In Deutsche Telekoms implementation the ECS is encrypting the operator token using the clients's public key.
GSMA's ASAC WG goes somewhat more into detail about the setup, but does "solves" calling the privileged app through url-schemes which are insecure especially on iOS. So iOS app clips and Android's assetlinks / instant apps are the way forward.

Through the relationship between API consumer and carrier, the API consumer can request an AcquirreOperatorToken-access token which is validated by the ECS before the operator token is created and returned to the API consumer.

Regarding id_token, that is standardized in OIDC and the operator token should only be a part of it but not the same as the id_token.

nickvenezia · 2024-09-14T07:54:56Z

Would it be relevant on how we handle this in ad tech? @AxelNennker and @chrishowell

nickvenezia · 2024-09-15T20:31:21Z

Would it be possible to append the ‘operator token’ with the ‘advertiser ID’ that has been assigned to both the ‘mobile device’ and the ‘user’?

An existing open-source standard used in Ad Tech could be deployed. This standard is managed by an established advertising trade organization.

Benefits
The ‘advertiser ID’ has

built-in expiration
granular 1:1 opt-out capabilities
global coverage

Future State Compliance

If a user opts out, the ‘advertiser ID’ is immediately terminated.
The expired identifier could serve as an ‘event flag’ to request re-authorization of consent.

This would increase the number of API pings that would come from ad tech.

eric-murray · 2024-09-18T12:14:19Z

Hi @Elisabeth-Ericsson

The name of this issue suggests that the proposal is to use the operator token as an additional method of identifying the end user subscription, and this is reflected in some of the examples above, where the operator token is shown as an alternative to, or additional option for, the login_hint.

But in several comments, it is mentioned that the operator token can be used to authenticate the end user (UE).

So is the proposal just to use the operator token solely for end user identification (so a more privacy friendly alternative to the MSISDN or IP address), or also for authentication?

If the proposal is to also use it for authentication:

What exactly is being authenticated about the end user in the context of the specific CAMARA service API call?
And what are the implications on the ECS itself for such CAMARA-specific authentication being embedded in the operator token?

Thanks

Elisabeth-Ericsson · 2024-09-19T12:50:45Z

Hi Eric,
the idea is to use the operator_token to identify and authenticate the end user (UE).
The authentication aspect is mainly relevant for CIBA, in case the user device is also the target device of an API call. Note: it does not however exclude OIDC Authorization Code Flow. Actually , it would allow for an improved implementation of number Verify, removing the need for an authorization code flow, which is cumbersome and latency intense. Using an operator_token is also access agnostic, e.g. it will work on WiFi.

The operator_token can be used by the application (the API client) to authenticate the end user device against the API provider (please see also TS.43 Service Entitlement Configuration (gsma.com)).

eric-murray · 2024-09-19T13:23:18Z

Thanks @Elisabeth-Ericsson

So I understand the intention is to authenticate something about the end user's "involvement" in the API flow.

Returning to my questions above:

What exactly is being authenticated? What is it about the token itself that prevents the API consumer just using an operator token that was issued (to the end user) for another purpose? More specifically, is it expected that CAMARA scopes, purposes (another scope, of course) and client id be contained in the token, and the token only issued if the end user has consented?
If it is expected the ECS be "CAMARA aware", what are the specific implications of this on the ECS, and how would the required ECS functionality co-exist with the end user consent checking solution that will still be required when the API consumer identifies the end user using one of the existing methods?

Elisabeth-Ericsson · 2024-09-25T15:35:51Z

Hi Eric, regarding your questions:

What exactly is being authenticated? Answer: It is the subscription on the device (SIM);
What is it about the token itself that prevents the API consumer just using an operator token that was issued (to the end user) for another purpose? More specifically, is it expected that CAMARA scopes, purposes (another scope, of course) and client id be contained in the token, and the token only issued if the end user has consented?
Answer: Not really. The token is a proof of SIM authentication and contains the MSISDN of that SIM. The scope and purpose is stated in the authorization request that will need to also carry the token as subscription authentication proof. The scopes contained in the CAMARA request are different.
If it is expected the ECS be "CAMARA aware", what are the specific implications of this on the ECS, and how would the required ECS functionality co-exist with the end user consent checking solution that will still be required when the API consumer identifies the end user using one of the existing methods?
Answer: No, the ECS does not need to be CAMARA aware, but it needs to expose an API for operator token introspection (already supported by TS.43). This API will be used by the Authorization server to retrieve the MSISDN in the operator token to be associated with the authcode.

Some additional info: According to my knowledge, none of the device OS vendors plan to support the operator token as described in TS 43 in short term to mid term.

eric-murray · 2024-09-26T08:55:42Z

Thanks @Elisabeth-Ericsson

What exactly is being authenticated? Answer: It is the subscription on the device (SIM);

I understand that the end user subscription (SIM) must have been authenticated for the operator token to be issued in the first place. But, given your other answers, in the context of the CAMARA API call this is irrelevant. The operator token itself is not a secret (the contents may be, but not the token), and hence the API provider cannot know how the API consumer obtained that token, and cannot assume that the end user knows anything about the CAMARA API call itself.

Hence, as proposed to be used above, operator tokens do NOT authenticate anything about the end user in the context of the CAMARA API call. The token will identify the end user, but the API provider will still have to verify that the end user has consented to the requested scopes being granted to the API consumer (client) for the declared purpose. This is no different to the case where the end user is identified by tel: or ipport:.

So we should stop referring to operator tokens as authenticating the end user for CAMARA API calls.

Elisabeth-Ericsson · 2024-09-30T11:22:45Z

Hi Eric,
I agree, I never intended to claim that the operator token will indicate that the end user has consented to requested scopes.
the operator token is only meant to identify the end user.
However, we might need to go away from the operator token (as specified by TS 43) and rather use

carrier Token (for iOS)
temporary Token (for Android)

These tokens - especially if we find a mechanism to relate then to the application - could give a more secure mechanism for conveying the end user identity.

AxelNennker · 2024-10-01T13:44:58Z

Hi Eric, I agree, I never intended to claim that the operator token will indicate that the end user has consented to requested scopes. the operator token is only meant to identify the end user. However, we might need to go away from the operator token (as specified by TS 43) and rather use
* carrier Token (for iOS)

* temporary Token (for Android)
These tokens - especially if we find a mechanism to relate then to the application - could give a more secure mechanism for conveying the end user identity.

DT/TDG has an implementation that gets an operator token on Android and on iOS.
The difference in the implementation is that on Android we have the privileges to do EAP-AKA and with the EAP-AKA response we request an temporary token from the ECS and with the temporary token we request an operator token from the ECS. The operator token is encrypted to the API consumer or the exposure platform.
On iOS we have the privileges to get an carrierToken and with the carrierToken we get an temporary token and with the temporary token we get the operator token.
This is all TS.43 compliant. TS.43 has specified a client_id and scope in the above flow. These are not necessarily Camara client_id or scope. In TS.43 there is also an access_token which is issued to the client.

The beauty of this is, that it all works over wifi as well and also it works silently.

The operator token is based on EAP-AKA and after successful EAP-AKA the operator token can contain anything that the ECS knows about the subscription e.g. IMEI of last ATTACH, IMSI, MSISDN, contract number related to subscription, ...
The operator token does not contain end-user information. It contains or can contain subscriber/subscription/device information. (If the user is the subscriber then the subscriber is the user data but we do not know that with out user authentication.)

In one user story the operator token is encrypted to MobileConnect IDGW (client_id mobileconnect).
The API consumer uses OIDC to IDGW and IDGW starts user authentication and consent collection.

So, I see no need to move away from operator token. The operator token was never intended to authenticate the end-user.

There are some variants to the above flow. We/DT have not decided yet which variant best fits Camara.
Looking forward to your input.

aabouchi · 2024-10-02T06:32:57Z

Hello,
If I understood correctly, TS.43 clients are not issued by OEMs but by carriers and there is a mechanism to obtain a carrierToken from the iOS platform.
The way to trigger the ECS wasn't very clear, but if I understood correctly, it's better understood now.

JeanPaulAdant · 2024-10-02T06:42:00Z

Axel's perspective highlights that there may not be a need to deviate from the Operator Token flow outlined in TS.43 and ASAC.

TS.43 establishes the interface between a TS.43 Client and an Entitlement Configuration Server, while the ASAC specification (available here https://www.gsma.com/newsroom/gsma_resources/asac-01-v1-0/ ) aims to define commendable APIs and workflows that facilitate third-party applications in utilizing a universal, SIM-based, and seamless/silent authentication method, as Axel mentioned.

The ASAC specification:

Ensures a standardized approach to SIM authentication, addressing various use cases.
Provides a commendable level of privacy.
Was collaboratively developed with Google during the workshops.

From Orange perspective, use of Operator Token flow outlined as defined in TS.43 and ASAC is privileged option.

JeanPaulAdant · 2024-10-02T08:27:19Z

Hello, If I understood correctly, TS.43 clients are not issued by OEMs but by carriers and there is a mechanism to obtain a carrierToken from the iOS platform. The way to trigger the ECS wasn't very clear, but if I understood correctly, it's better understood now.

Hello

TS.43 clients are typically provided by the OS maker, such as Google, and are offered as optional packages.
Device manufacturers (OEMs) have the flexibility to either adopt these clients or develop their own, as seen with companies like Samsung.
The implementation of TS.43 clients adheres to the standards established by all stakeholders, including OS makers, device manufacturers, carriers, and equipment makers...

Elisabeth-Ericsson · 2024-10-02T12:25:45Z

@axel Nennker: you describe that you are using the carrier token to get a temporary token and from this the operator token. I assume that this works on the carrier app interacting with DT's backend. For an application on the device to use this mecahnism and send the operator token to the backend, the app must find the carrier app via a deep link. How do you envision this to work ? How is the link to the carrier app retrieved, assuming that the app must work with multiple carriers ?

JeanPaulAdant · 2024-10-02T16:23:37Z

I would greatly appreciate it if someone could clarify the purpose of the carrier app, as its use is not referenced in TS 43.

aabouchi · 2024-10-02T16:33:49Z

on Android, as you wrote above, I guess it's Google's TS.43 client, on iOS I don't know!

Elisabeth-Ericsson added the enhancement New feature or request label Apr 15, 2024

AxelNennker added the ICM-Backlog label May 8, 2024

shilpa-padgaonkar mentioned this issue May 28, 2024

Revise the device object definition to simplify it camaraproject/Commonalities#171

Closed

Elisabeth-Ericsson changed the title ~~Allow to use operator_token (from TS43) to identify device on access token request~~ Allow to use operator_token (from TS43) to identify device on authentication request May 29, 2024

jpengar mentioned this issue Jun 12, 2024

Proposal to simplify device object and improve interoperability camaraproject/Commonalities#233

Merged

shilpa-padgaonkar mentioned this issue Sep 6, 2024

Integration to on device application (EAP-AKA) - ICM 3.0 Scope? #198

Closed

shilpa-padgaonkar mentioned this issue Sep 9, 2024

ICM 0.3.0 - preparing the scope for meta-release Spring25 #193

Open

jpengar mentioned this issue Sep 11, 2024

Replace Frontend Flow to unify consent collection and reduce latency #197

Closed

jpengar added the spring25-candidate label Sep 11, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

Elisabeth-Ericsson commented Apr 15, 2024 •

edited by AxelNennker

Loading

AxelNennker commented Apr 15, 2024

AxelNennker commented May 29, 2024

Elisabeth-Ericsson commented May 29, 2024

AxelNennker commented May 29, 2024

Elisabeth-Ericsson commented May 29, 2024

AxelNennker commented May 29, 2024

garciasolero commented May 31, 2024

AxelNennker commented May 31, 2024

AxelNennker commented May 31, 2024

garciasolero commented May 31, 2024

AxelNennker commented Sep 9, 2024

shilpa-padgaonkar commented Sep 11, 2024 •

edited

Loading

AxelNennker commented Sep 12, 2024

chrishowell commented Sep 12, 2024 •

edited

Loading

AxelNennker commented Sep 12, 2024 •

edited

Loading

nickvenezia commented Sep 14, 2024

nickvenezia commented Sep 15, 2024

eric-murray commented Sep 18, 2024

Elisabeth-Ericsson commented Sep 19, 2024

eric-murray commented Sep 19, 2024

Elisabeth-Ericsson commented Sep 25, 2024

eric-murray commented Sep 26, 2024

Elisabeth-Ericsson commented Sep 30, 2024

AxelNennker commented Oct 1, 2024

aabouchi commented Oct 2, 2024

JeanPaulAdant commented Oct 2, 2024

JeanPaulAdant commented Oct 2, 2024

Elisabeth-Ericsson commented Oct 2, 2024

JeanPaulAdant commented Oct 2, 2024

aabouchi commented Oct 2, 2024

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

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

Comments

Elisabeth-Ericsson commented Apr 15, 2024 • edited by AxelNennker Loading

AxelNennker commented Apr 15, 2024

AxelNennker commented May 29, 2024

Elisabeth-Ericsson commented May 29, 2024

AxelNennker commented May 29, 2024

Elisabeth-Ericsson commented May 29, 2024

AxelNennker commented May 29, 2024

garciasolero commented May 31, 2024

AxelNennker commented May 31, 2024

AxelNennker commented May 31, 2024

garciasolero commented May 31, 2024

AxelNennker commented Sep 9, 2024

shilpa-padgaonkar commented Sep 11, 2024 • edited Loading

AxelNennker commented Sep 12, 2024

chrishowell commented Sep 12, 2024 • edited Loading

AxelNennker commented Sep 12, 2024 • edited Loading

nickvenezia commented Sep 14, 2024

nickvenezia commented Sep 15, 2024

eric-murray commented Sep 18, 2024

Elisabeth-Ericsson commented Sep 19, 2024

eric-murray commented Sep 19, 2024

Elisabeth-Ericsson commented Sep 25, 2024

eric-murray commented Sep 26, 2024

Elisabeth-Ericsson commented Sep 30, 2024

AxelNennker commented Oct 1, 2024

aabouchi commented Oct 2, 2024

JeanPaulAdant commented Oct 2, 2024

JeanPaulAdant commented Oct 2, 2024

Elisabeth-Ericsson commented Oct 2, 2024

JeanPaulAdant commented Oct 2, 2024

aabouchi commented Oct 2, 2024

Elisabeth-Ericsson commented Apr 15, 2024 •

edited by AxelNennker

Loading

shilpa-padgaonkar commented Sep 11, 2024 •

edited

Loading

chrishowell commented Sep 12, 2024 •

edited

Loading

AxelNennker commented Sep 12, 2024 •

edited

Loading