diff --git a/draft-ietf-oauth-v2-1.md b/draft-ietf-oauth-v2-1.md
index f1c9802..b204dd3 100644
--- a/draft-ietf-oauth-v2-1.md
+++ b/draft-ietf-oauth-v2-1.md
@@ -884,8 +884,7 @@ authorization server during the client registration process.
 
 The redirect URI MUST be an absolute URI as defined by
 {{RFC3986}} Section 4.3.  The redirect URI MAY include an
-"application/x-www-form-urlencoded" formatted query
-component ({{WHATWG.URL}}), which MUST be retained when adding
+query string component ({{query-string-serialization}}), which MUST be retained when adding
 additional query parameters. The redirect URI MUST NOT include a
 fragment component.
 
@@ -1148,9 +1147,8 @@ but the URL is typically provided in the service documentation,
 or in the authorization server's metadata document ({{RFC8414}}).
 
 The authorization endpoint URL MUST NOT include a fragment component,
-and MAY include an "application/x-www-form-urlencoded" formatted
-query component {{WHATWG.URL}}, which MUST be retained when adding
-additional query parameters.
+and MAY include a query string component {{query-string-serialization}},
+which MUST be retained when adding additional query parameters.
 
 The authorization server MUST support the use of the HTTP `GET`
 method Section 9.3.1 of {{RFC9110}} for the authorization endpoint and MAY support
@@ -1184,8 +1182,7 @@ development of the client, or provided in the authorization server's metadata
 document ({{RFC8414}}) and fetched programmatically at runtime.
 
 The token endpoint URL MUST NOT include a fragment component,
-and MAY include an `application/x-www-form-urlencoded` formatted
-query component ({{WHATWG.URL}}).
+and MAY include a query string component {{query-string-serialization}}.
 
 The client MUST use the HTTP `POST` method when making requests to the token endpoint.
 
@@ -1234,8 +1231,8 @@ Client authentication is used for:
 ### Token Request {#token-request}
 
 The client makes a request to the token endpoint by sending the
-following parameters using the `application/x-www-form-urlencoded`
-format per {{application-x-www-form-urlencoded}} with a character encoding of UTF-8 in the HTTP
+following parameters using the form-encoded serialization
+format per {{form-serialization}} with a character encoding of UTF-8 in the HTTP
 request content:
 
 "grant_type":
@@ -1426,12 +1423,7 @@ parameters with the response:
      outside the set %x21 / %x23-5B / %x5D-7E.
 
 The parameters are included in the content of the HTTP response
-using the `application/json` media type as defined by [RFC7159].  The
-parameters are serialized into a JSON structure by adding each
-parameter at the highest structure level.  Parameter names and string
-values are included as JSON strings.  Numerical values are included
-as JSON numbers.  The order of parameters does not matter and can
-vary.
+using the `application/json` media type as defined in {{json-serialization}}.
 
 For example:
 
@@ -1440,7 +1432,7 @@ For example:
     Cache-Control: no-store
 
     {
-     "error":"invalid_request"
+     "error": "invalid_request"
     }
 
 # Grant Types {#obtaining-authorization}
@@ -1543,7 +1535,7 @@ authorization code is the same client that requested it.
 
 The client constructs the request URI by adding the following
 parameters to the query component of the authorization endpoint URI
-using the `application/x-www-form-urlencoded` format, per {{application-x-www-form-urlencoded}}:
+as described by {{query-string-serialization}}:
 
 "response_type":
 :    REQUIRED.  The authorization endpoint supports different sets of request and response
@@ -1690,8 +1682,8 @@ user agent.
 If the resource owner grants the access request, the authorization
 server issues an authorization code and delivers it to the client by
 adding the following parameters to the query component of the
-redirect URI using the `application/x-www-form-urlencoded` format,
-per {{application-x-www-form-urlencoded}}:
+redirect URI using the query string serialization described by
+{{query-string-serialization}}, unless specified otherwise by an extension:
 
 "code":
 :    REQUIRED.  The authorization code is generated by the
@@ -1766,8 +1758,8 @@ algorithm not supported.
 If the resource owner denies the access request or if the request
 fails for reasons other than a missing or invalid redirect URI,
 the authorization server informs the client by adding the following
-parameters to the query component of the redirect URI using the
-`application/x-www-form-urlencoded` format, per {{application-x-www-form-urlencoded}}:
+parameters to the query component of the redirect URI as described
+by {{query-string-serialization}}:
 
 "error":
 :    REQUIRED.  A single ASCII [USASCII] error code from the
@@ -3787,6 +3779,21 @@ and then represented in the content as:
 
     +%25%26%2B%C2%A3%E2%82%AC
 
+# Serializations {#serializations}
+
+Various messages in this specification are serialized using one of the methods described below. This section describes the syntax of these serialization methods; other sections describe when they can and must be used. Note that not all methods can be used for all messages.
+
+## Query String Serialization {#query-string-serialization}
+
+In order to serialize the parameters using the Query String Serialization, the Client constructs the string by adding the parameters and values to the query component of a URL using the application/x-www-form-urlencoded format as defined by {{WHATWG.URL}}. Query String Serialization is typically used in HTTP GET requests.
+
+## Form-Encoded Serialization {#form-serialization}
+
+Parameters and their values are Form Serialized by adding the parameter names and values to the entity body of the HTTP request using the application/x-www-form-urlencoded format as defined by {{application-x-www-form-urlencoded}}. Form Serialization is typically used in HTTP POST requests.
+
+## JSON Serialization {#json-serialization}
+
+The parameters are serialized into a JSON ({{RFC7159}}) object structure by adding each parameter at the highest structure level. Parameter names and string values are represented as JSON strings. Numerical values are represented as JSON numbers. Boolean values are represented as JSON booleans. Omitted parameters and parameters with no value SHOULD be omitted from the object and not represented by a JSON null value, unless otherwise specified. A parameter MAY have a JSON object or a JSON array as its value. The order of parameters does not matter and can vary.
 
 # Extensions {#extensions}