]> Provenant, Inc

daniel.hardman@gmail.com

voip telecom telco telephone number vetting KYC Verifiable Voice Protocol (VVP) authenticates and authorizes organizations and individuals making and/or receiving telephone calls. This eliminates trust gaps that malicious parties exploit. Like related technologies such as SHAKEN, RCD, and BCID, VVP uses STIR to bind cryptographic evidence to a SIP INVITE, and verify this evidence downstream. VVP can also let evidence flow the other way, proving things about the callee. VVP builds from different technical and governance assumptions than alternatives, and uses richer, stronger evidence. This allows VVP to cross jurisdictional boundaries easily and robustly. It also makes VVP simpler, more decentralized, cheaper to deploy and maintain, more private, more scalable, and higher assurance. Because it is easier to adopt, VVP can plug gaps or build bridges between other approaches, functioning as glue in hybrid ecosystems. For example, it may justify an A attestation in SHAKEN, or an RCD passport for branded calling, when a call originates outside SHAKEN or RCD ecosystems. VVP also works well as a standalone mechanism, independent of other solutions. An extra benefit is that VVP enables two-way evidence sharing with verifiable text and chat (e.g., RCS and vCon), as well as with other industry verticals that need verifiability in non-telco contexts. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction When we get phone calls, we want to know who's calling, and why. Often, we want similar information when we make calls as well, to confirm that we've truly reached who we intend. Strangers abuse expectations in either direction, far too often. Regulators have mandated protections, and industry has responded. However, existing solutions have several drawbacks:

• Assurance of callers derives only from the signatures of originating service providers, with no independently verifiable proof of what they assert.
• Proving the identity of the callee is not supported.
• Each jurisdiction has its own governance and its own set of signers. Sharing information across boundaries is fraught with logistical and regulatory problems.
• Deployment and maintenance costs are high.
• Market complexities such as the presence of aggregators, wholesalers, and call centers that proxy a brand are difficult to model safely.
• What might work for enterprises offers few benefits and many drawbacks for individual callers.

VVP solves these problems by applying crucial innovations in evidence scope, evidence format, and vetting mechanisms. These innovations profoundly upgrade what is provable in an ecosystem, as well as what is cacheable and what must be centralized. However, they have only subtle effects on the content of a STIR PASSporT, so they are explored outside this spec.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Overview Fundamentally, VVP requires identified parties (callers and/or callees) to curate a dossier () of stable evidence that proves things about them. This is done once or occasionally, in advance, as a configuration precondition. Then, for each call, participants decide whether to share this evidence. Callers share evidence by creating an ephemeral STIR-compatible VVP PASSporT () that cites () their preconfigured dossier. This passport travels along the delivery route as an Identity header in a SIP INVITE. Callees share evidence by sending an analogous passport back to the caller, preferably as an Identity header in a mid-dialog request (), and optionally as an attribute line in the SDP body of their SIP response. This passes a signed citation to their dossier in the other direction. Verifiers anywhere along the route check the citation(s) and corresponding dossier(s), including realtime revocation status, to make decisions (). A VVP call may carry assurance in either or both directions. Compliant implementations may choose to support only assurance about the caller, only assurance about the callee, or both.

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.

Callee For a given phone call, a callee receives the SIP INVITE. Typically one callee is targeted, but multiparty SIP flows allow INVITEs to multiple callees, either directly or via a conference server (see and ). 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.

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 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, the precise cryptographic identity of an OP should be narrower. 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.

Accountable Party For a given call, the accountable party (AP) is the organization or individual 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.

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.

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.

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 , . Therefore, we leave the question of curation to separate document (for example, ).

Citing

Citing the AP's dossier A VVP call that makes the caller verifiable begins when the OP () generates a new VVP passport that complies with STIR requirements. In its compact-serialized JWT form, this passport is then passed as an Identity header in a SIP INVITE . 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.

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.

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: The semantics of the fields are:

• alg (required) MUST be either "EdDSA" (), or (for post-quantum) "FN-DSA-512" (). Standardizing on best-in-class schemes prevents weaker cryptography from degrading the security guarantees of the ecosystem. The RSA, HMAC, and ES256 algorithms MUST NOT be used. (EdDSA is motivated by compatibility with the vLEI and its associated ACDC ecosystem, which currently uses the Montgomery-to-Edwards transformation.)
• typ (required) Per , MUST be "passport".
• ppt (required) Per , MUST identify the specific PASSporT type -- in this case, "vvp".
• kid (required) MUST be the OOBI of an AID () controlled by the OP (). 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 (). 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 single-sig 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 (), for interoperability reasons. It MUST also satisfy one additional constraint, which is that only one phone number is allowed. Despite 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 or 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 .
• goal (optional) A machine-readable, localizable goal code, as described informally by . 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, ) 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 ).
• 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 15 seconds (just long enough for an INVITE to be routed and trigger ringing on a handset), and MUST NOT exceed 60 seconds.
• jti (optional) Follows standard JWT semantics.

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 () on a request that it initiates within the dialog, following the connected-identity model of . Normally this is an UPDATE () sent after the callee has sent its 200 OK and received the ACK. Per , 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 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 ). 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.)

Verifying

Verifying the caller

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 () 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 (), 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 () -- or, if OP is not equal to AP and OP is using their own number, the OP () -- 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, in certain geos, to certain destinations (e.g., country codes or number prefixes, checked against dest), or at no more than a certain rate, check those attributes of the call. (A rate constraint cannot be evaluated from a single call; it is checkable only by a verifier that observes many calls signed by the same kid, and by the OP itself before signing. See .)

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 () 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.

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

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 (), 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.

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 (), 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 (). 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.

Security Considerations Complying with a specification may forestall certain easy-to-anticipate attacks. However, it does not mean that vulnerabilities don't exist, or that they won't be exploited. The overall assurance of VVP requires reasonable vigilance. Given that a major objective of VVP is to ensure security, implementers are strongly counseled to understand the underlying principles, the assumptions, and the ways that choices by their own or other implementations could introduce risk. Like most cryptographic mechanisms, VVP depends on the foundational assumption that human stakeholders will manage cryptographic keys carefully. VVP enforces this assumption more thoroughly than many existing solutions:

• Parties that issue credentials MUST be identified with AIDs () that use witnesses. This guarantees a non-repudiable, publicly accessible audit log of how their key state evolves, and it makes key rotation easy. It also offers compromise and duplicity detection. Via prerotation, it enables recovery from key compromise. AIDs can be upgraded to use quantum-proof signing algorithms without changing the identifier.
• Parties that issue credentials MUST do so using ACDCs () signed by their AID rather than a raw key. This makes evidence revocable. It also makes it stable across key rotation, and prevents retrograde attacks by allowing verifiers to map an issuance or revocation event to an unambiguous key state in the KEL ().
• Parties that issue credentials SHOULD employ threshold-based multi-signature schemes. This enhances security by distributing signing authority across multiple key holders, reducing the risk of single-point compromise. Threshold-based signatures ensure that no single key compromise undermines the system's integrity while enabling controlled key recovery and rotation without disrupting credential validity.

Nonetheless, it is still possible to make choices that weaken the security posture of the ecosystem, including at least the following:

• Sharing keys or controlling access to them carelessly
• Issuing credentials with a flimsy basis for trust
• Delegating authority to untrustworthy parties
• Delegating authority without adequate constraints
• Failing to fully verify evidence

Generally understood best practices in cybersecurity will avoid many of these problems. In addition, the following policies that are specific to VVP are strongly recommended:

1. Passports SHOULD have an aggressive timeout (e.g., 30 seconds). Signatures on passports are not anchored in a KEL, and must therefore be evaluated for age with respect to the time they were received. Overly old passports could be a replay attack (a purported second call with the same orig and dest numbers, using the same backing evidence, soon after the first.)
2. Witnesses (which MUST be used) SHOULD be used in such a way that high availability is guaranteed, and in such a way that duplicity by the controller of an AID is detected. (Verifiers will be able to see the witness policy of each AID controller, and SHOULD decide for themselves whether the party is reliable, depending on what they observe.)
3. Revocations SHOULD be timely, and the timeliness guarantees of issuers SHOULD be published.
4. Watchers SHOULD propagate events to local caches with a low latency, and MUST provide information that allows verifiers to decide whether that latency meets their freshness requirements.

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 () 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 over the SDP attribute for the same reason.

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 (), 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.

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.

IANA Considerations This document defines a new SDP session-level attribute: Attribute name: callee-passport Long-form description: Contains a STIR-compatible passport that references a dossier of evidence about the callee's identity, brand, and related attributes. Used in 200 OK and/or 180 Ringing responses. Type of attribute: session-level Subject to charset: No Reference: This document This specification also depends on OOBIs () being served as web resources with IANA content type application/cesr.

References Normative References This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] This specification defines the new UPDATE method for the Session Initiation Protocol (SIP). UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but can be sent before the initial INVITE has completed. This makes it very useful for updating session parameters within early dialogs. This document defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI). Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components. [STANDARDS-TRACK] This document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). [STANDARDS-TRACK] The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams to User Agents in order to deliver requests. However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars, and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep-alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its registrar. [STANDARDS-TRACK] This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer. This document obsoletes RFC 4474. This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIP Forum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network. This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. Trust Over IP Foundation Trust Over IP Foundation Trust Over IP Foundation In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References NIST The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi-party conferencing. This memo provides information for the Internet community. This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK] JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This document specifies a usage of the SIP Call-Info header field that incorporates Rich Call Data (RCD) associated with the identity of the originating party in order to provide to the terminating party a description of the caller (including details about the reason for the session). RCD includes information about the caller beyond the telephone number (such as a calling name, logo, photo, or jCard object representing the caller), which can help the called party decide how to handle the session request. This document defines three new parameters 'call-reason', 'verified', and 'integrity' for the SIP Call-Info header field and also a new token ("jcard") for the 'purpose' parameter of the Call-Info header field. It also provides guidance on the use of the Call-Info 'purpose' parameter token, "icon". CTIA

Acknowledgments Much of the cybersecurity infrastructure used by VVP depends on KERI, which was invented by Sam Smith, and first implemented by Sam plus Phil Feairheller, Kevin Griffin, and other technical staff at GLEIF. Thanks to logistical support from Trust Over IP and the Linux Foundation, and to a diverse community of technical experts in those communities and in the Web of Trust group. Techniques that apply KERI to telco use cases were developed by Daniel Hardman, Randy Warshaw, and Ruth Choueka, with additional contributions from Dmitrii Tychinin, Yaroslav Lazarev, Arshdeep Singh, and many other staff members at Provenant, Inc. Thanks as well to Ed Eykholt for multiple editorial improvements.

Contributors

victor@scarpprotocol.com

Feedback on SDP fragility, OOBI dereferencing, and toll fraud through compromised originators.