Re: [stir] Review of: draft-ietf-stir-passport-05

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

>> JWT was chosen not because it has any
>> exclusive or special applicability to SIP, but instead because it could
>> have applicability both to SIP and other protocols.
>
>Sorry to be repetitious but I do not see that case made, discussed or
>agreed to in the working group record.

So, the summary of the virtual interim states that the original JWT
verified token approach was compared with the concatenated string, but
since it does not say in which specific respects they were compared, then
I gather that this "working group record" is not sufficient for you to
believe that we ever considered the applicability of JWT to multiple
protocols in particular? Well, what if the original verified token I-D
stated that a goal of the work "is to be separable from any specific
signaling call logic, so creation and verification of information can be
implemented in a flexible way with minimal dependence on specific
signaling constructs." Maybe that's not good enough, the wording is a
little wild. Perhaps it could come through a bit more clearly in
passport-05, if it stated a goal that PASSporT be "independent of any
specific personal communications signaling call logic, so that creation
and verification of persona information can be implemented in a flexible
way and can be used in many personal communications applications including
end-to-end applications that require different signaling protocols."

But we're jumping the gun here - when and where was this principle vetted
in the working group, to measure whether or not such language belonged in
a WG draft? How about if the slides on verified token in the Oct 9 virtual
interim included a bullet on how the "separation of the token to signaling
specific attributes" has the additional benefit of "applicability to
future RTC applications and signaling protocols" (those slides are in the
virtual interim proceedings). Still, that could be (ungenerously) read to
mean exclusively future protocols, not currently existing ones. So what if
the slides that Chris and I sent out for the Oct 16 design team meeting
contained a slide called "Not So SIP Specific" that discusses the JWT
surviving gateway SIP->XMPP calls as a design goal, and even enabling
end-to-end SRTP through a gateway?

That same design team slide would need to have been presented in Yokohama
at the STIR WG meeting for the confirmation of the working group, of
course. Actually, not only was that "Not So SIP Specific" slide reproduced
(and presented), but the very first slide my presentation there talked
about "a new (well, resurrected) requirement" that the "signature should
be transportable outside of SIP" and observes that that wasn't really
possible with RFC4474bis before PASSporT. You can read the
proceedings/minutes of that discussion - oh wait, you were there, I see
your name in the minutes, actually. The minutes also note that Adam Roach
expressed interest in using STIR for RTCWeb in particular, so I could
furthermore point to Cullen's recent draft
(draft-jennings-stir-rtcweb-identity-00) as a "working group record" of
our multi-protocol direction, though admittedly that hasn't been discussed
outside of the RTCWeb working group - we're trying to get this core work
done before we start nailing down the applicability to other protocols, as
our charter effectively requires us to do the SIP using protocol for
PASSporT first. And lastly, I do seem to recall concluding the STIR
working group meeting in Berlin by advertising the forthcoming pivot to
these out-of-band use cases.

I don't think we need to meet this unusual bar for "working group record"
evidence that the case for JWT's applicability to multiple protocols was
made, or discussed, or agreed to - though I suspect we would happen to
meet it. More importantly, we have agreement among interested and active
parties on the PASSporT approach that has led to some initial
implementation - or as they call it around here, rough consensus and
running code.

>What I did see was a repeated claim that using JWT was simpler, which I
>suspect is quite simply wrong, if only because it requires more
>mechanism that directly adding the necessary information to a SIP header
>field. (cf, DKIM, of course.)

At last we have identified the root problem here: we didn't use DKIM. I
should have guessed - you brought it up in Yokohama too, as I see in the
STIR minutes. DKIM was an option we considered for SIP a long time ago...
around the time that Domain Keys and IIM were merging, if I recall, though
I doubt I could find you a "working group record" of that decision back
when RFC4474 was under development. I do see some record that we discussed
at least one of aspect of the trade-off between DKIM and PASSporT in
Yokohama, but it doesn't seem to have undermined our consensus to use
PASSporT. I see no reason to give this much further consideration.

Jon Peterson
Neustar, Inc.