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

[Dave Crocker <[e-mail]>]

On 8/6/2016 10:50 AM, Peterson, Jon wrote:
> 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.


I've read through the above a few times, to make sure I understood it. 
(Really, it did take more than once.)


The role being played by passport is to aid in authentication of the SIP 
caller-id information.  In terms of STIR's charter and the current round 
of specifications, that's is sole role. (I've phrased it with a generic 
term like 'caller-id' in order to encompass the variations that provide 
the value to be validated.)

In spite of having carefully read the passport spec and slogging through 
the rfc4474bis spec, I had not fully appreciated the level of 
indirection and complexity being introduced with the passport construct, 
until your note above.

This isn't just an encoding abstraction.  It's an entirely independent 
layer of complex mechanism, where the actual job that needs to be done 
is just finding a key and then hashing and signing some SIP header 
information.

The aggregate complexity and indirection of the specs developed so far 
seem to make it essentially impossible to determine a specific usage 
scenario that is viable.  And from what I can tell, this includes an 
inability to determine what details are yet to be specified, before 
there is core, usable capability that can operate over the Internet.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net