# Credential Types Existing attempts to eliminate fraud in telco suffer from weak or incomplete evidence. Voice traffic becomes verifiable if we prove, with robust evidence, various logical propositions about a call. Each cluster of related facts has a different purpose, a different lifecycle, and potentially, a different issuer. ## Journey Although order may vary, the steps in an enterprise's credential journey, leading up to its readiness to emit verifiable voice traffic, usually look like this:
## Identity credential Steps 1-4 in the diagram. Certifies that a given legal entity (an enterprise[^1] identified by its LEI), is also identified by a particular autonomic identifier (an AID). Different levels of assurance are possible with an identity credential, with the gold standard being the LE vLEI. In our project, we may begin with a bronze identity credential. This is the first step of the vLEI journey and can be upgraded to a full vLEI later. It is issued after confirming that: a) the requester is a human; b) the requester controls their email inbox; c) the requester formally identifies the legal entity in question, using its LEI; d) there is good reason to believe the legal entity controls the domain in the requester's email \[automated analysis + DNS TXT record or upload to website); e) the requester produces a cryptographic signature that proves they control the keys for the AID that the legal entity will be using. ## TN credential Step 5 in the diagram. Certifies that a given legal entity, as identified by the same AID in the vetting credential, is also entitled to use a given phone number for outbound calls. Must be issued by the rangeholder that sold this right to the legal entity. ## Brand credential Also step 5 in the diagram. Certifies that a given legal entity, as identified by the same AID in the identify credential, is also the owner[^2] or licensee of brand assets that may be used with a call. Issued after confirming brand rights. Any number of brand assets may be attested — anything representable using the VCard spec ([RFC 6530](https://www.rfc-editor.org/rfc/rfc6350)) — but the most important for our project are a service name and a logo. ## Settlement credential Also step 5 in the diagram. Proves that the calling organization has contractual agreements with someone that will guarantee that the terminating service provider gets paid for the call. ## Other credential types Also step 5 in the diagram. Any number of additional credential types could be added. For example, if an AI is making an outbound call, we could add a credential that proves that the AI uses a particular model and operates with specific safety guardrails. If, on the other hand, a human is making the call, we could add a proof-of-personhood credential to guarantee that no AI is involved. ## Delegated signer credential Implicit part of step 6 in the diagram. This is issued by an [accountable party](/glossary.md#accountable-party-ap) (an enterprise), to a high-speed signing service under the control of the [originating party](/glossary.md#originating-party-op) that creates their VVP-enabled SIP INVITEs. This credential type is mostly invisible in our project, because it is automatically created when the enterprise chooses their UCaaS provider and finalizes their dossier. However, it plays an important logical role in the overall strategy, because it justifies a belief that the signer of the Identity header in the SIP INVITE is actually a party that the enterprise intends to emit verifiable voice traffic on their behalf. (The party that signs the Identity header is identified by the kid field inside that header, and must have a delegated signer credential in the associated dossier.) ## Dossier A dossier is like an affidavit. It is signed by an [accountable party](/glossary.md#accountable-party-ap) (an enterprise). It lists all the pieces of evidence that the enterprise wants to associate with its reputation when making outbound calls — the other credential types listed above. The VVP Identity header is a JWT that contains a claim (a field) called evd. This is a URL that tells any verifier how to fetch and validate the dossier. [^1]: In casual speech, we often give examples of "enterprise" that are much looser than a legal entity. For example, we say "Coca Cola" without specifying whether we mean [Coca Cola HBC Schweiz AG](https://search.gleif.org/#/record/549300DVT3H44EQLQY73), [Compagnie Rafraîchissements Coca-Cola Canada](https://search.gleif.org/#/record/549300FD0ELR6PSTM595), or something different. In order to hold parties legally accountable, we need to precisely identify the legal entity. [^2]: This credential is separate from the identity credential for a legal entity because there is a many-to-many relationship between legal entities and brands. Dozens of legal entities all have the right to use the "Coca Cola" brand, and many of them also have the right to use the "Sprite" and "Fanta" brands as well. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ovc.provenant.net/cred-types.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.