[stir] Re: Verifiable Voice Protocol (VVP)

[Brett Nemeroff <[e-mail]>]

Daniel,
While I’m in other groups with you discussing this, I’m very interested from a STIR perspective what others think of this proposal.

I can’t speak for other STIR members, but I am interested in seeing that discussion and where it goes. I think it is of significant relevance to RCD, the FCC’s recent FNPRM and the OVC working groups as well.
-Brett



Brett Nemeroff
VP of Engineering - Voice
[e-mail]<mailto:%7BE-mail%7D> | 1-512-203-3884

[Logo.png]<https://www.numeracle.com/>

Empowering Calls with
Identity Management<https://www.numeracle.com/insights/entity-identity-management-to-empower-your-calls>


CONFIDENTIAL

From: Daniel Hardman <[e-mail]>
Date: Tuesday, October 14, 2025 at 11:58 AM
To: Peterson, Jon <Jon.Peterson=[e-mail]>
Cc: Orie <[e-mail]>, Russ Housley <[e-mail]>, Pierce Gorman <[e-mail]>, Chris Wendt <[e-mail]>, Brett Nemeroff <[e-mail]>, Richard Shockey <[e-mail]>, IETF STIR Mail List <[e-mail]>
Subject: Re: [stir] Re: Verifiable Voice Protocol (VVP)

You don't often get email from [e-mail]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
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]<mailto:[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]<mailto:[e-mail]>>
Date: Friday, October 10, 2025 at 9:19 AM
To: Russ Housley <[e-mail]<mailto:[e-mail]>>
Cc: Pierce Gorman <[e-mail]<mailto:[e-mail]>>, Chris Wendt <[e-mail]<mailto:[e-mail]>>, Brett Nemeroff <[e-mail]<mailto:[e-mail]>>, Richard Shockey <[e-mail]<mailto:[e-mail]>>, IETF STIR Mail List <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
stir mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>