Subject: [stir] 4474bis identity header - full JWT by default vs canon

From: Chris Wendt <[email-masked]>
Date: Tue, 31 May 2016 09:06:46 -0400

Hi All,

There was a discussion on the STIR interim call about whether there is any strong reasons to consider using the full PASSporT (header.claims.signature) as the default for the identity header in 4474bis.

The primary argument for the full token being default would be, it may be more efficient from an implementation point of view to have the constructed token available to the verification service to directly validate signature.  With the caveat that in either case you either need to re-construct the header.claims or you need to decode the Base64 to get the JSON header and claims to verify that the values correspond to values in the SIP header.

The primary argument for the current default of only including the signature, is to save the 80-100 bytes of “duplicate” information in the SIP payload.

Feel free to reword if i didn’t capture the main arguments correctly.

Would like to get other opinions or other arguments for or against keeping things the way they are or considering just using the full PASSporT token in the identity header.

Thanks.

-Chris

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 1 Jun 2016 00:25:34 +0000

This is a point that Chris and I have discussed a bit before, and is one
of those issues that is hard to resolve because the differences between
the two choices are so small.

>From my perspective, making implementations send "canon" by default, while
leaving the option to exclude it, requires the same two code paths to
exist as we do when we don't send "canon" by default, and leave the option
to include it. And yes, the argument not to send it be default is simply
to reduce message size, given the fields in canon are necessarily
redundant with various hearer field values and parameters in SIP. In some
environments, I still hear that message size is a concern. That's why
we've set it this way now. It might turn out in deployment that we need
"canon" more often that we'd think, because of things like Date header
changes, say. I'd be willing to revisit this when we have a bit more
experience under our collective belts.

Ultimately, as Chris says, a verification service will need to basically
reconstruct the header and claims itself anyway from the SIP request - or
at least that the differences between reconstructing them on the one hand
and extracting each individual field to compare them to the corresponding
headers and claims of the canonical JWT object on the other hand seem
unlikely to genuinely impact either the difficulty of implementation or
the compute cycles required.

But like Chris, I'm interested to hear people's thoughts on this, and I'm
not deeply committed to either approach.

Jon Peterson
Neustar, Inc.

On 5/31/16, 6:06 AM, "stir on behalf of Chris Wendt"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi All,
>
>There was a discussion on the STIR interim call about whether there is
>any strong reasons to consider using the full PASSporT
>(header.claims.signature) as the default for the identity header in
>4474bis.
>
>The primary argument for the full token being default would be, it may be
>more efficient from an implementation point of view to have the
>constructed token available to the verification service to directly
>validate signature.  With the caveat that in either case you either need
>to re-construct the header.claims or you need to decode the Base64 to get
>the JSON header and claims to verify that the values correspond to values
>in the SIP header.
>
>The primary argument for the current default of only including the
>signature, is to save the 80-100 bytes of ³duplicate² information in the
>SIP payload.
>
>Feel free to reword if i didn¹t capture the main arguments correctly.
>
>Would like to get other opinions or other arguments for or against
>keeping things the way they are or considering just using the full
>PASSporT token in the identity header.
>
>Thanks.
>
>-Chris
>_______________________________________________
>stir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/stir