Content for  TS 33.180  Word version:  17.8.0

This clause expands on the MCX user service authorization step shown in Figure 5.1.1-1 step C. MCX User Service Authorization is the function that validates whether or not a MCX user has the authority to access certain MCX services. In order to gain access to MCX services, the MCX client in the UE presents an access token (acquired during user authentication as described in subclause 5.1.2) to each service of interest (i.e. Key Management, MCX server, Configuration Management, Group Management, etc.). If the access token is valid, then the user is granted the use of that service. Figure 5.1.3.1-1 shows the flow for user authorization which covers key management authorization, MCX user service authorization, configuration management authorization, and group management authorization. For key management authorization, the KM client in the UE presents an access token to the KMS over HTTP. The access token shall be scoped for key management services as defined in Annex B.4.2.2. The KMS validates the access token and if successful, provides one or more sets of user specific key material back to the UE KM client based on the MC service ID(s) present in the access token (MCPTT ID, MCVideo ID and/or MCData ID). User specific key material includes identity based key information for media and signalling protection. If an interworking key management record (InterKMRec) exists and is associated to the requesting MC service ID (see clause 11.2.3), the KMS shall also provide the InterKMRec. This key management authorisation may be repeated for each KM service the user is authorised to use (MCPTT, MCVideo, MCData). In order to secure the transfer of user specific key material from the KMS to the KM client when using the TrK and InK, the KM client includes the TrK-ID and the InK-ID in the key management authorization request. For MCPTT user service authorization, the MCPTT client in the UE presents an access token to the MCPTT server over SIP. The access token shall be scoped for MCPTT services as defined in Annex B.4.2.2. The MCPTT server validates the access token and if successful, authorizes the user for full MCPTT services and sends an acknowledgement back to the MCPTT client. The MCPTT server then maps and maintains the IMPU to MCPTT ID association. The MCPTT ID to IMPU association shall only be known to the application layer. The SIP message used to convey the access token from the MCPTT client to the MCPTT server may be either a SIP REGISTER or SIP PUBLISH message. For MCVideo service authorization, the MCVideo client in the UE presents an access token to the MCVideo server over SIP. The access token shall be scoped for MCVideo services as defined in Annex B.4.2.2. The MCVideo server validates the access token and if successful, authorizes the user for full MCVideo services and sends an acknowledgement back to the MCVideo client. The MCVideo server then maps and maintains the IMPU to MCVideo ID association. The MCVideo ID to IMPU association shall only be known to the application layer. The SIP message used to convey the access token from the MCVideo client to the MCVideo server may be either a SIP REGISTER or SIP PUBLISH message. For MCData user service authorization, the MCData client in the UE presents an access token to the MCData server over SIP. The access token shall be scoped for MCData services as defined in Annex B.4.2.2. The MCData server validates the access token and if successful, authorizes the user for full MCData services and sends an acknowledgement back to the MCData client. The MCData server then maps and maintains the IMPU to MCData ID association. The MCData ID to IMPU association shall only be known to the application layer. The SIP message used to convey the access token from the MCData client to the MCData server may be either a SIP REGISTER or SIP PUBLISH message. The UE can now perform configuration management authorization and download the user profile for the service(s) (MCPTT, MCVideo, MCData). Following the flow described in subclause 10.1.4.3 of TS 23.280 "MC service user obtains the MC service user profile(s) from the network", the Configuration Management (CM) client in the UE sends an access token in the user profile query to the Configuration Management server over HTTP. The access token shall be scoped for configuration management services as defined in Annex B.4.2.2. The CM server receives the request and validates the access token, and if valid, the CM server uses the identity from the access token (MCPTT ID, MCVideo ID, MCData ID) to obtain the user profile from the MCX user database. The CM server then sends the user profile back to the CM client over HTTP. This configuration management authorisation may be repeated for each CM service the user is authorised to use (MCPTT, MCVideo, MCData). Upon receiving each user profile, the Group Management (GM) client in the UE can now perform group management authorization. The GM client obtains the user's group membership information from the user profile, and following the flow shown in clause 10.1.5.2 of TS 23.280 "Retrieve group configurations at the group management client", the Group Management (GM) client in the UE sends an access token in the Get group configuration request to the host GM server of the group membership over HTTP. The access token shall be scoped for group management services as defined in Annex B.4.2.2. The GM server validates the access token, and if valid, completes the flow. As part of group management authorization, group key information is provided as per subclause 5.7 of the present document. This group management authorisation may be repeated for each GM service the user is authorised to use (MCPTT, MCVideo, MCData). For MC UEs that support mission critical location services, authorization is accomplished by including an access token in each location message (i.e. location information report, location reporting trigger, etc.) sent by the location management client to the location management server. The access token shall be scoped for location management services as defined in Annex B.4.2.2. The location management server validates the access token and (if successful) processes the message (e.g. accepts and stores the location information report). If an access token cannot be validated, local policy may dictate an action to be taken within the location management server with regards to the received location message (e.g. the local policy may require storage of the location information report as an emergency provision).

The user authorization procedure in Step C of Figure 5.1.1-1 is further detailed into 5 sub steps that comprise the MCX user service authorization process: