The GUP harmonized access interface is the interface which can be used by the GUP suppliers and GUP consumers to access, manage and transfer the profile data. This application layer interface is independent of the profile structure.

There exists for each Profile a single point of access, which knows the location of the various components of the Profile. A discovery service, e.g. Liberty Discovery Service Specification [2] may be used to get the contact reference information for this access point if not known by other means.

A GUP functionality exists that is responsible to authenticate applications. Authentication is a vital function to be passed before any kind of access to GUP data is granted. GUP shall adopt generic mechanisms such as used for the OSA framework approach. More specifically GUP shall use authentication mechanisms from Liberty Alliance Project as specified in Liberty ID-WSF Security and Privacy Overview [5], Liberty Discovery Service [2] and Liberty ID-WSF Security Mechanisms [6].

A GUP functionality exists that is responsible to authorise applications to access GUP data based on User specific or common privacy rules. All attempts to access the GUP data are to be authorized according to the defined policies which shall include the requestor information, the requested data, the target subscriber and the performed operation, or some of those. GUP shall use authorization mechanisms from Liberty Alliance Project as specified in Liberty ID-WSF Security and Privacy Overview [5] and Liberty ID-WSF Security Mechanisms [6]. The GUP data structures need to satisfy the requirement to provide the authorization information on the different levels: profile, component or data element. In addition to the generic authorization data, additional service specific data may be defined (e.g. for LCS). The same applies for the authorization decision logic. The execution of the authorization logic leads to a decision whether a requestor is allowed to make the request at all, and additionally to which part of data the requestor has the appropriate access rights with regard to the nature of the request. GUP provides mechanisms for the different GUP entities for managing the authorization data. Both HPLMN based applications and non-HPLMN based applications are expected to send requests to the GUP Server. The GUP server shall have functionality to apply different authorization criteria, policy control and load control to HPLMN and non-HPLMN applications. Policy control and load control are out of the scope of the present document.

The tight connection of authentication, authorization and subscriber specific privacy requirements results in privacy control. Privacy control implies a centralized management for access rights including the subscriber's privacy requirements. GUP shall use privacy control mechanisms and other privacy related features from Liberty Alliance Project as specified in Liberty ID-WSF Security and Privacy Overview [5] and Liberty ID-WSF Security Mechanisms [6].

The GUP data repository holds the master copy of the GUP component data. Applications or GUP server may copy (i.e. read) the component data or request synchronization. The present document defines how the data is requested and sent. What is thereafter done with the data by the application or GUP server is beyond the scope of the present document. Synchronization means that the changes to the master copy of the data are propagated to the entities that request synchronization. The synchronization request specifies which data are monitored for changes. It is also possible to request that all changes are reported. Synchronization may cause heavy processing load to the involved entities, thus some policies are required in the implementations but those are not specified for the time being. However the GUP interfaces should carry sufficient data for enabling the load control mechanisms to work. The entity under a heavy processing load has the responsibility to handle the error cases and conditions and to reach the synchronization as fast as possible. All the unresolved errors or load balancing actions that affect synchronization shall be reported.

Access to GUP from a visited network shall follow the single point of access principle.

A GUP functionality exists that keeps information where GUP data are located.

The GUP Server shall be capable of providing charging information, e.g. to enable transaction/event based charging. Some GUP Data Repositories may provide charging information, while other GUP Data Repositories do not provide charging information. Mechanisms are needed to permit the GUP Server to know which GUP Data Repositories are (and are not) producing their own charging information. When the GUP Data Repository is capable of producing charging information, mechanisms are needed for the correlation of the charging information produced by GUP Server and GUP Data Repository. The charging information may also be used for other event logging, customer care, privacy auditing, etc. functions.

The GUP Server is a functional entity providing a single point of access to the Generic User Profile data of a particular subscriber. The reference architecture does not specify or limit the physical location of the GUP Server enabling flexibility in the implementations. However, the GUP Server shall be located in the home operator network of the targeted subscriber. The GUP Server includes the following main functionalities:

• Single point of access for reading and managing generic user profile data of a particular subscriber.
• Location of Profile Components.
• Authentication of profile requests.
• Authorization of profile requests.
• Synchronization of Profile Components.

The GUP Server may support two modes of operation:

• Proxy mode (see Figure 4.3). The Application requests user related data located in the GUP Data Repositories from the GUP Server. After taking care of needed actions specified for the GUP Server (and depending on the type of the request) the GUP Server makes requests to the corresponding GUP Data Repositories and receives responses from them. Finally the Application gets a response to the original request from the GUP Server. Depending on the type of the request also possible subsequent responses are delivered through the GUP Server.
• Redirect mode (see Figure 4.4). The Application requests user related data located in the GUP Data Repositories from the GUP Server. After taking care of needed actions specified for the GUP Server (and depending on the type of the request) the GUP Server returns to the Application the information (e.g. address of GUP Data Repository(s)) to allow the Application to request the information from the GUP Data Repositories. The Application then directly requests the information from the GUP Data Repositories.

The Proxy mode is the default mode of operation. Redirect capability and preference for the applied mode may be indicated by the application with the Requestor data parameter when accessing the GUP Server. The GUP Server decides which mode is selected for the different requests. In addition to the Requestor data parameter, the decision is based on the capabilities of the GUP Server and the related Repository Access Functions (RAF) as well as on the service configuration and policy data in the GUP Server related to the particular application. These service configuration and policy data are out of the scope of GUP standardisation. If the Redirect mode is not supported by the GUP Server the response is always sent according to the Proxy mode.

The Repository Access Function (RAF) realizes the harmonized access interface. It hides the implementation details of the data repositories from the GUP infrastructure. The RAF performs protocol and data transformation where needed. The protocol between the RAF and the GUP data repository is out of the standardization scope. It is recommended that the protocol used should support GUP requirements. The RAF may take part in the authorization of access to such GUP information, which are under the control of the RAF. In addition, the authorization data may be managed via the Rp reference point.

Each GUP Data Repository stores the primary master copy of one or several profile components. The RAF provides for the standardized access to the GUP Data Repository. The storage formats or the interface between the RAF and GUP Data Repository are not specified by GUP. It is presumed that the RAF and the GUP Data Repository are usually co-located in the same network element. The GUP Data Repository may contain also the authorization data depending on the authorization model and architecture.

Reference Points in the GUP Reference Architecture:

1. Reference point Rg
   This reference point shall allow applications to create, read, modify and delete any user profile data using the harmonized access interface. The GUP Server locates the data repositories responsible of the storage of the requested profile component(s) and in case of proxy mode carries out the requested operation on the data. The reference point Rg shall support interworking to other mechanisms that support parts of the user profile outside the scope of 3GPP e.g. Liberty ID-WSF SOAP Binding Specification [3] and Liberty ID-WSF Data Services Template [4].
   In the redirect mode, the GUP Server returns the locations of the GUP Data Repositories and the application can then send the requested operations via reference point Rp directly to the corresponding GUP Data Repositories.
   The reference point Rg carries user related data, and therefore shall be protected by security mechanisms.
2. Reference point Rp

This reference point shall allow the GUP Server or applications, excluding external applications (e.g. located in a third party application or in the UE), to create, read, modify and delete user profile data using the harmonized access interface. Rp is an intra-operator reference point. External applications and third party GUP data repositories shall be connected to the GUP Server only using the Rg reference point. The reference point Rp carries user related data, and therefore shall be protected by security mechanisms.

The applications that may apply GUP reference points Rg and Rp may be targeted for different purposes e.g. for value added services or subscription management. Both operator's own applications and third party applications are covered. The latter ones shall apply Rg reference point. Additionally the applications may utilise a discovery service to discover the contact reference information if not found out by other means. A discovery service e.g., as specified in Liberty Discovery Service Specification [2], may also act as Trusted Authority providing essential security related information (e.g. preferences in terms of peer entity and message authentication mechanism to be used and authentication and/or authorization assertions). Different policies may be followed in the use of discovery service. It may be used by different applications in different ways: per each operation, occasionally or not at all. In general terms, third party applications belonging to external security domains shall use a discovery service as a normal step, but in operator's services it may not be needed at all. Applications have different authorization rights to the GUP data of different subscribers as agreed between the parties.

For an application requesting GUP data component(s) a message flow is described in the following:

• The application requests a GUP component(s) via Single Point of Access (Rg) from the GUP server. The application will indicate if it can support the Redirect mode.
• The GUP server authenticates the application. Note that also separate authentication services may be applied.
• The GUP Server identifies the level of authorization the Application is allowed to access the GUP data.
• The GUP Server identifies the location of the GUP component(s).

At this point the GUP Server may (see Figure 4.5 below)

• Access the GUP component(s) by means of the Harmonized Access Interface (Rp) or by other means outside the scope of GUP.
• Respond to the application with the result of the request, optionally combining results from different GUP data repositories.

Or, depending on GUP data repositories choice and if the application has indicated that it can support the Redirect mode (see Figure 4.6 below)

• Respond to the application with reference(s) to the component(s) and additionally authorization credentials with limited lifetime. Note that authorization credentials from other sources are not excluded.
• The application uses the reference(s) and the authorization credentials to access GUP data repositories by means of the Rp reference point.

Privacy rules may stay together with the data it applies to at the data repository where the data is stored. In this case this privacy rules shall apply. Optionally, the GUP Server may apply additional privacy rules. However the GUP Server must never "bypass" existing privacy rules. The following figures show the message flows for both cases as described.