Various fixes

Author: maartenba

src/content/docs/identityserver/tokens/client-authentication.md

@@ -31,7 +31,7 @@ Duende IdentityServer has built-in support for various client credential types a
 All information in this section also applies to [API secrets](/identityserver/reference/models/api-resource/) for introspection.
 :::
 
-**We recommend using asymmetric client credentials like the [*private key jwt*](#private-key-jwts) or [*Mutual TLS*](#mutual-tls-client-certificates) authentication method over shared secrets.**
+**We recommend using asymmetric client credentials like the [*private key JWT*](#private-key-jwts) or [*Mutual TLS (mTLS)*](#mutual-tls-client-certificates) authentication method over shared secrets.**
 
 ### Assigning Secrets
 
@@ -60,7 +60,7 @@ client.ClientSecrets = new[] { primary, secondary };
 ### Secret Parsing
 During request processing, the secret must be somehow extracted from the incoming request. The various specs describe a couple of options, e.g. as part of the authorization header or the body payload.
 
-It is the job of implementations of the [ISecretParser](/identityserver/reference/models/secrets#duendeidentityservervalidationisecretparser) interface to accomplish this. You can add secret parsers by calling the `AddSecretParser()` service provider extension method.
+It is the job of implementations of the [`ISecretParser`](/identityserver/reference/models/secrets#duendeidentityservervalidationisecretparser) interface to accomplish this. You can add secret parsers by calling the `AddSecretParser()` service provider extension method.
 
 The following secret parsers are part of Duende IdentityServer:
 
@@ -86,7 +86,7 @@ The following secret parsers are part of Duende IdentityServer:
 
 
 ### Secret Validation
-It is the job of implementations of the [ISecretValidator](/identityserver/reference/models/secrets.md#duendeidentityservermodelparsedsecret) interface to validate the extracted credentials.
+It is the job of implementations of the [`ISecretValidator`](/identityserver/reference/models/secrets.md#duendeidentityservermodelparsedsecret) interface to validate the extracted credentials.
 
 You can add secret validators by calling the `AddSecretValidator()` service provider extension method.
 

src/content/docs/identityserver/tokens/index.md

@@ -25,9 +25,10 @@ While the `authorize` endpoint can be used for some special cases, you typically
 The following token types are supported.
 
 ### Identity Token
-During user authentication, your IdentityServer collects data about the user, e.g. authentication method, authentication time, some protocol information and a unique identifier for the user that was authenticated, to communicate back to the client application “what happened at the token service”.
+During user authentication, your IdentityServer collects data about the user, e.g. authentication method, authentication time, some protocol information, and a unique identifier for the user that was authenticated.
+This data is used to communicate back to the client application “what happened at the token service”.
 
-This data must be sent in a format that is both tamper proof and that allows the client to authenticate the issuer. In OIDC this format is JSON – and the way to add the above security properties to a JSON object is by wrapping it in a JWT (along with JWS, JWA and JWK) – hence the name identity `token`.
+This data must be sent in a format that is both tamperproof and allows the client to authenticate the issuer. In OIDC this format is JSON. The way to add the above security properties to a JSON object is by wrapping it in a JWT (along with JWS, JWA, and JWK) – hence the name identity *token*.
 
 The data includes token lifetime information (`exp`, `iat`, `nbf`), the authentication method (`amr`) and time (`auth_time`), the authentication source (`idp`), the session ID (`sid`) and information about the user (`sub` and `name`).
 

src/content/docs/identityserver/upgrades/identityserver4-v3-to-duende-identityserver-v6.md

@@ -13,19 +13,19 @@ redirect_from:
 ---
 
 This upgrade guide covers upgrading from IdentityServer4 v3.1.x to Duende IdentityServer v6.
-This upgrade is a complex one because the configuration object model had some non-trivial changes from IdentityServer4 v3 to IdentityServer4 v4.
+This upgrade is more complex because the configuration object model had some non-trivial changes from IdentityServer4 v3 to IdentityServer4 v4.
 
 In short, in IdentityServer4 v3 there was a parent-child relationship between the ApiResources and the ApiScopes.
 Then in IdentityServer4 v4 the ApiScopes was promoted to be its own top-level configuration. 
 This meant that the child collection under the ApiResources was renamed to ApiResourcesScopes and it contained a reference to the new top-level ApiScopes.
 
 If you were using a database for this configuration, then this means that configuration changed from a parent-child, to two top-level tables with a join table between them (to put it loosely). The new ApiResourcesScopes table was created to act as that join table.
 
-Also, all the prior tables that were associated with the ApiResources were prefixed with "Api" and that prefix became "ApiResource" to better indicate the association. 
+Also, all the prior tables associated with the `ApiResources` were prefixed with "Api" and that prefix became "ApiResource" to better indicate the association. 
 Then any new tables associated with the new top-level ApiScopes have the "ApiScope" prefix to indicate that association.
 
-In order to properly update the database, the easiest approach is to first update to the latest of IdentityServer4 v4. 
-Once that's complete, then it's very simple to move to Duende IdentityServer v5.
+To properly update the database, the easiest approach is to first update to the latest of IdentityServer4 v4. 
+Once that's complete, then it's straightforward to move to Duende IdentityServer v5.
 
 There is a sample project for this migration exercise. It is located [here](https://github.com/DuendeSoftware/UpgradeSample-IdentityServer4-v3).
 
@@ -50,7 +50,7 @@ If you're using any of the other IdentityServer4 packages, such as `IdentityServ
 
 If you are using a [database](/identityserver/data) for your configuration and operational data, then there is a bit of work.
 The reason is that for this type of schema restructuring EntityFramework Core's migrations can lose existing data.
-To handle this, the conversation from the old schema to the new will be performed by custom SQL.
+To handle this, custom SQL will perform the conversation from the old schema to the new.
 This is only needed for the configuration database, not the operational one so normal migrations will suffice for the operational database.
 
 First for the operational database, we can apply EF Core migrations.