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

[Dave Crocker <[e-mail]>]

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