Service Definition

[michaelsena]

cip: 
title: Service Definition
author: Joel Thorstensson (@oed), Janko Simonovic (@simonovic86)
discussions-to:
status: Idea
category: Standards
type: RFC
created: 2020-05-22
requires:
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

Simple Summary

Service Definition specifies a document which describes a service.

Abstract

A Service Definition document allows service providers to describe their microservice in a way that makes it easily discoverable and consumable by others. This is especially useful when thinking about services in the context of a user-centric web, where applications may need to interact with various services preferred by a user or that manage their data without having pre-existing relationships with those service providers.

Motivation

There is a need to improve service discoverability.

As the number of microservices and APIs on the web continues to increase at an exponential rate, discoverability becomes a challenge. By creating a service definition for your service, it instantly becomes publicly discoverable and searchable by everyone on the internet.

There is a need to decouple service definitions and endpoints from servers.

When an application does not know which services it may need to rely on to service a user prior to the user arriving at their site, that application needs a simple, permissionless way to dynamically discover the API definition and endpoint of the service they need to interact with. For this reason, service definitions need to be stored in the public domain where they can be seen by anyone at anytime, without needing to create an account or read the docs.

There is a need to eliminate account signups and API keys.

Modern development is trending in the direction of applications that don't manage a backend. Instead, developers are choosing to build lightweight frontends that rely on an ecosystem of composable backend services. Making things even more difficult, in the user-centric model of application development users may bring different services with them to an application, and the application needs to use those services to serve the user. It is infeasible for every application to create accounts with every single web service. For these reasons it is impossible to store an API key on a backend server to authenticate on behalf of a user.

There is a need to define access requirements, including payment.

When account signups and API keys are gone, how can services be authenticated and compensated? By creating service definitions, service providers can specify the access requirements for their service, which may include an authentication signature from a DID, a micropayment, or both. This allows services to serve a wide range of users that aren't direct customers without adding the friction of account signups.

There is a need to unlock interoperability.

Together the needs above all hint towards a future of the web where applications and services need to establish and dissolve fluid, dynamic relationships between each other, often for single interactions. It becomes increasingly important for services to make themselves as interoperable as possible to applications and other services so that they can take advantage of this new paradigm.