Verifiable Voice Protocol

3.1.1. Allocation Holder

An allocation holder controls how a phone number is used, in the eyes of a regulator. Enterprises and consumers that make and receive calls with phone numbers they legitimately control are the most obvious category of allocation holders, and are called direct telephone number users (TNUs). Range holders hold allocations for numbers that have not yet been assigned; they don't make or receive calls with these numbers, and are therefore not TNUs, but they are still allocation holders.¶

It is possible for an ecosystem to include other parties as allocation holders (e.g., wholesalers, aggregators). However, many regulators dislike this outcome, and prefer that such parties broker allocations without actually holding the allocations directly.¶

3.1.2. Callee

For a given phone call, a callee (also referred to as a terminating party or TP) receives the call. Typically one callee is targeted, but multiparty SIP flows allow INVITEs to multiple callees, either directly or via a conference server (see [RFC4353] and [RFC4575]). A callee can be an individual consumer or an organization. The direct service provider of the callee is the terminating service provider (TSP). In many use cases for VVP, callers attempt to prove things to callees, and callees and their service providers use VVP primarily with a verifier mindset. However, enterprises or call centers that accept inbound calls from individuals may want assurance to flow the other direction; hence, VVP supports optional evidence about callees as well.¶

3.1.3. Originating Party

An originating party (OP) controls the first session border controller (SBC) that processes an outbound call, and therefore builds the VVP passport that cites evidence about the caller.¶

It may be tempting to equate the OP with "the caller", and in some perspectives this could be true. However, this simple equivalence lacks nuance and doesn't always hold. In a VVP context, it is more accurate to say that the OP creates a SIP INVITE [RFC3261] with explicit, provable authorization from the party accountable for calls on the originating phone number. The OP originates the VVP protocol, but not always the call on the handset.¶

It may also be tempting to associate the OP with an organizational identity like "Company X". While this is not wrong, and is in fact used in high-level descriptions in this specification, in its most careful definition, the cryptographic identity of an OP should be more narrow. It typically corresponds to a single service operated by an IT department within (or outsourced but operating at the behest of) Company X, rather than to Company X generically. This narrowness limits cybersecurity risk, because a single service operated by Company X needs far fewer privileges than the company as a whole. Failing to narrow identity appropriately creates vulnerabilities in some alternative approaches. The evidence securing VVP MUST therefore prove a valid relationship between the OP's narrow identity and the broader legal entities that stakeholders more naturally assume and understand.¶

The service provider associated with an OP is called the originating service provider (OSP). For a given phone call, there may be complexity between the hardware that begins a call and the SBC of the OP -- and there may also be many layers, boundaries, and transitions between OSP and TSP.¶

3.1.4. Accountable Party

For a given call, the accountable party (AP) is the organization or individual (the TNU) that has the right to use the originating phone number, according to the regulator of that number. When a callee asks, "Who's calling?", they have little interest in the technicalities of the OP, and it is almost always the AP that they want to identify. The AP is accountable for the call, and thus "the caller", as far as the regulator and the callee are concerned.¶

APs can operate their own SBCs and therefore be their own OPs. However, APs can also use a UCaaS provider that makes the AP-OP relationship indirect. Going further, a business can hire a call center, and delegate to the call center the right to use its phone number. In such a case, the business is the AP, but the call center is the OP that makes calls on its behalf. None of these complexities alter the fact that, from the callee's perspective, the AP is "the caller". The callee chooses to answer or not, based on their desire to interact with the AP. If the callee's trust is abused, the regulator and the callee both want to hold the AP accountable.¶

In order to verify a caller, VVP requires an AP to prepare a dossier of evidence that documents a basis for imposing this accountability on them. Only the owner of a given dossier can prove they intend to initiate a VVP call that cites their dossier. Therefore, if a verifier confirms that a particular call properly matches its dossier, the verifier is justified in considering the owner of that dossier the AP for the call. Otherwise, someone is committing fraud. Accountability, and the basis for it, are both unambiguous.¶

3.1.5. Verified Party

A verified party (VP) is a party that uses VVP to prove assertions about itself and its delegation decisions. When VVP provides assurance about callers, the AP is a VP. When VVP provides assurance about callees, the callee is a VP. Some characteristics of proxies, delegates, and service providers may be proved by a dossier, but these parties are not VPs. They don't create dossiers, and dossiers are not focused on them.¶

3.1.6. Verifier

A verifier is a party that wants to know who's calling or being called, and maybe why -- and that evaluates the answers to these questions by examining formal evidence. Callees, callers, TSPs, OSPs, government regulators, law enforcement doing lawful intercept, auditors, and even APs or OPs can be verifiers. Each may need to see different views of the evidence about a particular phone call, and it may be impossible to comply with various regulations unless these views are kept distinct -- yet each wants similar and compatible assurance.¶

In addition to checking the validity of cryptographic evidence, the verifier role in VVP MAY also consider how that evidence matches business rules and external conditions. For example, a verifier can begin its analysis by deciding whether Call Center Y has the right, in the abstract, to make or receive calls on behalf of Organization X using a given phone number. However, VVP evidence allows a verifier to go further: it can also consider whether Y is allowed to exercise this right at the particular time of day when a call occurs, or in a particular jurisdiction, given the business purpose asserted in a particular call.¶

4.1.1. Questions answered by an AP's passport

The passport directly answers at least the following questions:¶

• What is the cryptographic identity of the OP?¶

• How can a verifier determine the OP's key state at the time the passport was created?¶

• How can a verifier identify and fetch more evidence that connects the OP to the asserted AP?¶

• What brand attributes are asserted to accompany the call?¶

The first two answers come from the kid header. The third answer is communicated in the required evd claim. The fourth answer is communicated in the optional card and goal claims.¶

More evidence can then be fetched to indirectly answer the following additional questions:¶

• What is the legal identity of the AP?¶

• Does the AP have the right to use the originating phone number?¶

• Does the AP intend the OP to sign passports on its behalf?¶

• Does the AP have the right to use the brand attributes asserted for the call?¶

Dossiers can be further expanded to answer even more questions; such dynamic expansion of the scope of proof is compatible with but not specified by VVP.¶

4.1.2. Sample passport

An example will help. In its JSON-serialized form, a typical VVP passport for an AP (with some long CESR-encoded hashes shortened by ellipsis for readability) might look like this:¶

{
  "header": {
    "alg": "EdDSA",
    "typ": "JWT",
    "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"
  }
}

The semantics of the fields are:¶

• alg (required) MUST be "EdDSA" ([RFC8032], [FIPS186-4]). Standardizing on one scheme prevents jurisdictions with incompatible or weaker cryptography. The RSA, HMAC, and ES256 algorithms MUST NOT be used. (This choice is motivated by compatibility with the vLEI and its associated ACDC ecosystem, which depends on the Montgomery-to-Edwards transformation.)¶

• typ (required) Per [RFC8225], MUST be "passport".¶

• ppt (required) Per [RFC8225], MUST identify the specific PASSporT type -- in this case, "vvp".¶

• kid (required) MUST be the OOBI of an AID ([TOIP-KERI]) controlled by the OP (3.1.3). An OOBI is a special URL that facilitates ACDC's viral discoverability goals. It returns IANA content-type application/json+cesr, which provides some important security guarantees. The content for this particular OOBI MUST be a KEL ([TOIP-KERI]). Typically the AID in question does not identify the OP as a legal entity, but rather software running on or invoked by the SBC operated by the OP. (The AID that identifies the OP as a legal entity may be controlled by a multisig scheme and thus require multiple humans to create a signature. The AID for kid MUST be singlesig and, in the common case where it is not the legal entity AID, MUST have a delegate relationship with the legal entity AID that's proved through formal evidence.)¶

• orig (required) Although VVP does not depend on SHAKEN, the format of this field MUST conform to SHAKEN requirements ([ATIS-1000074]), for interoperability reasons. It MUST also satisfy one additional constraint, which is that only one phone number is allowed. Depite the fact that a containing SIP INVITE may allow multiple originating phone numbers, only one can be tied to evidence evaluated by verifiers.¶

• dest (required) For interoperability reasons, MUST conform to SHAKEN requirements.¶

• card (optional) Contains one or more brand attributes. These are analogous to [RCD-DRAFT] or [CTIA-BCID] data, but differ in that they MUST be justified by evidence in the dossier. Because of this strong foundation that interconnects with formal legal identity, they can be used to derive other brand evidence (e.g., an RCD passport) as needed. Individual attributes MUST conform to the VCard standard [RFC6350].¶

• goal (optional) A machine-readable, localizable goal code, as described informally by [ARIES-RFC-0519]. If present, the dossier MUST prove that the OP is authorized by the AP to initiate calls with this particular goal.¶

• call-reason (optional) A human-readable, arbitrary phrase that describes the self-asserted intent of the caller. This claim is largely redundant with goal; most calls will either omit both, or choose one or the other. Since call-reason cannot be analyzed or verified in any way, and since it may communicate in a human language that is not meaningful to the callee, use of this field is discouraged. However it is not formally deprecated. It is included in VVP to facilitate the construction of derivative RCD passports which have the property.¶

• evd (required) MUST be the OOBI of a bespoke ACDC (the dossier, [TOIP-ACDC]) that constitutes a verifiable data graph of all evidence justifying belief in the identity and authorization of the AP, the OP, and any relevant delegations. This URL can be hosted on any convenient web server, and is somewhat analogous to the x5u header in X509 contexts. See below for details.¶

• origId (optional) Follows SHAKEN semantics.¶

• iat (required) Follows standard JWT semantics (see [RFC7519]).¶

• exp (required) Follows standard JWT semantics. As this sets a window for potential replay attacks between the same two phone numbers, a recommended expiration should be 30 seconds, with a minimum of 10 seconds and a maximum of 300 seconds.¶

• jti (optional) Follows standard JWT semantics.¶

5.1.1. Algorithm

When a verifier encounters a VVP passport, they SHOULD verify by using an algorithm similar to the following. Optimizations may combine or reorder operations, but MUST achieve all of the same guarantees, in order to be compliant implementations.¶

1. Analyze the iat and exp claims to evaluate timing. Confirm that exp is greater than iat and also greater than the reference time for analysis (e.g., now), and that iat is close enough to the reference time to satisfy the verifier's tolerance for replays. (A replay attack would have to call from the same orig to the same dest with the same iat, within whatever window the verifier accepts. Thirty seconds is a recommended default value.)¶

2. Confirm that the orig, dest, and iat claims match contextual observations and other SIP metadata. That is, the passport appears aligned with what is known about the call from external sources.¶

3. Extract the kid header.¶

4. Fetch the key state for the OP 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.¶

5. Use the public key of the OP to verify that the signature on the passport is valid for that key state. On success, the verifier knows that the OP is at least making an assertion about the identity and authorizations of the AP. (When reference time is now, this is approximately the level of assurance provided by existing alternatives to VVP.)¶

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

7. 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.¶

8. If the dossier requires full validation, perform it. Validation includes checking the signature on each ACDC in the dossier's data graph against the key state of its respective issuer at the time the issuance occurred. Key state is proved by the KEL ([TOIP-KERI]), and checked against independent witnesses.¶

   Issuance is recorded explicitly in the KEL's overall event sequence, so this check does not require guesses about how to map issuance timestamps to key state events. Subsequent key rotations do not invalidate this analysis.¶

   Validation also includes comparing data structure and values against the declared schema, plus a full traversal of all chained cryptographically verifiable evidence, back to the root of trust for each artifact. The verifier MUST accept the root of trust as a valid authority on the vital question answered by each credential that depends upon it. The correct relationships among evidence artifacts MUST also be checked (e.g., proving that the issuer of one piece is the issuee of another piece).¶

9. 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. If no, check for revocations anywhere in the data graph of the dossier. Revocations are not the same as key rotations. They can be checked much more quickly than doing a full validation. Revocation checks can also be cached, possibly with a different freshness threshold than the main evidence.¶

10. Assuming that the dossier is valid and has no breakages due to revocation, confirm that the OP is authorized to sign the passport. If there is no delegation evidence, the AP and the OP MUST be identical, and the OP MUST be the issuee of the identity credential; otherwise, the OP MUST be the issuee of a delegated signing credential for which the issuer is the AP.¶

11. Extract the orig field and compare it to the TNAlloc credential cited in the dossier to confirm that the AP (3.1.4) -- or, if OP is not equal to AP and OP is using their own number, the OP (3.1.3) -- has the right to originate calls with this number.¶

12. 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.¶

13. Check any business logic. For example, if the passport includes a non-null value for the optional goal claim, confirm that the verifier is willing to accept a call with that goal. Or, if the delegated signer credential says that the OP can only call on behalf of the AP during certain hours, or in certain geos, check those attributes of the call.¶