6 Protocol for data manipulation at the Ut reference point

24.1413GPPPresence service using the IP Multimedia (IM) Core Network (CN) subsystemRelease 17Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1 Introduction

XML Configuration Access Protocol (XCAP) is used to store, alter and delete data related to the presence service. XCAP is designed according to the Hypertext Transfer Protocol (HTTP) framework, and uses the HTTP methods PUT, GET and DELETE for communication over the Ut reference point. The general information that can be manipulated is user groups, subscription authorization policy, resource lists, hard state presence publication, MIME objects referenced from the hard state presence information, etc. Soft state presence information manipulated with a PUBLISH request is not manipulated by the mechanism provided over the Ut reference point.

6.2 Functional entities

6.2.1 User Equipment (UE)

The UE implements the XCAP client role as described in subclause 6.3.1.

For accessing presence servers in 3GPP system:

1) The UE shall implement HTTP digest AKA (see RFC 3310 [20]) and it shall initiate a bootstrapping procedure with the bootstrapping server function located in the home network, as described in 3GPP TS 24.109 [7].

2) The UE shall acquire the subscriber’s certificate from PKI portal by using a bootstrapping procedure, as described in 3GPP TS 24.109 [7];

3) The UE shall implement HTTP digest authentication (see RFC 7616 [53]); and

4) The UE shall implement Transport Layer Security (TLS) according to the TLS profile specified in 3GPP TS 33.310 [r33310] annex E. The UE shall be able to authenticate the network application function based on the received certificate during TLS handshaking phase.

For accessing presence servers in 3GPP2 system, the subscriber shall be authenticated by the presence server. subscriber authentication may be performed by the operator using proprietary or non-3G standardized methods. GBA defined in 3GPP2 S.S0109 [48] may also be used. If GBA based subscriber authentication is used, then the following shall apply:

1) The UE shall implement bootsrapping procedures as specified in 3GPP2 S.S0109 [48]; and

2) The UE shall implement TLS with pre-shared keys method specified in clause 5 of 3GPP2 S.S0114 [49].

6.2.2 Application Server (AS)

If an AS implements the role of a PS (see subclause 5.3.3) or of a RLS (see subclause 5.3.4), then the AS shall also implement the role of a XCAP server (see subclause 6.3.2).

If there is no authentication proxy in the network, then the AS in 3GPP system shall:

1) implement the role of a network application function, as described in 3GPP TS 24.109 [7];

2) implement TLS according to the TLS profile specified in 3GPP TS 33.310 [51] annex E;

3) implement HTTP digest authentication (see RFC 7616 [53]); and

4) support certificate authentication.

For 3GPP2 system, the authentication proxy does not apply. If GBA based authentication is used by an AS in 3GPP2 system, then the AS shall:

1) implement the role of a network application function, as described in 3GPP2 S.S0114 [49]; and

2) implement TLS with pre-shared keys method specified in clause 5 of 3GPP2 S.S0114 [49].

6.2.3 Authentication proxy

For 3GPP2 system, this subclause does not apply.

The generic requirements for an authentication proxy are defined in 3GPP TS 24.109 [7].

In addition an authentication proxy acting within the scope of presence shall:

1) verify the content of the "X-3GPP-Intended-Identity" header in case it is available in HTTP requests; and

2) indicate an asserted identity of the user in the "X-3GPP-Asserted-Identity" header in HTTP requests sent to the AS.

6.3 Roles

6.3.1 XCAP client

6.3.1.1 Introduction

The XCAP client is a logical function as defined in RFC 4825 [33]. The XCAP client provides the means to manipulate the data such as user groups, subscription authorization policy, resource lists, hard state presence infromation, MIME objects referenced from the hard state presence information, etc.

NOTE: In order to be able to manipulate data stored on the XCAP server, the XCAP client has the root directory on the XCAP server pre‑configured or uses some means to discover it. Discovery mechanisms are outside the scope of the present document.

6.3.1.2 Manipulating a resource list

When the XCAP client intends to manipulate a resource list, it shall generate an HTTP PUT, HTTP GET or HTTP DELETE request in accordance with RFC 7231 [52], RFC 4825 [33] and RFC 4826 [36].

6.3.1.3 Manipulating the subscription authorization policy

When the XCAP client intends to manipulate the subscription authorization policy, it shall generate an HTTP PUT, HTTP GET or HTTP DELETE request in accordance with RFC 7231 [52], RFC 4825 [33], RFC 4745 [35A], and RFC 5025 [35].

When the XCAP client intends to authorize particular watchers or watcher groups, the XCAP client shall authorize those watchers in <one> and <many> child elements of the <identity> element as specified in RFC 4745 [35A].

When the XCAP client intends to time-restrict presence attributes, the XCAP client shall define time periods in <validity> elements as specified in RFC 4745 [35A].

When the XCAP client intends to provide certain presence attributes to particular watchers or watcher groups and not others, the XCAP client shall permit those presence attributes in the <transformations> element as specified in RFC 5025 [35].

When the XCAP client intends to authorize providing a particular presence attribute to different watchers or watcher groups depending on the value of that attribute, the XCAP client shall specify those attribute values in the <transformations> element as specified in RFC 5025 [35].

6.3.1.4 Publishing hard state presence information

The XCAP client shall implement RFC 4827 [34] in order to be able to manipulate hard state presence information. Hard state presence information uses the same format as soft state information, namely "application/pidf+xml" content type as described in RFC 3863 [21] together with any of its extensions.

When the hard state presence information contains one or more MIME objects to be aggregated with the "application/pidf+xml" content type and any of its extensions, the XCAP client shall:

a) construct as many HTTP URIs as the number of objects to be stored and formulate every HTTP URI according to a predefined directory structure;

NOTE: In order to be able to manipulate data stored on the XCAP server, the XCAP client has the root directory on the XCAP server pre-configured or use some means to discover it. Discovery mechanisms are outside the scope of the present document.

b) store the objects on the XCAP server behind the HTTP URI(s) created in the previous step using standard HTTP procedures as defined in RFC 7231 [52];

c) include every HTTP URI as a value of the corresponding XML element in the published "application/pidf+xml" presence document referencing the stored object(s) in the previous step; and

d) publish the hard state presence information according to RFC 4827 [34].

6.3.2 XCAP server

6.3.2.1 Introduction

The XCAP server is a logical function as defined in RFC 4825 [33]. The XCAP server can store data such as user groups, subscription authorization policy, resource lists, hard state presence information, MIME objects referenced from the hard state presence information, etc.

6.3.2.2 Resource list manipulation acceptance

When the XCAP server receives an HTTP PUT, HTTP GET or HTTP DELETE request for manipulating or fetching a resource list, the XCAP server shall first authenticate the request in accordance with 3GPP TS 24.109 [7] and then perform authorization. Afterwards the XCAP server shall perform the requested action and generate a response in accordance with RFC 7231 [52], RFC 4825 [33] and RFC 4826 [36].

6.3.2.3 Subscription authorization policy manipulation acceptance

When the XCAP server receives an HTTP PUT, HTTP GET or HTTP DELETE request for manipulating or fetching of the subscription authorization policy, the XCAP server shall first authenticate the request in accordance with 3GPP TS 24.109 [7] and then perform authorization. Afterwards the XCAP server shall perform the requested action and generate a response in accordance with RFC 7231 [52], RFC 4825 [33], RFC 4745 [35A], and RFC 5025 [35].

6.3.2.4 Publication acceptance of hard state presence information

When the XCAP server receives an HTTP PUT, HTTP GET or HTTP DELETE request for publishing, fetching or deleting of hard state presence information, the XCAP server shall first authenticate the request in accordance with 3GPP TS 24.109 [7] and then perform authorization. Afterwards the XCAP server shall:

a) if the HTTP URI points to a predefined directory reserved for storing MIME objects and the request is an HTTP PUT request, replace any existing content referenced by the Request-URI with the content of the request;

b) if the Request-URI points to an uncreated directory and the request is HTTP PUT, create the directory, store the content there and associate the content with the Request-URI. For all requests, i.e. HTTP PUT, HTTP GET and HTTP DELETE requests, generate an appropriate response in accordance with RFC 7231 [52]; or

c) if the HTTP URI points to an XCAP directory and the Application Unique ID (AUID) part of the HTTP URI is set to "pidf-manipulation", process the request and generate an appropriate response in accordance with RFC 4825 [33], RFC 4827 [34] and RFC 7231 [52].