Subject: [stir] Raw notes from STIR design team call Oct 16

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 16 Oct 2015 19:51:33 +0000

Discussion around pros / cons of JWT vs 4474 approach 

- Martin & Richard said they want to be able to use this for things other identity 

- Jon raised point key thing is knowing which one to pick 

Presented proposed changes to 4474bis

Question: about where this work will go process wise?

Proposal is we will split the token out and put in PS document 

Rich does not support this as WG item and stated people that people have concerns about the process. 

Henning likes the modularity of this. Nice to be able to leave certain options in the future. 

On the topic of goal to allow the the signature to survive gateways to different protocols (xmpp to sip)

- lots of people agree that STIR was not a silver bullet 

Richard, don't need to remove METHOD from signature yet. We need more time to look at it. We are moving too fast on this. No ready to give an answer on if we need it or not. 

On topic of handling Extensibility

Henning - pointed out there are 3 levels of extensibility / complexity / interoperability 

1) minimal base level - you can reconstruct JWT without carrying it all around

2) somewhere we specify a specific set of things that gets signed

3) we add a JWT object that can contain anything, and the objects that was signed gets transported. And there are a lot more questions. 

Richard would like a 3rd party to be able to assert claims that are additional properties of the transaction. Don't want any IANA policy on this. 

On to multiple identity signatures topic 

Henning - they have a purpose and you discard on that are for the purpose you want

Martin - want to look at a particular signature like the one for priority services 

Jon - the GETS signature would have a marking that told you what this signature if for 

Seemed to be broad agreement on multiple signatures, each labeled with the specific purpose they are for. 

Martin will charge a beer to Jon's account for reasons that will not be recorded

Next update of draft will not have a IANA section. 

It will not standards action. 

Richard was happy about that. But prefer FCFS.

What to do about multiplicity in next rev of spec. 

If we do it with header, we are going to be in the range 700 byte headers 

Henning like compact as possible because even two signatures are bit. Seem like new IANA registry for #2 in above notes. 

Agree we need to label the object such that you don't have to look inside them all to find what you want. 

Pierce - want us to keep it simple. Put a base signature in some SIP header. Any more complex stuff put it in a message body. 

Henning - prefer not to create a a two class system where the 2nd class is significantly more complex

Jon will update draft with proposed plan. Everyone was OK with that. 

Henning suggested putting in an introductory example so people could quickly their heads around it