Signing "orig" and "dest" and Verification "from", "to" and "dest" parameter values

[kpolitz]

Please provide input so we can align on this recent testing item:

Signing: "orig" is defined as a single string and "dest" is defined as an array of strings.

Verification: "from", "to" and "dest" all are defined as single strings.

At a minimum, it seems that Verification "to" should be defined as an array of strings given that Signing "orig" is this way. This is what our current implementation assumes.

Our current implementation further assumes Verification "dest" to also be an array of strings. This can accommodate a single or multiple values.

We value feedback here so we can determine what change(s)/correction(s) should be contributed to 3GPP.

Thanks.

[di-shi]

I am afraid we have different understanding for these fields. From 3GPP, for verification, "from", "to" and "dest" are clearly defined. I do not see any reason to assume there are multiple To or R-URI in a SIP INVITE. For authentication, dest has another context.

[kpolitz]

If the SIP "To", "P-A-I/From" and "Request-URI" headers can be assumed to always reference a single identity, then having all three of these as single string claims is straightforward. It would seem that the 3GPP Description in the Table for signingRequest also implies "dest" then as a single value? Thoughts?

[di-shi]

It would seem that the 3GPP Description in the Table for signingRequest also implies "dest" then as a single value?

As mentioned prior, authentication dest has its context other than verification. 3GPP refers to RFC 8224 for it.

RFC 8224:
"Multiple JSON objects are permitted in "dest" for future compatibility reasons."

[kpolitz]

Thanks for this input! Consulted internally as well. There is no change required on the signing side, but we will update the verification side so that "to" and "dest" are no longer arrays. Will send an e-mail when these changes are deployed.

[di-shi]

In fact, in our implementation, based on ATIS10k82, verification "to" is array. For consistency, we would prefer to array. Let's see what others think.

[kpolitz]

Our folks feel that, as defined in spec, there would only be a single identity in the SIP To header. Do you have a use case in mind where that wouldn't happen?

[kpolitz]

For now, we are going to align with current spec definition.

[di-shi]

Our folks feel that, as defined in spec, there would only be a single identity in the SIP To header. Do you have a use case in mind where that wouldn't happen?

div should be an example. but "dest" is added by 3GPP for it. Even without "dest", Identity headers have the number chain.

[kpolitz]

We will note this as a topic for discussion at 3GPP and their original intent.