Re: [stir] draft-ietf-stir-passport JOSE Registrations

Jim Schaad <ietf@augustcellars.com> Sat, 01 October 2016 04:57 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE6612B19E; Fri, 30 Sep 2016 21:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.217
X-Spam-Level:
X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qkCyPcDUm_3; Fri, 30 Sep 2016 21:57:06 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF3112B008; Fri, 30 Sep 2016 21:57:06 -0700 (PDT)
Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 30 Sep 2016 22:10:14 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: "'Peterson, Jon'" <jon.peterson@neustar.biz>, draft-ietf-stir-passport@ietf.org
References: <01fe01d2184d$46f75b50$d4e611f0$@augustcellars.com> <D4140D3B.1BB670%jon.peterson@neustar.biz>
In-Reply-To: <D4140D3B.1BB670%jon.peterson@neustar.biz>
Date: Fri, 30 Sep 2016 21:56:48 -0700
Message-ID: <068a01d21ba0$395fc260$ac1f4720$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQF2CGt8c7l6aEkIHzrrgQxdISYIhgHaVgxJoTxcl1A=
X-Originating-IP: [24.21.96.37]
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/RH5o2hV9edaBJTNMuveqXI58AIk>
Cc: stir@ietf.org
Subject: Re: [stir] draft-ietf-stir-passport JOSE Registrations
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Oct 2016 04:57:08 -0000

Things look reasonable.  It is not laid out the way that I would have done
it but other than that it looks fine.

Is there any plan to have some type of centralized list of ppt values?

jim

> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
> Sent: Friday, September 30, 2016 9:45 AM
> To: Jim Schaad <ietf@augustcellars.com>; draft-ietf-stir-passport@ietf.org
> Cc: stir@ietf.org
> Subject: Re: draft-ietf-stir-passport JOSE Registrations
> 
> First of all, beware, as there were some changes to the "ppt" text in the
> -08 version of PASSporT that fell out of the new specification of the
"full" and
> "compact" (that is, Appendix F of 7515 as we spec it) form of the token.
> 
> 
> But speaking to the -08: the purpose of "ppt" is to subtype PASSporT with
an
> indication that there are additional claims in the payload of the JWT
beyond
> those specified in the baseline draft-ietf-stir-passport spec, and that
support for
> this extension is mandatory for relying parties. If you just want to put a
few
> extra optional claims in the JWT payload and you don't care if relying
parties
> support them or not, you don't use "ppt"
> (though you do need to use the full as opposed to the compact form of
> PASSporT). You just stick in the claims and ship the object.
> 
> You are correct that the spec only supports one mandatory extension per
> PASSporT, and that you'd have to send multiple PASSporTs (which in SIP
would
> mean multiple Identity headers, which is permitted) if you wanted to use
> multiple mandatory extensions. We aren't envisioning a lot of extensions
that
> would need to be mandatory today, but the ones that are will probably be
> profiles that specify multiple additional claims that will be present in
the
> PASSporT payload. But we do understand that if you want to mandate relying
> party support for both profile A and profile B with a single PASSporT,
that isn't
> possible in the current syntax - you'd have to send multiple PASSporTs.
We're
> cool with that.
> 
> Jon Peterson
> Neustar, Inc.
> 
> On 9/26/16, 7:25 PM, "Jim Schaad" <ietf@augustcellars.com> wrote:
> 
> >So I just got this pointed to me
> >
> >I am unsure of what the value of  "ppt" is supposed to be in one case.
> >Is the intention that extensions will only be done serially or can they
> >be done in parallel?  The first case allows for a high water mark to be
> >used until the next one.  In the second case the question comes up if
> >one wants to use both extension 'a' and extension 'b' in some sense.
> >(Consider the case where the extensions are orthogonal to each other by
> >requiring different JWT claims to be present.)
> >
> >In the second case it does not appear to be expressible in the current
> >syntax.
> >
> >Jim
> >
> >