Verifiable Voice Protocol

Verifiable Voice Protocol Provenant, Inc

daniel.hardman@gmail.com

voip telecom telco telephone number vetting KYC Verifiable Voice Protocol (VVP) authenticates and authorizes organizations and individuals making telephone calls. This eliminates trust gaps that scammers exploit. Like related technolgies such as SHAKEN, RCD, and BCID, VVP binds cryptographic evidence to a SIP INVITE, and verifies this evidence downstream. However, VVP builds from different technical and governance assumptions, and uses stronger, richer 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 than alternatives. 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. Annoying or malicious strangers abuse expectations far too often. Regulators have mandated protections, and industry has responded. However, existing solutions have several drawbacks:

Assurance derives only from the signatures of originating service providers, with no independently verifiable proof of what they assert.
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 three crucial innovations.

Evidence scope Existing solutions aim to assert variable levels of confidence about a caller's identity, plus possibly some brand attributes. These assertions rest entirely on a service provider's judgment and are testable only in the moment a call is initiated; later, they become repudiable. VVP proves more. It always proves the caller's legal identity, plus any authority that the caller has delegated to staff and service providers. It typically also proves brand attributes and right to use a phone number. If a call center is involved, it proves the constraints under which the call center operates as a representative. All VVP proof is traceable back to justifying evidence and can be evaluated in the present or the past. This guarantees accountability for all parties with a permanent, non-repudiable audit trail.

Evidence format VVP is rooted in an evidence format called authentic chained data containers (ACDCs) -- . Other forms of evidence (e.g., JWTs/STIR PASSporTs, digital signatures, and optional interoperable inputs from W3C verifiable credentials and SD-JWTs ) also contribute. However, the foundation that VVP places beneath them is unique. For a discussion of the theory behind VVP evidence, see . For more about additional evidence types, see and . Because of innovations in format, VVP evidence is easier to create and maintain, safer, and more flexible than alternative approaches. It also lasts much longer. This drastically lowers the friction to adoption.

Vetting refinements Although VVP interoperates with governance frameworks such as SHAKEN , it allows for a dramatic upgrade of at least one core component: the foundational vetting mechanism. The evidence format used by VVP is also the format used by the Verifiable Legal Entity Identifier (vLEI) standardized in . vLEIs implement a KYC approach advocated by the G20's Financial Stability Board, and overseen by the G20's Regulatory Oversight Committee. This approach follows LEI rules for KYC (), and today it's globally required in high-security, high-regulation, cross-border banking. Millions of institutions have already undergone LEI vetting, and they already use the resulting evidence of their organizational identity in day-to-day behaviors all over the world. By adopting tooling that's compatible with the vLEI ecosystem, VVP gives adopters an intriguing option: just skip the task of inventing a whole new vetting regime unique to telco, with its corresponding learning curve, costs, and legal and business adoption challenges. To be clear, VVP does not require that vLEIs be used for vetting. However, by choosing an evidence format that is high-precision and lossless enough to accommodate vLEIs, VVP lets telco ecosystems opt in, either wholly or partially (see ), to trust bases that are already adopted, and that are not limited to any particular jurisdiction or to the telco industry. It thus offers two-way, easy bridges between identity in phone calls and identity in financial, legal, technical, logistic, regulatory, web, email, and social media contexts.

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 a caller to curate () a dossier () of stable evidence that proves identity and authorization. This is done once or occasionally, in advance, as a configuration precondition. Then, for each call, an ephemeral STIR-compatible VVP PASSporT () is generated that cites () the preconfigured dossier. Verifiers check the passport and its corresponding dossier, including realtime revocation status, to make decisions ().

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.

Allocation Holder An allocation holder controls how a phone number is used, in the eyes of a regulator. Enterprises and consumers that make 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 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 as intermediaries.

Terminating Party For a given phone call, the terminating party (TP) receives the call. A TP can be an individual consumer or an organization. The direct service provider of the TP is the terminating service provider (TSP).

Originating Party An originating party (OP) controls the first session border controller (SBC) that processes a call, and therefore builds the VVP passport () that cites the evidence that authenticates and authorizes the call. It may be tempting to equate the OP with "the caller", and in some ways this perspective might reflect truth. 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, not 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 is 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 (see ). 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 (the TNU) that has the right to use the originating phone number, according to the regulator of that number. When a TP 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 TP 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 TP's perspective, the AP is "the caller". The TP chooses to answer or not, based on their desire to interact with the AP. If the TP's trust is abused, the regulator and the TP both want to hold the AP accountable. 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 (see ). 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.

Verifier A verifier is a party that wants to know who's calling, and why, and that evaluates the answers to these questions by examining formal evidence. TPs, 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 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 the jurisdiction of a particular TP, 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. This specification includes normative statements about evidence. However, curating does not occur in realtime during phone calls. Citing and verifying are the heart of VVP, and implementers will probably approach VVP from the standpoint of SIP flows , . Therefore, we defer the question of curation to . Where not-yet-explained evidence concepts are used, inline references allow easy cross-reference to formal definitions that come later.

Citing A call secured by VVP 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 dossier; see ). Safely and efficiently citing stronger evidence is one way that VVP differs from alternatives.

Questions answered by a passport The passport directly answers 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?

Sample passport An example will help. In its JSON-serialized form, a typical VVP passport (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 "EdDSA". 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 , 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 singlesig and, in the common case where it is not the legal entity AID, MUST have a delegate relationship with the legal entity AID, proved through Delegate Evidence .)
orig (required) Although VVP does not depend on SHAKEN, the format of this field MUST conform to SHAKEN requirements (), for interoperability reasons (see ). 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 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, it 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 (see ).
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 30 seconds, with a minimum of 10 seconds and a maximum of 300 seconds.
jti (optional) Follows standard JWT semantics.

For information about the signature over a passport, see .

Verifying

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

Confirm that the orig and dest fields match contextual observations and other SIP metadata. That is, the passport appears aligned with what is known about the call from external sources. This is not a cryptographic analysis.
Extract the kid field.
Fetch the key state for the OP from the OOBI in kid. Caches may be used to optimize this, as long as they meet the freshness standards of the verifier. Normally, the current key state is checked, but the OOBI returns a data stream that also allows historical analysis.
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. (This is approximately the level of assurance provided by existing alternatives to VVP.)
Extract the evd field, which references the dossier () that constitutes backing evidence.
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.
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 CVD (), 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).
Check to see whether the revocation status of the dossier and each item it depends on has been tested recently enough to satisfy the verifier's freshness standards. 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.
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 vetting credential; otherwise, the OP MUST be the issuee of a delegated signing credential for which the issuer is the AP.
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.
If the passport includes non-null values for the optional card or goal fields, extract that information and check that the brand attributes claimed for the call are justified by a brand credential () in the dossier.
Check any business logic. For example, 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.

Planning for efficiency The complete algorithm listed above 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 justify many outbound 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 (see ). 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.

Curating The evidence that's available in today's telco ecosystems resembles some of the evidence described here, in concept. However, existing evidence has gaps, and its format is fragile. It requires direct trust in the proximate issuer, and it is typically organized for discovery; both characteristics lead to large, centralized registries at a regional or national level. These registries become a trusted third party, which defeats some of the purpose of creating decentralized and independently verifiable evidence in the first place. Sharing such evidence across jurisdiction boundaries requires regulatory compatibility and bilateral agreements. Sharing at scale is impractical at best, if not illegal. How evidence is issued, propagated, quality-controlled, and referenced is therefore an important concern for this specification.

Activities The following curation activities guarantee the evidence upon which a VVP ecosystem depends.

Witnessing and watching In an ACDC-based ecosystem, issuers issue and revoke their own evidence without any calls to a centralized registry or authority. However, KERI's decentralized witness feature MUST be active. This provides an official, uniform, and high-security methodology for curating the relationship between keys and identifiers, and between identifiers and non-repudiable actions like issuing and revoking credentials. In addition, watchers MAY be used by given verifiers, to provide efficient caching, pub-sub notifications of state changes, and duplicity detection. For more about these topics, see .

Vetting identity The job of vetting legal entities (which includes APs , but also OPs ) and issuing vetting credentials () is performed by a legal entity vetter. VVP MUST have evidence of vetted identity. It places few requirements on such vetters, other than the ones already listed for vetting credentials themselves. Vetting credentials MAY expire, but this is not particularly desirable and might actually be an antipattern. ACDCs and AIDs facilitate much longer lifecycles than certificates; proactive key rotation is recommended but creates no reason to rotate evidence. However, a legal entity vetter MUST agree to revoke vetting credentials in a timely manner if the legal status of an entity changes, or if data in a vetting credential becomes invalid.

Vetting brand At the option of the AP and OP, VVP MAY prove brand attributes. When this feature is active, the job of analyzing the brand assets of a legal entity and issuing brand credentials () is performed by a brand vetter. A brand vetter MAY be a legal entity vetter, and MAY issue both types of credentials after a composite analysis. However, the credentials themselves MUST NOT use a combined schema, the credentials MUST have independent lifecycles, and the assurances associated with each credential type MUST remain independent. A brand vetter MUST verify the canonical properties of a brand, but it MUST do more than this: it MUST issue the brand credential to the AID of an issuee that is also the issuee of a vetting credential that already exists, and it MUST verify that the legal entity in the vetting credential has a right to use the brand in question. This link MUST NOT be based on mere weak evidence such as an observation that the legal entity's name and the brand name have some or all words in common, or the fact that a single person requested both credentials. Further, the brand vetter MUST agree to revoke brand credentials in a timely manner if the associated vetting credential is revoked, if the legal entity's right to use the brand changes, or if characteristics of the brand evolve.

Allocating TNs At the option of the AP and OP, VVP SHOULD prove the right to use the originating phone number. When this feature is active, regulators MUST issue TNAlloc credentials () to range holders, and range holders MUST issue them to downstream AHs in an unbroken chain that reaches telephone number users (TNUs; see ). TNUs MAY in turn issue them to a delegate such as a call center. If aggregators or other intemediaries hold an RTU in the eyes of a regulator, then intermediate TNAlloc credentials MUST be created to track that RTU as part of the chain. On the other hand, if TNUs acquire phone numbers through aggregators, but regulators do not consider aggregators to hold allocations, then aggregators MUST work with range holders to assure that the appropriate TNAlloc credentials are issued to the TNUs.

Authorizing brand proxy When VVP is used to prove brand, APs () MAY issue brand proxy credentials () to OPs (), giving them the right to use the AP's brand. Without this credential, the OP only has the right to use the AP's phone number. Decisions about whether to issue vetting and brand credentials might be driven by large databases of metadata about organizations and brands, but how such systems work is out of scope. The credentials themselves contain all necessary information, and once credentials are issued, they constitute an independent source of truth as far as VVP is concerned. No party has to return to the operators of such databases to validate anything.

Delegating signing authority An AP MUST prove, by issuing a delegated signer credential (), that the signer of its VVP passports does so with its explicit authorization. Normally the signer is automation under the control of the OP, but the issuee of the credential MAY vary at the AP's discretion. Since this credential merely documents the AP's intent to be accountable for the actions of the signer, the AP MAY choose whatever process it likes to issue it.

Revoking Revoking an ACDC is as simple as the issuer signing a revocation event and distributing it to witnesses (see ). Parties that perform a full validation of a given ACDC (see ) will automatically detect the revocation event in realtime, because they will contact one or more of these witnesses. Parties that are caching their validations MAY poll witnesses very efficiently to discover revocation events. Some witnesses may choose to offer the option of registering a callback, allowing interested parties to learn about revocations even more efficiently.

Building blocks The term "credential" has a fuzzy meaning in casual conversation. However, understanding how evidence is built from credentials in VVP requires considerably more precision. We will start from lower-level concepts.

SAID A self-addressing identifier (SAID) is the hash of a canonicalized JSON object, encoded in self-describing CESR format . The raw bytes from the digest function are left-padded to the nearest 24-bit boundary and transformed to base64url . The left-pad char from the converted left-pad byte is replaced with a code char that tells which digest function was used. An example of a SAID is E81Wmjyz5nXMCYrQqWyRLAYeKNQvYLYqMLYv_qm-qP7a, and a regex that matches all valid SAIDs is: [EFGHI][-_\w]{43}|0[DEFG][-_\w]{86}. The E prefix in the example indicates that it is a Blake3-256 hash. SAIDs are evidence that hashed data has not changed. They can also function like a reference, hyperlink, or placeholder for the data that was hashed to produce them (though they are more similar to URNs than to URLs , since they contain no location information).

Signature A digital signature over arbitrary data D constitutes evidence that the signer processed D with a signing function that took D and the signer's private key as inputs: signature = sign(D, privkey). The evidence can be verified by checking that the signature is bound to D and the public key of the signer: valid = verify(signature, D, pubkey). Assuming that the signer has not lost unique control of the private key, and that cryptography is appropriately strong, we are justified in the belief that the signer must have taken deliberate action that required seeing an unmodified D in its entirety. The assumption that a signer has control over their private keys may often be true (or at least believed, by the signer) at the time a signature is created. However, after key compromise, an attacker can create and sign evidence that purports to come from the current or an earlier time period, unless signatures are anchored to a data source that detects anachronisms. Lack of attention to this detail undermines the security of many credential schemes, including in telco. VVP explicitly addresses this concern by anchoring signatures on non-ephemeral evidence to KELs ().

AID An autonomic identifier (AID) is a short string that can be resolved to one or more cryptographic keys at a specific version of the identifier's key state. Using cryptographic keys, a party can prove it is the controller of an AID by creating digital signatures. AIDs are like W3C DIDs , and can be transformed into DIDs. The information required to resolve an AID to its cryptographic keys is communicated through a special form of URI called an out-of-band invitation (OOBI). An OOBI points to an HTTP resource that returns IANA content-type application/json+cesr; it is somewhat analogous to a combination of the kid and x5u constructs in many JWTs. AIDs and OOBIs are defined in the KERI spec . An example of an AID is EMCYrQqWyRLAYqMLYv_qm-qP7eKN81Wmjyz5nXQvYLYa. AIDs are created by calculating the hash of the identifier's initial state; since this state is typically a canonicalized JSON object, AIDs usually match the same regex as SAIDs (which are hashes of JSON). A noteworthy exception is that non-transferrable AIDs begin with B instead of E or another letter. Such AIDs hash only their public key, not a document. They are analogous to did:key values, and play a limited role in VVP. They are incapable of rotating keys or anchoring events to a KEL. They therefore lack OOBIs and can receive but not issue ACDCs. However, their virtue is that they can be created and used without a sophisticated wallet. This may make them a convenient way to identify the automation that signs passports and receives a delegated signer credential (see ). An example of an OOBI for an AID is https://agentsrus.net/oobi/EMCYrQqWyRLAYqMLYv_qm-qP7eKN81Wmjyz5nXQvYLYa/agent/EAxBDJkpA0rEjUG8vJrMdZKw8YL63r_7zYUMDrZMf1Wx. Note the same EMCY... in the AID and its OOBI. Many constructs in KERI may have OOBIs, but when OOBIs are associated with AIDs, such OOBIs always contain their associated AID as the first URL segment that matches the AID regex. They point either to an agent or a witness that provides verifiable state information for the AID. AIDs possess several security properties (e.g., self-certification, support for prerotation and multisig, support for witnesses, and cooperative delegation) that are not guaranteed by DIDs in general. Such properties are vital to some of VVP's goals for high assurance.

Signatures over SAIDs Since neither a SAID value nor the data it hashes can be changed without breaking the correspondence between them, and since the cryptographic hash function used ensures strong collision resistance, signing over a SAID is equivalent, in how it commits the signer to content and provides tamper evidence, to signing over the data that the SAID hashes. Since SAIDs can function as placeholders for JSON objects, a SAID can represent such an object in a larger data structure. And since SAIDs can function as a reference without making a claim about location, it is possible to combine these properties to achieve some indirections in evidence that are crucial in privacy and regulatory compliance. VVP uses SAIDs and digital signatures as primitive forms of evidence.

X509 certificates VVP does not depend on X509 certificates for any of its evidence. However, if deployed in a hybrid mode, it MAY be used beside alternative mechanisms that are certificate-based. In such cases, self-signed certificates that never expire might suffice to tick certificate boxes, while drastically simplifying the burden of maintaining accurate, unexpired, unrevoked views of authorizations and reflecting that knowledge in certificates. This is because deep authorization analysis flows through VVP's more rich and flexible evidence chain. See .

Passport VVP emits and verifies a STIR PASSporT that is fully compliant in all respects, except that it MAY omit the x5u header that links it to an X509 certificate (see ). The passport is a form of evidence suitable for evaluation during the brief interval when a call is being initiated, and it is carefully backed by evidence with a longer lifespan (). Conceptually, VVP's version is similar to a SHAKEN passport . It MAY also reference brand-related evidence, allowing it to play an additional role similar to the RCD passport . Neither VVP's backing evidence nor its passport depends on a certificate authority ecosystem. The passport MUST be secured by an EdDSA digital signature , , rather than the signature variants preferred by the other passport types. Instead of including granular fields in the claims of its JWT, the VVP passport cites a rich data graph of evidence by referencing the SAID of that data graph. This indirection and its implications are discussed below.

ACDCs Besides digital signatures and SAIDs, and the ephemeral passport, VVP uses long-lasting evidence in the ACDC format . This is normalized, serialized data with an associated digital signature. Unlike X509 certificates, ACDCs are bound directly to the AIDs of their issuers and issuees, not to public keys of these parties. This has a radical effect on the lifecycle of evidence, because keys can be rotated without invalidating ACDCs (see ).

KELs Unlike X509 certificates, JWTs , and W3C Verifiable Credentials , signatures over ACDC data are not contained inside the ACDC; rather, they are referenced by the ACDC and anchored in a verifiable data structure called a key event log or KEL .

X509 compared to ACDC <![CDATA[ X509 ACDC +-----------------------+ +------------------------+ | Data | | v (version) | | Version | | d (SAID of item) <---+ | | Serial Number | | i (AID of issuer) | | | Issuer: DN of issuer | | ri (status registry) | | | Validity | | s (schema) | | | Subject: DN of issuee | | a (attributes) | | | Sub PubKey Info: KeyX | | i (AID of issuee) | | | Extensions | | dt (issuance date) | | | Signature | | ...etc | | +-----------------------+ +----------------------+-+ | KEL | +---------------+ | | signed anchor | | | for SAID +------+ +---------------+ ]]> A KEL has some trust characteristics that resemble a blockchain. However, it is specific to one AID only (the AID of the issuer of the ACDC) and thus is not centralized. The KELs for two different AIDs need not (and typically do not) share any common storage or governance, and do not require coordination or administration. KELs thus suffer none of the performance and governance problems of blockchains, and incur none of blockchain's difficulties with regulatory requirements like data locality or right to be forgotten. ACDCs can be freely converted between text and binary representations, and either type of representation can also be compacted or expanded to support nuanced disclosure goals (see ). An ACDC is also uniquely identified by its SAID, which means that a SAID can take the place of a full ACDC in certain data structures and processes. None of these transformations invalidate the associated digital signatures, which means that any variant of a given ACDC is equivalently verifiable. The revocation of a given ACDC can be detected via the witnesses declared in its issuer's KEL. Discovering, detecting, and reacting to such events can be very efficient. Any number of aggregated views can be built on demand, for any subset of an ecosystem's evidence, by any party. This requires no special authority or access, and does not create a central registry as a source of truth, since such views are tamper-evident and therefore can be served by untrusted parties. Further, different views of the evidence can contain or elide different fields of the evidence data, to address privacy, regulatory, and legal requirements.

CVD Cryptographically verifiable data (CVD) is data that's associated with a digital signature and a claim about who signed it. When CVD is an assertion, we make the additional assumption that the signer intends whatever the data asserts, since they took an affirmative action to create non-repudiable evidence that they processed it. CVD can be embodied in many formats, but in the context of VVP, all instances of CVD are ACDCs. When CVD references other CVD, the computer science term for the resulting data structure is a data graph.

Credential A credential is a special kind of CVD that asserts entitlements for its legitimate bearer -- and only its bearer. CVD that says Organization X exists with a particular ID number in government registers, and with a particular legal name, is not necessarily a credential. In order to be a credential, it would have to be associated with an assertion that its legitimate bearer -- and only its bearer -- is entitled to use the identity of Organization X. If signed data merely enumerates properties without conferring privileges on a specific party, it is just CVD. Many security gaps in existing solutions arise from conflating CVD and credentials. ACDCs can embody any kind of CVD, not just credentials.

Bearer token VVP never uses bearer tokens, but we define them here to provide a contrast. A bearer token is a credential that satisfies binding requirements by a trivial test of possession -- like a movie ticket, the first party that presents the artifact to a verifier gets the privilege. Since Bearer Credentials can be stolen or copied, this is risky. JWTs, session cookies, and other artifacts in familiar identity technologies are often bearer tokens, even if they carry digital signatures. Although they can be protected to some degree by expiration dates and secure channels, these protections are imperfect. For example, TLS channels can be terminated and recreated at multiple places between call origination and delivery.

Targeted credential A targeted credential is a CVD that identifies an issuee as the bearer, and that requires the issuee to prove their identity cryptographically (e.g., to produce a proper digital signature) in order to claim the associated privilege. All credentials in VVP are targeted credentials.

JL A justifying link (JL) is a reference, inside of one CVD, to another CVD that justifies what the first CVD is asserting. JLs can be SAIDs that identify other ACDCs. JLs are edges in an ACDC data graph.

Specific artifacts

PSS Each voice call begins with a SIP INVITE, and in VVP, each SIP INVITE contains an Identity header that MUST contain a signature from the call's OP (). This passpport-specific signature (PSS) MUST be an Ed25519 signature serialized as CESR; it is NOT a JWS. The 64 raw bytes of the signature are left-padded to 66 bytes, then base64url-encoded. The AA at the front of the result is cut and replaced with 0B, giving an 88-character string. A regex that matches the result is: 0B[-_\w]{86}, and a sample value (with the middle elided) is: 0BNzaC1lZD...yRLAYeKNQvYx. The signature MUST be the result of running the EdDSA algorithm over input data in the manner required by : signature = sign(base64url(header) + "." + base64url(payload). Also per the JWT spec, when the signature is added to the compact form of the JWT, it MUST be appended to the other two portions of the JWT, with a . delimiter preceding it. Per STIR conventions, it MUST then be followed by ";ppt=vvp" so tools that scan the Identity header of the passport can decide how to process the passport without doing a full parse of the JWT. The headers MUST include alg, typ, ppt, and kid, as described in . They MAY include other values, notably x5u (see ). The claims MUST include orig, dest, iat, exp, and evd, and MAY include card, goal, call_reason, jti, origId, and other values (also described in ). The signature MUST use all headers and all claims as input to the data stream that will be signed.

Dossier The evd field in the passport contains the OOBI () of an ACDC data graph called the dossier. The dossier is a compilation of all the permanent, backing evidence that justifies trust in the identity and authorization of the AP and OP. It is created and must be signed by the AP. It is CVD () asserted to the world, not a credential () issued to a specific party.

Accountable Party Evidence The dossier MUST include at least what is called accountable party evidence (APE). APE consists of several credentials, explored in detail below. It MUST include a vetting credential for the AP. It SHOULD include a TNAlloc credential that proves RTU. Normally the RTU MUST be assigned to the AP; however, if a proxy is the OP and uses their own phone number, the RTU MUST be assigned to the OP instead. If the AP intends to contextualize the call with a brand, it MUST include a brand credential for the AP. (In cases where callers are private individuals, "brand" maps to descriptive information about the individual, as imagined in mechanisms like VCard or JCard .) If no brand credential is present, verifiers MUST NOT impute a brand to the call on the basis of any VVP guarantees. APE MAY also include evidence that will aid in settlement.

Delegation Evidence When a private individual makes a call with VVP, they might be both the AP and the OP. In such cases, we expect their AID to be the recipient or issuee of all the APE, and no backing evidence beyond the APE may be necessary. However, in business contexts, it will almost always be true that the OP role is played by a delegate. In such conditions, evidence must also include proof that this indirection is valid. We call this delegation evidence (DE). DE is nearly always required when the AP is an organization, because the cryptographic identifier for the organization as a legal entity is typically not the same as the cryptographic identifier for the organization's automated software that prepares SIP INVITEs. DE can thus distinguish between Acme Corporation in general, and software operated by Acme's IT department for the express purpose of signing voice traffic. The former has a vetting credential and legal accountability, and can act as the company to publish press releases, prepare invoices, spend money, and make attestations to regulators; the latter should only be able to sign outbound voice calls on Acme's behalf. Failing to make this distinction creates serious cybersecurity risks. Delegation evidence may also be used to prove that an AI-powered agent is empowered to make phone calls on behalf of an AP.

Vetting credential A vetting credential is a targeted credential that enumerates the formal and legal attributes of a unique legal entity. It MUST include a legal identifier that makes the entity unique in its home jurisdiction (e.g., an LEI), and it MUST include an AID for the legal entity as an AP. This AID is globally unique. The vetting credential is so called because it MUST be issued according to a documented vetting process that offers formal assurance that it is only issued with accurate information, and only to the entity it describes. A vetting credential confers the privilege of acting with the associated legal identity if and only if the bearer can prove their identity as issuee via a digital signature from the issuee's AID. A vetting credential MUST include a JL to a credential that qualifies the issuer as a party trusted to do vetting. This linked credential that qualifies the issuer of the vetting credential MAY contain a JL that qualifies its own issuer, and such JLs MAY be repeated through as many layers as desired. In VVP, the reference type of a vetting credential is an LE vLEI; see and . This implies both a schema and a governance framework. Other vetting credential types are possible, but they MUST be true credentials that meet the normative requirements here. They MUST NOT be bearer tokens. To achieve various design goals, a vetting credential MUST be an ACDC, but this ACDC MAY be a transformation of a credential in another format (e.g., W3C VC, SD-JWT, X509 certificate). See .

TNAlloc credential A TNAlloc credential is a targeted credential that confers on its issuee the right to control how one or more phone numbers are used. Regulators issue TNAlloc credentials to range holders, who in turn issue them to TNUs. TNUs often play the AP role in VVP. If an AP delegates RTU to a proxy (e.g., an employee or call center), the AP MUST also issue a TNAlloc credential to the proxy, to confer the RTU. With each successive reallocation, the set of numbers in the new TNAlloc credential may get smaller. Except for TNAlloc credentials issued by regulators, all TNAlloc credentials MUST contain a JL to a parent TNAlloc credential, having an equal or bigger set of numbers that includes those in the current credential. This JL in a child credential documents the fact that the child's issuer possessed an equal or broader RTU, from which the subset RTU in child credential derives. To achieve various design goals, a TNAlloc credential MUST be an ACDC, but this ACDC MAY be a transformation of a credential in another format (e.g., a TNAuthList from ). See . An example TNAlloc credential and its schema are described in .

Brand credential A brand credential is a targeted credential that enumerates brand properties such as a brand name, logo, chatbot URL, social media handle, and domain name. It MUST be issued to an AP as a legal entity, but it does not enumerate the formal and legal attributes of the AP; rather, it enumerates properties that would be meaningful to a TP who's deciding whether to take a phone call. It confers on its issuee the right to use the described brand by virtue of research conducted by the issuer (e.g., a trademark search). This credential MUST be issued according to a documented process that offers formal assurance that it is only issued with accurate information, and only to a legal entity that has the right to use the described brand. A single AP MAY have multiple brand credentials (e.g., a fictional corporation, Amce Space Travel Deutschland, GmbH, might hold brand credentials for both Sky Ride and for Orbítame Latinoamérica). Rights to use the same brand MAY be conferred on multiple APs (Acme Space Travel Deutschland, Gmbh and Acme Holdings Canada, Ltd may both possess brand credentials for Sky Ride). A brand credential MUST contain a JL to a vetting credential, that shows that the right to use the brand was evaluated only after using a vetting credential to prove the identity of the issuee. An example brand credential and its schema are described in .

Brand proxy credential A brand proxy credential confers on an OP the right to project the brand of an AP when making phone calls, subject to a carefully selected set of constraints. This is different from the simple RTU conferred by TNAlloc. Without a brand proxy credential, a call center could make calls on behalf of an AP, using the AP's allocated phone number, but would be forced to do so under its own name or brand, because it lacks evidence that the AP intended anything different. If an AP intends for phone calls to be made by a proxy, and wants the proxy to project the AP's brand, the AP MUST issue this credential. An example brand proxy credential and its schema are shown in .

Delegated signer credential A delegated signer credential proves that automation running under the control of the OP has been authorized by the AP to originate VVP traffic (and thus, sign VVP passports) on its behalf. An example delegated signer credential and its schema are shown in .

Additional credential types New credential types can be added to a dossier, to answer any number of novel questions for verifiers, without changing the core characteristics of VVP. For example, a credential could be attached to a dossier to prove that the caller is a human being instead of an AI (see and ), or a credential could be attached to a dossier to prove that the AP empowered an AI agent to make calls on its behalf (analogous to how chatbots represent companies in RCS contexts). An additional credential could assist with questions about settlement (how the terminating service provider will be paid to connect the call). It might document the relationship between an AP and one or more financial clearinghouses.

Interoperability VVP can achieve its goals without any dependence on RCD, SHAKEN, or similar mechanisms. However, it also provides easy bridges so value can flow to and from other ecosystems with similar goals.

Chat and conversations The dossier cited in a VVP passport may also be cited by an RCS verification authority (VA), may include evidence that is also submitted to a VA, or may consist of evidence created by a VA. This unlocks synergies between vetting for RCS () and vetting for voice. It may also allow properly vetted RCS chatbots to make verifiable voice calls, including calls that carry brand information (see and ), distinguishing them with 100% confidence from AI-driven voice scams. When conversations are captured in rich containers such as vCon (), a VVP passport may be included (e.g., in the stir field of a vCon), proving the identity of a calling party. As long as signatures over the data structure assert truthfully that the passport was verified at the time of attachment, no replay attack is possible, and all of VVP's guarantees transfer. A VVP dossier by itself can also provide permanent evidence of assertions as attachments to a conversation.

Certificates Certificates can add value to VVP, and VVP can add value to certificate-based ecosystems or stacks. In the rest of this section, note the difference between normative language (imposing requirements on VVP implementations) and non-normative language (suggesting how other solutions could react).

Cascaded mode Verifiers who prefer to operate in certificate ecosystems such as SHAKEN and RCD can be satisfied by having an intermediary verify according to VVP rules (see ), and then signing a new passport in a certificate-dependent format (e.g., for SHAKEN and/or RCD). In such cases, the new passport contains an x5u header pointing to the certificate of the new signer. This form of trust handoff is called cascaded mode. In cascaded mode, if the certificate fetched from the x5u URL satisfies enough trust requirements of the verifier, the goals of the new context are achieved. For example, if this intermediary is the OSP, the standard assumptions of SHAKEN are fully met, but the OSP's attestation can always be A, since VVP conclusively proves the identity of the AP and OP.

Foundation mode In another pattern called foundation mode, a VVP passport MAY itself contain an x5u header. If it does, the x5u header MUST NOT be used to achieve any VVP verification guarantees; the key state of the OP's AID MUST still justify any acceptance of the signature. However, the associated X509 certificate SHOULD be issued to the public key of the party that plays the OP role in VVP. If and only if it does so, the full weight of VVP evidence about the OP's status as a trusted signer for the AP could be transferred to the certificate, even if the certificate is self-issued or otherwise chains back to something other than a known, high-reputation certificate authority. Valid VVP passports that obey this requirement can thus be used to enable VVP-unaware but certificate-based checks without certificate authorities (or without prior knowledge of them). Such certificate-based checks should be done in real-time, since the binding between a key and the owner of a cert cannot be known to be valid except at the current moment.

Other credential formats The stable evidence that drives VVP -- vetting credential (), TNAlloc credential (), brand credential (), brand proxy credential (), and delegated signer credential () -- MUST all be ACDCs. This is because only when the data in these credentials is modeled as an ACDC is it associated with permanent identities that possess appropriate security guarantees. However, VVP can easily be driven by other approaches to evidence, treating the ACDCs as a somewhat secondary format transformation. In such a case, a bridging party plays a pivotal role. This party MUST verify foreign evidence (e.g., W3C verifiable credentials ), and then issue ACDCs that derive from it (e.g., using ). It MAY radically transform the data in the process (e.g., combining or splitting credentials, changing schemas or data values). This transformation from foreign evidence to ACDCs is very flexible, and allows for tremendous interoperability. On the calling side, any ecosystem that deals in cryptographic evidence can provide input to VVP, no matter what evidence mechanisms they prefer. (On the receiving side, the information carried via ACDCs in VVP could be transformed again, with a second bridging party, to enable even more interoperability. However, the goals of such a secondary transformation are undefined by VVP, so the constraints and rules of the transformation are out of scope here.) All VVP stakeholders need to understand that accepting foreign evidence does much more than alter format. Bridging is not a simple conversion or reissuance. It replaces identifiers (e.g., DIDs as specified in with AIDs as specified in ). The new identifiers have different lifecycles and different trust bases than the original. Bridging also changes the meaning of the credential. Foreign evidence directly asserts claims backed by the reputation of its original issuer. A new ACDC embodies a claim by the bridging party, that they personally verified foreign evidence according to foreign evidence rules, at a given moment. It cites the foreign evidence as a source, and may copy claims into the ACDC, but the bridging party is only asserting that they verified the original issuer's commitment to the claims, not that the bridging party commits to those claims. Verifiers MAY choose to accept such derivative ACDCs, but the indirection SHOULD color their confidence. They MUST NOT assume that identifiers in the foreign evidence and in the ACDC have the same referents or controllers. They MUST NOT hold the bridging party accountable for the claims -- only for the claim that they verified the original issuer's commitment to the claims. Unless additional governance offers guarantees beyond those explicitly provided by VVP, they MUST accept that there is no defined relationship between revocation of the foreign evidence and revocation of the ACDC.

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 people 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:

Passports SHOULD have an aggressive timeout (e.g., 1 minute). 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.)
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. See . (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.)
Revocations SHOULD be timely, and the timeliness guarantees of issuers SHOULD be published.
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.

Privacy Both institutions and individuals that make phone calls may have privacy goals. Although their goals might differ in some ways, both will wish to disclose some attributes to the TP, and both may wish to suppress some of that same information from intermediaries. Both will want control over how this disclosure works.

Graduated Disclosure ACDCs support a technique called graduated disclosure that enables this. The hashing algorithm for ACDCs resembles the hashing algorithm for a merkle tree. An ACDC is a hierarchical data structure that can be modeled with nested JSON. Any given layer of the structure may consist of a mixture of simple scalar values and child objects. The input to the hashing function for a layer of content equals the content of scalar fields and the hashes of child objects.

ACDC hashes like a Merkle tree <![CDATA[ Fully Partially Fully Expanded ACDC Compact ACDC Compact ACDC +------------+ +------------+ +------------+ | a = { | | a = { | | a = H(...) | | b = N, | | b = N, | +------------+ | C = { | | c = H(c),| | d = M, | | g = Q, | | e = O, | | i = H(i) | | f = P | | } | | }, | +------------+ | g = Q, | | i = { | | j = R, | | k = S | | } | | } | +------------+ H(a) = H( H(a) = H( H(a) = SAID b = N, b = N, c = H(c), c = H(c), recurse g = Q, g = Q, i = H(i) i = H(i) ) = SAID recurse ) = SAID ]]> This means is that any given child JSON object in an ACDC can be replaced with its hash, without altering the hash of the parent data. Thus, there can be expanded ACDCs (where all data inside child objects is visible) or compacted ACDCs (where some or all of the child objects are opaquely represented by their equivalent hashes). A signature over an expanded ACDC is also a signature over any of the compacted versions of the same ACDC, and a revocation event over any of the versions is guaranteed to mean the same thing. In combination with the evd claim in a passport, graduated disclosure can be used to achieve privacy goals, because different verifiers can see different variations on an ACDC, each of which is guaranteed to pass the same verification tests and has the same revocation status. For example, suppose that company X wants to make a call to an individual in jurisdiction Y, and further suppose that auditor Z requires proof that X is operating lawfully, without knowing the name of X as a legal entity. In other words, the auditor needs to qualify X but not necessarily identify X. Company X can serve the KEL for its dossier from a web server that knows to return the expanded form of the vetting credential in the dossier to the individual or the individual's TSP in Y, but a compacted form of the vetting credential (revealing just the vetter's identity and their signature, but not the legal identity of the issuee, X) to auditor Z. Later, if law enforcement sees the work of the auditor and demands to know the legal identity of X, discovery of the expanded form can be compelled. When the expanded form is disclosed, it will demonstrably be associated with the compact form that Z recorded, since the qualifying and identifying forms of the ACDC have the same hash. Company X doesn't have to engage in sophisticated sniffing of traffic by geography to achieve goals like this. It can simply say that anonymous and unsigned HTTP requests for the dossier return the compact form; anyone who wants the expanded form must make an HTTP request that includes in its body a signature over terms and conditions that enforce privacy and make the recipient legally accountable not to reshare. Importantly, transformations from expanded to compact versions of an ACDC can be performed by anyone, not just the issuer or holder. This means that a verifier can achieve trust on the basis of expanded data, and then cache or share a compacted version of the data, meaning that any subsequent or downstream verifications can have equal assurance but higher privacy. The same policy can be applied to data any time it crosses a regulatory, jurisdictional boundary where terms and conditions for disclosure have weaker enforcement. It can also be used when business relationships should be redacted outside of a privileged context. Schemas for credentials should be designed to allow graduated disclosure in increments that match likely privacy goals of stakeholders. ACDC schema design typically includes a salty nonce in each increment, avoiding rainbow attacks on the hashed data. VVP encourages but does not require this.

Correlation Privacy theorists will note that, even with contractually protected graduated disclosure and maximally compact ACDCs, verifiers can still correlate by using some fields in ephemeral passports or long-lived ACDCs, and that this may undermine some privacy goals. There are three correlators in each passport:

Any brand information in card (may strongly identify an AP)
the kid header (identifies the OP)
the evd claim (uniquely identifies a dossier used by an AP)

We discount the first correlator, because if it is present, the AP is explicitly associating its correlated reputation with a call. It has asserted this brand publicly, to every stakeholder in the SIP pipeline. In such cases, any question of the AP's privacy is off the table, and no privacy protections on the other two correlators will be effective. However, if the first correlator is missing, the other two correlators become more interesting.

kid In VVP, the OP role that's identified by kid is played by automation. Automation is unlikely to have any direct privacy goal. The company that operates it is likely to be either a service provider, or a large corporation capable of significant IT investments. Either way, the OP is in the business of servicing phone calls, and is likely to be content for its traffic to be correlated publicly. Therefore, the fact that kid correlates the OP is not particularly interesting. However, could the OP be used as an indirect correlator for the AP? The OP's SBC can service many thousands or millions of callers, providing a some herd privacy. This is not a perfect protection, but it is a beginning. We add to this the crucial observation that the OP doesn't need to have a stable reputation to support VVP goals. Trust in the OP comes from the existence of a delegated signer credential (see ), not from a certificate or any other long-term identity. Therefore, the AID that provides cryptographic identity for an OP MAY be rotated often (as often as APs are willing to delegate to a new one). Further, even without rotation, an OP organization MAY provide multiple instances of its automation, each using a different AID. Also, an AP MAY delegate signing authority to multiple OP organizations, each of which is using various strategies to mitigate correlation. Taken together, these measures offers reasonable protection -- protection that an AP can tune -- against correlating an AP via kid.

evd The other correlator, evd, tracks an AP more directly, because a dossier is uniquely identified by its SAID, and can only be used by a single AP. Furthermore, if someone resolves evd to an actual dossier (something that might be avoidable with judicious use of graduated disclosure), the dossier will at a minimum have an issuer field that ties it to the AP as a perfect correlator. One answer here is to introduce an AP blinding service. This service creates derived dossiers on a schedule or by policy. Each derivation includes the hash of the original dossier, in a field that is hidden but available (along with a salty nonce) via graduated disclosure. The derived dossier is signed by the blinding service rather than the original AP. It embodies an assertion, by the blinding service, that it has verified the original dossier according to published rules, and that it will revoke the derivative if the original is revoked. AP blinding services would have to be trusted by verifiers, much like root CAs in SHAKEN. However, unlike CAs, their actions could be trivially audited for correctness, since every derivation would have to be backed by a dossier that has the associated hash. Such a mechanism is probably unnecessary for b2c calling, but may be justified when VVP is used by individual APs if they wish to merely qualify without identifying themselves to some intermediaries or TPs.

Appendix A: Evidence theory Most existing approaches to secure telephony uses X509 certificates for foundational identity. Certificates have great virtues. Notably, they are well understood, and their tooling is ubiquitous and mature. However, they also have some serious drawbacks. They are protected by a single key whose compromise is difficult to detect. Recovery is cumbersome and slow. As a result, certificates are far more temporary than the identities they attest. This has numerous downstream consequences. When foundational evidence of identity has to be replaced constantly, the resulting ecosystem is fragile, complex, and expensive for all stakeholders. Vulnerabilities abound. Authorizations can only be analyzed in a narrow now window, never at arbitrary moments in time. This creates enormous pressure to build a centralized registry, where evidence can be curated once, and where the cost of reacting to revocations is amortized. The entire fabric of evidence has to be rebuilt from scratch if quantum security becomes a requirement. In contrast, the issuers and holders of ACDCs -- and thus, the stakeholders in VVP passports -- are identified by autonomic identifiers, not raw keys. This introduces numerous security benefits. Keys, key types, and signing algorithms can all change (even for post-quantum upgrades) without invalidating evidence. Signing and rotation operations are sequenced deterministically, making historical audits possible. Key compromises are detected as soon as an attacker attempts consequential actions. Recovery from compromise is trivial. Multisig signing policies allow diffuse, nuanced control. The result is that identities in ACDCs are as stable as identities in real organizations. This makes delegations and chaining mechanisms far more robust than their analogs in certificates, and this in turn makes the whole ecosystem safer, more powerful, and easier to maintain. Revocations are cheap and fast. No central registries are needed, which eliminates privacy concerns and regulatory hurdles. Adoption can be opportunistic; it doesn't require a central mandate or carefully orchestrated consensus throughout a jurisdiction before it can deliver value. ACDCs make it practical to model nuanced, dynamic delegations such as the one between Organization X and Call Center Y. This eliminates the gap that alternative approaches leave between accountable party and the provider of call evidence. Given X's formal approval, Y can sign a call on behalf of X, using a number allocated to X, and using X's brand, without impersonating X. They can also prove to any OSP or any other party, in any jurisdiction, that they have the right to do so. Furthermore, the evidence that Y cites can be built and maintained by X and Y, doesn't get stale or require periodic reissuance, and doesn't need to be published in a central registry. Even better, when such evidence is filtered through suballocations or crosses jurisdictional boundaries, it can be reused, or linked and transformed, without altering its robustness or efficiency. Unlike W3C verifiable credentials and SD-JWTs, which require direct trust in the proximate issuer, ACDCs and the JWTs that reference them verify data back to a root through arbitrarily long and complex chains of issuers, with only the root needing to be known and trusted by the verifier. The synergies of these properties mean that ACDCs can be permanent, flexible, robust, and low-maintenance. In VVP, no third party has to guess who's accountable for a call; the accountable party is transparently and provably accountable, period. (Yet notwithstanding this transparency, ACDCs support a form of pseudonymity and graduated disclosure that satisfies vital privacy and data processing constraints. See .)

Appendix B: Witnesses and Watchers A full description of witnesses and watchers is available in . Here, we merely summarize. A KERI witness is a lightweight server that acts as a notary. It exposes a standard interface. It receives signed events from the controller of an identifier that it services. If these events are properly sequenced and aligned with the identifier's signing policy and key state, they are recorded and become queryable, typically by the public. KERI allows the controller of an autonomic identifier to choose zero or more witnesses. The witnesses can change over the lifecycle of the identifier. However, the relationship between an identifier and its witnesses cannot be changed arbitrarily; the controller of the identifier makes a cryptographic commitment to its witnesses, and can only change that commitment by satisfying the signing policy of the identifier. In VVP, identifiers used by issuers MUST have at least one witness, because this guarantees viral discoverability, and SHOULD have at least 3 witnesses, because this guarantees both high availability and the detection of duplicity by the controller of the identifier. Witnesses provide, for VVP, many of the security guarantees that alternate designs seek from blockchains. However, witnesses are far more lightweight than blockchains. They can be run by anyone, without coordination or approval, and can be located in any jurisdiction that the owner of the identifier prefers, satisfying regulatory requirements about data locality. Although a single witness may service mulptiple identifiers, the records related to any single identifier are independent, and no consensus algorithm is required to order them relative to others. Thus, every identifier's data evolves in parallel, without bottlenecks, and any identifier can be deleted without affecting the integrity of other identifiers' records, satisfying regulatory requirements about erasure. Witnesses only store (and thus, can only expose to the public) what a given data controller has instructed them to store and publish. Thus, witnesses do not create difficulties with consent or privacy. In VVP, when a party shares an identifier or a piece of evidence, they do so via a special URL called an OOBI (out of band invitation). The OOBI serves a tamper-evident KEL () that reveals the full, provable history of the key state and other witnesses for the identifier, and even includes a forward reference to new witnesses, if they have changed. It also allows the discovery of issuance and revocation events, and their sequence relative to one another and to key state changes. An additional and optional feature in KERI is enabled by adding watchers. Watchers are lightweight services that synthesize witness data. They may MAY monitor multiple witnesses and enable hyper-efficient caching. They SHOULD also compare what multiple witnesses for a given identifier are saying, which prevents controllers of an identifier from forking reality in a duplicitous way, and which can detect malicious attempts to use stolen keys. Witnesses are chosen according to the preference of each party that controls an identifier, and a mature ecosystem could have dozens, hundreds, or thousands. Watchers, on the other hand, address the needs of verifiers, because they distill some or all of the complexity in an ecosystem down to a single endpoint that verifiers can query. Any verifier can operate a watcher at any time, without any coordination or approval. Viral discoverability can automatically populate the watcher's cache, and keep it up-to-date as witness data evolves. Verifiers can share watchers if they prefer. Anything that watchers assert must be independently verified by consulting witnesses, so watchers need not have a complete picture of the world, and they are a convenience rather than an oracle that must be trusted. The data that watchers synthesize is deliberately published by witnesses for public consumption, at the request of each data stream's associated data controllers, and does not represent surveillance (). If a watcher can no longer find witness data to back one of its assertions, it MUST delete the data to satisfy its contract. This means that acts of erasure on witnesses propagate to watchers, again satisfying regulatory erasure requirements.

Appendix C: Sample Credentials

Common fields Some structure is common to all ACDCs. For details, consult . Here, we provide a short summary.

v (required) Contains a version statement.
d (required) Contains the SAID () of the ACDC. (Nested d fields contain SAIDs of nested JSON objects, as discussed in .
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 allowed 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 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.

All ACDCs are validated against a schema that conforms to . Below we show some sample credentials and their corresponding schemas. VVP does not require these specific schemas, but rather is compatible with any that have roughly the same information content.

Vetting credential The schema of a vetting credential () can be very simple; it needs to identify the issuer and issuee by AID, and it needs to identify the vetted legal entity in at least one way that is unambiguous. Here is a sample LE vLEI that meets these requirements. The issuer's AID appears in the first i field, the issuee in the second i field, and the connection to a vetted legal entity in the LEI field. (The validity of this credential depends on its issuer having a valid, unrevoked QVI credential; the specifc credential it links to is conveyed in e. The full text of rules has been elided to keep the example short.) The schema that governs this credential, ENPX...DZWY, is shown in the s field. LE vLEI credential schemas are managed by GLEIF and published at . As fundamentally public artifacts that are issued only to organizations, not individuals, vLEIs are not designed for graduated disclosure (). Vetting credentials for individuals would require a different schema -- perhaps one that documents their full legal name but allows disclosure strategies such as first name + last initial, or first initial plus last name.

TNAlloc credential A TNAlloc credential needs to identify its issuer and issuee. If and only if it isn't issued by a national regulator that acts as a root of trust on allocation questions, it also needs to cite an upstream allocation that justifies the issuer's right to pass along a subset of the numbers it controls. Here is a sample TNAlloc credential that meets these requirements. The schema used by this particular credential, EFvn...GgSQ, is published at .

Brand credential TODO ~~~json ~~~

Brand proxy credential A brand proxy credential () is very similar to a delegated signer credential, in that it proves carefully constrained delegated authority. The difference lies in what authority is delegated (proxy a brand vs. sign passports). A Generalized Cooperative Delegation (GCD) credential embodies delegated but constrained authority in exactly this way. A GCD credential suitable for use as a brand proxy in VVP might look like this: Note the c_goal field that limits goals that can be justified with this credential, and the c_proto field that says the delegate can only exercise this authority in the context of the "VVP" protocol with the "OP" or "TP" role. The wildcard in c_goal and the addition of the "TP" role in c_proto are complementary changes that allow this credential to justify proxying the brand on both outbound and inbound calls. (Branding on inbound calls is out of scope for VVP, but is included here just to show that the same credentials can be used for both VVP and non-VVP solutions. To convert this credential to a purely outbound authorization, replace the wildcard with send, and limit the roles in VVP to OP.) The schema for GCD credentials, and an explanation how to add additional constraints, is documented at .

Delegated signer credential A delegated signer credential () must prove that the issuer is giving authority to the issuee. This authority should be carefully constrained so that it applies only to outbound voice calls, not to signing invoices or legal contracts. It can also be constrained so it only applies on a particular schedule, or when the call originates or terminates in a particular geo or jurisdiction. A Generalized Cooperative Delegation (GCD) credential embodies delegated but constrained authority in exactly this way. A GCD credential suitable for use as a delegated signer credential in VVP might look like this: Note the c_goal field that limits goals that can be justified with this credential, and the c_proto field that says the delegate can only exercise this authority in the context of the "VVP" protocol with the "OP" role. The schema for GCD credentials, and an explanation how to add additional constraints, is documented at .

Dossier A dossier () is almost all edges -- that is, links to other credentials. Here's what one might look like: Notice how each named edge references one of the previous sample credentials in its n field, and that other credential's associated schema in the s field. The schema for this credential is documented at .

IANA Considerations This specification requires no IANA actions. However, it does depend on OOBIs (see ) being served as web resources with IANA content type application/json+cesr.

References Normative References SIP: Session Initiation Protocol 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] Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) 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] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] The Base16, Base32, and Base64 Data Encodings This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Edwards-Curve Digital Signature Algorithm (EdDSA) 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. Authenticated Identity Management in the Session Initiation Protocol (SIP) 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. PASSporT: Personal Assertion Token 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. Digital Signature Standard (DSS) National Institute of Standards and Technology (NIST) Composable Event Streaming Representation (CESR) Trust Over IP Foundation Key Event Receipt Infrastructure (KERI) Trust Over IP Foundation Authentic Chained Data Containers (ACDC) Trust Over IP Foundation Financial services – Legal entity identifier (LEI) – Part 1: Assignment International Organization for Standardization inancial services – Legal entity identifier (LEI) – Part 3: Verifiable LEIs (vLEIs) International Organization for Standardization Signature-Based Handling of Asserted Information Using toKENs (SHAKEN) Alliance for Telecommunications Industry Solutions Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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 Uniform Resource Identifier (URI): Generic Syntax A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] JSON Web Token (JWT) 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. Secure Telephone Identity Credentials: Certificates In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) 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. vCard Format Specification 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] jCard: The JSON Format for vCard This specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications. The JSON format for vCon - Conversation Data Container SIPez LLC Strolid A vCon is the container for data and information relating to a real- time, human conversation. It is analogous to a [vCard] which enables the definition, interchange and storage of an individual's various points of contact. The data contained in a vCon may be derived from any multimedia session, traditional phone call, video conference, SMS or MMS message exchange, webchat or email thread. The data in the container relating to the conversation may include Call Detail Records (CDR), call meta data, participant identity information (e.g. STIR PASSporT), the actual conversational data exchanged (e.g. audio, video, text), realtime or post conversational analysis and attachments of files exchanged during the conversation. A standardized conversation container enables many applications, establishes a common method of storage and interchange, and supports identity, privacy and security efforts (see [vCon-white-paper]) Rich Communication Suite - Advanced Communications Services and Client Specification, version 11.0 GSMA SIP Call-Info Parameters for Rich Call Data Somos Neustar This document describes a usage of the SIP Call-Info header field that incorporates Rich Call Data (RCD) associated with the identity of the calling party in order to provide to the called party a description of the caller or details about the reason for the call. RCD includes information about the caller beyond the telephone number such as a calling name, or a logo, photo, or jCard object representing the caller, which can help the called party decide whether to answer the phone. The elements defined for this purpose are intended to be extensible in order to accommodate related information about calls and to be compatible and complementary with the STIR/PASSporT RCD framework. 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". PASSporT Extension for Rich Call Data Somos Inc. Neustar Inc. This document extends PASSporT, a token for conveying cryptographically-signed call information about personal communications, to include rich meta-data about a call and caller that can be signed and integrity protected, transmitted, and subsequently rendered to the called party. This framework is intended to include and extend caller and call specific information beyond human-readable display name comparable to the "Caller ID" function common on the telephone network and is also enhanced with a integrity mechanism that is designed to protect the authoring and transport of this information for different authoritative use-cases. Selective Disclosure for JWTs (SD-JWT) Authlete Keio University Ping Identity This specification defines a mechanism for the selective disclosure of individual elements of a JSON-encoded data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. Branded Calling ID Best Practices CTIA Decentralized Identifiers (DIDs) v1.0 Verifiable Credentials Data Model v1.1 Aries RFC 0519: Goal Codes JSON Schema Specification 2020-12 JSON Schema Community Legal Entity vLEI Credential GLEIF TN Allocation Credential Provenant Personhood credentials: Artificial intelligence and the value of privacy-preserving tools to distinguish who is real online Face-to-Face Credentials Citation Schema Generalized Cooperative Delegation (GCD) Credentials Verifiable Voice Dossier

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