Re: [stir] a syntax change

"Peterson, Jon" <> Mon, 11 July 2016 13:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08F5112D185 for <>; Mon, 11 Jul 2016 06:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SXf6V0WUNr1B for <>; Mon, 11 Jul 2016 06:30:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8A706128E18 for <>; Mon, 11 Jul 2016 06:30:00 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u6BDNFXW016159; Mon, 11 Jul 2016 09:29:57 -0400
Received: from ([]) by with ESMTP id 242wcq3a75-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Jul 2016 09:29:57 -0400
Received: from ([]) by ([::1]) with mapi id 14.03.0279.002; Mon, 11 Jul 2016 09:29:56 -0400
From: "Peterson, Jon" <>
To: Christer Holmberg <>
Thread-Topic: a syntax change
Thread-Index: AQHR2W7bzsTobHl6sEOOeZEJkt6dxqATONnwgAAE6Vs=
Date: Mon, 11 Jul 2016 13:29:55 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_2EF2D1DCA51042A8BAA9C2058F9EA782neustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-11_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607110135
Archived-At: <>
Cc: IETF STIR Mail List <>
Subject: Re: [stir] a syntax change
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Jul 2016 13:30:02 -0000

I don't think we took a formal consensus call, or what have you. What we did do though is to include in rfc4474bis a URI normalization procedure that we hope will obviate the ambiguity about URI comparisons you raised.

I still think the message size reduction is worth the complexity trade-off to permit "canon" not to be included - and if it is allowed to be absent at all, then I think by default it should be absent.

Jon Peterson
Neustar, Inc.

Sent from my iPad

On Jul 11, 2016, at 9:13 AM, Christer Holmberg <<>> wrote:


Some time ago there was a discussion whether we should include the claims to begin with, as the information can be retrieved from other SIP information elements.

Did we make a conclusion on that?



From: stir [] On Behalf Of Peterson, Jon
Sent: 09 July 2016 02:17
To: IETF STIR Mail List <<>>
Subject: [stir] a syntax change

Attentive readers will observed a syntax change in passport-04 which carries over to rfc4744bis-10. Implementers, especially those looking forward to the SIPit coming up, should take note.

The change is to the claims of the PASSporT object. Rather than having two different versions of each claim to reflect the originating and destination side, such as "otn" and "dtn", there is now simply a "tn" claim. That claim will appear within a JSON array explicitly labeled as "orig" or "dest" in the PASSporT object.

This will result in PASSporT claims like the following:

      { "orig":{"tn":"12155551212"},


        "iat":"1443208345" }

The "dest" claim is specifically defined to allow one or more values, so it replaces the previous "dgrp" claim to be used in cases where a message has multiple destinations.

This eliminated the redundancy of having future extensions to the PASSporT claims identify whether they carried an identifier for the originating or destination side. Now, new claim definitions simply have to state that they contain identifiers: the semantics of the identifier will depend on whether it appears under "orig" or "dest". In fact, PASSporT could probably work with some existing JWT claims now that represent identifiers. This seemed like a much better idea than the way we were doing it before.

This was a fairly last-minute fix, but it didn't require much spec change and is hopefully stable and consistent. Thoughts welcome.

Jon Peterson
Neustar, Inc.