# Overview {% hint style="info" %} This document explores all aspects of the GSMA Foundary Open Verifiable Calling project. If you're looking for role-specific material, see also [Guide for Issuers](broken://pages/jZrGpT1jnjalzw13JyDX), [Guide for Signers](/signers), [Guide for Verifiers](/verifiers). {% endhint %} ### Introduction & Orientation Branded Calling—Making Trust Visible and Verifiable Voice remains the world’s most universal channel for personal and business communication. Yet today, as fraud, spoofing, and uncertainty escalate, both enterprises and consumers are asking: *Who is really calling me—and can I trust them?* At the same time, carriers and regulators face the urgent challenge of restoring trust and transparency to the voice channel, while keeping up with shifting technology, compliance needs, and consumer expectations. Branded Calling has emerged as the global response. By allowing organizations to display their verifiable name, logo, and even the reason for the call on recipients’ devices, branded calling directly addresses the root causes of declining answer rates, lost consumer confidence, and rising regulatory pressure. But the true innovation isn’t just in what users see—it’s in the ability for every participant in the ecosystem to independently verify the evidence behind every branded call. (See [Comparing to RCD](/comparing-to-rcd).) The GSMA Foundry “Open Verifiable Calling” project brings together leading carriers, technology providers, vetting authorities, and brands to demonstrate that verifiable branded calling can be achieved—securely, openly, across borders, and at industry scale. This is more than just upgrading caller ID. (See [Comparing to SHAKEN](/comparing-to-shaken).) It’s about building an end-to-end global trust framework where the evidence of telephone number rights, brand rights, and call intent travels with every call and can be validated at every step, open to audit by anyone, anywhere, at any time. What makes this initiative unique: * Authoritative onboarding and vetting: Brand and number rights are established by recognized authorities—ensuring that only legitimate organizations can present branded calls. * Cryptographically verifiable credentials: The proof of rights and identity is embedded as part of each call, so that any operator, network, or device can check the evidence, not just trust prior approval. * Visible user indicators: Consumers and enterprises both benefit from clear, consistent signals—knowing, with confidence, who is calling, what brand or service is represented, and why the call is happening. * Open and interoperable by design: Built on global, standards-aligned protocols, the solution is designed for rapid adoption, cross-carrier interoperability, and ongoing regulatory compliance. Our shared goal: To deliver a demonstration—at industry scale—that proves branded calling can be trusted, compliant, user-friendly, and universally accessible, regardless of carrier, device, or geography. This guide is your map. Whether you are a carrier, vetting provider, brand, integrator, or observer, you are invited to join this collaborative journey. Together, we will define and prove the new standard for trusted, verifiable branded calling—rooted in openness, evidence, and visible assurance for every call. ### Project Context & Problem Statement Why Branded Calling? Why Now? The decline in consumer trust for voice calls is a global challenge. Traditional caller ID solutions, and even newer frameworks like STIR/SHAKEN, have shifted the baseline for number authentication, but have not solved the need for trusted, verifiable branding—especially for cross-border and multi-carrier calls. The result: * Consumers increasingly ignore or block calls—even from businesses and institutions they know. * Enterprises face falling answer rates and limited ability to reassure customers about the legitimacy of important calls. * Regulators require stronger Know Your Customer (KYC) and Know Your Business (KYB) processes, auditability, and proof of compliance—not just at onboarding, but for every call. Branded Calling, when truly verifiable, brings all stakeholders onto common ground: * Consumers gain confidence with visible, validated caller information. * Businesses and brands see higher engagement and brand equity. * Carriers and vendors can assure regulators of robust, evidence-backed processes. * Regulators get transparency, auditability, and compliance by design. What’s been missing until now is a framework that makes this verifiability portable between networks and jurisdictions, cryptographic, and open—removing dependence on proprietary or “black box” solutions, and allowing any participant to independently verify the evidence for every branded call – in realtime, or auditable at any time afterwards. #### Why GSMA Foundry, and Why Now? The OVC project breaks this stalemate by demonstrating a truly open, decentralized, and evidence-based approach. Drawing from other industries (notably, global LEI/vLEI standards in finance), and building on recent live, cross-border telecom trials, OVC now brings these lessons to the broadest stage: * Demonstrate interoperable, verifiable calling at Mobile World Congress 2026 * Onboard vetters, signers, verifiers, and observers into a functioning, evidence-based ecosystem * Document and share a toolkit for industry and regulatory adoption, paving the way for global deployment **The Stakes** Trust should not just be aspirational–it is now the competitive edge, a regulatory requirement, and the foundation for the next era of digital communications. OVC is the industry’s opportunity to show how verifiable evidence delivers trust and unlocks new value for regulators, operators, enterprises, and consumers alike. ### Project Streams & Governance #### How the Project is Structured The OVC Foundry Project is organized into four collaborative streams, each focused on a critical success factor: * Demonstrator Stream:\ Builds, tests, and validates the end-to-end branded calling platform—including onboarding, signing, and verification, with agreed basic vetting for the demo. * Technology Stream:\ Reviews all technical components (KERI, ACDC, vLEI, SIP, RCD, etc.), aligns architecture for branding presentation and verification, addresses scalability, security, and integration. * Go-to-Market Stream:\ Shapes the overall service offering, governance processes, monetization, and extended use cases (e.g., consumer-to-consumer, brand-to-consumer). Participation in all streams is open to all qualified organizations. Regular sessions and biweekly stream meetings ensure ongoing alignment and progress. ### Core Approach — The Evidence Advantage #### Evidence That Travels with Every Call The Open Verifiable Calling solution is built on the simple, but transformative, principle that every claim of identity, number right, or branding right [must be backed by cryptographically verifiable evidence](https://www.linkedin.com/pulse/part-1-evidence-advantage-building-trust-new-era-randy-warshaw-fpxpe/) that can be checked by any participant at any time: * Trust must be evidence-based—and that evidence must travel with the call itself. * Every claim—who is calling, which brand, what authority, for what purpose—is not just asserted but cryptographically proven, inspectable, and portable. **Core Components** * Verifiable Credentials:\ All rights and claims (numbers, brands, logos, call intent) are represented as portable, cryptographically signed credentials. * Open Standards:\ The protocols (KERI, ACDC, vLEI, SIP, STIR, RCD, etc.) are globally recognized, non-proprietary, and designed for broad adoption. * Collections of Evidence:\ Each call carries a dossier—a compact collection of verifiable credentials—that can be embedded in signaling or referenced as metadata. This dossier proves, in real time, the chain of authority that can be proven from initial vetting to the call itself. * Distributed Governance:\ No single gatekeeper. Multiple vetting authorities, issuers, and verifiers can participate. Trust is anchored in open, verifiable evidence, not vendor lock-in. **How It Works** 1. Onboarding & Vetting:\ Enterprise/brand is onboarded and vetted by an authorized provider, issuing credentials attesting to identity, number, and brand rights. 2. Signing & Call Origination:\ The call is signed using these credentials—proving, cryptographically, who is calling and what rights are asserted. 3. Transmission & Verification:\ As the call traverses networks, the dossier remains attached/discoverable and tamper-evident. 4. Verification & Presentation:\ Any operator or provider can independently verify the claims—no “phoning home,” no “black box.” The user receives a branded, trusted, verifiable call. **What This Enables** * Faster onboarding, lower integration cost (no proprietary API lock-in) * Regulatory compliance across borders, for cloud or delegated calls * Level playing field—open standards, not vendor lock-in * Future-proofing for AI, delegation, traceability, and revocation **Why Now?** By moving from assertion (“trust us”) to verifiable evidence (“prove it, in real time”), OVC lays the foundation for regulatory, commercial, and technical trust across the voice ecosystem. ### Project Structure & Participant Roles #### Key Participant Roles * [Vetters / Credential Issuers](broken://pages/jZrGpT1jnjalzw13JyDX):\ Onboard and vet brands, enterprises, numbers, logos; issue credentials per governance models. * [Signers / Originators](/signers):\ Initiate calls, signing them with relevant credentials—may include cloud platforms, contact centers, delegated human or AI agents. * [Verifiers / Terminators](/verifiers):\ Receive, inspect, and verify the dossier; present trusted information to end users. * Observers / Industry Partners:\ Stakeholders in testbed evaluation, regulatory review, or industry analysis. #### How Coordination Works * Weekly calls, dedicated prep and debriefs, clear alignment * All participants receive clear, role-specific guides (with this overview as their “navigation map”). * Consensus is sought, but progress is prioritized—blockers are escalated as needed * All materials, results, and findings are shared for industry and regulatory reporting ### Demonstration Goals & Success Criteria #### What Are We Proving? * End-to-End Branded Calls:\ Seamless, evidence-rich call flow—from onboarding and vetting, through signing and transmission, to verification and branded presentation. * Cloud-Originated, Cross-Border Trust:\ Portable, verifiable proof of right-to-use for international, cross-border, cloud-based calls. * Flexible Governance:\ Trust is not locked into a single vendor or CA—multiple vetting and credential-issuing organizations prove trust can be federated. * Mutual Authentication & Delegation:\ Support for advanced use cases: B2B, B2C, delegated calls (AI/agent). * Interoperability:\ Demo works across diverse carriers, network types, device classes—proving readiness for global deployment. #### Validation of Success * Live demonstration at MWC 2026—multiple parties, real-world flows. * At least three participant types integrate using project documentation/toolkits, with reduced onboarding friction. * Calls traverse international boundaries, involve multiple operators, and are independently verified at termination. * Credentials, flows, and outcomes are auditable; toolkit and whitepaper provide a replicable roadmap for global adoption. ### Participation & Next Steps #### How to Get Started 1. Join the Project: Confirm participation, assign a lead, identify roles. 2. Access Documentation & Tools: guides for [issuers](broken://pages/jZrGpT1jnjalzw13JyDX), [signers](/signers), and [verifiers](/verifiers); integration support [available](mailto:daniel@provenant.net). 3. Complete Onboarding: Credentialing, integration, verification, testing in the sandbox. 4. Engage and Iterate: Weekly calls, workshops, feedback to refine the toolkit. 5. Prepare for Demo Day: Milestones and feedback loop for validation. **Expectations** * Open collaboration; active engagement; willingness to iterate. * Commitment to project goals and shared success. * Contact project leads or your stream coordinator with questions. * All onboarding materials available via the GSMA Foundry portal. ### What Happens After the Demo? The MWC 2026 demonstration will inform GSMA and industry about the path to standardization, regulatory alignment, and commercial pilots. OVC is designed as a springboard for broader adoption—enabling future phases, pilots, and open standards alignment across multiple regions and industry segments.\ This Overview Guide is a living document—feedback and updates are welcomed as the project evolves. ### Guiding Principles & Closing * Openness: All standards, protocols, and documentation are public and non-proprietary. * Evidence Over Heuristics: Every claim must be backed by cryptographically verifiable evidence. * Portability & Flexibility: Designed for global, cross-carrier, and cross-border deployment. * Decentralized Governance: Trust is anchored in evidence and transparency—not single points of failure. * Pragmatism & Results: Every feature is designed for practical deployment, tested in live calls, with real-world feedback. #### Vision & Call to Action Restore confidence for consumers, enterprises, and regulators. Unlock new value for all participants. Future-proof voice for AI, automation, and global scale. This is a call to build more than just a demonstration. Let’s prove how it’s possible to deploy a durable, open standard for the next era of trusted communications together. #### Supporting Materials * [Glossary](/glossary) * Appendix B: End-to-End Call Flow Diagrams * [Credential Structure](/cred-structure) * Role-Specific Integration Checklists * Appendix E: Frequently Asked Questions (FAQ) * Appendix F: Reference Links & Further Reading * Appendix G: Attribution, Credits & Contact Info # Guide for Issuers Most companies in the GSMA foundry project won't have an issuer role, so they can ignore this doc. If you are a vetter or a seller of TNs, you will be issuing, but your work is quite simple: * [ ] Find your company's LEI, or get one if you don't already have one. * [ ] Ask Provenant to turn your LEI into a bronze vLEI suitable for use in this project. * [ ] For the handful of enterprises that will make outbound calls for the MWC demo, issue a token, certification, telephone number, or credential in exactly the way you currently do. * [ ] Share your output with Provenant so it can be converted into VVP-compatible evidence. # Guide for Signers Signers in GSMA's Open Verifiable Calling project are also called [originating parties](https://docs.google.com/document/d/1N1_sOo1RWr93NewQOtOohbNx-H3aFJ8pWx-a8_xTn4E/edit?tab=t.0#heading=h.hm2g9bxbly2v) (OPs). They are typically UCaaS providers or traditional carriers and operators positioned in a route immediately after the internal VOIP systems of the [accountable party](https://docs.google.com/document/d/1N1_sOo1RWr93NewQOtOohbNx-H3aFJ8pWx-a8_xTn4E/edit?tab=t.0#heading=h.yv4p2lsthmco) (the enterprise whose brand is associated with the call). Signers are responsible for generating a SIP INVITE (or receiving an incomplete INVITE) for each call, and then adding to that INVITE an Identity header that contains the STIR-compliant [VVP](https://dhh1128.github.io/vvp/draft-hardman-verifiable-voice-protocol.html) passport. Before any calls can be signed, VVP requires enterprises to organize evidence that proves important things about their identity, brand, telephone number, and intentions. See [Credential Types](https://docs.google.com/document/d/1Aw4h95UmnOggZRxCf0F9lcw-psAKnpBbGNERCJtKlXo/edit?tab=t.0). Enterprises that want signed traffic configure most of this evidence ahead of time, but finish assembling their [dossier](https://docs.google.com/document/d/1N1_sOo1RWr93NewQOtOohbNx-H3aFJ8pWx-a8_xTn4E/edit?tab=t.0#heading=h.qrrt5pae2t1v) at the moment the signer agrees to produce signed traffic for them. Once this permanent dossier exists, it is referenced repeatedly, without modification, as calls occur in realtime. Dossiers last as long as the enterprise wants to keep signed traffic configured that way; unlike X509 certificates, dossiers do not require periodic reissuance as keys rotate. A signer fits into the overall SIP call flow exactly as [STIR imagines](https://www.rfc-editor.org/rfc/rfc8224) (see steps 3 and 4):
What is different in our project is that the passport contains richer, more robust, and more permanent evidence than with other STIR passport types — proof of the legal identity of the caller, right to use TN, brand attributes, delegation to the originating service provider, relationship to call center, settlement, AI involvement, and so forth. See [The Evidence Advantage](https://www.linkedin.com/pulse/part-1-evidence-advantage-building-trust-new-era-randy-warshaw-fpxpe/). The verifier is able to achieve higher levels of assurance about more facts, and to justify their decisions to auditors anywhere in the world, now and at any future time, without central governance. ## Approaches to signing There are 3 ways you can implement signing behavior in this project: * with SIP redirects (just requires simple SBC config) * by calling RESTful APIs (requires a small amount of coding to integrate) * by implementing verification from scratch (doable with a significant investment) In the first two approaches, signers call services that do the heavy lifting. In the Open Verifiable Calling project, these services are provided to experimenters by Provenant. In the final approach, signers collect and analyze the open [VVP](https://dhh1128.github.io/vvp/draft-hardman-verifiable-voice-protocol.html) data themselves, and thus have full flexibility. ## Easiest way to sign: use SIP redirect server In this approach, the signer's SBC receives or generates a SIP INVITE that is not yet protected by [VVP](https://dhh1128.github.io/vvp/draft-hardman-verifiable-voice-protocol.html), and passes it to a SIP redirect server at `sip-sign.voice.sandbox.provenant.net`. This server uses the originating TN to look up the associated, preconfigured dossier. It then generates a signed Identity header (= STIR PASSporT; a JWT in compact format) matching (and hyperlinking to) that dossier. It returns an updated SIP INVITE containing this header. The response begins with a SIP status line that has a [SIP response code that tells the SBC what kind of handling](/sip-response-codes) for the call is appropriate, based on the state of the evidence. #### Prerequisites * [ ] [Contact Provenant](mailto:daniel@provenant.net) and arrange to have the IP address of your SBC whitelisted. ### Requesting an INVITE protected by VVP Your SBC should forward to the signing endpoint every SIP INVITE that it wants to protect with the [VVP](https://dhh1128.github.io/vvp/draft-hardman-verifiable-voice-protocol.html) mechanism.No special headers or parameters are required — just the INVITE as it would normally be generated. This INVITE will naturally contain the From and To headers (inputs for the PASSporT that will reference the dossier and hold a signature). #### Sample TCP SIP signing request What your SBC sends to this endpoint might look like this: ```http INVITE sip:+XXXXXXXXXXX@sip-sign.voice.sandbox.provenant.net:5060 SIP/2.0 Via: SIP/2.0/TCP 192.168.122.197:5060;branch=z9hG4bK2437132 From: +XXXXXXXXXXX ;tag=12345 To: +YYYYYYYYYYY Call-ID: e403c07d-86cb-43c7-bf46-78c3a1d49d25 CSeq: 1 INVITE Contact: sip:+XXXXXXXXXXX@192.168.122.197:5060 Max-Forwards: 70 Content-Type: application/sdp Content-Length: 0 ``` #### Sample TCP SIP signing response The response from the SIP redirect server is normally an upgraded SIP INVITE that now contains an Identity header. This new INVITE is what should be passed to downstream nodes in the route. For example: ```http SIP/2.0 306 branded 0x00204800 CSeq: 1 INVITE Call-ID: e403c07d-86cb-43c7-bf46-78c3a1d49d25 From: "+" ;tag=12345 To: "+YYYYYYYYYYY" Via: SIP/2.0/TCP 192.168.122.197:5060;branch=z9hG4bK2437132;received=192.168.20.23;rport=46137 Contact: Identity: eyJhbGciOiJFZERTQSIsInR5cCI6InBhc3Nwb3J0IiwicHB0IjoidnZwIiwia2lkIjoiaHR0cDovL3dpdG5lc3MxLmRldi5wcm92ZW5hbnQubmV0OjU2MzEvb29iaS9FSVo1MGdaLXJIanNtdHljQWQ4VGtpRnJfU01RSmd0X1ZkN2xxb0s0UUZnNi93aXRuZXNzIn0.eyJvcmlnIjp7InRuIjpbIjQ0MjA3OTQ2MDgyMyJdfSwiZGVzdCI6eyJ0biI6WyIxMjEyMzMzMTIzNCJdfSwiaWF0IjoxNzU3NjA1NDI4LCJjYXJkIjpudWxsLCJjYWxsX3JlYXNvbiI6bnVsbCwiZ29hbCI6bnVsbCwiZXZkIjoiaHR0cHM6Ly9vcmlnaW4uZGV2LnByb3ZlbmFudC5uZXQvdjEvYWdlbnQvcHVibGljL0VHVGxRd1pUZTktLUlRQjhtamJzT0QyVjJ5b3ZON09KcWI1VEJZOTV3SWY1L2Rvc3NpZXIuY2VzciIsIm9yaWdJZCI6IiIsImV4cCI6MTc1NzYwNTcyOCwicmVxdWVzdF9pZCI6IiJ9.ZorPngtPKtA8T0NeIrHROq987hVvRR4sZhaIt-bMuJdk5cKvb-Kx57MiwXYX5qpEscUdlW8X7WyrJOJvWYjcDg;ppt=vvp Request_id: 49066ecb-84e0-4723-8186-de9223431d1c Content-Length: 0 ``` #### Sample structure inside the Identity header If you pass such an Identity header to a JWT parser (e.g., on ), you'll see that in addition to a signature, it contains substructure like this: Header ```json { "alg": "EdDSA", "typ": "passport", "ppt": "vvp", "kid": "http://witness1.provenant.net:5631/oobi/EIZ50gZ-rHjsmtycAd8TkiFr_SMQJgt_Vd7lqoK4QFg6/witness" } ``` Payload ```json { "orig": { "tn": [ "XXXXXXXXXXX" ] }, "dest": { "tn": [ "YYYYYYYYYYY" ] }, "iat": 1757605428, "card": null, "call_reason": "debt collection" "evd": "https://acme.com/dossiers/EGTlQwZTe9--IQB8mjbsOD2V2yovN7OJqb5TBY95wIf5.cesr", "origId": "", "exp": 1757605728, "request_id": "49066ecb-84e0-4723-8186-de9223431d1c" } ``` In this data structure, the kid header allows verifiers to look up the key state of the signer, and the evd claim references the permanent dossier of evidence. #### Possible outcomes These samples show a typical interaction where evidence is complete and in optimal state, and branding information is included. Of course, the SIP redirect server at `sip-sign.voice.sandbox.provenant.net` also communicates errors exactly as the SIP spec expects — with 4xx and 5xx response codes. It will also advise callers if evidence doesn't intend to prove brand, or if it has a more complex state. It does this by signalling 5 different ways that downstream verifiers might react to the evidence. See [SIP Response Codes](https://docs.google.com/document/d/1zfHaZQzlz92yjoXvI1aJY25z7DHlop1gy4nLFRr_gmc/edit?tab=t.0) for more details. ### More control, slightly more effort: use RESTful web service In this approach, your SBC calls an HTTPS signing endpoint, `https://voice.sandbox.provenant.net/v1/signer/voice/sign`, instead of a SIP redirect server. The benefit is that you can get richer data and can perform arbitrary customizations in your routing logic. The tradeoff is that you have to call an HTTPS API from SIP infrastructure. Performance at scale is optimized and can approach that of raw SIP, but to use the API, you must satisfy the API's cybersecurity requirements. Instead of using an API key or an OAuth token, you must sign your HTTP requests according to rules of [RFC 9421](https://datatracker.ietf.org/doc/rfc9421/). This RFC is elegant and very secure, but it is also relatively new, so the technique may be unfamiliar. (Implementation is not difficult — 20 to 40 lines of code in most common programming languages. Provenant has reference implementations that it can share upon request.) Perhaps more important, this also requires your infrastructure to create, register, and manage the lifecycle of an Ed25519 keypair, and it requires your code to depend on a cryptographic library like libsodium. #### Sample POST A request to the web verification endpoint is a POST. It must define the Content-Digest, Signature, and Signature-Input headers, and its body must be JSON that includes the orig and dest TNs, an optional request\_id for tracing, and an optional call\_reason. A sample request might look like this: ```http POST /v1/signer/voice/sign HTTP/1.1 Accept: application/json origin-date: 2025-09-10T15:44:02.625712445-04:00 content-digest: sha-256=:aFeN5cBYC-fgfXYuD8wSzLf5gPnzElIRmlGgUY97sDc: signature:indexed="?0";provenant-au="0BDKj3dIJjEylI3ZirsUM9waSuK7CpOlq_iHB2AkJuAd_V-0cn9Kc2reGe7wl6hyYjmyfPOGu7_R77-FbVN4Ue8E" signature-input: provenant-au=("@method" "@path" "origin-date" "content-digest"); "created"="1757533442626";"keyid"="BB5o8EzplEwMlqZMJaiFhveqND1X0ECqhgyyu4S5VOmd";"alg"="ed25519"; Content-Type: application/json Content-Length: 81 Host: sign.sip.callverify.com Connection: Keep-Alive Accept-Encoding: gzip User-Agent: okhttp/4.12.0 {"orig":"+442079460823","dest":"+12123331234","request_id":"49066ecb-84e0-4723-8186-de9223431d1c","call_reason":"debt collection"} ``` If you'd like the OpenAPI (Swagger) definitions for this API, use ssh-keygen to create an Ed25519 keypair. Then [contact Provenant](mailto:daniel@provenant.net) with your public key and the IP address you'll be calling from. Your key will be registered and you'll receive docs to explore further. ### Maximum control, significant investment: implement from scratch The [VVP specification](https://datatracker.ietf.org/doc/draft-hardman-verifiable-voice-protocol/) and the related [KERI](https://trustoverip.github.io/tswg-keri-specification/), [ACDC](https://trustoverip.github.io/tswg-acdc-specification/), [CESR](https://trustoverip.github.io/tswg-cesr-specification/), and [Dossier](https://trustoverip.github.io/kswg-dossier-specification) specifications that it depends on are all open, published to the world by standards organizations. In addition, there are reference implementations of major components of a VVP stack under permissive open source licenses on github (see [1](https://github.com/WebOfTrust/keripy), [2](https://github.com/WebOfTrust/keria), [3](https://github.com/WebOfTrust/signify-ts), [4](https://github.com/WebOfTrust/cesride), [5](https://github.com/WebOfTrust/signify-browser-extension), [6](https://github.com/WebOfTrust/cesr-ts), [7](https://github.com/WebOfTrust/signifypy), [8](https://github.com/THCLab/keriox), [9](https://github.com/THCLab/cesrox), [10](https://github.com/THCLab/acdc-rust), [11](https://github.com/GLEIF-IT/vlei-verifier), [12](https://github.com/GLEIF-IT/vlei-verifier-router), [13](https://github.com/WebOfTrust/vLEI)). The communities behind these resources conduct meetings that are open to the public, and may be able to offer simple orientation to what they've published. Participants in the Open Verifiable Calling project would likely be welcomed as peers with enthusiasm. However, these resources represent many person-years of investment in a specialized problem domain. Therefore, those pursuing this approach should expect a significant learning curve. After they've mastered the basics, there is still work to be done, gluing the components together, adapting them to the special needs of VVP use cases, testing them rigorously, and deploying for high availability, scale, cybersecurity, and similar goals. # Guide for Verifiers Verifiers in GSMA's Open Verifiable Calling project are typically transit operators, gateway operators, or terminating service providers (though they could be auditors or national regulators, too). They are responsible for inspecting SIP INVITEs and deciding whether a call deserves to be routed (with verifiable branding) or declined. For calls that connect, verifiers also provide the verified, branded caller attributes that ultimately appear on the handset. A verifier fits into the overall SIP call flow exactly as [STIR imagines](https://www.rfc-editor.org/rfc/rfc8224) (see steps 6 and 7):
What is different in our project is that the passport contains richer, more robust, and more permanent evidence than with other STIR passport types — proof of the legal identity of the caller, right to use TN, brand attributes, delegation to the originating service provider, relationship to call center, settlement, AI involvement, and so forth. See [The Evidence Advantage](https://www.linkedin.com/pulse/part-1-evidence-advantage-building-trust-new-era-randy-warshaw-fpxpe/). The verifier is able to achieve higher levels of assurance about more facts, and to justify their decisions to auditors anywhere in the world, now and at any future time, without central governance. ### Approaches to verification There are 3 ways you can implement verifier behavior in this project: * with SIP redirects (just requires simple SBC config) * by calling RESTful APIs (requires a small amount of coding to integrate) * by implementing verification from scratch (doable with a significant investment) In the first two approaches, verifiers call services that do the heavy lifting. In the Open Verifiable Calling project, these services are provided to experimenters by Provenant. In the final approach, verifiers collect and analyze the open [VVP](https://dhh1128.github.io/vvp/draft-hardman-verifiable-voice-protocol.html) data themselves, and thus have full flexibility. ### Easiest way to verify: use SIP redirect server In this approach, the verifier's SBC receives an incoming SIP INVITE, and passes it to a SIP redirect server at `sip-verify.voice.sandbox.provenant.net`. This server analyzes the INVITE and returns a SIP response code that tells the SBC whether to continue routing or decline the call. If the decision is to continue routing, the response also adds verified brand information such as a logo to the call's Call-Info header so it can be displayed on the handset. #### Prerequisites * [ ] [Contact Provenant](mailto:daniel@provenant.net) and arrange to have the IP address of your SBC whitelisted. #### Requesting verification Your SBC should forward to the verification endpoint every SIP INVITE that is using the [VVP](https://dhh1128.github.io/vvp/draft-hardman-verifiable-voice-protocol.html) mechanism. This means every INVITE that has an Identity header ending in `;type=vvp`. No special headers or parameters are required — just the INVITE as it was received from an upstream node in the route, and as it would be forwarded to any other SIP redirect endpoint. #### Sample TCP SIP verification request What your SBC sends to this endpoint might look like this: ```http INVITE sip:+XXXXXXXXXXX@sip-verify.voice.sandbox.provenant.net:5060 SIP/2.0 Via: SIP/2.0/TCP 192.168.122.197:5060;branch=z9hG4bK2712455 From: +XXXXXXXXXXX ;tag=12345 To: +YYYYYYYYYYY Call-ID: 3da62474-f40c-4cb1-b6d9-2ad09e8fde8d CSeq: 1 INVITE Contact: sip:+XXXXXXXXXXX@192.168.122.197:5060 Identity: eyJhbGciOiJFZERTQSIsInR5cCI6InBhc3Nwb3J0IiwicHB0IjoidnZwIiwia2lkIjoiaHR0cDovL3dpdG5lc3MxLmRldi5wcm92ZW5hbnQubmV0OjU2MzEvb29iaS9FSVo1MGdaLXJIanNtdHljQWQ4VGtpRnJfU01RSmd0X1ZkN2xxb0s0UUZnNi93aXRuZXNzIn0.eyJvcmlnIjp7InRuIjpbIjQ0MjA3OTQ2MDgyMyJdfSwiZGVzdCI6eyJ0biI6WyIxMjEyMzMzMTIzNCJdfSwiaWF0IjoxNzU3NjA1NDI4LCJjYXJkIjpudWxsLCJjYWxsX3JlYXNvbiI6bnVsbCwiZ29hbCI6bnVsbCwiZXZkIjoiaHR0cHM6Ly9vcmlnaW4uZGV2LnByb3ZlbmFudC5uZXQvdjEvYWdlbnQvcHVibGljL0VHVGxRd1pUZTktLUlRQjhtamJzT0QyVjJ5b3ZON09KcWI1VEJZOTV3SWY1L2Rvc3NpZXIuY2VzciIsIm9yaWdJZCI6IiIsImV4cCI6MTc1NzYwNTcyOCwicmVxdWVzdF9pZCI6IiJ9.ZorPngtPKtA8T0NeIrHROq987hVvRR4sZhaIt-bMuJdk5cKvb-Kx57MiwXYX5qpEscUdlW8X7WyrJOJvWYjcDg;ppt=vvp Max-Forwards: 70 Content-Type: application/sdp Content-Length: 0 ``` #### Sample TCP SIP verification response The SIP redirect server at `sip-verify.voice.sandbox.provenant.net` communicates errors exactly as the SIP spec expects — with 4xx and 5xx response codes. But in the normal case, verification results fall into one of 5 outcomes and are signalled with 3xx and 6xx status codes. See [SIP Response Codes](/sip-response-codes) for more details. A typical response might look like this: ```http SIP/2.0 306 branded 0x02388000 CSeq: 1 INVITE Call-ID: ca4b5a6b-4efb-412b-a8ff-9e8c64d967c6 From: "+XXXXXXXXXXX" ;tag=12345 To: "+YYYYYYYYYYY" Via: SIP/2.0/TCP 192.168.122.197:5060;branch=z9hG4bK9566937;received= 192.168.3.41;rport=52557 Request_id: 49066ecb-84e0-4723-8186-de9223431d1c Contact: Identity: eyJhbGciOiJFZERTQSIsInR5cCI6InBhc3Nwb3J0IiwicHB0IjoidnZwIiwia2lkIjoiaHR0cDovL3dpdG5lc3MxLmRldi5wcm92ZW5hbnQubmV0OjU2MzEvb29iaS9FSVo1MGdaLXJIanNtdHljQWQ4VGtpRnJfU01RSmd0X1ZkN2xxb0s0UUZnNi93aXRuZXNzIn0.eyJvcmlnIjp7InRuIjpbIjQ0MjA3OTQ2MDgyMyJdfSwiZGVzdCI6eyJ0biI6WyIxMjEyMzMzMTIzNCJdfSwiaWF0IjoxNzU3NjA1NDI4LCJjYXJkIjpudWxsLCJjYWxsX3JlYXNvbiI6bnVsbCwiZ29hbCI6bnVsbCwiZXZkIjoiaHR0cHM6Ly9vcmlnaW4uZGV2LnByb3ZlbmFudC5uZXQvdjEvYWdlbnQvcHVibGljL0VHVGxRd1pUZTktLUlRQjhtamJzT0QyVjJ5b3ZON09KcWI1VEJZOTV3SWY1L2Rvc3NpZXIuY2VzciIsIm9yaWdJZCI6IiIsImV4cCI6MTc1NzYwNTcyOCwicmVxdWVzdF9pZCI6IiJ9.ZorPngtPKtA8T0NeIrHROq987hVvRR4sZhaIt-bMuJdk5cKvb-Kx57MiwXYX5qpEscUdlW8X7WyrJOJvWYjcDg;ppt=vvp Call-Info: ;purpose=icon, ;purpose=reason Content-Length: 0 ``` The Identity and Call-Info headers in the response may be passed to downstream parties that are willing to trust the verifier; these function as a receipt that can be presented to an auditor. The hex code at the end of the response's initial status line (0x023888000), and that is repeated inside Call-Info in the URL with purpose=reason, is called a [reason code](https://docs.google.com/document/d/1N1_sOo1RWr93NewQOtOohbNx-H3aFJ8pWx-a8_xTn4E/edit?tab=t.0#heading=h.h12y079rdbun). It gives details about how the verification service evaluated evidence, and can be converted to a human-friendly explanation for troubleshooting purposes using the URL. ### More control, slightly more effort: use RESTful web service In this approach, your SBC calls an HTTPS verification endpoint instead of a SIP redirect server. The benefit is that you can get richer data and can perform arbitrary customizations in your routing logic. The tradeoff is that you have to call an HTTPS API from SIP infrastructure. Performance at scale is optimized and can approach that of raw SIP, but to use the API, you must satisfy the API's cybersecurity requirements. Instead of using an API key or an OAuth token, you must sign your HTTP requests according to rules of [RFC 9421](https://datatracker.ietf.org/doc/rfc9421/). This RFC is elegant and very secure, but it is also relatively new, so the technique may be unfamiliar. (Implementation is not difficult — 20 to 40 lines of code in most common programming languages. Provenant has reference implementations that it can share upon request.) Perhaps more important, this also requires your infrastructure to create, register, and manage the lifecycle of an Ed25519 keypair, and it requires your code to depend on a cryptographic library like libsodium. #### Sample POST A request to the web verification endpoint, `https://voice.sandbox.provenant.net/v1/verifier/voice/verify`, is a POST. It must define the Content-Digest, Signature, and Signature-Input headers, and its body must be JSON that includes the orig and dest TNs, the Identity header received from upstream, and a request\_id for tracing. A sample request might look like this: ```http POST /v1/verifier/voice/verify HTTP/1.1 Accept: application/json origin-date: 2025-09-11T14:39:10.315887244-04:00 content-digest: sha-256=:VB7N894Lwiz1hh7BUk6fKaXGBDn2C1j4cUluErclL5w: signature: indexed="?0";provenant-au="0BAlLeQYQ-GPXnu81eJdc1zG52aDQoZQ5UvGrvoElcPfT5MjGA3eG-qa0IQ7MZO5qqn9EPTtLOW8QdoyUa0bh28O" signature-input: provenant-au=("@method" "@path" "origin-date" "content-digest");"created"="1757615950316";"keyid"="BCR0ytXKwOzeRwoLUkgHx3pKwmDQfCYJXXfArjL-UCik";"alg"="ed25519"; Content-Type: application/json Content-Length: 747 Host: verify.web.callverify.com Connection: Keep-Alive Accept-Encoding: gzip "{"orig":"+442079460823","dest":"+12123331234","identity":"eyJhbGciOiJFZERTQSIsInR5cCI6InBhc3Nwb3J0IiwicHB0IjoidnZwIiwia2lkIjoiaHR0cDovL3dpdG5lc3MxLmRldi5wcm92ZW5hbnQubmV0OjU2MzEvb29iaS9FSVo1MGdaLXJIanNtdHljQWQ4VGtpRnJfU01RSmd0X1ZkN2xxb0s0UUZnNi93aXRuZXNzIn0.eyJvcmlnIjp7InRuIjpbIjQ0MjA3OTQ2MDgyMyJdfSwiZGVzdCI6eyJ0biI6WyIxMjEyMzMzMTIzNCJdfSwiaWF0IjoxNzU3NjE1OTIzLCJjYXJkIjpudWxsLCJjYWxsX3JlYXNvbiI6bnVsbCwiZ29hbCI6bnVsbCwiZXZkIjoiaHR0cHM6Ly9vcmlnaW4uZGV2LnByb3ZlbmFudC5uZXQvdjEvYWdlbnQvcHVibGljL0VHVGxRd1pUZTktLUlRQjhtamJzT0QyVjJ5b3ZON09KcWI1VEJZOTV3SWY1L2Rvc3NpZXIuY2VzciIsIm9yaWdJZCI6IiIsImV4cCI6MTc1NzYxNjIyMywicmVxdWVzdF9pZCI6IiJ9.2bRFuprx0dmRxauiK4t7YmSIh2jMG0jQMzrf1sc-2AI6iwOvRGh4fARk3Ubrh2hOpNi_5SRhk3E2x2L5JX6bAg;ppt=vvp","request_id":""}" ``` If you'd like the OpenAPI (Swagger) definitions for this API, use ssh-keygen to create an Ed25519 keypair. Then [contact Provenant](mailto:daniel@provenant.net) with your public key and the IP address you'll be calling from. Your key will be registered and you'll receive docs to explore further. ### Maximum control, significant investment: implement from scratch The [VVP specification](https://datatracker.ietf.org/doc/draft-hardman-verifiable-voice-protocol/) and the related [KERI](https://trustoverip.github.io/tswg-keri-specification/), [ACDC](https://trustoverip.github.io/tswg-acdc-specification/), [CESR](https://trustoverip.github.io/tswg-cesr-specification/), and [Dossier](https://trustoverip.github.io/kswg-dossier-specification) specifications that it depends on are all open, published to the world by standards organizations. In addition, there are reference implementations of major components of a VVP stack under permissive open source licenses on github (see [1](https://github.com/WebOfTrust/keripy), [2](https://github.com/WebOfTrust/keria), [3](https://github.com/WebOfTrust/signify-ts), [4](https://github.com/WebOfTrust/cesride), [5](https://github.com/WebOfTrust/signify-browser-extension), [6](https://github.com/WebOfTrust/cesr-ts), [7](https://github.com/WebOfTrust/signifypy), [8](https://github.com/THCLab/keriox), [9](https://github.com/THCLab/cesrox), [10](https://github.com/THCLab/acdc-rust), [11](https://github.com/GLEIF-IT/vlei-verifier), [12](https://github.com/GLEIF-IT/vlei-verifier-router), [13](https://github.com/WebOfTrust/vLEI)). The communities behind these resources conduct meetings that are open to the public, and may be able to offer simple orientation to what they've published. Participants in the Open Verifiable Calling project would likely be welcomed as peers with enthusiasm. However, these resources represent many person-years of investment in a specialized problem domain. Therefore, those pursuing this approach should expect a significant learning curve. After they've mastered the basics, there is still work to be done, gluing the components together, adapting them to the special needs of VVP use cases, testing them rigorously, and deploying for high availability, scale, cybersecurity, and similar goals. # Glossary ## Accountable Party (AP) Loosely, "the enterprise". In the context of a SIP call, this is the party that holds the right to use the originating phone number, according to the regulator, and the party whose brand will be conveyed by branded calling. They must assemble evidence (a dossier) to prove their identity, reputation, and intentions. The accountable party may delegate signing duties to their UCaaS, and may delegate actual call mechanics to a call center. However, they retain ultimate accountability for calls that correctly cite their evidence — and they should repudiate any calls that don't. ## ACDC *Authentic Chained Data Containers*: a format for verifiable digital data like credentials and affidavits. X509 certificates are generation-1 PKI credentials. W3C Verifiable Credentials are generation-2 credentials. ACDCs are generation-3. They are more permanent than an X509 certificate, because they do not require reissuance when keys rotate. They also eliminate the need for centrally managed certificate authorities. They are more flexible than a W3C VC, because they can model scientific and financial data, not just credentials. Unlike either of their predecessor technologies, they can be verified with respect to arbitrary points in time, not just "now", and they support arbitrarily rich chaining with verifiable hyperlinks. ACDCs are the most expressive, highest-security, most permanent way to represent credentials in our project. They are stored in [CESR](#cesr) format, but can be down-converted to older forms of evidence for interoperability. ACDCs are used by [GLEIF](https://gleif.org/) [vLEIs](https://www.gleif.org/en/organizational-identity/introducing-the-verifiable-lei-vlei/introducing-the-vlei-ecosystem-governance-framework) in the financial industry and became a [standard](https://github.com/trustoverip/tswg-acdc-specification) when [ISO 17442:3](https://www.iso.org/standard/85628.html) was published. A sample ACDC is shown in [Credential Structure](/cred-structure). ## CESR *Composable Event Streaming Representation*: a serialization format used by KERI and [ACDCs](#acdc) that can freely mix or convert between a JSON-like text form, and a CBOR-like binary form. CESR is terser than JSON as text, and terser than CBOR as binary — and unlike either of these other formats, signed CESR data can be transformed back and forth between text and binary, and between compressed and expanded forms, without invalidating a signature. CESR supports binary attachments and recognizes cryptographic primitives natively, making clunky constructions like JWK (a complex JSON data structure for describing public keys) unnecessary. The sample ACDC shown in [Credential Structure](/cred-structure) is in CESR format; it begins with a text JSON block, and ends with a binary attachment. ## Dossier See [comments about dossiers](https://docs.google.com/document/d/1Aw4h95UmnOggZRxCf0F9lcw-psAKnpBbGNERCJtKlXo/edit?tab=t.0#heading=h.sy778n6090x8) in Credential Types. ## Integration Agent A lightweight web service (distributed as a Docker container) that bridges between ACDC technology and the infrastructure of an issuer of credentials. The agent exposes APIs to issue, revoke, and enumerate credentials, and also a simple UI to configure such actions. It is designed to run on the issuer's internal network, under the issuer's control. ## Originating Party (OP) The party that operates the SBC that creates the first SIP INVITE for an outbound call. This is often a service provider for the AP. The OP must sign the VVP passport (the Identity header) that makes the call verifiable (see [Guide for Signers](/signers)), and they must do so with keys that have been authorized by the AP. ## Reason Code An unsigned integer bitmask that explains why a voice call could be judged worthy of routing, by detailing the characteristics of all the associated evidence (which credentials exist, whether they are expired or revoked, whether a passport matches the observed metadata for the call, whether the signature on the passport is valid, etc.). Reason codes should be saved in a CDR; in conjunction with the Identity header that they explain, they constitute a receipt that supports forensic analysis. Verifiers define business rules that determine how a reason code turns into a routing decision (e.g., "If all of the following conditions are true, accept the call; otherwise, reject it.")
# Credential Types Existing attempts to eliminate fraud in telco suffer from weak or incomplete evidence. Voice traffic becomes verifiable if we prove, with robust evidence, various logical propositions about a call. Each cluster of related facts has a different purpose, a different lifecycle, and potentially, a different issuer. ## Journey Although order may vary, the steps in an enterprise's credential journey, leading up to its readiness to emit verifiable voice traffic, usually look like this:
## Identity credential Steps 1-4 in the diagram. Certifies that a given legal entity (an enterprise[^1] identified by its LEI), is also identified by a particular autonomic identifier (an AID). Different levels of assurance are possible with an identity credential, with the gold standard being the LE vLEI. In our project, we may begin with a bronze identity credential. This is the first step of the vLEI journey and can be upgraded to a full vLEI later. It is issued after confirming that: a) the requester is a human; b) the requester controls their email inbox; c) the requester formally identifies the legal entity in question, using its LEI; d) there is good reason to believe the legal entity controls the domain in the requester's email \[automated analysis + DNS TXT record or upload to website); e) the requester produces a cryptographic signature that proves they control the keys for the AID that the legal entity will be using. ## TN credential Step 5 in the diagram. Certifies that a given legal entity, as identified by the same AID in the vetting credential, is also entitled to use a given phone number for outbound calls. Must be issued by the rangeholder that sold this right to the legal entity. ## Brand credential Also step 5 in the diagram. Certifies that a given legal entity, as identified by the same AID in the identify credential, is also the owner[^2] or licensee of brand assets that may be used with a call. Issued after confirming brand rights. Any number of brand assets may be attested — anything representable using the VCard spec ([RFC 6530](https://www.rfc-editor.org/rfc/rfc6350)) — but the most important for our project are a service name and a logo. ## Settlement credential Also step 5 in the diagram. Proves that the calling organization has contractual agreements with someone that will guarantee that the terminating service provider gets paid for the call. ## Other credential types Also step 5 in the diagram. Any number of additional credential types could be added. For example, if an AI is making an outbound call, we could add a credential that proves that the AI uses a particular model and operates with specific safety guardrails. If, on the other hand, a human is making the call, we could add a proof-of-personhood credential to guarantee that no AI is involved. ## Delegated signer credential Implicit part of step 6 in the diagram. This is issued by an [accountable party](/glossary#accountable-party-ap) (an enterprise), to a high-speed signing service under the control of the [originating party](/glossary#originating-party-op) that creates their VVP-enabled SIP INVITEs. This credential type is mostly invisible in our project, because it is automatically created when the enterprise chooses their UCaaS provider and finalizes their dossier. However, it plays an important logical role in the overall strategy, because it justifies a belief that the signer of the Identity header in the SIP INVITE is actually a party that the enterprise intends to emit verifiable voice traffic on their behalf. (The party that signs the Identity header is identified by the kid field inside that header, and must have a delegated signer credential in the associated dossier.) ## Dossier A dossier is like an affidavit. It is signed by an [accountable party](/glossary#accountable-party-ap) (an enterprise). It lists all the pieces of evidence that the enterprise wants to associate with its reputation when making outbound calls — the other credential types listed above. The VVP Identity header is a JWT that contains a claim (a field) called evd. This is a URL that tells any verifier how to fetch and validate the dossier. [^1]: In casual speech, we often give examples of "enterprise" that are much looser than a legal entity. For example, we say "Coca Cola" without specifying whether we mean [Coca Cola HBC Schweiz AG](https://search.gleif.org/#/record/549300DVT3H44EQLQY73), [Compagnie Rafraîchissements Coca-Cola Canada](https://search.gleif.org/#/record/549300FD0ELR6PSTM595), or something different. In order to hold parties legally accountable, we need to precisely identify the legal entity. [^2]: This credential is separate from the identity credential for a legal entity because there is a many-to-many relationship between legal entities and brands. Dozens of legal entities all have the right to use the "Coca Cola" brand, and many of them also have the right to use the "Sprite" and "Fanta" brands as well. # Credential Structure Participants in our project do not need a deep understanding of credential structure. However, we provide this information to help with debugging and exploration. When an issuer issues a credential, they do it either by manually interacting with a UI on their [integration agent](/glossary#integration-agent), or by calling APIs that their integration agent exposes. Either way, the agent populates a JSON data structure, hashes it, and then digitally signs the hash. The issuer's signature is not stored within or beside the data structure, but is instead reported to witnesses (lightweight web servers, analogous to bind servers in DNS, that testify to the public about what the issuer has done). Issuance automatically gives a copy of the credential to the holder, and notifies the world about what you've done. ### Sample All the credentials we'll be using are stored in [ACDC format](/glossary#acdc). Basically, they are JSON with some attached base64-encoded binary data; you can handle them as text files and inspect them in any convenient text editor. Here is what an actual credential (in this case, a vLEI with a couple text fields shortened by ellipses, and a binary attachment at the end) looks like: 
{
  "v":"ACDC10JSON0005c8_",
  "d":"EIiGTpV9qNIUeyF-vg7FI-E-LfJmwWzn1bDhgMMNggwm",
  "i":"ED88Jn6CnWpNbSYz6vp9DOSpJH2_Di5MSwWTf1l34JJm",
  "ri":"EKfi58Jiv-NVqr6GOrxgxzhrE5RsDaH4QNwv9rCyZCwZ",
  "s":"ENPXp1vQzRF6JwIuS-mp2U8Uf1MoADoP_GqQ62VsDZWY",
  "a":{
    "d":"EOLRvvUtC4Rhf81jXehqTUZGMjvDc_44EXqQKjb5N-7C",
    "i":"EKXZ8mKY8wL7kFq-WsJX0t6TaLkDFR3aP_-xO7NNMvb2",
    "dt":"2025-08-12T08:41:29.626000+00:00",
    "LEI":"50670047U83746F70E20"
  },
  "e":{
    "d":"EEyVJC9yZKpbIC-LcDhmlS8YhrjD4VIUBZUOibohGXit",
    "qvi":{
      "n":"EMatUqz_u9BizxwOc3JishC4MyXfiWzQadDpgCBA6X9n",
      "s":"EBfdlu8R27Fbx-ehrqwImnK-8Cm79sqbAQ4MmvEAYqao"
    }
  },
  "r":{
    "d":"EGZ97EjPSINR-O-KHDN_uw4fdrTxeuRXrqT5ZHHQJujQ",
    "usageDisclaimer":{"l":"Usage of a valid, unexpired, and non -revoked..."},
    "issuanceDisclaimer":{"l":"All information..."}
  }
}-IABEI iGTpV9qNIUeyF-vg7FI-E-LfJmwWzn1bDhgMMNggwm0AAAAAAAAAAAAAAAAAAAAAAAEIBpniUi5yXEsebs1nJShMxvkbLyy4wN6v0hgBBpl0Sl
### Fields Schemas for ACDCs follow the [JSON Schema](https://json-schema.org/) standard. The unique fields in each schema type are inside the a object that lives at the root of the data structure, on the 4th line above. Other fields at the root of the data structure, that are common to all schemas, include: v (required) Contains a version statement. d (required) Contains the SAID (CESR-encoded Blake3 hash) of the ACDC. (Nested d fields contain SAIDs of nested JSON objects. These are used for graduated disclosure to accomplish some privacy goals, and they become important in caching as well.) i (required) In the outermost structure, contains the AID of an issuer. Inside a, contains the AID of the issuee. ri (optional) Identifies a registry that tracks revocations that might include one for this credential. s (required) Contains the SAID of a schema to which the associated ACDC conforms. a (required) Contains additional attributes for this specific ACDC, as defined by its schema. dt (optional) Contains the date when the issuer claims to have issued the ACDC. This data will correspond closely with a timestamp saved in the issuer's KEL, at the point where the signature on the ACDC was signed and anchored there. The ordering of the signature in the KEL, relative to other key state events, is what is definitive here; the timestamp itself should be viewed more as a hint. e (optional) Contains edges (in the computer science data graph sense) that connect this ACDC to other data upon which it depends. r (optional) Contains one or more rules that govern the use of the ACDC. Holding the credential requires a cryptographically nonrepudiable admit action with a wallet, and therefore proves that the holder agreed to these terms and conditions. # Comparing to SHAKEN VVP (the protcol used by Open Verifiable Calling) is compatible with SHAKEN. It was not created to replace SHAKEN, but to provide broader and more robust evidence as input to OSP attestations in SHAKEN, and to allow security guarantees to extend across the jurisdictional boundaries that limit where SHAKEN is used. VVP is also capable of bridging between VOIP and other important contexts, such as RCS/BCID, SMS, web meetings, social media, email, vCon, and more. A VVP dossier and a single vetting process can generate evidence for any or all of them. Both SHAKEN and VVP use RFC 8225-compatible STIR PASSporTs. Per the SIP and STIR RFCs, a single call may contain `Identity` headers of both types at the same time, which means that the mechanisms can freely overlap or be used together. A call may also begin its route outside a SHAKEN jurisdiction, protected by VVP data, and then transition into SHAKEN mode (or combined VVP and SHAKEN mode) when nodes on the route require it. It is not possible to go the other way (SHAKEN → VVP), because SHAKEN passports lack some information that VVP requires. |


| SHAKEN | VVP | | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | legal and geo application | Wherever a jurisdiction specifies a governance process and a set of certificate authorities to trust. | Global | | regulatory compliance | Required in US, Canada, Brazil, France. | May satisfy many national regulators, but not required anywhere | | standards | Uses STIR standard with several national variants that are also formally standardized. | Uses STIR standard. No need for national variants. VVP is an [RFC draft](https://datatracker.ietf.org/doc/draft-hardman-verifiable-voice-protocol/); dossier is a a [draft standard at Trust Over IP Foundation](https://trustoverip.github.io/kswg-dossier-specification/). | | scope of evidence | Commitment by OSP to an opinion about reliability of caller's CLID. |

  1. Globally recognized identity of legal entity that's accountable for the call
  2. Ownership or license for that legal entity to use brand assets
  3. Call intent
  4. Right of legal entity to use telephone number
  5. Relationship between legal entity and a BPO that proxies them
  6. Signing authority delegated from legal entity to their OSP
  7. Certifications, licenses, or accreditations of the caller
  8. Certifications or accreditations of each issuer of evidence, tracing back to global roots of trust like GLEIF or national regulatory authorities
  9. Involvement (or lack of involvement) of an AI agent in the communication
  10. Settlement details
  11. Identity, qualifications, and authorizations of the specific staff member making a call on behalf of the responsible organization
  12. Optionally, the same attributes about the callee (instead or in addition)
  13. Historical audit trail
| | timing | Can only be evaluated in the present moment, not in a historical audit trail. | Can be evaluated forever, with respect to the moment in time when the call occurred. | | size of passport | 200-300 bytes | 200-300 bytes | | centralization | Certification, registry, and governance of certificate authorities; certificate revocation lists | none | | lifespan | CA certs replaced every 3 months (SHAKEN extensions that call for delegated certs would be more frequent) | permanent — no replacement or reissuance needed | | infrastructure support | any SIP route or node that preserves Identity headers is already compatible; out-of-band can bridge non-SIP; TSPs must verify | any SIP route or node that preserves Identity headers is already compatible; out-of-band can bridge non-SIP; anybody can verify, including handsets | # Comparing to RCD VVP (the protocol used by Open Verifiable Calling) is compatible with RCD. It was not created to replace or supplant RCD (Rich Call Data), but to provide broader and more durable evidence about caller and callee identity, authorization, and accountability. VVP can produce evidence that justifies an RCD-branded call passport, and can operate independently or alongside RCD-based solutions. It is designed to extend trust across jurisdictions and ecosystems where RCD is not yet deployed, and to add verifiability for non-brand-related questions such as the use of agents, call centers, or AI participants. Both RCD and VVP can coexist in SIP signaling. A single call may include both an RCD PASSporT and a VVP PASSporT in the same SIP INVITE. (In fact, it may include a SHAKEN PASSporT as well. See [Comparing to SHAKEN](/comparing-to-shaken).) RCD focuses on consumer-facing display of brand within contexts where some other mechanism provides assurance of the caller's right to use the telephone number (e.g., SHAKEN). VVP provides foundational, cryptographically verifiable evidence that is standalone, and that can strengthen or justify RCD branding claims. A call may originate in a VVP-only environment and later traverse into an RCD/SHAKEN jurisdiction, with VVP data supplying the trust basis for an RCD passport. However, an RCD-only call cannot be upgraded to VVP downstream, because RCD’s evidence scope is narrower. | **Aspect** | **RCD** | **VVP** | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Primary Purpose** | Building on a CLID assurance mechanism like SHAKEN, enhance consumer recognition and trust by displaying verified brand and intent information (logo, name, call reason). | Provide independent, cryptographically verifiable evidence of identity, authority, and accountability for any caller or callee. | | **Underlying Technology** | In-band SIP signaling when caller identy already has an "A" attestation in SHAKEN. (Technically, can be used without SHAKEN, but this enables some fraud scenarios.) | Uses STIR-compatible PASSporTs with evidence of many facts including identity and brand; no dependence on SHAKEN or additional brand vetting. | | **Scope of Evidence** | Brand assets: name, logo, color scheme, and call intent. |

  1. Globally recognized identity of legal entity that's accountable for the call
  2. Ownership or license for that legal entity to use brand assets: name, logo, color scheme.
  3. Call intent
  4. Right of legal entity to use telephone number
  5. Relationship between legal entity and a BPO that proxies them
  6. Signing authority delegated from legal entity to their OSP
  7. Certifications, licenses, or accreditations of the caller
  8. Certifications or accreditations of each issuer of evidence, tracing back to global roots of trust like GLEIF or national regulatory authorities
  9. Involvement (or lack of involvement) of an AI agent in the communication
  10. Settlement details
  11. Identity, qualifications, and authorizations of the specific staff member making a call on behalf of the responsible organization
  12. Optionally, the same attributes about the callee (instead or in addition)
  13. Historical audit trail
| | **Verification Direction** | Caller → Callee (unidirectional) | Bidirectional (caller ↔ callee) | | **Timing** | Evaluated in real time only. | Can be verified retroactively, preserving a permanent audit trail. | | **Governance and Jurisdiction** | Depends on national STIR/SHAKEN governance; primarily domestic use. | Global; independent of jurisdiction; interoperable across industries. | | **Integration with SHAKEN** | Requires “A attestation” under STIR/SHAKEN. | Can justify “A attestation” or generate RCD passports from its evidence. | | **Evidence Persistence** | Short-lived; limited to the call moment. | Long-lived; dossiers and credentials are reusable and cacheable. | | **Centralization** | Relies on national or carrier-based certificate authorities. | Decentralized; no registry or central CA required. | | **Use Cases** | Brand recognition, marketing, and anti-spoofing for enterprises. | Broader assurance: cross-border compliance, AI involvement, regulated sectors, or identity interoperability with web/email/RCS. | In short, RCD focuses on improving call presentation and consumer confidence in specific telephony contexts where another mechanism like SHAKEN is also assumed to exist, while VVP generalizes verifiable identity and evidence to any communication or jurisdiction, making it the foundation upon which mechanisms like RCD can safely rest. # SIP Response Codes Provenant's SIP redirect servers for signing and verification both define 5 standard VVP call routing outcomes for infrastructure that handles calls. They use numeric SIP response codes (e.g., 302, 307, 603, etc.) to distinguish these outcomes. Each outcome has a standard response code, but the numbers can be overridden by caller policy to meet the needs of different SBCs. SIP status lines in responses from SIP redirect services include the numeric code, plus a label for one of these 5 outcomes, and then a hex encoding of a 32-bit [reason code](/glossary#reason-code): `SIP/2.0 306 branded 0xReason` The reason code at the end is NOT for processing during routing, but rather to snapshot evidence state for recording in logs, for troubleshooting by developers, etc. It can be ignored or omitted by entities that don't wish to use it. All routing decisions are made by looking at the SIP status code. The 5 standard outcomes are: 1. **branded**: Call should be connected. Brand and CLI should be displayed. Brand attributes, legal identity of caller, TN and its RTU, and delegated signing authority were verified and remain verifiable everywhere. Default SIP response code for this outcome: [`306`](https://en.wikipedia.org/wiki/List_of_SIP_response_codes#3xx%E2%80%94Redirection_Responses). (A custom redirect code that says to continue routing with brand.) 2. **accountable**: Brand should be suppressed, but CLI should be displayed. Brand attributes are omitted from the evidence, but the other evidence was verified and remains verifiable, and the caller is therefore accountable to regulators and service providers even if the handset doesn't display the brand. Default SIP response code: [`307`](https://en.wikipedia.org/wiki/List_of_SIP_response_codes#3xx%E2%80%94Redirection_Responses). (A custom redirect code that says to continue routing without brand.) 3. **unknowable**: CLI should be suppressed, ideally with a message that says "Caller identity and number withheld" or similar. Dipping CNAM is strongly discouraged, as it would constitute a guess that could invite undeserved trust. No caller attributes are verifiable, so the caller suppressed the VVP mechanism and made no claim about such attributes. This is not an error condition, just an honest acknowledgement that what's known about the caller is near zero and guesses shouldn't be trusted to move the needle. Default SIP response code: [`302`](https://en.wikipedia.org/wiki/List_of_SIP_response_codes#302) (because existing, unsigned traffic needs this outcome and should trigger a no-op, "keep going but I've nothing to say" response to the verifier). 4. **dangerous**: Call should be rejected. The evidence is definitely broken in ways that are unreasonable — malformed data, missing or invalid signature, a signature from someone who shouldn't be signing, or a dossier that doesn't cover the orig TN. Innocent VVP software should never emit (sign) calls with dangerous evidence. (If a service provider connects the call anyway, brand and CLI must be suppressed, and a warning should be displayed; something like "Caller is dangerous, either due to fraud or misconfigured software.") Default SIP response code: [`608`](https://en.wikipedia.org/wiki/List_of_SIP_response_codes#608) 5. **policy needed**: This is an intermediate rather than a final outcome. It signals that evidence is well formed and complete, but some of it has expired or been revoked since it was created; whether it still proves enough to satisfy a verifier is therefore a subjective question. The specifics are described in the reason code. Each verifier should configure a policy to decide how to react to particular reason codes; until they do so, the call should be rejected (response code [`608`](https://en.wikipedia.org/wiki/List_of_SIP_response_codes#608), reason label "policy needed"; details in code). # About Replay Attacks Replay attacks attempt to reuse valid evidence into a new context. VVP offers best-in-class protections against attacks like these. ### Protection 1: timing STIR passports are JWTs that carry a signature, a timestamp (the `iat` field), and an expiration (the `exp` field). VVP requires that these values in the STIR passport be managed carefully to minimize risk from replays. Before a VVP passport is signed, a current timestamp is generated and inserted into the passport's `iat` claim. An expiration date is also generated and inserted into the `exp` claim. Valid calls must take place on or after `iat`, but before `exp` — so the paired values establish a validity window. Any attempts to replay a passport must take place within this window, or they are rejected out of hand. STIR suggests small validity windows, but does not recommend specific values or enforce further constraints. RCD and BCID passports leave this validity window equally unspecified. SHAKEN becomes more explicit about what values might be good but still does not enforce. VVP recommends 15 seconds — just long enough for a SIP INVITE to be routed and trigger the handset to ring — and requires that the validity window not exceed 60 seconds. ### Protection 2: phone numbers STIR passports (including VVP) also contain `orig` and `dest` phone numbers. Besides creating a validity window, signing a STIR passport also commits the caller to making a call from `orig` to `dest` , not between other phone numbers. However, SIP routing doesn't use `orig` and `dest`; the originating number in SIP is stored in a `From` header on the SIP INVITE, and the destination number is stored in a `To` header. STIR does not require `From` and `orig` to correspond, or `To` and `dest` to correspond. However, VVP closes this vulnerability (as does SHAKEN); an attacker cannot replay an intercepted VVP SIP INVITE unless they are willing to route the call between the same `orig` and `dest` as the legitimate call. ### Protection 3: call reason Like RCD, VVP allows a call to carry branded information. An attacker cannot change the call reason when replaying a legitimate VVP passport. If the original call had no call reason, the replayed call must also have no call reason. If the original call had reason X, the replayed call must also have reason X. This further narrows the possible scope of an attack. ### Additional protections A determined and unusually capable attacker might still have an exploitable vulnerability, IFF: * They find all of the other constraints acceptable. That is, they're attempting to conduct fraud within a 15-second validity window, using exactly the same two phone numbers, with the same call reason. * They can prevent the legitimate call from ringing (so a replay attempt would be perceived by the callee as the only incoming call, instead of a second, redundant call). * They can intercept SIP responses from the callee, inserting themselves into the streaming media handshake. If callers and callees (or service providers for these parties) correlate CDRs, they will eventually detect a simple hijack of the streaming media, because callers will think calls ended quickly, whereas callees will think it continued. Such comparison is made more likely by VVP's ability to carry settlement evidence, because settlement requires agreement about whether a call connected.\ \ But this does not address the risk of replays used to construct a persistent MITM instead of a one-time hijack on the streaming channel. If the party conducting the replay attack can lurk in the streaming channel, but allow correct media to flow to correct parties most of the time, VVP has one more tool at its disposal.\ \ The verified party in a VVP conversation (often the caller, possibly the callee, or possibly both) has an AID and an agent that's capable of communicating on behalf of the AID's controlling party. This constitutes an out-of-band channel. It can be used to compare each party's views of ongoing communication. By periodically exchanging hashes of media packets, the parties can detect any tampering with media. If they detect a problem, or if they want to eliminate any risk of MITM eavesdropping, they can switch to a more secure channel like the one provided by [Trust Spanning Protocol](https://trustoverip.github.io/tswg-tsp-specification/) in [SPAC](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/SPAC_Message.md) mode.