Intro and high level architecture

draft-sheffer-wimse-s2s-protocol.md

@@ -25,7 +25,7 @@ venue:
 author:
  -
     fullname: "Brian Campbell"
-    organization: Ping Identity
+    organization: "Ping Identity"
     email: [email protected]
  -
     fullname: "Daniel Feldman"
@@ -52,34 +52,83 @@ TODO Abstract
 
 # Introduction
 
-TODO Introduction
+This document defines authentication and authorization in the context of interaction between two workloads.
+This is the core component of the WIMSE architecture {{?I-D.ietf-wimse-arch}}.
+Assume that Service A needs to call Service B. For simplicity, this document focuses on REST services,
+and the service-to-service call consists of a single HTTP request and its response.
+We define the credentials that both services should possess and how they are used to protect the HTTP exchange.
+
+There are multiple deployment styles in use today, and they result in different security properties.
+We propose to address them differently.
+
+* Many use cases have various middleboxes inserted between pairs of services, resulting in a transport layer
+that is not end-to-end encrypted. We propose to address these use cases by protecting the REST messages at the application
+level ({{app-level}}).
+
+* The other commonly deployed architecture has a mutual-TLS connection between each pair of services. This setup
+can be addressed by a simpler solution ({{mutual-tls}}).
+
+It is an explicit goal of this protocol that a service deployment, and in fact a single call chain,
+can include both architectures. In other words, Service A can call Service B with mutual TLS protection,
+while the next call to Service C is protected at the application level.
+
+For application-level protection we currently propose two alternative solutions, one inspired by DPoP {{?RFC9449}} and
+one which is a profile of HTTP Message Signatures {{!RFC9421}}. The design team believes that we need to pick
+one of these two alternatives for standardization, once we have understood their pros and cons.
 
 ## Deployment Architecture and Message Flow
 
+Regardless of the transport between the workloads, we assume the following logical architecture:
+
 ~~~ aasvg
-+---------+
-|         |
-| This    |
-| is      |
-| a       |
-| box     |
-|         |
-+---------+
++------------+               +------------+
+|            |               |            |
+|            |               | Workload B |
+| Workload A |==============>|            |
+|            |               +------------+
+|            |               |    PEP     |
++------------+               +------------+
+      ^                            ^
+      |                            |
+      |                            |
+      v                            v
++------------+               +------------+
+|            |               |            |
+|  Identity  |               |    PDP     |
+|   Server   |               | (optional) |
+|            |               |            |
++------------+               +------------+
 ~~~
 
+The Identity Server provisions credentials to each of the workloads. At least Workload A (and possibly both) must be provisioned
+with a credential before the call can proceed. Details of communication with the Identity Server are out of scope
+of this document, however we do describe the credential received by the workload.
+
+PEP is a Policy Enforcement Point, the component that allows the call to go through or blocks it. PDP is an optional
+Policy Decision Point, which may be deployed in architectures where policy management is centralized. All details of
+policy management and message authorization are out of scope of this document.
+
+The high-level message flow is as follows:
+
+* Workload A obtains a credential from the Identity Server. This happens periodically, e.g. once every 24 hours.
+* Workload A makes a REST call into Workload B. This is a regular REST call, with the additional protection
+mechanisms defined below.
+* Workload B now authenticates Workload A and decides whether to authorize the call.
+In certain architectures, Workload B may need to consult with an external server to decide whether to accept the call.
+
 # Conventions and Definitions
 
 {::boilerplate bcp14-tagged}
 
-# Application Level Service To Service Authentication
+# Application Level Service To Service Authentication {#app-level}
 
 ## The WIMSE ID Token
 
-## Option 1: DPoP-Inspired Authetication
+## Option 1: DPoP-Inspired Authentication
 
 ## Option 2: Authentication Based on HTTP Message Signatures
 
-# Using Mutual TLS for Service To Service Authentication
+# Using Mutual TLS for Service To Service Authentication {#mutual-tls}
 
 # Security Considerations