Add numbering to high-level sequence (#80)

* Add numbering to high-level sequence

* Typo

* Revise diagram to include the MTLS option

---------

Co-authored-by: ysheffer <[email protected]>

draft-ietf-wimse-s2s-protocol.md

@@ -97,19 +97,23 @@ one of these two alternatives for standardization, once we have understood their
 
 ## Deployment Architecture and Message Flow
 
-Regardless of the transport between the workloads, we assume the following logical architecture:
+Regardless of the transport between the workloads, we assume the following logical architecture
+(numbers refer to the sequence of steps listed below):
 
 ~~~ aasvg
 +------------+               +------------+
+|            |      (1)      |            |
+|            |<=============>|            |
 |            |               |            |
-|            |               | Workload B |
-| Workload A |==============>|            |
-|            |               |   +--------+
-|            |               |   |  PEP   |
+| Workload A |      (3)      | Workload B |
+|            |==============>|            |
+|            |               |            |
+|            |      (5)      |   +--------+
+|            |<==============|   |  PEP   |
 +------------+               +---+--------+
       ^                        ^     ^
-      |                        |     |
-      | +----------------------+     |
+      |            (2)         |     |
+  (2) | +----------------------+     | (4)
       | |                            |
       v v                            v
 +------------+               +------------+
@@ -119,6 +123,7 @@ Regardless of the transport between the workloads, we assume the following logic
 |            |               |            |
 +------------+               +------------+
 ~~~
+{: #high-level-seq title="Sequence of Operations"}
 
 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
@@ -130,12 +135,16 @@ 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 an HTTP call into Workload B. This is a regular HTTP request, with the additional protection
+1. A transport connection is set up. In the case of mutual TLS, this includes authentication of both workloads to
+one another. In the case of application-level security, the TLS connection is typically one-way authenticated,
+and workload-level authentication does not yet take place.
+2. Workload A (and similarly, Workload B) obtains a credential from the Identity Server. This happens periodically, e.g. once every 24 hours.
+3. Workload A makes an HTTP call into Workload B. This is a regular HTTP request, 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.
-* Workload B returns a response to Workload A, which may be an error response or a regular one.
+4. In the case of application-level security, Workload B authenticates Workload A (when using mutual TLS, this happened in step 1).
+In either case, Workload B decides whether to authorize the call.
+In certain architectures, Workload B may need to consult with an external server when making this decision.
+5. Workload B returns a response to Workload A, which may be an error response or a regular one.
 
 # Conventions and Definitions