Re: [stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)

["Peterson, Jon" <[e-mail]>]

:)

Jon Peterson
Neustar, Inc.

Sent from my iPad

On Aug 7, 2016, at 11:51 AM, Richard Shockey <[e-mail]<mailto:[e-mail]>> wrote:


Did someone mention examples?

—
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us<http://www.shockey.us>
www.sipforum.org<http://www.sipforum.org>
richard<at>shockey.us<http://shockey.us>
Skype-Linkedin-Facebook rshockey101
PSTN [phone]


From: stir <[e-mail]<mailto:[e-mail]>> on behalf of Christer Holmberg <[e-mail]<mailto:[e-mail]>>
Date: Sunday, August 7, 2016 at 7:10 AM
To: "Peterson, Jon" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Paul Kyzivat <[e-mail]<mailto:[e-mail]>>
Subject: Re: [stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)

Hi Jon,

My point is that (as you also wrote) how PASSporT is used with SIP is covered in 4424bis. Whether the current text is sufficient enough or not is a separate discussion, not related to draft-passport.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Peterson, Jon<mailto:[e-mail]>
Sent: ‎06/‎08/‎2016 20:50
To: Christer Holmberg<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; Paul Kyzivat<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)
Briefly, there is and always has been a "bare minimum" set of headers and claims that are mandatory for PASSporT. Ultimately, the question of what headers and claims are mandatory in PASSporT is a stir-passport question. SIP as a using protocol of PASSporT defines only which fields in a SIP request will populate those mandatory components of a PASSporT object, and that information is given in considerable detail in RFC 4474bis today.

Extensions may propose additional claims that will appear in PASSporT objects. The extensibility model of PASSporT is similarly a matter for the PASSporT spec rather than RFC 4474bis, though we anticipate that extensions may want to specify some initial using protocol behavior as well. We should have a few examples of that soon.

Jon Peterson
Neustar, Inc.
Sent from my iPad

On Aug 5, 2016, at 4:03 PM, Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
Hi Dave,

I don't know whether the WG has yet decided whether there will be options and alternatives (i.e. whether sending of claims/headers will be mandatory, optional or forbidden) - so we don't yet know whether there will be an "if" :)

But, if there will be an "if", 4424bis needs to describe how to correctly handle the different options and alternatives.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Dave Crocker<mailto:[e-mail]>
Sent: ‎05/‎08/‎2016 17:20
To: Christer Holmberg<mailto:[e-mail]>; Paul Kyzivat<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)
Christer,


On 8/4/2016 11:45 PM, Christer Holmberg wrote:
>
> The receiver needs to be able to parse JSON if the sender includes the
> claims, in order to verify the signature.

Alternatives and options make specifications more complex and often
introduce potential non-determinacies.  So the 'if' that you cite is not
a small matter.

In practical terms, the 'if' means that verifiers must be able to parse
json as well as encode it.


> Also, whatever headers we include, I assume the receiver should be able
> to parse them.
>
> But, parsing JSON is not a difficult thing to do, and there are
> available libraries for those who don't want to implement the parser
> themselves.

Just to make sure this sub-thread retains its context:  I did not
comment on the choice of JSON/JWT in the actual review.  It's not an
irrational or horrible choice.

But it does add overhead.  It adds it to the effort needed to understand
the specifications.  And it adds it to the software.  (It might also add
it to the execution of the software, but I suspect that is, at worst, a
negligible difference here.)

One of the more deceptive parts of writing standards is the seduction of
"is not a difficult thing to do".  In most cases where that sort of
comment is offered, it is quite true.  The problem is with incremental
complexities.  A not-difficult here; a not-difficult there... They
really do mount up.

By way of example, having to send the reader off to become proficient in
two additional specifications is not a small increment in developmental
overhead, especially when those specification have no natural -- ie,
pre-occurring -- relevance to the current work.

d/
--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net<http://bbiw.net>
_______________________________________________
stir mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/stir
_______________________________________________ stir mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/stir