diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md
index 1b82a11..3a09939 100644
--- a/openid-caep-interoperability-profile-1_0.md
+++ b/openid-caep-interoperability-profile-1_0.md
@@ -209,11 +209,11 @@ Verification as defined in {{SSF}} Section 8.1.4.
 The Transmitter Configuration Metadata MUST include the `authorization_schemes`
 field and its value MUST include the value:
 
-```json
+~~~ json
 {
   "spec_urn": "urn:ietf:rfc:6749"
 }
-```
+~~~
 
 ### Streams {#transmitter-common-stream-configuration}
 
@@ -278,7 +278,7 @@ methods:
 
 ### JWKS URI {#receiver-jwks-uri}
 
-The Receiver MUST obtain the Transmitter’s signing key(s) using the `jwks_uri`
+The Receiver MUST obtain the Transmitter's signing key(s) using the `jwks_uri`
 from the Transmitter Configuration Metadata, as defined in {{SSF}} Section 7.1.
 
 ### Authorization Schemes {#receivers-authorization-schemes}
@@ -356,7 +356,44 @@ at least one of subject identifier formats specified in this section.
 All events MUST be signed using the `RS256` algorithm using a minimum of
 2048-bit keys.
 
-## OAuth Service
+## OAuth Support
+
+Implementations MUST support OAuth 2.0 {{RFC6749}}. The following diagram
+illustrates the OAuth flow between the SSF Transmitter, SSF Receiver, and the
+Authorization Server.
+
+~~~ascii
++--------------+
+|              |                             +-----------------+
+|              | 1. AS Metadata Request      |                 |
+|              |---------------------------->|                 |
+|              |<----------------------------|  Authorization  |
+|              | Client obtains AS Metadata  |   Server (AS)   |
+|    Client    |                             |       --        |
+|(SSF Receiver)|                             | Trusted by the  |
+|              | 2. OAuth Exchange           | SSF Transmitter |
+|              |<--------------------------->|                 |
+|              | Client obtains access token |                 |
+|              |                             |                 |
+|              |                             +-----------------+
+|              |
+|              | 3. SSF API Request with     +-----------------+
+|              |    Access Token             | Resource Server |
+|              |---------------------------->|(SSF Transmitter)|
++--------------+                             +-----------------+
+~~~
+{: #figintro title="OAuth Support for CAEP Interoperability Profile"}
+
+1. The SSF Receiver/Client makes a request to fetch the Authorization Server
+metadata at its Metadata URL. The Metadata URL can be discovered from the
+Resource Server via {{OPRM}} or out-of-band. The Authorization Server responds
+with the Authorization Server metadata document as described in {{RFC8414}}.
+
+2. The SSF Receiver/Client obtains an access token from the Authorization Server
+using either the authorization code grant or the client credentials grant.
+
+3. The SSF Receiver/Client makes a request to the Transmitter's protected
+endpoints using the access token.
 
 ### Authorization Server
 
@@ -379,8 +416,9 @@ considerations.
 
 ### OAuth Scopes
 
-Depending on the features supported by the OAuth service and the SSF APIs, the
-OAuth Client SHALL discover the OAuth scopes as follows:
+Depending on the features supported by the Authorization Server and the SSF
+APIs, the OAuth Client SHALL discover the OAuth scopes that MAY be used as
+follows:
 
 * If the Resource Server, hosting SSF configuration APIs, supports OAuth
 Protected Resource Metadata {{OPRM}} then the client MUST obtain the required