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

Did someone mention examples? 

— 

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 <stir-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com>
Date: Sunday, August 7, 2016 at 7:10 AM
To: "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: "stir@ietf.org" <stir@ietf.org>, "dcrocker@bbiw.net" <dcrocker@bbiw.net>, Paul Kyzivat <pkyzivat@alum.mit.edu>
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
Sent: ‎06/‎08/‎2016 20:50
To: Christer Holmberg
Cc: dcrocker@bbiw.net; Paul Kyzivat; stir@ietf.org
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 <christer.holmberg@ericsson.com> 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
Sent: ‎05/‎08/‎2016 17:20
To: Christer Holmberg; Paul Kyzivat
Cc: stir@ietf.org
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

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir 