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.

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!

AxelNennker · 2024-10-08T10:04:39Z

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

Both iOS and Android require special permissions that only carriers get. The carrier-app needs these permission, otherwise there is no way to start EAP-AKA. In TS.43 the carrier-app is called TS.43 Client
https://www.gsma.com/newsroom/wp-content/uploads//TS.43-v11.0-Service-Entitlement-Configuration.pdf

I assume that most carrier have some customer-facing app that could have the required privileges.
Or the carrier could create a separate "Smartphone Authenticator App" that has the privileges and would then allow API consumers to request an operator token through it.

etxheos · 2024-10-08T10:25:55Z

Don't we need a solution that works without the user having to download an app? For iOS, the solution can be to use App Clips to avoid that problem. It can run with carrier privileges and retrieve carrier token. We then also need something similar on Android (or an API open to any app).

AxelNennker · 2024-10-08T10:50:40Z

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

There can't be one app for all carriers and there can't be one deep-link for all carriers. The mobile operating systems, as far as I know, do not allow this.
That is one reason I create this Android feature request "Carrier OpenId API".
https://issuetracker.google.com/issues/308240647
Please +1 that. Regardless of operator token getting the openid configuration of the carrier would solve a ton of problems that currently hinder carrier user stories. The need for telcofinder would go away. I think all telco's would benefit if "Carrier OpenId API" is implemented. Also the carrier's OpenId configuration can contain the link to the ECS or the deep-link to the carrier-app...

Currently my plan for Camara is that the API consumer

starts the OIDC authorization code flow with the aggregator from the mobile device
the aggregator does it telcofinder magic and then knows whether that carrier supports operator token and redirects to the registered URL for that carrier
the mobile OS sees the registered URL and
- opens the carrier's appclip or instant app (carrier app, TS.43 Client, Smartphone Authenticator App, ...) if the carrier app is not installed.
- opens the carrier app if it is installed
the operator token is retrieved by the carrier app (clip) and there is a redirect to e.g. the Device App / API Consumer App or the Aggregator and that redirect contains the operator token. Then "the real" OIDC authorization request is done with e.g. login_hint=ot:<operator_token>
the code is returned and then
the access token is returned.

I think the above fits into the OIDC flow and also into the OpenGateway flow. Just more redirects.

If a telco wants to support e.g. Smartwatches, eSim profile transfer, etc, then the telco needs an Entitlement Configuration Server.
Supporting operator token is then a small step.

A non-Camara use case is using the operator token for the carrier's own apps, no need for SMS-OTP or on-net network-based authentication.

BTW wrong @axel please use @AxelNennker

AxelNennker · 2024-10-08T11:02:08Z

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

Although, Google/Android implements TS.43 and in that sense provides TS.43 clients, those APIs require special privileges which are not accessible by API consumer apps. Currently only carrier-apps can use these APIs.
(For the technically inclined: get your application's hash into this list carrier_certificate_string_array e.g. https://android.googlesource.com/platform/packages/apps/CarrierConfig/+/master/assets/carrier_config_carrierid_3_Telekom.xml)

JeanPaulAdant · 2024-10-14T16:59:48Z

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

Both iOS and Android require special permissions that only carriers get. The carrier-app needs these permission, otherwise there is no way to start EAP-AKA. In TS.43 the carrier-app is called TS.43 Client https://www.gsma.com/newsroom/wp-content/uploads//TS.43-v11.0-Service-Entitlement-Configuration.pdf

I assume that most carrier have some customer-facing app that could have the required privileges. Or the carrier could create a separate "Smartphone Authenticator App" that has the privileges and would then allow API consumers to request an operator token through it.

The ASAC-defined framework appears to be more flexible, as it eliminates the need for carrier privileges and allows any 3rd party to request a token.
This approach has been developed collaboratively within the GSMA, with participation from Google. So we don't think getting these APIs should be an issue.
Additionally, this framework would prevent the necessity for each carrier to widely deploy an app with carrier privilege that other applications would need to interface with.

JeanPaulAdant · 2024-10-14T17:00:21Z

Don't we need a solution that works without the user having to download an app? For iOS, the solution can be to use App Clips to avoid that problem. It can run with carrier privileges and retrieve carrier token. We then also need something similar on Android (or an API open to any app).

Yes, as explained above, we don't think that forcing users to go through an existing app would be a winning proposition.
However app clip also has its own problems and once again the ASAC standard is here to solve it all.

JeanPaulAdant · 2024-10-14T17:02:19Z

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

There can't be one app for all carriers and there can't be one deep-link for all carriers. The mobile operating systems, as far as I know, do not allow this. That is one reason I create this Android feature request "Carrier OpenId API". https://issuetracker.google.com/issues/308240647 Please +1 that. Regardless of operator token getting the openid configuration of the carrier would solve a ton of problems that currently hinder carrier user stories. The need for telcofinder would go away. I think all telco's would benefit if "Carrier OpenId API" is implemented. Also the carrier's OpenId configuration can contain the link to the ECS or the deep-link to the carrier-app...

Currently my plan for Camara is that the API consumer

starts the OIDC authorization code flow with the aggregator from the mobile device

the aggregator does it telcofinder magic and then knows whether that carrier supports operator token and redirects to the registered URL for that carrier

the mobile OS sees the registered URL and

opens the carrier's appclip or instant app (carrier app, TS.43 Client, Smartphone Authenticator App, ...) if the carrier app is not installed.

opens the carrier app if it is installed

the operator token is retrieved by the carrier app (clip) and there is a redirect to e.g. the Device App / API Consumer App or the Aggregator and that redirect contains the operator token. Then "the real" OIDC authorization request is done with e.g. login_hint=ot:<operator_token>

the code is returned and then

the access token is returned.

I think the above fits into the OIDC flow and also into the OpenGateway flow. Just more redirects.

If a telco wants to support e.g. Smartwatches, eSim profile transfer, etc, then the telco needs an Entitlement Configuration Server. Supporting operator token is then a small step.

A non-Camara use case is using the operator token for the carrier's own apps, no need for SMS-OTP or on-net network-based authentication.

BTW wrong @axel please use @AxelNennker

While your proposal would probably work, it still has some drawbacks against what's defined in ASAC:

all MNOs would need to implement the new "Carrier OpenID API", manage a deeplink and provide an app that manage carrier token and all the rest in the proper way. That's a lot. A BIG lot.
The aggregators need to do their "Telco Finder Magic". As nothing is magic in this world, this Telco Finder story might raise more questions than it solves.

Therefore we think that the best proposal here again is to stick to ASAC.

JeanPaulAdant · 2024-10-14T17:03:11Z

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

Although, Google/Android implements TS.43 and in that sense provides TS.43 clients, those APIs require special privileges which are not accessible by API consumer apps. Currently only carrier-apps can use these APIs. (For the technically inclined: get your application's hash into this list carrier_certificate_string_array e.g. https://android.googlesource.com/platform/packages/apps/CarrierConfig/+/master/assets/carrier_config_carrierid_3_Telekom.xml)

This is indeed a big issue to allow the whole ecosystem or leverage the SIM as a convenient possession factor in app and needs to be resolved ASAP.
This is why we all worked with Google to propose the ASAC standard including the eligibility flow to manage authorization and privacy.

garciasolero · 2024-10-15T10:04:23Z

Very interesting debates have arisen, but we think they are outside the scope of this forum. In our view, we should focus the discussion on what we need to define in order to work with operator tokens in the context of CAMARA, regardless of how they are generated and used to route the request. From a CAMARA perspective, it is an opaque identifier.

Therefore, as mentioned before, we should simply define a new valid prefix for the login_hint parameter (e.g. operator_token). When the authorization server receives it, it will translate it into an MSISDN by using the Entitlement Server.

etxheos · 2024-10-15T11:37:46Z

Very interesting debates have arisen, but we think they are outside the scope of this forum. In our view, we should focus the discussion on what we need to define in order to work with operator tokens in the context of CAMARA, regardless of how they are generated and used to route the request. From a CAMARA perspective, it is an opaque identifier.

Therefore, as mentioned before, we should simply define a new valid prefix for the login_hint parameter (e.g. operator_token). When the authorization server receives it, it will translate it into an MSISDN by using the Entitlement Server.

Fully agree, but how much of the overall process should be described in detail in the CAMARA Security and Interoperability Profile?

eric-murray · 2024-10-15T13:06:40Z

@garciasolero

Therefore, as mentioned before, we should simply define a new valid prefix for the login_hint parameter (e.g. operator_token). When the authorization server receives it, it will translate it into an MSISDN by using the Entitlement Server.

Would this be for CIBA only?

There has been a lot of discussion above about using operator tokens in the Authorisation Code Flow (either as a login_hint parameter, or a new operator_token parameter) and I really don't understand its role there. If the proposal is to include this as an option for the Authorisation Code Flow as well, I'd like to understand what the authorisation server of the API provider is expected to do with the token once received, as it will anyway know the subscription identity from network-based authentication.

AxelNennker · 2024-10-15T14:12:44Z

However app clip also has its own problems and once again the ASAC standard is here to solve it all.
ASAC is first of all a protocol specification not a API specification. TS.43 uses the TS.43 Client, which needs privileges to do its work. We can certainly define a public API that does not need privileges and can be called by any mobile application.

I have not viewed ASAC as that specification that specifies this public mobile-OS API. Let's discuss this in ASAC.

This issue assumes that the API consumer got the operatorToken. The question this issue is about is, how does the API consumer uses the operatorToken to get a CAMARA access token.

The OIDC and CIBA parameter login_hint was proposed and I think that is the way forward that does not require us to change OIDC or CIBA. No extension of the protocols we already use is needed.

AxelNennker · 2024-10-16T09:25:03Z

@JeanPaulAdant wrote:

While your proposal would probably work, it still has some drawbacks against what's defined in ASAC:
* all MNOs would need to implement the new "Carrier OpenID API", 
   manage a deeplink and provide an app that manage carrier token and all the rest in the proper way. 
   That's a lot. A BIG lot.

* The aggregators need to do their "Telco Finder Magic". As nothing is magic in this world, this Telco Finder story might raise more questions than it solves.
Therefore we think that the best proposal here again is to stick to ASAC.

DT's Android feature request is a feature request where we ask Google to implement the following method in Android.

public String getOidcConfiguration (int subscriptionId)

This is no API that MNOs need to implement.
The new Android API really does have nothing to do with TS.43 and ASAC and operator token.
Sorry, if the feature request is unclear. Please help me improve it.

The new API can be used by any mobile app. All it does is return the URL to the carrier's OpenId Configuration.
If the MNO does not use OpenId, then getOidcConfiguration returns null.
Android implemented a more complicated, internal version of this simple, public method already.
Please see here.
That internal Android method does have something to do with TS.43, but I only mentioned that in the feature request to show that basically everything is already implemented in Android and that only a new public wrapper is needed.
That is the only relationship to TS.43 and ASAC. I want to say to Google "Look here, the code is 99% already there. This feature is easy to implement".
The MNO does not have to implement any app nor does the MNO have to register deep links.
The new method has nothing to do with operator token.

If the MNO already uses OpenId, then all they might do is check their openid configuration as defined here. CIBA and other standards add their own fields to the openid configuration. Also please see OAuth2.

There really is nothing the MNO has to do, if they already run an OpenId Provider.
The new Android API make possible for a mobile application to find the OpenId configuration and thereby the OpenId Provider the carrier provides.

I think all Telcos who use OpenId should support the feature request. If you use OpenId, then please support (+1) the feature request. If something is unclear in the feature request, then please comment on it.
I assume all participating here in ICM and Camara use OpenId.

garciasolero · 2024-10-16T10:09:03Z

@eric-murray

When I talk about using the login_hint parameter, I am only referring to the CIBA flow. Currently, for existing use cases in CAMARA, the Authorization Code flow should be used in scenarios where we need to ensure that the consumption device and the authentication device match. That is, for On-net scenarios, where the login_hint is not required. For instance, for network-based authentication to access the Number Verification API.

Once the operator token is supported in CIBA, the Authorization Code flow would no longer be necessary for number verification, as CIBA is simpler (no redirects) and solves the problem of navigation over WiFi.

eric-murray · 2024-10-16T11:29:32Z

Thanks @garciasolero

I understood you until your last point:

Once the operator token is supported in CIBA, the Authorization Code flow would no longer be necessary for number verification, as CIBA is simpler (no redirects) and solves the problem of navigation over WiFi.

So my questions here are:

If the end user device is connected to WiFi, then they will be a customer of both a fixed network provider and a mobile network provider. So how is the API consumer (or aggregator) supposed to know that the CIBA request should be directed to the /bc-authorize endpoint of the mobile network, and not that of the fixed network? How is the mobile network that issued the token identified from the token itself?
Additionally, the operator token itself is not a secret (contents, yes, but not the token). So if the token includes nothing specific to CAMARA, how does the authorisation server know that the operator token attached to the CIBA request was generated specifically to authenticate the end user device that is the subject of the forthcoming API request, and is not a token that was created for some other purpose, but has been obtained by the API consumer to fool the authorisation server into thinking the end user device is in the loop?

This last point relates to my comments above. I can see how the operator token can be used to identify the end user, but don't understand how it can be used to authenticate that end user if the scopes, client id etc. in the token are nothing to do with CAMARA.

JeanPaulAdant · 2024-10-16T20:13:24Z

However app clip also has its own problems and once again the ASAC standard is here to solve it all.
ASAC is first of all a protocol specification not a API specification. TS.43 uses the TS.43 Client, which needs privileges to do its work. We can certainly define a public API that does not need privileges and can be called by any mobile application.

I have not viewed ASAC as that specification that specifies this public mobile-OS API. Let's discuss this in ASAC.

This issue assumes that the API consumer got the operatorToken. The question this issue is about is, how does the API consumer uses the operatorToken to get a CAMARA access token.

The OIDC and CIBA parameter login_hint was proposed and I think that is the way forward that does not require us to change OIDC or CIBA. No extension of the protocols we already use is needed.

The public API requirements are specified on ASAC.OA section 5.2.1 TS.43 Client High level requirements.
Yes, let's talk about that on ASAC

JeanPaulAdant · 2024-10-16T21:15:48Z

Very interesting debates have arisen, but we think they are outside the scope of this forum. In our view, we should focus the discussion on what we need to define in order to work with operator tokens in the context of CAMARA, regardless of how they are generated and used to route the request. From a CAMARA perspective, it is an opaque identifier.
Therefore, as mentioned before, we should simply define a new valid prefix for the login_hint parameter (e.g. operator_token). When the authorization server receives it, it will translate it into an MSISDN by using the Entitlement Server.

Fully agree, but how much of the overall process should be described in detail in the CAMARA Security and Interoperability Profile?

It could be relevant to add some requirements on operatorToken e.g scope and client_id of the operatorToken should be the same values that the scope and client_id from the camara request /authorize (or /bc.authorize)

garciasolero · 2024-10-17T10:12:44Z

@eric-murray

As TS.43 is being designed, the operator token will be generated by the SIM, i.e. it will be an operator token of the mobile network, regardless of the provider of the WiFi connection. The operator token is self-contained and it can be inspected by the aggregator to allow routing decisions.
You can't ensure that the operator token will be generated for other purposes, just as if you were using the MSISDN or IP. Only trusted applications should use it, and you could partly mitigate this by having a very short lifespan to prevent its reuse.

eric-murray · 2024-10-17T10:32:45Z

Thanks @garciasolero

The operator token is self-contained and it can be inspected by the aggregator to allow routing decisions

That's the bit I was missing. So even though the token is opaque (because it is encrypted), the issuer can be determined from the token itself. So an operator token can only be used for APIs that are fulfilled by a mobile operator, as the authorisation request will be routed to that operator (as the issuer of the token).

Does this routing have to be done by an aggregator? Or can the API consumer (i.e. application) determine this directly?

garciasolero · 2024-10-17T10:47:34Z

In the defined multi-operator service model, all requests are routed through the aggregator. Therefore, only the aggregator will have access to the internal data of the operator token. For the application, this token is completely opaque and should be sent to the aggregator as-is in the request.

Elisabeth-Ericsson · 2024-10-23T10:53:11Z

I suggest to structure the discussion and address the various problem spaces separately and conclude on the different topics:

Get Operator token – Where/How it is generated ?
Use Operator token instead of MSISDN on access token /access code request
Extract MSISDN for consent check
Use operator token as device identifier on NW API call
Extract MSISDN to be used in NW API

The different problems are illustrated on the diagram.
icm-145.pptx

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

AxelNennker mentioned this issue Oct 16, 2024

operator token login_hint format #218

Merged

This was referenced Nov 4, 2024

integration to on device application (EAP-AKA) camaraproject/NumberVerification#86

Open

Proposed text that removes "WiFi is out of scope" and proposed operator token camaraproject/NumberVerification#153

Open

AxelNennker closed this as completed in #218 Nov 6, 2024

Elisabeth-Ericsson mentioned this issue Nov 19, 2024

Allow to use operator token for device authentication in OpenID Auth code flow #232

Open

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

JeanPaulAdant commented Oct 2, 2024

Elisabeth-Ericsson commented Oct 2, 2024

JeanPaulAdant commented Oct 2, 2024

aabouchi commented Oct 2, 2024

AxelNennker commented Oct 8, 2024

etxheos commented Oct 8, 2024 • edited Loading

AxelNennker commented Oct 8, 2024

AxelNennker commented Oct 8, 2024

JeanPaulAdant commented Oct 14, 2024

JeanPaulAdant commented Oct 14, 2024

JeanPaulAdant commented Oct 14, 2024

JeanPaulAdant commented Oct 14, 2024

garciasolero commented Oct 15, 2024

etxheos commented Oct 15, 2024

eric-murray commented Oct 15, 2024

AxelNennker commented Oct 15, 2024

AxelNennker commented Oct 16, 2024

garciasolero commented Oct 16, 2024

eric-murray commented Oct 16, 2024

JeanPaulAdant commented Oct 16, 2024

JeanPaulAdant commented Oct 16, 2024

garciasolero commented Oct 17, 2024

eric-murray commented Oct 17, 2024

garciasolero commented Oct 17, 2024

Elisabeth-Ericsson commented Oct 23, 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

etxheos commented Oct 8, 2024 •

edited

Loading