E/// proposal to use GPSI as UE identifier

[jordonezlucena]

Telefónica would like to thank Ericsson for bringing this proposal for discussion. We have carefully analyzed the material, and realize that it captures two separate yet intertwined topics: on the use of GPSI as UE identifier and network neutrality.

1) On the use of GPSI as UE identifier. Two comments on this topic:

• It is important to make sure that the use of this UE identifier in the 'service API' has an implementable solution in the 'network API'. In other words, the proposal of using GPSI shall match with the parameters to be populated in the NEF API, according to 3GPP TS 29.522.
• The validity of this proposal is subject to the B2C scenario/use case under consideration. If end user has a contract signed with the 3rd party (e.g. gaming service provider), then 3rd party has access to MSISDN/GPSI. However, if the end user DOES NOT have a contract signed with the 3rd party (e.g. the operator acting as re-seller of 3rd party), then the 3rd party is not able to gain access to MSISDN/GPSI (because of GDPR and the like). In the latter case, the operator shall proceed with the MSISDN/GPSI tokenization, mapping the UE identifier to a token (that is to be issued to the 3rd party as user ID).

2) Network neutrality. The scenario presented in this material does not fit/match with NetNeutrality policy. If enhanced QoS is required for cloud gaming, then this policy enforces the operator to apply the same QoS to all gaming applications. In other words, it is not possible for operator to apply QoS#1 for gaming app#1 and QoS#2 for gaming app#2. In a nutshell, what this policy says that the operator is not allowed to sell QoS per gaming app. In our understanding, for the proposed gaming scenario, the user story corresponding to the (on-demand) provision of enhanced QoS would be as follows:

• Operator offers a gaming pack to end users. This pack is offered as a product, and allows the end user to have premium experience (QoS#X) for all gaming apps.
• The end user subscribes to this gaming pack. From this moment on, the traffic from all gaming apps used by the end user shall be treated with QoS#X. These gaming apps can be from the same or different cloud gaming providers.
• When the user uses a gaming app, the corresponding cloud gaming provider asks the perator whether the end user is subscribed to the gaming pack. If so, the operator sends a token to the cloud gaming provider.
• This token is used in the session establishment between the end user (UE) and the gaming cloud provider's app hosting server (application server). The use of this token lets operator know that the traffic flows within the session are to be treated according to QoS#X.

[sm7084]

Thanks to E/// for the contribution.

As correctly identified in E///'s contribution, IP address is not appropriate to be used as a userId as IP address changes. The contribution suggested the use of MSISDN as userId instead.

AT&T is concerned with the suggested approach as using MSISDN as a userId is very problematic and can lead to big issues. The reason is that change MSISDN and MSISDN recycling are facts of life and hence the usage of MSISDN to identify a user/subscriber over APIs can easily lead to pointing to a wrong subscriber.

This issue (Apps being able to identify a user using an External Id as opposed to IP address or MSISDN) was recently discussed at length in 3GPP and as a result the SA2 WG specified a new NEF operation called "Nnef_UEId_Get" in Rel-17 of 23.502. This RESTful operation/API which is exposed over the northbound of NEF is going to become available soon (it's being specified in stage 3 WG; spec 29.522).

Using the Nnef_UEId_Get operation the application server can exchange the UE's IP address for a static App specific UEId which is formatted as an External_Id. Please note that, every time the user uses the App, the App (application server) would call the Nnef_UEId_Get operation in order to identify the user (i.e. the response from NEF is going to be the same static UEId from one session to the next so that the App can identify a returning user by matching the UEId received from the NEF with what (UEId) the application server has saved in its user's profile upon user's record/account creation).

[T-sm]

Ericsson has uploaded their proposal to the WG repo: https://github.com/camaraproject/WorkingGroups/blob/main/Commonalities/documentation/Deliverables/UE%20identifiers.pptx

[jordonezlucena]

Agree with the solution proposed by Ericsson. One question on slide 6, step 1. What happens if the UE IP address is private? Would it work?

[shilpa-padgaonkar]

Agree with solution proposed by E/// to include GPSI-External_Id as a valid option for UE identification. For the current QoD APIs, changes will be made after NEF AsSessionWithQoS API includes this option or when a separate relevant NEF API offers the needed capability to keep the complexity of service api implementation to the minimum and ensure validations.

[Kevsy]

Agree that MSISDN should not be used as per privacy and regulations.

Agree that GPSI-External_Id is a good alternative as 3GPP compliant

what this policy says that the operator is not allowed to sell QoS per gaming app

@jordonezlucena I think this may be possible if it is the end user that has requested and provided explicit consent to the upgraded QoS for a particuar app. But that needs to be checked on a per market basis by the regulatory teams.

[eric-murray]

• Vodafone support the Ericsson proposal to use GPSI as a possible identifier for the UE and as an alternative to the UE source IP address & port.
• Either a MSISDN or External Identifier should be able to be specified as the GPSI. MSISDN should NOT be excluded as a possible identifier just because of potential privacy concerns or the possibility that a MSISDN could be transferred to another subscriber.
• Definition should be the same as defined by 3GPP in TS 29.571, i.e.

  Gpsi:
    type: string
    pattern: '^(msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|.+)$'
    description: String identifying a Gpsi shall contain either an External Id or an MSISDN. It shall be formatted as follows -External Identifier= "extid-<extid>, where <extid> shall be formatted according to clause 19.7.2 of 3GPP TS 23.003 that describes an External Identifier.

• Operator issued tokens identifying the UE should also be supported as an alternative to GPSI if the GPSI is unknown or cannot be used for privacy or other reasons, but that should be discussed as a separate issue.

[T-sm]

Thank you for your proposal and comments until now. Please note that we have the Authentication and authorization concept document in review (see issue #27 for details), could you please provide a chapter/appendix on possible GPSI application for the document? Or would you prefer to have it documented separately?

[miguel-garcia-ericsson]

Hi all: I think we agree with all the previous comments and concerns, and we should aim at writing this down in a document that discusses the identification of users in Camara APIs. I was looking at the Authentication/Authorization concept document and got the impression that it is more about a network function or entity authenticating and getting authorization for invoking APIs in a second NF or entity. So, I think that user identification lies a bit outside the scope of the document. Due to this, our preference is for capturing this discussion in a separate document, devoted to identification of users in Camara APIs. We can take the action point of drafting a first version, addressing all the comments received so far, and submit it as soon as it is ready.

[jordonezlucena]

Agree with the way forward captured above.

[shilpa-padgaonkar]

@miguel-garcia-ericsson

The first half of the AuthN-AuthZ doc does not include the user identity. This is mainly talking about authorization and suggests client credentials flow as user resource is not involved in the flow.

The second half of the AuthN&AuthZ brings the API users in the picture. From section https://github.com/camaraproject/WorkingGroups/blob/main/Commonalities/documentation/Deliverables/CAMARA-AuthN-AuthZ-Concept.md#oidc- user related aspects get included.

The user identification elaboration, will have to include authentication and authorization as well (maybe in the form of delegation or impersonation) and it would be great if we could extend the existing doc with this content as it would then become a single point of reference.

Would be glad to know what you think.

[miguel-garcia-ericsson]

I see that the AuthN&AuthZ document touches the end-user authentication. We could try to add the UE Identity discussion in there, I don't have a problem with that approach either.

[shilpa-padgaonkar]

@miguel-garcia-ericsson Much appreciated

[sm7084]

Agree to the usage of GPSI in the form of a Static AF-Specific External-ID as intended by 3GPP SA2 (23.502) and SA6 (23.558).

I'd like point out the following couple of points:

1. I find the following bullet on E///'s slide 5 misleading/unclear: "The AF keeps the AF-specific UE external identifier for the duration of the AF session". The reason for saying that is that: The UEID (i.e. GPSI in the form of an AF-Specific External-ID) is intended to be "static" so that once the AF retrieves it from the 3GPP network it can store it locally for proper user identification over subsequent user's visits to the AF service (i.e. the AF "Nnef_UEId_Get" request would always return the same (Static) AF-Specific UE External-ID and hence the AF can perform GPSI lookup locally to locate the user's record).

2. For the cases where the user willingly divulges his/her MSISDN to the AF and AF uses MSISDN form of the GSPI for the API calls, the AF must subscribe for change-MSISDN event notifications from the 3GPP network (don't know if NEF/29.522 exposes this event) or otherwise a changeMSISDN requested by the user (which is a fact of life for operations in MNOs) can easily result in the AF being in the dark and hence later making API calls onto a wrong user/UE (who happened to be assigned an old user's MSISDN due to MSISDN recycling phenomena in MNOs). Having said that, I still see the usage of MSISDN a risky proposition as the MNO is at the mercy of the AF doing the right thing in properly subscribing for change-MSISDN event notifications (if offered by NEF) and taking appropriate actions as opposed to GPSI in the form of a static AF-Specific External-ID which MNOs can be certain the right user is being targeted over the APIs.

[eric-murray]

Whilst AuthN/AuthZ and UE identification are clearly related, they are not synonymous. The API consumer may not be the UE, and it may be that identifying the API consumer does not uniquely identify the target UE. Hence mechanisms to identify the target UE in addition to source IP / port are required for the reasons identified by Ericsson. It is for the API provider to confirm that the identified API consumer has the necessary rights to request service modifications for the identified target UE.

Vodafone agree that the alternative target UE identification parameter to be passed to an API should be GPSI. 3GPP allow this to be either MSISDN or External Identifier. I agree with AT&T that there are several advantages in using External Identifier if that is known to the API consumer. But for the APi consumer to learn this, it is necessary that:

• the API consumer knows the source IP / port that has been allocated to the UE; and
• the API provider has implemented the Nnef_UEId_Get service

As also noted by Ericsson, even if the source IP / port is known, identifying the target UE from the source IP / port can be problematic when NATed IPv4 addresses are in use, and the API provider may not be able to offer the Nnef_UEId_Get service for this reason.

For these reasons, Vodafone would like MSISDN to be supported as an option for the GPSI in addition to the External Identifier. There are many mechanisms through which the API consumer can learn the MSISDN of the target UE if the External Identifier is unavailable to it. It is for the API provider to assess whether allowing MSISDN as a target UE identification option has an acceptably low risk of either miss-identification of the UE (due to MSISDN recycling) or security / privacy breach when transporting this information.

[shilpa-padgaonkar]

Closed with merge of https://github.com/camaraproject/WorkingGroups/pull/86 which included review done as a part of https://github.com/camaraproject/WorkingGroups/pull/51