Subject: [stir] a (proposed) syntax change

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 22 Sep 2016 19:49:04 +0000

At this point in STIR's development, I am loathe to introduce any further change to the rfc4474bis/PASSporT syntax and interaction. However, we hold events like SIPit so we can learn from implementers what we need to fix, and from that event, and surrounding discussion, we apparently still have some qualms about "canon".

To summarize the current situation briefly, a PASSporT object consistent of three components: a JOSE header, a payload (containing the claims), and a signature. In rfc4474bis-12, the Identity header begins with the signature component, and optionally can include the header and payload in the "canon" parameter. In order to form a full PASSporT object, a recipient of an Identity header must therefore: a) when "canon" is present, concatenate the contents of "canon" and the signature at the beginning of the Identity header; or b) when "canon" is not present, reconstruct the value of "canon" from the SIP request, and then concatenate that value with the signature at the beginning of the Identity header.

We store the header and payload in "canon" for largely historical reasons: "canon" was originally created as a parameter to store the optional canonicalization of any originating or destination telephone number(s) in the request, and when we migrated to PASSporT, we repurposed the parameter to store the header and payload, as they contained a superset of that data. One could argue though that a better syntax for PASSporT would be to dispense with "canon" and simply prepend the header and payload to the signature in the Identity header when they are included in the request: this would effectively mean that the entire JWT object would appear in one place in the header, rather than being broken in two the way it is in option (a) today. For option (b), then, we would need some way for the auth service to signify that the header and claims are omitted: we could for example just put two leading "."'s at the start of the header, the first representing the "." between the header and payload, and the second the "." between the payload and the signature. That would be in keeping with the spirit of RFC7515 Appendix F - and let's face it, that section is heavy on spirit and light on letter.

>From an rfc4474bis perspective, this is purely a syntactical change. It trades the six octets of "canon=" that we pay every time that the header and payload are included in a request for the two octets of ".." that we would pay under this proposal every time we did not include the header and payload in a request. For implementers, it shifts around the burden of who does which concatenation operation a bit, but if any implementation out there would seriously be taxed by one additional concatenation operation, it probably shouldn't be working with JSON or SIP at all. This proposal would also move much of the specification of this over to the PASSporT document: that specification would now define a "full" and "compact" mode for PASSporT, and rfc4474bis would simply specify where you stick it and and when you need to use one or the other. But making this change would require substantial and pervasive changes in rfc4474bis, and significant additions to PASSporT as well, which again at this late stage I am very hesitant to do for solely syntactical reasons.

By the by, this issue is orthogonal to the question of when we recommend using the full as opposed to compact form. This change would be neutral with regard to that. This is simply a proposed change to the syntax.

If anyone has any opinions about this, this would be the time to speak up. When two syntax approaches are as similar as these, it can be very difficult to decide between them, because there simply aren't sufficient grounds to prefer one over the other. From my perspective, the increase in clarity that comes from having the concept of a "full" and "compact" mode for PASSporT might be helpful for other using protocols as well as SIP, and it thus seems architecturally cleaner than having SIP define its own legacy-encumbered way to render PASSporT compact. The cost of this to rfc4474bis, though, would be an onerous update that would require careful review before we proceed. It is difficult for me to justify any delay for the sake of tweaking the syntax.

Jon Peterson
Neustar, Inc.

---

From: Chris Wendt <[email-masked]>
Date: Fri, 23 Sep 2016 08:29:18 -0400

Hi Jon, All,

I do think this change has a few nice things about it:

- removes the “canon” concept, which is not necessarily complex or anything, but not as intuitive as the proposal Jon makes.  Consolidating the token into a single object right after identity: in either compact or long form just makes things more straight forward and avoids the need for concatenation, etc.
- aligns better with the Appendix F that Christer brought up
- saves a few bytes and parsing logic

I think the general discussion that SIPit brought to a head with a few of the implementers in the room, is why not do this, it just makes sense.

That said, we are also under pressure to get this out.

So i’m favor in making this change but also want to make sure this won’t alter timelines.  Somehow i suspect that can’t be strictly true, but maybe someone can prove me wrong.

I am willing to make changes in the document quickly, i think Jon is signing up for 4474bis changes quickly as well.

But in any case, need some guidance, and in short order :)

-Chris

> On Sep 22, 2016, at 3:49 PM, Peterson, Jon <[email-masked]> wrote:
> 
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Sep 2016 13:16:40 +0000

Hi,

>- aligns better with the Appendix F that Christer brought up

It actually aligns with JWS in general, with or without Appendix F, because we can include the base64 encoded JWS string directly (without splitting it into two different pieces).

I indicated in Berlin that I can live with “canon”. But, as people are now asked to give their opinion, my preference no “canon” and use Jon’s “dot suggestion” for omitting headers and/or claims. However, I will not object to “canon” if the community wants to go that way.

Regards,

Christer

On Sep 22, 2016, at 3:49 PM, Peterson, Jon <[email-masked]<mailto:[email-masked]>> wrote:

Jon Peterson
Neustar, Inc.
_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir

---

From: Mary Barnes <[email-masked]>
Date: Fri, 23 Sep 2016 12:44:14 -0500

Jon,

I totally understand your concern about making the change this late in the
game.  But, I think Chris made some really good points and now is the time
to do it, otherwise, I can envision years of repeated discussion around
this as new people come along.   Hopefully, we're talking about a few weeks
delay which is tolerable I think for a WG that just had it's 3rd birthday.

Regards,
Mary.

On Fri, Sep 23, 2016 at 7:29 AM, Chris Wendt <[email-masked]>
wrote:

> - removes the “canon” concept, which is not necessarily complex or
> anything, but not as intuitive as the proposal Jon makes.  Consolidating
> the token into a single object right after identity: in either compact or
> long form just makes things more straight forward and avoids the need for
> concatenation, etc.
> I think the general discussion that SIPit brought to a head with a few of
> the implementers in the room, is why not do this, it just makes sense.
>
> So i’m favor in making this change but also want to make sure this won’t
> alter timelines.  Somehow i suspect that can’t be strictly true, but maybe
> someone can prove me wrong.
>
> I am willing to make changes in the document quickly, i think Jon is
> signing up for 4474bis changes quickly as well.
>
> At this point in STIR's development, I am loathe to introduce any further
> change to the rfc4474bis/PASSporT syntax and interaction. However, we hold
> events like SIPit so we can learn from implementers what we need to fix,
> and from that event, and surrounding discussion, we apparently still have
> some qualms about "canon".
>
> To summarize the current situation briefly, a PASSporT object consistent
> of three components: a JOSE header, a payload (containing the claims), and
> a signature. In rfc4474bis-12, the Identity header begins with the
> signature component, and optionally can include the header and payload in
> the "canon" parameter. In order to form a full PASSporT object, a recipient
> of an Identity header must therefore: a) when "canon" is present,
> concatenate the contents of "canon" and the signature at the beginning of
> the Identity header; or b) when "canon" is not present, reconstruct the
> value of "canon" from the SIP request, and then concatenate that value with
> the signature at the beginning of the Identity header.
>
> We store the header and payload in "canon" for largely historical reasons:
> "canon" was originally created as a parameter to store the optional
> canonicalization of any originating or destination telephone number(s) in
> the request, and when we migrated to PASSporT, we repurposed the parameter
> to store the header and payload, as they contained a superset of that data.
> One could argue though that a better syntax for PASSporT would be to
> dispense with "canon" and simply prepend the header and payload to the
> signature in the Identity header when they are included in the request:
> this would effectively mean that the entire JWT object would appear in one
> place in the header, rather than being broken in two the way it is in
> option (a) today. For option (b), then, we would need some way for the auth
> service to signify that the header and claims are omitted: we could for
> example just put two leading "."'s at the start of the header, the first
> representing the "." between the header and payload, and the second the "."
> between the payload and the signature. That would be in keeping with the
> spirit of RFC7515 Appendix F - and let's face it, that section is heavy on
> spirit and light on letter.
>
> From an rfc4474bis perspective, this is purely a syntactical change. It
> trades the six octets of "canon=" that we pay every time that the header
> and payload are included in a request for the two octets of ".." that we
> would pay under this proposal every time we did not include the header and
> payload in a request. For implementers, it shifts around the burden of who
> does which concatenation operation a bit, but if any implementation out
> there would seriously be taxed by one additional concatenation operation,
> it probably shouldn't be working with JSON or SIP at all. This proposal
> would also move much of the specification of this over to the PASSporT
> document: that specification would now define a "full" and "compact" mode
> for PASSporT, and rfc4474bis would simply specify where you stick it and
> and when you need to use one or the other. But making this change would
> require substantial and pervasive changes in rfc4474bis, and significant
> additions to PASSporT as well, which again at this late stage I am very
> hesitant to do for solely syntactical reasons.
>
> By the by, this issue is orthogonal to the question of when we recommend
> using the full as opposed to compact form. This change would be neutral
> with regard to that. This is simply a proposed change to the syntax.
>
> If anyone has any opinions about this, this would be the time to speak up.
> When two syntax approaches are as similar as these, it can be very
> difficult to decide between them, because there simply aren't sufficient
> grounds to prefer one over the other. From my perspective, the increase in
> clarity that comes from having the concept of a "full" and "compact" mode
> for PASSporT might be helpful for other using protocols as well as SIP, and
> it thus seems architecturally cleaner than having SIP define its own
> legacy-encumbered way to render PASSporT compact. The cost of this to
> rfc4474bis, though, would be an onerous update that would require careful
> review before we proceed. It is difficult for me to justify any delay for
> the sake of tweaking the syntax.
>
> Jon Peterson
> Neustar, Inc.

---

From: Richard Shockey <[email-masked]>
Date: Fri, 23 Sep 2016 13:58:04 -0400

+1  Lets do it now. 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook rshockey101

PSTN +1 703-593-2683

From: stir <[email-masked]> on behalf of Mary Barnes <[email-masked]>
Date: Friday, September 23, 2016 at 1:44 PM
To: Chris Wendt <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>, "Peterson, Jon" <[email-masked]>
Subject: Re: [stir] a (proposed) syntax change

Jon,

I totally understand your concern about making the change this late in the game.  But, I think Chris made some really good points and now is the time to do it, otherwise, I can envision years of repeated discussion around this as new people come along.   Hopefully, we're talking about a few weeks delay which is tolerable I think for a WG that just had it's 3rd birthday.   

Regards,

Mary. 

On Fri, Sep 23, 2016 at 7:29 AM, Chris Wendt <[email-masked]> wrote:

Hi Jon, All,

-Chris

 

Jon Peterson

Neustar, Inc.

_______________________________________________ stir mailing list [email-masked] https://www.ietf.org/mailman/listinfo/stir