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

From: Jim Schaad <[email-masked]>
Date: Mon, 26 Sep 2016 16:25:29 -0700

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 30 Sep 2016 16:45:28 +0000

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.

---

From: Jim Schaad <[email-masked]>
Date: Fri, 30 Sep 2016 21:56:48 -0700

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:[email-masked]]
> Sent: Friday, September 30, 2016 9:45 AM
> To: Jim Schaad <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Subject: Re: draft-ietf-stir-passport JOSE Registrations
> 
"full" and
> "compact" (that is, Appendix F of 7515 as we spec it) form of the token.
> 
> 
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"
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.
> >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.)
> >