Guide for Issuers

In GSMA's Open Verifiable Calling project, identity credentials and brand credentials are issued by vetters, TN credentials (proving right to use a specific number) are issued by range holders, and additional credential types may also be relevant. Enterprises that make verifiable calls also issue a credential of sorts, called a dossier. All of these credentials are defined and described in Credential Types.

Credentials are relatively permanent, like X509 certificates, not ephemeral like STIR passports. This means that credential issuance does not occur repeatedly in realtime, as calls are made; rather, it happens once or occasionally beforehand; then, when calls are made, existing credentials are referenced via hyperlink, as described in Guide for Signers.

Any party that issues credentials always has the option of revoking credentials they issued, at any time, including in realtime, as calls occur. Verifiers will learn about revocation and begin reacting appropriate to the invalidated traffic within a few seconds.

Issuer tools

Instead of asking issuers to learn a bunch of new tools and processes, each issuer in the GSMA initiative will have their own issuance-in-a-box tool: a docker container that bundles everything they need, and that is preconfigured to create exactly their evidence contribution in response to some simple signals. Initially, issuers don't even have to host this docker container: Provenant will run a placeholder for them, as the project kicks off, so no party is on another party's critical path. This provides a functional ecosystem immediately, and drastically simplifies the logistics of testing. However, it doesn't accomplish our security goals in the long run, so issuers should take over the management of their docker container whenever they are ready.

We call this docker container an integration agent.

A given issuer's integration agent exposes web service endpoints that can be called (by the issuer or by any other party the issuer authorizes) to issue and revoke credentials. These endpoints are easy to call from the backend of an issuer organization's existing web portals and/or automated services, at whatever points make sense in their current processes. For example, if a brand vetter currently generates a JWT or x509 certificate as the output of their vetting processes, they can simply add a call to generate the associated VVP evidence at the same time. Their integration agent will take care of all the heavy lifting of creating and managing cryptographic keys, building the right data structure, signing the credential, running KERI protocols to talk to witnesses, and transferring it to the new credential holder. This leaves the issuer to concentrate on the infrastructure and business processes where it is already a world expert.

In addition to issuance-in-a-box, Provenant has written a simple web application, exposed at https://voice.sandbox.provenant.net/, that serves as a placeholder or demo of all the evidence-creation workflows for enterprises. It calls the integration agents of all the issuers in the ecosystem. In the long run, service providers may tweak their UIs to expose evidence-creation questions and approvals in existing processes, making this web application unnecessary. However, until those UIs call integration agents organically, all evidence creation UX can be demoed and driven through this web app.

Configuring and monitoring your integration agent

Provenant's placeholder instances of integration agents will be mostly preconfigured. They will enforce some basic security and will be exposed at the following hostnames and ports:

<to do>

Once an integration agent shifts to the control of an issuer's IT/Ops staff, it should be placed inside a trusted perimeter and fronted by a web proxy that exposes it only to callers that the issuer org wants to authorize. Admins may also wish to configure the port and numerous other details. The Integration Agent Operation Guide contains details.

Issuing credentials

Credentials issued by you during this trial should be real, in the sense that they should contain data that you believe to be true, truly signed in reaction to processes that match as closely as possible what you truly do. However, they will also be fake, in the sense that they depend on simulated roots of trust that have no reputation in real life. This means that it is not dangerous for you to experiment, and nobody can use one of your trial credentials to prove anything outside the trial context.

The total number of credentials that you're likely to issue during this trial will be driven by the number of enterprises that we configure for verifiable voice traffic — probably less than a dozen. We can experiment with calls any number of times without changing this number. However, if we experiment with credential issuance multiple times, and if the experiments use your real systems and real integration instead of the simulated ones in the placeholder version of your integration agent, the number of issuances seen by your own systems might go up a bit.

What do you as an issuer actually have to do, to issue credentials in your name?

• As your company's financial officers to give you your company's LEI — or, use the search feature on gleif.org to look it up. If you do not find one, and Provenant can't find one either, then go to GLEIF's LEI issuer table and select a provider to get one. This is a short, self-service process that takes a few minutes of your time and that often completes after an hour or two. It typically costs less than 100 USD. However, it generates a permanent, public record with implications for your company's reputation, particularly in global banking, so it should not be done without conferring with your company's financial officers.

• Ask Provenant to turn your LEI into a bronze vLEI. This is an easy, free, interactive process that takes about 10 minutes.

• Decide how the evidence you already generate (e.g., certificates, tokens, affidavits) will be turned into VVP-compatible evidence. Mostly, this means deciding when you whether you want to issue VVP-compatible evidence in response to external signals or to milestones in an internal process, or both — and sharing with Provenant a schema that documents what data is associated with your evidence. Provenant will respond with a mapping from your evidence to the VVP equivalent, and will configure your integration agent to generate the right kind of data at the right time.

• Discuss internally to decide when you'd like to take over the management of your integration agent, and schedule a transition with Provenant.