Content for TS 24.229 Word version: 19.4.1

1… 3… 4… 4.5… 5… 5.1.1.4… 5.1.2… 5.1.4… 5.2… 5.2.3… 5.2.6… 5.2.7… 5.3… 5.4… 5.4.1.2.2… 5.4.1.3… 5.4.2 5.4.3… 5.4.3.3… 5.4.4… 5.5… 5.7… 5.7.2… 5.8… 5.11… 6… 6.6… 7… 7.2A… 7.2A.6… 7.3… 7.9A… 8… A… A.2… A.2.1.4… A.2.1.4.7… A.2.1.4.8… A.2.1.4.10A… A.2.1.4.12… A.2.2… A.2.2.4… A.2.2.4.7… A.2.2.4.8… A.2.2.4.10A… A.2.2.4.12… A.3… A.3.3… B… C… E… F… H… I… K… L… L.2A… M… N… O… Q… R… S… U… U.2A… V… W…

V.1 Scope V.2 Ms reference point V.2.1 General V.2.2 Resource structure V.2.3 Request requirements V.2.4 Response requirements V.2.5 signing V.2.6 verification

V (Normative) HTTP Profiling |R15| p. 997

V.1 Scope p. 997

The present annex defines the HTTP messages and data types sent over reference points specified in the present document.

V.2 Ms reference point p. 997

V.2.1 General p. 997

The Ms reference point is used to request signing of an Identity header field or request verification of a signed assertion in an Identity header field.

HTTP POST method is used for the verification request.

HTTP 200 (OK) is used when the AS for verification has successfully processed the verification request.

HTTP POST method is used for the signing request.

HTTP 200 (OK) is used when the AS for signing has successfully processed the signing request.

HTTP POST method is used for the diversion signing request.

HTTP 200 (OK) is used when the AS for signing has successfully processed the diversion signing request.

HTTP POST method is used for the Resource-Priority header field signing request.

HTTP 200 (OK) is used when the AS for signing has successfully processed the Resource-Priority header field signing request.

HTTP POST method is used for the Resource-Priority and Priority header fields signing request.

HTTP 200 (OK) is used when the AS for signing has successfully processed the Resource-Priority and Priority header field signing request.

HTTP POST method is used for the RCD info signing request.

HTTP 200 (OK) is used when the AS for signing has successfully processed the RCD info signing request.

Reproduction of 3GPP TS 24.229, Fig. V.2.1-1: Usage of the Ms reference point

Figure V.2.1-1: Usage of the Ms reference point

V.2.2 Resource structure p. 998

API resources are defined with respect to a "server root". The server root is a URI:

{hostname}:{port}/{RoutingPath}.

The resource URI structure is shown in Figure V.2.2-1.

Reproduction of 3GPP TS 24.229, Fig. V.2.2-1: Resource structure for the resource exposed over the Ms reference point

Figure V.2.2-1: Resource structure for the resource exposed over the Ms reference point

For signing and verification of the RCD info, resource URIs "/rcdSigning" and "/rcdVerification" shall only be used if the Calling number verification using signature verification and attestation information feature is not supported. Otherwise, resource URIs "/signing" and "/verification" shall be used for the RCD info.

Table V.2.2-1: Variables for the server root

Variable	Description	Presence
hostname	Host name used to reach the resource.	M
port	Port where the resource is reached	M
RoutingPath	Path identifying the resource	M

V.2.3 Request requirements p. 999

V.2.3.1 General p. 999

V.2.3.2 Request header requirements p. 999

Table V.2.3.2-1 lists request header field requirements.

Table V.2.3.2-1: Header fields included in the requests

Header field name	Description	Presence
Content-Type	Describes the format of the request body. Shall be set to "application/json"	M
Accept	Describes the supported format of the response body. Shall be set to "application/json" if present	O

The JSON object in a request starts with the name of the request.

For the signingRequest, the JSON object starts with:

{
   "signingRequest": {

For the verificationRequest, the JSON object starts with:

{

   "verificationRequest": {

V.2.4 Response requirements p. 999

V.2.4.1 General p. 999

V.2.4.2 Response header requirements p. 999

Table V.2.4.2-1: Header fields included in the responses

Header field name	Description	Presence
Content-Type	Describes the format of the response body. Shall be set to "application/json"	M

The JSON object in a response starts with the name of the response.

For the signingResponse, the JSON object starts with:

{
   "signingResponse": {

For the verificationResponse, the JSON object starts with:

{
   "verificationResponse": {

V.2.4.3 Error response requirements p. 1000

V.2.4.3.1 General p. 1000

If the server cannot process the request, the server provides an HTTP error response. The error response contains a JSON object specifying the error type.

The server provides a service error when the server is unable to process the request.

The server provides a policy error when the server is able to process the request, but not able to complete the service execution due to a policy restriction.

V.2.4.3.2 Service errors p. 1000

Table V.2.4.3.2-1: Service failure descriptions

Exception ID	Exception text	HTTP status code	Exception variables	Description
-	Error: Missing request body.	400	-	The request could not be processed due to missing request body.
-	Error: Missing mandatory parameter.	400	-	The request could not be processed due to missing parameters.
-	Error: Requested response body type is not supported.	406	-	The request could not be processed due to a not supported message body format.
-	Error: Requested resource not found.	404	-	The request could not be processed due to no resource available related to the Request-URI
-	Error: Unsupported request body type.	415	-	The request could not be processed due to not supported message body.
-	Error: Invalid parameter value.	400	-	The request could not be processed due to invalid parameter value.
-	Error: Failed to parse message body.	400	-	The request could not be processed due to failure to parse the message body.
-	Error: Missing mandatory Content-Length headers	411	-	The request could not be processed due to a missing Content-Length header.

V.2.4.3.3 Policy errors p. 1001

Table V.2.4.3.3-1: Policy failure descriptions

Exception ID	Exception text	HTTP status code	Exception variables	Description
-	Method not allowed	405	-	The resource was invoked with unsupported operation
-	Internal server error.	500	-	The request failed due to internal error

V.2.5 signing p. 1001

V.2.5.1 General p. 1001

To construct a PASSporT SHAKEN object specified in RFC 8588, a PASSporT rph object specified in RFC 8443 and RFC 9027, a PASSporT div object, specified in RFC 8946, or a PASSporT rcd object, specified in RFC 9795, the client sends an HTTP POST request to the AS for signing containing the SIP request information plus any additional claim information to be signed by the target PASSporT type. If the request was successfully processed, then the received signingResponse contains an Identity header field value populated with a signed PASSporT of the requested type along with the appropriate Identity header field parameters.

Unsuccessful requests are responded with an HTTP 4xx or 5xx response.

V.2.5.2 Data types p. 1001

Table V.2.5.2-1 specifies the data types included in the signing request. The signing request contains the claims included in:

a PASSporT SHAKEN JSON Web Token, specified in RFC 8588;
a PASSporT div JSON Web Token specified in RFC 8946];
a PASSporT rph JSON Web Token specified in RFC 8443] and RFC 9027; or
a PASSporT rcd JSON Web Token specified in RFC 9795.

Table V.2.5.2-1: Data types for the signingRequest

Parameter	Type; Value	Presence	Description
ppt	string; set to the value of the "ppt" parameter in the protected header of the PASSporT to be created	O	This parameter is included to inform the AS for signing the type of PASSporT that is to be constructed and signed.
attest	string; "A", "B" or "C"	O	Identifying the relation between the service provider attesting the identity and the subscriber. Specified in RFC 8588.
dest	array of identity claim JSON objects representing destination identities; tn or uri	M	Identifying the called user taken from the To header field for a "shaken" or "rph" PASSporT as specified in RFC 8224, and from the Request-URI after retargeting for a "div" PASSporT as specified in RFC 8946.
div	identity claim JSON object, tn or uri. A hi element should be included.	O	Identifying the diverting user; i.e., the user identified in the Request-URI before retargeting, taken from the History-Info header field as specified in RFC 8946.
iat	integer; time and date of issuance of the PASSporT token	M	Time since 1 January 1970 in Numeric Date format as specified in RFC 7519.
orig	identity claim JSON object; tn or uri	M	Identifying the calling user. Specified in RFC 8225.
origid	String; UUID	O	Specified in RFC 8588
rph	array of strings that correspond to the r-values indicated in the SIP Resource-Priority header field	O	Contains assertion of the priority level of the user to be used for a given communication session as specified in RFC 8443 and RFC 9027.
sph	string "psap-callback"	O	Contains header field value "psap-callback" of the SIP Priority header field as specified in RFC 9027
rcd	rcd claim JSON object; structured data type containing one or more key value pairs	O	Contains a call initiator data as specified in RFC 9795, i.e. "nam", "apn", "icn", "jcd" and "jcl" key parameters.
rcdi	rcdi claim JSON object with a set of JSON key/value pairs	O	Contains the elements of the "rcd" claim object that require integrity protection with an associated digest over the content referenced by the key string as specified in RFC 9795.

The signing request provides the following two options for identifying the PASSporT type to be constructed:

the PASSporT type is indicated by invoking the signing resource associated with that PASSporT type, as defined in subclause V.2.2; or
the PASSporT type is identified by including a ppt parameter when invoking the /signing resource defined in subclause V.2.2.

Table V.2.5.2-1a indicates representative signingRequest parameter inclusion rules per PASSporT type.

Table V.2.5.2-1a: signingRequest parameters per PASSporT Type

PASSporT Type	Parameter
PASSporT Type	attest	dest	div	iat	orig	origid	rph	sph	rcd	rcdi
shaken	M	M	X	M	M	M	X	X	O	O
div	X	M	M	M	M	X	X	X	O	O
rph	X	M	X	M	M	X	M	O	X	X
rcd	X	M	X	M	M	X	X	X	M	O
rcdi	X	X	X	X	X	X	X	X	M	M
NOTE: "M" means "mandatory", "O" means "optional", and "X" means "not applicable".

Table V.2.5.2-2 further specifies the data types contained in the signing request parameters.

Table V.2.5.2-2: Data types for the signingRequest parameters

Parameter	Type; Value	Presence	Description
apn	JSON key/value pair; tn	O	The "apn" key value as specified in RFC 9795 is an optional alternate presentation number associated with a call initiator, which may for example match the user component of the From header field value of a SIP request (in cases where a network number is carried in the P-Asserted-Identity, or alternatively from the Additional-Identity header field value.
hi	string. An "index" header field parameter as specified in RFC 7044	O	The "index" header field parameter is included in the entry identifying the diverting user in the History-Info header field.
icn	JSON key/value pair; uri	O	The "icn" key value as specified in RFC 9795 is an optional HTTPS URL reference to an image resource that can be used to pictorially represent a call initiator.
jcd	JSON object; structured data type RcdInformation as specified in TS 29.571	O	The "jcd" key value as specified in RFC 9795 contains RCD information about the call initiator and is intended to directly match the Call-Info header field value defined in draft-ietf-sipcore-callinfo-rcd [303]. (NOTE 2)
jcl	JSON key/value pair; uri	O	The "jcl" key value as specified in RFC 9795 is an HTTPS URL that refers to a jCard JSON object on a web server. (NOTE 2)
nam	JSON key/value pair; tn	C	The "nam" key value as specified in RFC 9795 is a display name, associated with a call initiator, which may for example match the display-name component of the From header field value or alternatively from the P-Asserted-Identity header field value of a SIP request. This key shall be included once as part of the "rcd" claim value JSON object. If there is no string associated with a display name, the claim value shall be an empty string.
tn	string; allowed characters as for local-number-digits and global-number-digits defined in RFC 3966	M	The number needs to be in canonical form according to Section 8.3 of RFC 8224.
uri	string; A SIP URI as specified in RFC 3261 following the generic guidelines in RFC 3986.	O	Used if the "orig" or "dest" is given in a SIP URI.
NOTE 1: The TAS is expected to provide a valid globally routable number. NOTE 2: The "jcd" or "jcl" keys may only appear once in the "rcd" claim but they are mutually exclusive.

Table V.2.5.2-3 specifies the data types included in the signing response.

Table V.2.5.2-3: Data types for the signingResponse

Parameter	Type; Value	Presence	Description
identityHeader	string; Identity header field value as specified in RFC 8224	M	This string cannot be NULL

V.2.6 verification p. 1005

V.2.6.1 General p. 1005

To verify one or more received PASSporTs, the client sends a verification request in the form of an HTTP POST request to the AS for verification containing the Identity header field(s) populated with the PASSporT object(s) to be verified. The verification request also contains the following information:

the originating identity and optionally all the diverting identities;
the Resource-Priority header field value and optionally the header field value "psap-callback" of the Priority header field; and/or
the value of the Call-Info header field containing the RCD parameters.

The verificationResponse contains the outcome of the verification in a verstat claim with values as specified for the verstat tel URI parameter in subclause 7.2A.20 and in a verstatPriority claim with values as specified for the Priority-Verstat header field in subclause 7.2.21. The verificationResponse can optionally contain the claims of PASSporT(s) that passed verification.

The verificationResponse can also contain verification results information for each verified PASSporT, as follows:

if verification passed, then verificationResponse contains the validated claims of the PASSporT;
if verification failed, then verificationResponse contains information describing the reason for the failure.

Unsuccessful requests are responded with an HTTP 4xx or 5xx response.

V.2.6.2 Data types p. 1005

Table V.2.6.2-1 specifies the data types included in the verification request.

Table V.2.6.2-1: Data types for the verificationRequest

Parameter	Type; Value	Presence	Description
identityHeader	string; Identity header field value for the originating identity as specified in RFC 8224 and RFC 8588 and the rcd info as specified in RFC 9795	M	This parameter contains the "shaken" Identity header field value to be verified (see NOTE 1).
identityHeaders	array of string; Identity header field values as specified in RFC 8224, RFC 8443, RFC 8946, RFC 9027, RFC 9795. One identityHeader claim per received Identity header field is sent.	O	This array contains the "div", "rph" and "rcd" Identity header field values to be verified (see NOTE 2).
to	string; identity claim JSON object; tn or uri	M	The destination identity taken from the To header field. Used when no div claim is included.
dest	string; identity claim JSON object; tn or uri	O	The destination identity taken from the Request-URI in the incoming request.
time	integer; Numeric date format defined in RFC 7519	M	Time based on the Date header field in the incoming request.
from	string; identity claim JSON object; tn or uri	M	The asserted identity, taken from the P-Asserted-Identity or the From header field of the incoming request
protectedHeaders	array of string; header field(s)	O	Contains the SIP header field(s) protected by claims in the PASSporT(s) of the identityHeaders array or the identityHeader parameter (see NOTE 4).
NOTE 1: For "shaken" PASSporT verification, an identityHeader parameter containing a "shaken" Identity header field shall be included in the verification request. NOTE 2: For "rph" PASSporT verification, an identityHeaders parameter containing an "rph" Identity header field shall be included in the verification request. If the identityHeader parameter contains a "shaken" Identity header field, and/or the identityHeaders parameter contains an "rph" Identity header field, then all "div" Identity header field(s) received in an INVITE request shall be included in the identityHeaders parameter of the verification request. If "rph" PASSporT verification is not to be performed, and if the INVITE request does not contain any "div" Identity header fields, then the identityHeaders parameter shall not be included in the verification request. NOTE 3: The identityHeader parameter containing the "shaken" Identity header field may contain the RCD info as specified in RFC 9795. NOTE 4: The identityHeader parameter applies for the "shaken" Identity header field with the RCD.

Invocation of the verification request results in the verification of the Identity header fields in the identityHeader and identityHeaders parameters. In addition, a verification request invocation can verify the integrity of SIP header fields protected by the "div", "rph" and "rcd" PASSporTs. When verification of SIP header field integrity is required, the protected SIP header field(s) information shall be conveyed in the protectedHeaders parameter.

The dest parameter is included when the verification request includes a div claim, and when the verification service is required to distinguish between a legitimately retargeted request and a maliciously replayed request.

Table V.2.6.2-1a indicates representative inclusion rules for the verification request identityHeader and identityHeaders parameters for the different combinations of PASSporT types to be verified.

Table V.2.6.2-1a: Verification request identityHeader and identityHeaders parameter inclusion rules

PASSporT type(s) to be verified	Parameter
PASSporT type(s) to be verified	identityHeader	identityHeaders
shaken	M	X
shaken, div	M	M
rph	X	M
rph, div	X	M
shaken, rph	M	M
shaken, rph, div	M	M
rcd	X	M
rcd, div	X	M
rcd, rph	X	M
rcd, div, rph	X	M
shaken, div, rcd	M	M
shaken, rph, rcd	M	M
shaken, div, rph, rcd	M	M
shaken, rph, div	M	M
NOTE 1: "M" means "mandatory" and "X" means "not applicable". NOTE 2: The "shaken" and "rcd" PASSporTs may be present in SIP INVITE request as specified in RFC 9795.

Table V.2.6.2-2 specifies the data types included in the verification response.

Table V.2.6.2-2: Data types for the verificationResponse

Parameter	Type; Value	Presence	Description
divResult	array of one or more [div, verstatValue] tuples	O	Parameter informing of the result of the verification of diverting identities. For each verified identity the verstat parameter is added to the verified identity.
verstatValue	string; set to a value defined in Table 7.2A.20.3-1	O	Parameter informing of the result of the verification of originating identity. To be used in the verstat parameter added to the verified identity. The parameter is mandatory if the request contained a PASSporT SHAKEN JSON Web Token.
verstatPriority	string; set to a value defined in Table 7.2.21-1	O	Parameter informing of the result of the verification of the Resource-Priority header field and optionally the header field value "psap-callback" of the Priority header field.
verstatRcd	string; set to one of the following values: "RCD-Validation-Passed", "RCD-Validation-Failed" and "No-RCD-Validation"	O	Parameter informing of the result of the verification of the Call-Info header field containing the RCD parameters if the request contained a rcd claim within PASSporT SHAKEN or rcd JSON Web Token. (NOTE)
verifyResults	array of one or more verifyResult, as defined in Table V.2.6.2-3	O	Each array entry contains the verification results of a PASSporT contained in the request.
NOTE: The verification result values of the rcd claim shall be the same independently if the RCD info was included within the "shaken" or "rcd" PASSporT.

Table V.2.6.2-3 specifies the mandatory data types of the verifyResult parameter included in the verification response.

Table V.2.6.2-3: Data types for mandatory verifyResult parameters

Parameter	Type; Value	Presence	Description
verifyResult	structured data type containing [ppt, status, validClaims, reasonCode, reasonText, passport] tuple	M	Contains the verification results of a single Identity header field contained in the identityHeader parameter or an entry of the identityHeaders array of the verification request. The ppt and status parameters are always present. The inclusion of the other parameters in the tuple depends on the value of the status parameter.
ppt	string, set to the value of the ppt parameter in the protected header of the PASSporT.	M	Identifies the type of PASSporT associated with this array entry.
status	String, set to the value pass, fail or none.	M	Identifies the verification result of the PASSporT associated with this array entry.

Each verifyResult entry of the verifyResults array conveys the verification results of an Identity header field contained in the identityHeader parameter or contained in an entry of the identityHeaders array of the verification request.

Additional verifyResult parameters are returned based on the value of the status parameter as follows:

a status parameter with a value of "fail" returns the parameters shown in Table V.2.6.2-4;
a status parameter with a value of "pass" returns the parameter shown in Table V.2.6.2-5; and
a status parameter with a value of "none" returns no additional parameters.

A status parameter with a value of "none" indicates that the PASSporT type is not supported.

Table V.2.6.2-4 specifies the optional data types of the verifyResult parameter included in the verification response.

Table V.2.6.2-4: Data types of optional verifyResult parameters

Parameter	Type; Value	Presence	Description
reasonCode	integer	O	Identifies the 4xx failure reason code of the failing PASSporT, as defined in RFC 8224.
reasonText	string	O	Identifies the failure text associated with the 4xx failure reason code, as specified in RFC 8224.
passport	string	O	Contains the failing PASSporT
NOTE: These parameters are optional since they are included only when the verifyResult "status" parameter has a value of "fail".

Table V.2.6.2-5 specifies the additional data types included in the verification response when the status parameter contains a value of "pass".

Table V.2.6.2-5: Data types of additional verifyResults parameter for status of "passc"

Parameter	Type; Value	Presence	Description
validClaims	JSON object	O	The validClaims parameter contains the payload of the verified PASSporT.

The validClaims parameter can be used:

to verify the integrity of SIP header field information associated with the validated claims, where a mismatch results in a verification failure; or
to ensure that SIP header field contents contain the information authorized by the validated claims, where a mismatch is resolved by updating the SIP header field to match the validated claims.