[stir] Re: Verifiable Voice Protocol (VVP)

[Daniel Hardman <[e-mail]>]

Hi there, Jon. Thank you so much for having a look, and for providing some
smart feedback.

Thank you as well for the pointer on connected identity (RFC 4916-update).
How to communicate callee identity back the other direction was the part of
VVP I was least confident of, so I'll definitely go study that.

VVP doesn't attempt to replace OP signing with caller signing; it wants
both, and it bifurcates the evidence into two parts. There's ephemeral
evidence (the passport that travels with the SIP signals), but it is linked
to evidence with a much broader scope and a longer lifespan. The caller
assembles this long-lived evidence, and signs the subset of that evidence
that embodies their intentions; the OP signs the ephemeral passport. The
long-lived evidence includes a statement from the caller signaling their
intention to let the OP sign their passports, which links the two together.

The long-lived evidence does cover a lot of the same territory as RCD, but
it goes beyond the specific remit of RCD, because it can prove arbitrarily
complex propositions, including:

- the identity of the caller as a legal entity (Coca Cola Holdings UK Ltd,
not "Coca Cola"), using an LEI which is unambiguous in all jurisdictions --
important for legal and regulatory accountability of the caller instead of
the OP
- the caller has the right to use the CLI (and how that right traces back
through a carrier, possibly via wholesalers and suballocations, to a
national regulatory authority)
- the caller has the right to use brand assets or any other attributes that
would appear in a jcard (as in RCD)
- the caller is working with a particular call center or BPO that has the
delegated right to represent them and use their brand when making outbound
calls (and the constraints under which that authority may be exercised,
such as limiting by geo, call purpose, time of day, etc.)
- the identity of the call center or BPO as a legal entity
- the caller has delegated signing authority to a particular OP (and the
constraints under which that authority may be exercised, such as limiting
by geo, call purpose, time of day, etc.)
- the caller is a human instead of an AI (or alternatively, the caller is
an AI agent that has formally delegated authority from the calling org to
represent it in outbound calls)
- the caller has a settlement contract with a particular settlement
provider and is willing to pay a particular price for branded calling info
to appear on the handset
- the person or org making a call has one or more certifications,
memberships, or other background (e.g., a licensed CPA, lawyer, or doctor)

Essentially the same information can move the other way, as in cases where
a consumer calls a call center and wants assurance about similar facts.
Carrying all of this info in a passport is not heavy, because it travels by
hyperlink, not by direct embedding. And it is eminently cacheable; only
revocation status needs rechecking, and that can be optimized dramatically.

VVP is not attempting to replace RCD; it is trying to enrich the evidence
that is available to decision-makers. This opens up possibilities like
bridging from a jurisdiction that doesn't use RCD, into one that does. Same
for BCID. Same for SHAKEN. Essentially, we want a payload to be lossless
WRT verifiable information content, and WRT to time (same info can be
verified minutes, days, or years later). VVP is also lossless WRT
channel/context, because the same information can be attached to a TLV in
an SMS, or to the profile of a participant in a Zoom meeting or RCS or
vCon, or to a post on social media. No need to re-assemble the evidence
over and over. Then, if a communication enters a context where less
information is needed, a simpler passport can be derived on demand -- kind
of like a graphic artist derives a JPG from a lossless image on demand.
There's nothing wrong with JPGs -- they're great. They just optimize for a
different problem than the lossless raw form.

You're totally right that the long-lived evidence is certificate-like.
However, there are some reasons why we're not using certificates, which I'd
like a chance to explain to the group. Not sure if it's better to explain
it over email or in a meeting?

--Daniel

On Tue, Oct 14, 2025 at 6:17 AM Peterson, Jon <Jon.Peterson=
[e-mail]> wrote:

>
> I took an initial look at this. Broadly, I’d probably embed most of the
> information in the proposed new PASSporT headers/claims into either
> subelements of rcd (a lot of this overlaps with what RCD does) or into STIR
> certs themselves. RCD is supposed to provide externally verifiable data
> about the calling party, data that you trust because you trust the party
> signing it - architecturally, it should be a sufficient wrapper for the
> sort of dossier the draft is linking to STIR.
>
> In most  STIR deployments today, the OP (as the draft calls it) is the
> entity signing the PASSporT. If we could snap our fingers and make it the
> TNU (as the draft calls it) that signs PASSporTs today, I imagine the bulk
> of the problems this draft is trying to address would already be solved
> without the addition of any new headers. STIR has always strongly favored
> making the security association here (caller-callee)  as end-to-end as
> possible.
>
> Also, transmitting this sort of assurance back from the callee to the
> caller is the problem we call “connected identity,” there is a mature draft
> describing it (4916-update). I would not recommend using an SDP field to
> pass such information in the backwards direction.
>
> Jon Peterson
> TransUnion
>
> *From: *Orie <[e-mail]>
> *Date: *Friday, October 10, 2025 at 9:19 AM
> *To: *Russ Housley <[e-mail]>
> *Cc: *Pierce Gorman <[e-mail]>, Chris Wendt <
> [e-mail]>, Brett Nemeroff <[e-mail]>,
> Richard Shockey <[e-mail]>, IETF STIR Mail List <[e-mail]>
> *Subject: *[stir] Re: Verifiable Voice Protocol (VVP)
>
> This Message Originated from Outside of the Organization
> Do not click links or open attachments unless you can confirm the sender
> and know the content is safe.
> Report Suspicious
> <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/GX53klZ1TQ0!Y2Oq2O7wX37ubKekr-dBgYAjreGWKEVVDeLxjlKzsFDxWCESADeCsixwdZGWnG05ljc6pG33AO2U8owwJZgxbQXbV9GaVEd_2XRVawHgoC6IXX370JXaPMwhHPbUM9MVKg$>
>
> Hi Daniel ! & STIR,
>
> First time seeing this draft : )
>
> There have been some STIR presentations of applicability of the "Issuer,
> Holder / Presenter, Verifier" model for verifiable credentials to STIR WG,
> at previous IETFs.
> For folks less familiar with Verifiable Credentials, they are sorta like
> https://datatracker.ietf.org/doc/html/rfc5755
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc5755__;!!GX53klZ1TQ0!1v_DDAI_jfLPL72FRmRJh69uINmJYOn_UrvcBB1jcjoeIJD9EyrHtg3omFjBzF5qZHoF-E5v8w5X6QogRIo$>
> They are also worked on in OAUTH and SPICE, with primitives coming from
> JOSE / COSE (or other security mechanisms like
> https://www.w3.org/TR/vc-data-integrity/
> <https://urldefense.com/v3/__https://www.w3.org/TR/vc-data-integrity/__;!!GX53klZ1TQ0!1v_DDAI_jfLPL72FRmRJh69uINmJYOn_UrvcBB1jcjoeIJD9EyrHtg3omFjBzF5qZHoF-E5v8w5Xos8Xu3M$>,
> or https://trustoverip.github.io/tswg-acdc-specification/
> <https://urldefense.com/v3/__https://trustoverip.github.io/tswg-acdc-specification/__;!!GX53klZ1TQ0!1v_DDAI_jfLPL72FRmRJh69uINmJYOn_UrvcBB1jcjoeIJD9EyrHtg3omFjBzF5qZHoF-E5v8w5XKCbTM4c$>
>  )
>
> Here are some related drafts to consider:
>
> - https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/__;!!GX53klZ1TQ0!1v_DDAI_jfLPL72FRmRJh69uINmJYOn_UrvcBB1jcjoeIJD9EyrHtg3omFjBzF5qZHoF-E5v8w5XvE9nRZY$>
> - https://datatracker.ietf.org/doc/draft-wendt-stir-vesper/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wendt-stir-vesper/__;!!GX53klZ1TQ0!1v_DDAI_jfLPL72FRmRJh69uINmJYOn_UrvcBB1jcjoeIJD9EyrHtg3omFjBzF5qZHoF-E5v8w5X3AEU4Ec$>
>
> The security technology "ACDCs" have also been proposed in this draft:
>
> - https://datatracker.ietf.org/doc/draft-smith-satp-vlei-binding/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-smith-satp-vlei-binding/__;!!GX53klZ1TQ0!1v_DDAI_jfLPL72FRmRJh69uINmJYOn_UrvcBB1jcjoeIJD9EyrHtg3omFjBzF5qZHoF-E5v8w5XhyF--Oo$>
>
> I'll leave it to the STIR chairs to handle the agenda discussions, just
> thought I would share some background on this topic.
>
> Regards,
>
> OS, ART AD
>
>
>
>
>
> On Wed, Oct 8, 2025 at 12:44 PM Russ Housley <[e-mail]> wrote:
>
> Pierce:
>
> For historical reasons, the tooling fills in “Network Working Group“ if
> the author does not specify a working group.  The final RFC is approved,
> will just indicate "IETF"
>
> Russ
>
>
> On Oct 8, 2025, at 12:14 PM, Pierce Gorman <[e-mail]>
> wrote:
>
> Is anyone aware of an effort to bring VVP into the STIR working group?
>
> The protocol specification posted in the IETF archive under the “Network
> Working Group“ (?) defines a new kind of STIR PASSporT using numerous
> non-STI verifiable credentials.
>
> *Verifiable Voice Protocol
> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-hardman-verifiable-voice-protocol-00.html__;!!GX53klZ1TQ0!1v_DDAI_jfLPL72FRmRJh69uINmJYOn_UrvcBB1jcjoeIJD9EyrHtg3omFjBzF5qZHoF-E5v8w5XDdDnQzc$>*
>
> Pierce
>
>
> _______________________________________________
> stir mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> stir mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>