TS 24.482
Mission Critical Services (MCS)
Identity Management

3GPP‑Page ETSI‑search CONTENT_↓

V18.0.1 (PDF) 2023/06 19 p.

V17.1.0 2022/03 19 p.

V16.0.0 2020/06 19 p.

V15.1.0 2020/06 19 p.

V14.4.0 2020/06 19 p.

V13.3.0 2017/03 16 p.

Rapporteur:: Mr. Lazara, Dominic
Motorola Solutions UK Ltd.

Content for TS 24.482 Word version: 18.0.1

1 Scope p. 5

This document specifies the identity management and authentication protocols needed to support Mission Critical Services (MCSs). Identity management applies only to on-network operation.

MCSs are services that require preferential handling compared to normal telecommunication services, e.g. in support of police or fire brigade.

MCSs can be used for public safety applications and also for general commercial applications (e.g., utility companies and railways).

This document is applicable to User Equipment (UE) supporting the identity management client functionality, and to application servers supporting the identity management server functionality.

2 References p. 5

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2] Void.

[3]

TS 22.179: "Mission Critical Push To Talk (MCPTT) over LTE".

[4] Void.

[5]

RFC 6749: "The OAuth 2.0 Authorization Framework".

[6]

"OpenID Connect Core 1.0": incorporating errata set 1.

[7]

W3C.REC-html401-19991224: "HTML 4.01 Specification".

[8]

TS 23.379: "Functional architecture and information flows to support mission critical communication services".

[9] Void.

[10]

RFC 2818: "HTTP Over TLS".

[11]

TS 24.483: "Mission Critical Services (MCS) Management Object (MO)".

[12]

TS 24.379: "Mission Critical Push To Talk (MCPTT) call control Protocol specification".

[13]

TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2".

[14]

RFC 6750: "The OAuth 2.0 Authorization Framework: Bearer Token Usage".

[15]

TS 24.109: "Bootstrapping interface (Ub) and network application function interface (Ua); Protocol details".

[16]

TS 23.280: "Common functional architecture to support mission critical services; Stage 2".

[17]

TS 33.180: "Security of the Mission Critical Service".

[18]

RFC 8693: "OAuth 2.0 Token Exchange".

[19]

RFC 7523: "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants".

[20]

RFC 7159: "The JavaScript Object Notation (JSON) Data Interchange Format".

[21]

TS 24.281: "Mission Critical Video (MCVideo) signalling control; Protocol specification".

[22]

TS 23.282: "Mission Critical Data (MCData) signalling control; Protocol specification".

[23]

RFC 7230: "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing".

[24]

RFC 7231: "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content".

[25]

TS 24.484: "Mission Critical Services (MCS) configuration management; Protocol specification".

3 Definitions and abbreviations p. 6

3.1 Definitions p. 6

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

IdM client id:

The client_id as specified in TS 33.180 which is used to identify the IdM client to the IdM server.

Authorisation endpoint:

An identity management server protocol endpoint used by the identity management client to obtain an authorisation grant, as specified in RFC 6749.

Token endpoint:

An identity management server protocol endpoint used by the identity management client to exchange an authorisation grant for an access token, as specified in RFC 6749.

MC UE:

A UE that is used to host one or more MC service clients.

For the purposes of the present document, the following terms and definitions given in TS 22.179 apply:

MCPTT UE

For the purposes of the present document, the following terms and definitions given in TS 23.379 apply:

MCPTT group ID

MCPTT ID

For the purposes of the present document, the following terms and definitions given in TS 23.228 apply:

Public service identity

For the purposes of the present document, the following terms and definitions given in TS 23.280 apply:

MC service

MC service client

MC service group

MC service ID

MC service user

MC user

3.2 Abbreviations p. 7

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

HTTP

Hypertext Transfer Protocol

IdM

Identity Management

LTE

Long Term Evolution

MCData

Mission Critical Data

MC ID

Mission Critical User Identity

MCPTT

Mission Critical Push To Talk

MCVideo

Mission Critical Video

OIDC

OpenID Connect

TLS

Transport Layer Security

User Equipment

4 General p. 7

4.1 Identity management p. 7

The Identity Management functional model for MC services is shown in Figure 4.1-1 below and consists of the identity management server located in the common services core and the identity management client located in the MC UE. The IdM server and the IdM client in the MC UE establish the foundation for MC services user authentication and user authorisation.

Reproduction of 3GPP TS 24.482, Fig. 4.1-1: Functional model for MC services identity management

Figure 4.1-1: Functional model for MC services identity management

The CSC-1 reference point, between the IdM client in the UE and the Identity Management server, provides the interface for user authentication. CSC-1 supports OpenID Connect Core 1.0 [6] and RFC 6749.

The OpenID Connect profile for MC services is implemented as described in TS 33.180. The MC services user authentication, the MC services user authorisation, the OpenID Connect Core 1.0 [6] and the OpenID Connect profile described in TS 33.180 for MC services forms the basis of the MC services identity management architecture.

Subclause 6.2.1 and subclause 6.3.1 describes the procedures for the MC services user authentication. OIDC is flexible with respect to the user authentication mechanism used. As TS 33.180 has indicated that username and password authentication is mandatory to support, that mechanism is included in subclause 6.2.1 and subclause 6.3.1, although other mechanisms are possible.

When the MC services user is authenticated, the procedure will provide an id token, an access token and a refresh token, which are all described in TS 33.180. The access token is scoped to the services the MC services user is authorised for, e.g., group management services, key management services and MC services. The access token will be utilized for MCPTT service authorisation, MCData service authorisation and MCVideo service authorisation as documented in TS 24.379, TS 24.282 and TS 24.281 respectively.

After an MC service user has obtained an access token from their home IdM server, they can acquire a security token from their home IdM server by means of the procedures of subclause 6.2.2, subclause 6.3.2. The security token can be used to acquire an access token from the IdM server of a partner system to allow access to resources in the partner system's domain by means of the procedures of subclause 6.2.3 and subclause 6.3.3.

5 Entities p. 8

5.1 Identity management client p. 8

The identity management client acts as the application user agent for MC ID transactions. It interacts with the identity management server. The identity management client:

shall support identity management registration to the identity management server;
shall support the MC services user authentication framework as specified in TS 33.180;
shall support a username and password method of authentication as specified in TS 33.180; and
may support additional methods of authentication.

5.2 Identity management server p. 8

The identity management server is a functional entity that is capable of authenticating the MC ID. It contains the knowledge and means to do authentication by verifying the credentials supplied by the user. The identity management server:

shall support identity management registration of the identity management client;
shall support the MC services user authentication framework as specified in TS 33.180;
shall support a username and password method of authentication as specified in TS 33.180; and
may support additional methods of authentication.

5.3 MC service client p. 8

The MC service client shall interact with the IdM client as specified in subclause 6.2:

to trigger initiation of the user authentication procedure; and
to receive the credentials obtained from the IdM server.

5.4 HTTP proxy p. 8

The HTTP proxy acts as the proxy for all hypertext transactions between the HTTP client and the HTTP server. The HTTP proxy terminates the TLS session with the HTTP client of the MC UE in order to allow the HTTP client to establish a single TLS session for hypertext transactions with multiple HTTP servers as specified in TS 23.280.

6 Authentication procedures p. 9

6.1 General p. 9

6.2 Identity management client procedures p. 9

6.2.1 User authentication p. 9

Upon an indication from the MC service client to initiate MC service user authentication, the IdM client shall perform the user authentication procedure according to TS 33.180 with the following clarifications:

shall establish a TLS tunnel to the authorisation endpoint of the IdM server as specified in TS 33.180 using the configured URL of the authorisation endpoint of the IdM server as specified in the "/<x>/OnNetwork/AppServerInfo/IDMSAuthEndpoint" leaf node defined in TS 24.483 and the clarifications in Annex A;
shall generate an OIDC Authentication Request message as specified in the OpenID Connect 1.0 [6] and RFC 6749 with the following clarifications:
1. shall generate an HTTP GET request method according to IETF RFC 7231;
2. shall include the configured parameter IdM client id as the client_id parameter specified in TS 33.180 in the query component of the authorization endpoint's URI using the "application/x-www-form-urlencoded" format as specified in W3C.REC-html401-19991224 [7]; and
  
  NOTE 1:
  The configuration of client_id is specified in TS 24.483.
3. shall include the remaining required parameters as specified in TS 33.180 in the query component of the authorization endpoint's URI using the "application/x-www-form-urlencoded" format as specified in W3C.REC-html401-19991224 [7]; and
shall send the HTTP GET request method towards the IdM server.

NOTE 2:
The OpenID Connect 1.0 [6] specification allows for an alternative mechanism for sending the OIDC Authentication request message using an HTTP POST request method which can be used in place of steps 1, 2, and 3 above.

Upon receipt of an HTTP 200 (OK) response from the IdM server, the IdM client:

shall prompt the MC service user for their username and password;

NOTE 3:
Other types of authentication are supported and are not defined by the OIDC specifications. TS 33.180 has defined username and password as a mandatory authentication method to be supported, hence a procedure to realize that method is included here.
shall generate an HTTP POST request method containing the MC service user's username and password; and
shall send the HTTP POST request method towards the IdM server.

Upon receipt of an OIDC Authentication Response message, the IdM client:

shall establish a TLS tunnel to the token endpoint of the IdM server as specified in TS 33.180 using the configured URL of the token endpoint of the IdM server as specified in the "/<x>/OnNetwork/AppServerInfo/IDMSTokenEndpoint" leaf node defined in TS 24.483 and the clarifications in Annex A;
shall generate an OIDC Token Request message as specified in OpenID Connect 1.0 [6] and RFC 6749 with the following clarifications:
1. shall generate an HTTP POST request method according to IETF RFC 7231; and
2. shall include the grant_type parameter set to a value of "authorization_code" and the other required parameters in the entity body of the HTTP POST request method using the using the "application/x-www-form-urlencoded" format as specified in TS 33.180; and
shall send the HTTP POST request method towards the IdM server.

Upon receipt of an OIDC Token Response message, the IdM client:

shall validate the id_token, access_token and refresh token in the received OIDC Token Response message as specified in the OpenID Connect 1.0 [6] specification; and
shall provide the id_token and access_token in the received OIDC Token Response message to the MC service client.

The MC UE may repeat the entire procedure in this subclause as needed to obtain the necessary authorisation tokens for the MC service clients, depending on the scope parameter in the Authentication Request message as specified in TS 33.180.

6.2.2 Token exchange procedure |R14| p. 10

Upon an indication from the MC service client to acquire a security token for authentication of the MC service user with a partner IdM server, the IdM client:

shall establish a TLS tunnel to the token endpoint of the home IdM server as specified in TS 33.180 using the configured URL of the token endpoint of the IdM server as specified in the "/<x>/OnNetwork/AppServerInfo/IDMSTokenEndpoint" leaf node of the MCS UE initial configuration MO defined in TS 24.483 and the clarifications in Annex A;
shall generate a Token Exchange Request message as specified in TS 33.180 and RFC 8693 with the following clarifications:
1. shall generate an HTTP POST request method according to IETF RFC 7231;
2. shall include the following parameters in the in the entity body of the HTTP POST request method using the "application/x-www-form-urlencoded" format as specified in W3C.REC-html401-19991224 [7]:
  1. the grant_type parameter set to a value of "urn:ietf:params:oauth:grant-type:token-exchange" as specified in sub-clause B.7.2 of TS 33.180; and
  2. the other required parameters as specified in subclause B.7.2 of TS 33.180; and
shall send the HTTP POST request method towards the IdM server.

Upon receipt of a Token Exchange Response message as specified in TS 33.180 and RFC 8693, the IdM client:

shall extract the security token contained in the access_token parameter of the received Token Exchange Response message; and
shall temporarily store the extracted security token.

6.2.3 Token request to a partner system IdM server |R14| p. 10

Upon an indication from the MC service client to acquire an access token from a partner IdM server to authorise the MC service user to access the resources of a partner system, the IdM client:

shall obtain a valid security token appropriate for inclusion in a Token Request message to be sent to the targeted partner IdM server by the procedures specified in subclause 6.2.2 if the IdM client has not already done so; and
shall generate a Token Request message as specified in the OpenID Connect 1.0 [6] and RFC 6749 with the following clarifications:
1. If the IdM client is attempting to acquire an access token from a partner IdM server not for the purpose of migration, the IdM client shall establish a TLS tunnel to the configured URL of the token endpoint of the partner system IdM server as specified in the MC service user profile MO with the following clarifications:
  1. for MCPTT, use the token endpoint defined in the "/<x>/<x>/OnNetwork/GroupServerInfo/IDMSTokenEndpointList/<x>/Entry/IDMSTokenID" leaf node as defined in the MCPTT service user profile MO TS 24.483;
  2. for MCData, use the token endpoint defined in the "/<x>/<x>/OnNetwork/MCDataGroupList/<x>/Entry/IdMSTokenEndPointList/<x>/IdMSTokenEndPoint" leaf node as defined in the MCData service user profile MO TS 24.483; and
  3. for MCVideo, use the token endpoint defined in the "/<x>/<x>/OnNetwork/MCVideoGroupList/<x>/Entry/IdMSTokenEndPointList/<x>/IdMSTokenEndPoint" leaf node as defined in the MCVideo service user profile MO TS 24.483.
  NOTE 1:
  The specific IDM token endpoint can be found by finding the server information for a particular MC service group.
  
  NOTE 2:
  The specific IDM token endpoint can also be found in the respective MC service user profile document (see TS 24.483) in the parameters corresponding to those identified in steps i), ii) and iii) above.
  
  If the IdM client is attempting to acquire an access token from a partner IdM server for the purpose of migration, the IdM client shall establish a TLS tunnel to the configured URL of the token endpoint of the partner system IdM server as specified in the MC service user profile configuration document with the following clarifications:
  1. for MCPTT, use the token endpoint defined in the <idms-token-endpoint> element in the <App-Server-Info> element in the <on-network> element in the <mcptt-UE- initial-configuration> in the <AccessInformationForPartnerMCPTTSystem> element in the <MigratablePartnerMCPTTSystemInfo> element in the <anyExt> element in the <OnNetwork> element in the <mcptt-user-profile> document as defined in TS 24.484;
  2. for MCData, use the token endpoint defined in the <idms-token-endpoint> element in the <App-Server-Info> element in the <on-network> element in the <mcptt-UE- initial-configuration> in the <AccessInformationForPartnerMCDataSystem> element in the <MigratablePartnerMCDataSystemInfo> element in the <anyExt> element in the <OnNetwork> element in the <mcdata-user-profile> document as defined in TS 24.484; and
  3. for MCVideo, use the token endpoint defined in the <idms-token-endpoint> element in the <App-Server-Info> element in the <on-network> element in the <mcptt-UE- initial-configuration> in the <AccessInformationForPartnerMCVideoSystem> element in the <MigratablePartnerMCVideoSystemInfo> element in the <anyExt> element in the <OnNetwork> element in the <mcvideo-user-profile> document as defined in TS 24.484.
2. The IdM client shall generate an HTTP POST request method according to IETF RFC 7231 including in the entity body the following parameters using the "application/x-www-form-urlencoded" format as specified in W3C.REC-html401-19991224 [7]:
  1. the grant_type parameter set to value of "urn:ietf:params:oauth:grant-type:jwt-bearer" as specified in sub-clause B.7.4 of TS 33.180 and RFC 7523; and
  2. all other required parameters specified in sub-clause B.7.4 of TS 33.180; and
3. The IdM client shall send the HTTP POST request method towards the token endpoint of the partner system IdM server.

6.3 Identity management server procedures p. 12

6.3.1 User authentication p. 12

Upon receipt of an OIDC Authentication Request message as specified in the OpenID Connect 1.0 [6] and RFC 6749 via a secure TLS tunnel between the identity management client and the authorisation endpoint of the IdM server, the IdM server:

shall validate the received OIDC Authentication Request message as specified in the OpenID Connect 1.0 [6] and RFC 6749;
shall generate an HTTP 200 (OK) response according to IETF RFC 7231 including form data to prompt the MC service user for their username and password credentials; and

NOTE 1:
The username will be the MC service user's MC ID.
shall send the HTTP 200 (OK) response towards the IdM client.

Upon receipt of an HTTP POST request method from the IdM client containing the MC service user's username and password, the IdM server authenticates the MC service user and:

shall generate an OIDC Authentication Response message as specified in OpenID Connect 1.0 [6] and RFC 6749 with the following clarifications:
1. shall generate an HTTP 302 (FOUND) response according to IETF RFC 7231; and
2. shall include the required parameters including the authorization_code as specified in TS 33.180 in the query component of the redirection URI contained in the Location header field of the HTTP FOUND request method using the "application/x-www-form-urlencoded" format as specified in W3C.REC-html401-19991224 [7]; and
shall send the HTTP 302 (FOUND) response towards the IdM client.

Upon receipt of an OIDC Token Request message via a secure TLS tunnel established between the identity management client and the token endpoint of the IdM server, the IdM server:

shall validate the OIDC Token Request message and if valid shall generate an OIDC Token Response message as specified in OpenID Connect 1.0 [6] and RFC 6749 with the following clarifications:
1. shall generate an HTTP 200 (OK) response according to IETF RFC 7231;
2. shall based on the received MC ID obtained from the received user authentication credentials, determine the MC service ID of the MC service user;
3. shall include an id_token, access_token and refresh_token and MC service ID as specified in TS 33.180; and
4. shall include the other required parameters as specified in OpenID Connect 1.0 [6] and RFC 6749; and
shall send the HTTP 200 (OK) response towards the IdM client.

6.3.2 Token exchange procedure |R14| p. 12

Upon receipt of a Token Exchange Request message as specified in RFC 8693 via a secure TLS tunnel between the identity management client and the token endpoint of the IdM server, the IdM server:

shall validate the received Token Exchange Request message as specified in IETF RFC 8693;
shall generate a Token Exchange Response message as specified in RFC 8693 and RFC 6749 with the following clarifications:
1. shall generate an HTTP 200 (OK) response to the received Token Exchange Request message according to IETF RFC 7231; and
2. include the parameters specified in sub-clause B.7.3 of TS 33.180 serialized into a JavaScript Object Notation (JSON) structure as specified in RFC 8693 and RFC 7159 with the following clarification:
  1. include the parameters specified in sub-clause B.8 of TS 33.180 in the security token included in the access_token parameter specified in sub-clause B.7.3 of TS 33.180; and
shall send the HTTP 200 (OK) response towards the IdM client.

6.3.3 Token request from an IdM client to a partner system |R14| p. 13

Upon receipt of an OIDC Token Request message via a secure TLS tunnel established between the identity management client and the token endpoint of the IdM server, the IdM server:

shall validate the Token Request message and the included security token as specified in sub-clause B.11.3 of TS 33.180 and if valid shall generate a Token Response message as specified in OpenID Connect 1.0 [6] and RFC 6749 with the following clarifications:

NOTE:
The access token referred to in step 1) is the security token provided by the home IdM server by the procedures of subclause 6.3.2.
1. shall generate an HTTP 200 (OK) response according to IETF RFC 7231;
2. shall include an id_token, access_token and refresh_token and MCPTT ID as specified in TS 33.180; and
3. shall include the other required parameters as specified in OpenID Connect 1.0 [6] and RFC 6749; and
shall send the HTTP 200 (OK) response towards the IdM client.

7 Inter/intra domain interface security p. 13

Inter/intra domain interface security shall be provided as specified in TS 33.180;

A (Normative) HTTP entities p. 14

A.1 Scope p. 14

This annex describes the functionality expected from the HTTP entities (i.e., the HTTP client, the HTTP proxy and the HTTP server) defined by TS 23.280 and TS 33.180.

A.2 Procedures p. 14

A.2.1 HTTP client p. 14

A.2.1.1 General p. 14

The HTTP client in the UE shall support the client role defined in IETF RFC 7230.

A.2.1.2 HTTP client in UE p. 14

The HTTP client in the UE shall support the client role defined in RFC 2818.

The HTTP client in the UE shall support transport layer security (TLS) as specified in TS 33.180.

The HTTP client in the UE is configured with the following parameters:

a home HTTP proxy FQDN;
a home HTTP proxy port;
a TLS tunnel authentication method. The TLS tunnel authentication method parameter is set to one of the following:
1. one-way authentication of the HTTP proxy based on the server certificate;
2. mutual authentication based on certificates; and
3. mutual authentication based on pre-shared key;
as specified in TS 33.180;
if the TLS tunnel authentication method is the mutual authentication based on certificates:
1. TLS tunnel authentication X.509 certificate; and
if the TLS tunnel authentication method is the mutual authentication based on pre-shared key;
1. TLS tunnel authentication pre-shared key.

The HTTP client in the UE shall establish a TCP connection towards the home HTTP proxy FQDN and the home HTTP proxy port, unless the specific TCP connection is to be used for the IdM client to IdM server procedures described in subclause 6.2 and subclause 6.3 in the present document, in which case the HTTP client shall establish a TCP connection towards the IdM server.

The HTTP client in the UE shall establish a TLS tunnel via the TCP connection as specified in TS 33.180. When establishing the TLS tunnel, the HTTP client in the UE shall act as a TLS client and the UE shall perform the TLS tunnel authentication using the TLS authentication method indicated by the TLS tunnel authentication method parameter according to TS 33.180. The UE shall use the configured TLS tunnel authentication X.509 certificate and the configured TLS tunnel authentication pre-shared key when applicable for the used TLS authentication method. In order to prevent man-in-the-middle attacks, the HTTP client in the UE shall check the home HTTP proxy FQDN against the server's identity as presented in the received server's certificate message if the TCP connection terminates on the HTTP proxy. The HTTP client in the UE shall not check the portion of dereferenced HTTP URL against the server's identity as presented in the received server's certificate message if the TCP connection terminates on the HTTP proxy, but shall do so if the TCP connection terminates on the IdM server.

The HTTP client in the UE shall send and receive all HTTP messages via the TLS tunnel.

If the HTTP client in the UE has an access token of the "bearer" token type as specified in RFC 6750], the HTTP client in the UE shall include an Authorization header field with the "Bearer" authentication scheme as specified in RFC 6750] in HTTP requests.

A.2.1.3 HTTP client in network entity p. 15

The HTTP client in the network entity is configured with the following parameters:

a home HTTP proxy FQDN; and
a home HTTP proxy port.

The HTTP client in the network entity shall send and receive all HTTP messages via the home HTTP proxy.

The HTTP client in the network entity shall insert an X-3GPP-Asserted-Identity header field as specified in TS 24.109 in the HTTP request and shall set X-3GPP-Asserted-Identity header field to the identity of the HTTP client in the network entity. The identity of the HTTP client in the network entity can be a public service identity, an MC service group ID, or an MC service ID.

A.2.2 HTTP proxy p. 15

A.2.2.1 General p. 15

The HTTP proxy shall support proxy role of IETF RFC 7230.

A.2.2.2 HTTP request method from HTTP client in UE p. 15

The HTTP proxy shall support the server role of IETF RFC 7230, and IETF RFC 2818.

The HTTP proxy shall support transport layer security (TLS) as specified in TS 33.180.

The HTTP proxy is configured with the following HTTP proxy parameters:

an FQDN of an HTTP proxy for UEs; and
a TCP port of an HTTP proxy for UEs.

The HTTP proxy shall support establishing TCP connections on the FQDN of HTTP proxy for UEs and the TCP port of HTTP proxy for UEs. The HTTP proxy shall support establishing a TLS tunnel via each such TCP connection as specified in TS 33.180. When establishing the TLS tunnel, the HTTP proxy shall act as TLS server.

Upon reception of an HTTP request method via a TLS tunnel:

if the HTTP request method contains an X-3GPP-Asserted-Identity header field as specified in TS 24.109, the HTTP proxy shall reject the HTTP request method with an HTTP 403 (Forbidden) response and do not continue with rest of the steps;
if the HTTP request method contains a Request-URI identifying a resource in a partner's MC service provider, the HTTP proxy shall forward the HTTP request method according to the Request-URI; and
if an HTTP request method contains a Request-URI identifying a resource in own MC service provider, the HTTP proxy shall act as reverse proxy for the HTTP request method and shall forward the HTTP request method according to the MCPTT provider policy.

A.2.2.3 HTTP request method from HTTP client in network entity within trust domain p. 16

The HTTP proxy is configured with the following parameters:

a FQDN of an HTTP proxy for trusted entities; and
a TCP port of an HTTP proxy for trusted entities.

Upon receiving an HTTP request method via a TCP connection established on the FQDN of HTTP proxy for UEs and the TCP port of HTTP proxy for UEs, if the TCP connection is between network elements within trusted domain as specified in TS 33.180:

if the HTTP request method contains a Request-URI identifying a resource in a partner's MC service provider, the HTTP proxy shall forward the HTTP request method according to the Request-URI; and
if an HTTP request method contains Request-URI identifying a resource in own MC service provider, the HTTP proxy shall act as reverse proxy for the HTTP request method and shall forward the HTTP request method according to MC service provider policy.

A.2.3 HTTP server p. 16

The HTTP server shall support the server role of IETF RFC 7230.

Upon reception of an HTTP request:

if the received HTTP request does not contain an Authorization header field with the "Bearer" authentication scheme and a bearer access token as specified in RFC 6750 and the received HTTP request does not contain an X-3GPP-Asserted-Identity header field as specified in TS 24.109, the HTTP server shall reject the request with HTTP 403 (Forbidden) response;
if the received HTTP request contains an Authorization header field with the "Bearer" authentication scheme and a bearer access token as specified in RFC 6750;
1. the HTTP server shall validate the bearer access token as specified in RFC 6750; and
2. the HTTP server shall consider the MC service ID derived from the bearer access token as the identity of the sender of the HTTP request; and
if the received HTTP request does not contain an Authorization header field with the "Bearer" authentication scheme and a bearer access token as specified in RFC 6750 and the received HTTP request contains an X-3GPP-Asserted-Identity header field as specified in TS 24.109, the HTTP server shall consider the URI in the X-3GPP-Asserted-Identity header field as the identity of the sender of the HTTP request.