Verifiable Voice Protocol

3.1. Roles

Understanding the workflow in VVP requires a careful definition of roles related to the protocol. The terms that follow have deep implications for the mental model, and their meaning in VVP may not match casual usage.¶

3.2. Lifecycle

VVP depends on three interrelated activities with evidence:¶

• Curating¶

• Citing¶

• Verifying¶

Chronologically, evidence must be curated before it can be cited or verified. In addition, some vulnerabilities in existing approaches occur because evidence requirements are too loose. Therefore, understanding the nature of backing evidence, and how that evidence is created and maintained, is a crucial consideration for VVP.¶

However, curating does not occur in realtime during phone calls, and is out of scope for a network protocol specification. Citing and verifying are the heart of VVP, and implementers will approach VVP from the standpoint of SIP flows [RFC3261], [RFC5626]. Therefore, we leave the question of curation to separate document (for example, [TOIP-DOSSIER]).¶

4.1. Citing the AP's dossier

A VVP call that makes the caller verifiable begins when the OP (Section 3.1.2) generates a new VVP passport [RFC8225] that complies with STIR [RFC8224] requirements. In its compact-serialized JWT [RFC7519] form, this passport is then passed as an Identity header in a SIP INVITE [RFC3261]. The passport constitutes lightweight, direct, and ephemeral evidence; it cites and therefore depends upon comprehensive, indirect, and long-lived evidence (the AP's dossier). Safely and efficiently citing stronger evidence in a dossier is one way that VVP differs from alternatives.¶

{
  "header": {
    "alg": "EdDSA",
    "typ": "passport",
    "ppt": "vvp",
    "kid": "https://agentsrus.net/oobi/EMC.../agent/EAx..."
  },
  "payload": {
    "orig": {"tn": ["+33612345678"]},
    "dest": {"tn": ["+33765432109"]},
    "card": ["NICKNAME:Monde d'Exemples",
      "CHATBOT:https://example.com/chatwithus",
      "LOGO;HASH=EK2...;VALUE=URI:https://example.com/ico64x48.png"],
    "goal": "negotiate.schedule",
    "call-reason": "planifier le prochain rendez-vous",
    "evd": "https://fr.example.com/dossiers/E0F....cesr",
    "origId": "e0ac7b44-1fc3-4794-8edd-34b83c018fe9",
    "iat": 1699840000,
    "exp": 1699840030,
    "jti": "70664125-c88d-49d6-b66f-0510c20fc3a6"
  }
}

4.2. Citing a callee's dossier

Optionally, evidence in VVP can also flow from callee to caller. For privacy reasons, individuals who receive phone calls may choose not to use VVP in this way. However, enterprises and call centers may find it useful as a reassurance to their customers about who they've reached.¶

In such cases, the callee must have curated a dossier. The format of the callee dossier is identical in schema to that used by a caller. It may therefore introduce evidence of the callee's legal identity, right to use a brand, right to use a TN, delegated authority to a call center proxy or an AI, and so forth. (A callee's dossier might differ in one minor way that doesn't affect the schema: it could prove the right to use a TN that has a DNO flag.)¶

A callee's passport cannot travel in an Identity header on a SIP response, because existing SIP tooling does not expect or preserve Identity headers on responses. Instead, the callee SHOULD convey its passport in an Identity header ([RFC8224]) on a request that it initiates within the dialog, following the connected-identity model of [RFC4916]. Normally this is an UPDATE ([RFC3311]) sent after the callee has sent its 200 OK and received the ACK. Per [RFC4916], a re-INVITE MAY be used instead when the caller does not support UPDATE, and an UPDATE MAY be sent on an early dialog to make the callee verifiable before the call is answered. Requests are handled by intermediaries the same way as a caller's INVITE, so the passport has the same chance of surviving the route as a caller's passport does.¶

The callee MAY also, or instead, add a special a=callee-passport:X attribute line to the SDP [RFC8866] body of its 200 OK response, and optionally of a 180 Ringing response. The value of this line is a JWT in compact form, with the ;type=vvp suffix -- exactly the format used to convey VVP passports in Identity headers. This option requires no additional request, but it is fragile: session border controllers and B2BUAs regenerate SDP at most enterprise and carrier boundaries, and will usually drop the attribute. It is therefore suitable mainly where the path between caller and callee is known to preserve SDP. A callee that uses the SDP attribute without the request SHOULD place it in the 200 OK.¶

If the passport arrives by both routes, the two MUST be identical. A caller that receives no callee passport by either route treats the callee as unverified (see Section 5.3).¶

Although dossiers are identical in either direction, the callee JWT has a slightly different schema than a caller's VVP passport. The headers of the JWT match, but kid contains the OOBI of the callee, not of the OP. Two new claims are added to the JWT payload: call-id and cseq. These MUST contain the values of the Call-ID and CSeq values on the preceding SIP INVITE. The iat claim MUST also be present and MUST contain a value from the system clock of the callee. The exp field MAY also be present and use a value chosen by the callee; if it is missing, this communicates the callee's intention to impose no new timeout logic on the call. The evd field MUST also be present, and MUST contain the OOBI of the callee's dossier. The card and goal claims are also allowed. Other claims MAY be present, but MUST be ignored by compliant implementations that do not understand them. (Because the callee references the specific SIP dialog via call-id and cseq, there is no point in repeating fields that describe the dialog, like orig, dest, and so forth.)¶

5.1. Verifying the caller

5.2. Verifying the callee

The callee is verified with an algorithm that MAY be optimized but MUST achieve the same security guarantees as this:¶

1. Confirm that the call-id and cseq claims match the values of Call-ID and CSeq from the preceding SIP INVITE. If the passport arrived in a request such as UPDATE, also confirm that the request belongs to the same dialog.¶

2. Confirm that the iat claim matches contextual observations and other SIP metadata. That is, the timing described by the callee appears aligned with what is known about the call from external sources.¶

3. If the exp claim is present, analyze the iat and exp claims to evaluate timeout.¶

4. Extract the kid header.¶

5. Fetch the key state for the callee at the reference time from the OOBI in kid. Caches may be used to optimize this, as long as they meet the freshness requirements of the verifier.¶

6. Use the public key of the callee to verify that the signature on the passport is valid for that key state.¶

7. Extract the evd field, which references the dossier that constitutes backing evidence.¶

8. Use the SAID ([TOIP-CESR]) of the dossier as a lookup key to see whether the dossier has already been fully validated. Since dossiers are highly stable, caching dossier validations is recommended.¶

9. Confirm that the dossier was signed (issued) by the same AID that appears in the kid header.¶

10. If the dossier requires full validation, perform it.¶

11. Check to see whether the revocation status of the dossier and each item it depends on has been tested recently enough, at the reference time, to satisfy the verifier's freshness requirements.¶

12. Compare the callee's TN to the TNAlloc credential cited in the dossier to confirm that the callee has the right to accept calls at this number.¶

13. If the passport includes non-null values for the optional card claim, extract that information and check that the brand attributes claimed for the call are justified by a brand credential in the dossier.¶

14. Check any business logic. For example, if the passport includes a non-null value for the optional goal claim, and the preceding INVITE included a VVP passport that also declared a goal, confirm that the callee's and caller's goals overlap (one must be a subset of the other). Or, if the delegated signer credential says that a call center or an AI can accept calls during certain hours, or in certain geos, check those attributes of the call.¶

5.3. Verification outcomes

A verifier MUST classify the result of examining a call, in each direction where it looks for evidence, as exactly one of the following:¶

verified:

A VVP passport was present, and every step of the applicable algorithm succeeded.¶

absent:

No VVP passport was present. Either the party did not provide one, or an intermediary removed it. Absence is a policy question, not an integrity failure; the verifier MAY accept the call at reduced assurance, challenge it, or reject it, according to local policy.¶

failed:

A VVP passport was present, and at least one step of the algorithm definitively failed: the passport was malformed or stale, the channel binding did not match, the signature was invalid, the dossier was invalid or revoked, the OP was not authorized, the TN or brand was not justified, or a constraint in a delegation credential was violated. A failed passport MUST NOT be treated more favorably than an absent one.¶

indeterminate:

A VVP passport was present, but verification could not be completed -- for example, because an OOBI or the dossier could not be fetched within the verifier's time budget, or because revocation status could not be refreshed to meet the verifier's freshness requirements. An indeterminate result MUST NOT be reported as verified. It SHOULD NOT be reported as failed, because its usual cause is network conditions rather than forgery. A verifier MAY let the call proceed while it completes verification asynchronously, and act on or record the eventual result.¶

A verifier MAY additionally report which steps succeeded before verification stopped (for example, a valid signature from the OP, but a dossier that could not be fetched).¶

When a verification service rejects a request because of a VVP passport, it SHOULD use the response codes of [RFC8224], Section 6.2.2: 403 with the reason phrase "Stale Date" when iat falls outside its replay tolerance; 436 "Bad Identity Info" for an indeterminate result caused by inability to dereference kid or evd; 437 "Unsupported Credential" when it does not support the signing algorithm; and 438 "Invalid Identity Header" for other failures. As [RFC8224] notes, intermediaries often forward a call with an annotation rather than reject it. Because a callee passport conveyed in UPDATE arrives after the call is established, rejecting that UPDATE does not end the call; a caller that wishes to end a call whose callee failed verification does so with BYE.¶

5.4. Planning for efficiency

A complete verification of either caller or callee passport, from scratch, is quite rigorous. With no caches, it may take several seconds, much like a thorough validation of a certificate chain. However, much VVP evidence is stable for long periods of time and lends itself to caching, subject to the proviso that revocation freshness must be managed wisely. Since the same dossier is used to add assurance to many calls -- perhaps thousands or millions of calls, for busy call centers -- and many dossiers will reference the same issuers and issuees and their associated key states and KELs ([TOIP-KERI]), caching will produce huge benefits.¶

Furthermore, because SAIDs and their associated data (including links to other nodes in a data graph) have a tamper-evident relationship, any party can perform validation and compile their results, then share the data with verifiers that want to do less work. Validators like this are not oracles, because consumers of such data need not trust shared results blindly. They can always directly recompute some or all of it from a passport, to catch deception. However, they can do this lazily or occasionally, per their preferred balance of risk/effort.¶

In toto, these characteristics mean that no centralized registry is required in any given ecosystem. Data can be fetched directly from its source, across jurisdictional boundaries. Because it is fetched from its source, it comes with consent. Privacy can be tuned. Simple opportunistic, uncoordinated reuse (e.g., in or across the datacenters of TSPs) will arise spontaneously and will dramatically improve the scale and efficiency of the system.¶

5.5. Historical analysis

Normally, a verification algorithm determines whether the passport verifies now. (This is the only evaluation that's valid for most JWTs, because they depend on ephemeral key state fetched just in time from x5u). However, a VVP passport can do more. Its kid header references a KEL for the signer's AID ([TOIP-KERI]), and its evd header references a dossier issued by either the AID of the AP or the AID of the callee. Thence it connects to a KEL ([TOIP-KERI]). These data structures provide key state transitions that are timestamped -- both by the controllers of the AIDs, and by their independent witnesses. Although the timestamps are not guaranteed to be perfectly synchronized, they can be compared to establish rough transition times and to detect duplicity.¶

Using this historical information, it becomes possible to ask whether a VVP passport would have verified at an arbitrary moment in the past. In such framings, the reference time from the verification algorithm is then, not now. In the normal case where then falls outside a fuzzy range, answers about key state are clear to all observers. In the rare cases where then falls inside a fuzzy range, a state transition was underway but not yet universally known, and a verifier can compute the key state (and thence, the outcome of the verification algorithm) according to their preferred interpretation.¶

6.1. Intermediaries that modify signaling

SBCs and B2BUAs along the call route may strip or fail to forward Identity headers, and commonly regenerate SDP bodies. An attacker who controls such an intermediary can suppress a VVP passport, downgrading the call from verified (or failed) to absent. VVP cannot prevent this, but the distinction between absent and failed outcomes (Section 5.3) means that suppression can only lower assurance; it cannot make a forged passport verify. Deployments that need end-to-end VVP assurance SHOULD make preservation of Identity headers a condition of their interconnect agreements. Callees SHOULD prefer the request-based transport described in Section 4.2 over the SDP attribute for the same reason.¶

6.2. Dereferencing OOBIs

The kid and evd values of a passport are URLs chosen by whoever built the passport, and a verifier dereferences them before it knows whether the passport is genuine. A verifier that fetches them naively, on every call, exposes itself and others to several attacks:¶

• Server-side request forgery. A passport can point kid or evd at an internal service on the verifier's network. Verifiers MUST only dereference https URLs, and MUST refuse to connect to loopback, link-local, and private address ranges (checked after DNS resolution, and again after any redirect) unless local policy explicitly allows a particular internal host. Verifiers SHOULD limit the number of redirects they follow, the size of responses they accept, and the time they spend on each fetch.¶

• Reflection and amplification. An attacker can place many calls whose passports point at a victim's web server, so that verifiers along the route generate traffic against it. Verifiers SHOULD rate-limit fetches per host, and SHOULD cache failed fetches for a short period so that repeated calls citing the same unreachable URL do not each trigger a new fetch.¶

• Delay. A verifier with a cold cache may need several seconds to fetch and validate a dossier, and an attacker can choose a slow server deliberately. Verifiers SHOULD set a time budget for fetching during call setup. If the budget is exhausted, the outcome is indeterminate (Section 5.3), and the verifier MAY complete verification asynchronously. Because dossiers are cached by SAID and are reused across many calls, this cost falls mostly on the first call that cites a given dossier; verifiers MAY also prefetch dossiers for frequent callers.¶

Content fetched from an OOBI is self-certifying: a KEL is verified against the AID it claims to describe, and a dossier against its SAID. A malicious server can therefore cause delay or failure, but cannot cause forged evidence to verify.¶

6.3. Compromised legitimate originator

A common form of toll fraud does not rely on a fake system. Instead, the attacker takes over a genuine PBX or SBC and routes calls through it -- often in from outside and straight back out, to premium-rate or international destinations. The outbound call then carries the real identity of the compromised system. If that system is a VVP OP, its key signs the fraudulent passports, and they verify.¶

Key rotation does not address this, because the attacker uses the system to sign rather than stealing the key. VVP limits the damage in other ways, and OPs and APs SHOULD use them:¶

• Delegated signer credentials SHOULD constrain the OP to the destinations it legitimately needs (for example, by country code or number prefix) and to a maximum call rate, in addition to any time-of-day and geographic constraints. Verifiers check destination constraints against dest on every call. Rate constraints can be checked by any verifier that observes aggregate traffic for a given kid, such as a TSP.¶

• An OP SHOULD apply its own outbound policy before signing, refusing to sign passports for calls that its delegation would not authorize, rather than relying on downstream verifiers to catch them.¶

• Each SBC or signing service SHOULD have its own AID, so that a compromise affects only the calls that pass through that service. When a compromise is detected, revoking that service's delegated signer credential stops further passports from verifying, without disturbing the AP's other delegates.¶

8.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3261]

Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, July 2002, <https://www.rfc-editor.org/rfc/rfc3261>.

[RFC3311]

Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 2002, <https://www.rfc-editor.org/rfc/rfc3311>.

[RFC4575]

Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, DOI 10.17487/RFC4575, August 2006, <https://www.rfc-editor.org/rfc/rfc4575>.

[RFC4916]

Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 2007, <https://www.rfc-editor.org/rfc/rfc4916>.

[RFC5626]

Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009, <https://www.rfc-editor.org/rfc/rfc5626>.

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/rfc/rfc8032>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8224]

Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, <https://www.rfc-editor.org/rfc/rfc8224>.

[RFC8225]

Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, <https://www.rfc-editor.org/rfc/rfc8225>.

[RFC8588]

Wendt, C. and M. Barnes, "Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)", RFC 8588, DOI 10.17487/RFC8588, May 2019, <https://www.rfc-editor.org/rfc/rfc8588>.

[RFC8866]

Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", RFC 8866, DOI 10.17487/RFC8866, January 2021, <https://www.rfc-editor.org/rfc/rfc8866>.

[TOIP-ACDC]

Smith, S., Feairheller, P., Griffin, K., Ed., and Trust Over IP Foundation, "Authentic Chained Data Containers (ACDC)", November 2023, <https://trustoverip.github.io/tswg-acdc-specification/>.

[TOIP-CESR]

Smith, S., Griffin, K., Ed., and Trust Over IP Foundation, "Composable Event Streaming Representation (CESR)", November 2023, <https://trustoverip.github.io/tswg-cesr-specification/>.

[TOIP-DOSSIER]

Hardman, D., "Verifiable Dossiers", September 2025, <https://trustoverip.github.io/kswg-dossier-specification/>.

[TOIP-KERI]

Smith, S., Griffin, K., Ed., and Trust Over IP Foundation, "Key Event Receipt Infrastructure (KERI)", January 2024, <https://trustoverip.github.io/tswg-keri-specification/>.

8.2. Informative References

[ARIES-RFC-0519]

Hardman, D., "Aries RFC 0519: Goal Codes", April 2021, <https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0519-goal-codes/README.md>.

[CTIA-BCID]

CTIA, "Branded Calling ID Best Practices", November 2022, <https://api.ctia.org/wp-content/uploads/2022/11/Branded-Calling-Best-Practices.pdf>.

[FN-DSA]

NIST, "FIPS 206: FN-DSA (Falcon)", September 2025, <https://csrc.nist.gov/presentations/2025/fips-206-fn-dsa-falcon>.

[RFC4353]

Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, <https://www.rfc-editor.org/rfc/rfc4353>.

[RFC6350]

Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, <https://www.rfc-editor.org/rfc/rfc6350>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC9796]

Wendt, C. and J. Peterson, "SIP Call-Info Parameters for Rich Call Data", RFC 9796, DOI 10.17487/RFC9796, July 2025, <https://www.rfc-editor.org/rfc/rfc9796>.