diff --git a/configuration/token-formats.md b/configuration/token-formats.md
index 49d9020..ccb69fe 100644
--- a/configuration/token-formats.md
+++ b/configuration/token-formats.md
@@ -18,7 +18,7 @@ developed and maintained by Microsoft to generate signed and encrypted tokens us
 To protect against token substitution and confused deputy attacks, **OpenIddict 3.0 uses the standard `typ` JWT header to convey the actual token type**.
 This mechanism replaces the private `token_usage` claim used for the same purpose in previous versions of OpenIddict.
 
-As required by the [JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens draft](https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-2.1),
+As required by the [JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens specification](https://datatracker.ietf.org/doc/html/rfc9068),
 **access tokens produced by OpenIddict 3.0 are always issued with a `"typ": "at+jwt"` header** while identity tokens still use `"typ": "JWT"` for backward compatibility.
 Other types of tokens – only accepted by OpenIddict's own endpoints – use private token types prefixed by `oi_`.
 
diff --git a/guide/migration/20-to-30.md b/guide/migration/20-to-30.md
index fa69791..7b5c1d8 100644
--- a/guide/migration/20-to-30.md
+++ b/guide/migration/20-to-30.md
@@ -76,9 +76,9 @@ services.AddOpenIddict()
     .AddServer(options =>
     {
         options.UseAspNetCore()
-              .EnableAuthorizationEndpointPassthrough()
-              .EnableLogoutEndpointPassthrough()
-              .EnableTokenEndpointPassthrough();
+               .EnableAuthorizationEndpointPassthrough()
+               .EnableLogoutEndpointPassthrough()
+               .EnableTokenEndpointPassthrough();
     });
 ```
 
@@ -108,8 +108,8 @@ services.AddOpenIddict()
     .AddServer(options =>
     {
         options.UseAspNetCore()
-              .EnableAuthorizationRequestCaching()
-              .EnableLogoutRequestCaching();
+               .EnableAuthorizationRequestCaching()
+               .EnableLogoutRequestCaching();
     });
 ```
 
@@ -117,7 +117,7 @@ services.AddOpenIddict()
 
 If you use JSON.NET to serialize or deserialize `OpenIdConnectMessage`, `OpenIdConnectRequest` or `OpenIdConnectResponse` instances,
 consider moving to `System.Text.Json` when migrating to OpenIddict 3.0, as 3.0 no longer includes a built-in JSON.NET `JsonConverter` for their
-equivalent in 3.0: `OpenIddictMessage`, `OpenIddictRequest` or `OpenIddictResponse`.
+equivalent in 3.0 (i.e `OpenIddictMessage`, `OpenIddictRequest` and `OpenIddictResponse`).
 
 In most cases, this should be as simple as replacing `JsonConvert.SerializeObject()`/`JsonConvert.DeserializeObject()`
 by their `System.Text.Json` equivalent: `JsonSerializer.Serialize()`/`JsonSerializer.Deserialize()`.
@@ -140,12 +140,12 @@ In 3.0, the constants used as the ASP.NET Core authentication schemes have chang
 > [!NOTE]
 > In 3.0, the OpenIddict server ASP.NET Core handler supports authenticating userinfo requests. As such, if you use the pass-through mode
 > to handle userinfo requests in your own userinfo MVC action, consider using `OpenIddictServerAspNetCoreDefaults.AuthenticationScheme`
-> instead of `OpenIddictValidationAspNetCoreDefaults.AuthenticationScheme` for your userinfo endpoint to avoid duplicate access token validation.
+> instead of `OpenIddictValidationAspNetCoreDefaults.AuthenticationScheme` for your userinfo endpoint to avoid validating access tokens twice.
 
 ## Update your application to work with the new `scope` format
 
-In OpenIddict 3.0, the format of the `scope` claim used in JWT tokens has changed from a JSON array to a single space-separated claim to match
-[the JWT access token specification](https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-12). To ensure your authorization policies
+In OpenIddict 3.0, the format of the `scope` claim used in JWT tokens has changed from a JSON array to a single space-separated claim
+to match [the JWT access token specification](https://datatracker.ietf.org/doc/html/rfc9068). To ensure your authorization policies
 still work after migrating, consider using the `principal.HasScope()` extension to determine whether a scope has been granted:
 
 ```csharp