Service Level Agreements, Trust, and the ITN (or Give it a DID!)
In our previous blogs, we have explained how the ITN (Integrated Trust Network) addresses some of the key issues of digital business transactions. Specifically, how the cost of trust on the Internet is growing exponentially, the need for IoT devices to have trusted identities including trusted identifiers that multiple stakeholders can use, and the need for devices to have trusted locations without actually exposing their location.
In this blog, we explain how the ITN addresses the need to give trusted identities and trusted locations to virtual resources, and not just to physical resources. For this, we use the example of telecoms that buy and sell data connectivity services to one another. Connectivity and its complexity are present all the time, but this is a hidden resource that we very often take for granted.
Hundreds of thousands of enterprises across the globe buy data connectivity services from their trusted (retail) communications service providers. Such connectivity services are the lifeblood of countless businesses today. These services play key roles in connecting enterprise sites, remote employees, and devices with each other and, equally importantly, with cloud services.
Such connectivity requirements are seldom achievable with data networks controlled by one communications service provider. Typically, the enterprise’s retail service provider has to complete network connectivity for the enterprise customer by buying supplementary connectivity services from wholesale data network operators to reach locations that, by itself, the retail service provider could not include in its offering (‘off-net’). In other words, communications service providers worldwide are constantly assembling connectivity services, not only from their own inventory but also from wholesale suppliers.
These connectivity services being transacted between retailers and wholesalers, or buyers and sellers, can last from only a few minutes to as long as a few years. A so-called ‘end-to-end’ connectivity service can comprise multiple wholesale connectivity segments supplied by a number of suppliers. Failure of one of these segments results in the failure of the whole end-to-end connectivity service and lost business for the enterprise using that service.
For that reason, such connectivity services are sold with Service Level Agreements (SLA) which stipulate the level of performance and reliability of the service being sold and the penalties to be paid if the service does not meet the requirements in the SLA. This regulates both the relationship between the final customer and the retailer as well as between the retailer and any wholesalers that are involved in the connectivity service.
The various parties to this service need to periodically verify the performance parameters and agree on any resulting credits owed to them. This activity, along with the subsequent handshakes, reconciliations, and disputes, may involve extensive effort, delays, and financial impact on both buyer and seller.
To better understand the burden resulting from this simple checking and invoicing activity — called SLA enforcement, billing, and settlement — we need to understand the possible scale of the task: A medium-sized global telecom operator may have thousands of active circuits, each comprising at least three network segments from suppliers, hence three different agreements. This translates into tens of thousands of separate SLA enforcements — and potentially thousands of disputes — to be periodically processed. Doing this manually, as is often the case today, typically means that only a small proportion of circuits are periodically checked for SLA exceptions and SLA credits claimed. It also means that the customer experience is more than likely not optimal. In other words, buyers are not getting credits owed to them and customers may not be as happy as they should be with the quality of the product.
Automation is clearly the answer. By using smart contracts based on DLT (Distributed Ledger Technology, AKA ‘blockchain’) to achieve automation of SLA assurance, buyers will get a larger proportion of credits owed to them, and ultimately, the customer experience will be improved.
Smart contracts are executable programs in the form of if-then-else statements that run on blockchains. Their advantage is that smart contracts running on a blockchain are mutually agreed upon between buyer and seller, run automatically, and cannot be tampered with (immutable). Smart contracts synchronize the business ‘states’ between buyer and seller referencing the same set of rules and commonly agreed resources. In our example, the retailer and the wholesalers will use smart contracts to capture the rules of the mutually agreed SLA and automatically use data provided by both buyer and seller in real-time to calculate and detect SLA exceptions and automatically calculate penalties owed to the buyer.
Automation implemented by the “shared” smart contract on the blockchain allows for substantial simplification of the SLA process as it provides trustable and deterministic outcomes based on the trustable inputs that all parties provide.
So to summarize, SLA assurance is a real and significant business problem which can be solved by business automation using smart contracts on blockchains. The remaining question is how decentralized identity services — such as the ITN — are an important part of the automation solution.
The SLAs in this example relate to an intangible product — namely connectivity services. We cannot touch them but they are critical for business. They are supplied by multiple service providers and referenced by multiple SLAs. As stated previously, they have life cycles just like tangible products that might last minutes or years. They are ‘born’ (they often get ‘birth certificates’), maintained, and switched off. Connectivity services need to be identified securely and effectively by multiple stakeholders or supply chain participants during that lifecycle. Connectivity services effectively have identities that are constantly evolving. Moreover, connectivity services comprise many components such as smaller connectivity services that form segments of the end-to-end connectivity service, interconnection points (ENNIs, or External Network to Network Interfaces, and UNIs, or User Network Interfaces), and so on. These in turn need to be uniquely identified and their performance tracked for the purposes of the overall SLA assurance process.
Coming back to our example of the mid-sized telecom earlier, we can see that SLA assurance for tens of thousands of connectivity services (or circuits) might well mean tracking in real-time hundreds of thousands of service components across hundreds or even thousands of partners.
If each such component needs an identifier for tracking purposes, and an identity associated with it that can be recognized and trusted in real-time by multiple stakeholders, we can quickly see that we need a highly scalable trusted identity service (certificate authority) that is trusted by all the stakeholders even for the most dynamic and short-lasting connectivity services.
Just like we need to provide universally recognized and trusted identifiers for things, we need to do the same for intangible or virtual resources like connectivity services. Not only do these virtual resources need to have universal identifiers, but they also need to have trusted identities behind those identifiers. We can see that the cost of trust for these connectivity services must be very low in order to scale to millions of connectivity services over the coming years.
Let’s use an example to illustrate this and how the ITN addresses this problem.
Let’s say that a retail service provider (B) as the Buyer buys a connectivity service from a wholesale operator (S), the Seller. S guarantees certain performance levels for the connectivity service (or ‘circuit’) to B as part of the SLA between them. Both B and S need to refer to the circuit with an identifier so that when they check performance, they know that they are both referring to the same circuit. Think of the identifier as a serial number for the circuit. Both B and S need to trust that the circuit is being referenced using the correct and trusted identifier. Any performance data recorded for the purposes of making claims B for penalties to be paid by S needs to be associated with that identifier. The smart contract processing the performance data needs to reference that identifier. The SLA also needs an identifier with which to associate the SLA with the circuit.
The ITN provides the globally unique W3C standards-based identifiers — DIDs, or Decentralized Identifiers — for these circuits. Once a circuit has a DID, performance data can be recorded for that DID and checked for conformance with the SLA (via the SLA’s DID). All DID management is handled by the ITN. By virtue of the ITN being a decentralized identity service, it is accessible to all (censorship-resistant), cannot be manipulated, and cannot be turned off. Being able to use the ITN to manage DIDs for connectivity services means that data communication service providers can build and manage trusted identities for them in a highly scalable manner. These trusted identities capture information such as the ‘birth’ of the service, its end, its performance and ‘reputation’, the trusted identity of the supplier and its reputation, etc.
If this is applicable to connectivity services, it is equally applicable to any virtual resource or service in the telecom world — for example, compute services (IaaS), cybersecurity services (SASE and SSE), interconnections (ENNI), and so on. And if it is applicable to virtual resources and services in the telecom world, then it can be applied to any virtual resource, service, and product in any industry.
