DI -> (ASP.NET Core) service provider

src/content/docs/accesstokenmanagement/advanced/client-credentials.md

@@ -12,7 +12,7 @@ The most common way to use the access token management for machine to machine co
 
 ## Client options
 
-You can add token client definitions to your host while configuring the DI container, e.g.:
+You can add token client definitions to your host while configuring the ASP.NET Core service provider, e.g.:
 
 ```cs
 services.AddClientCredentialsTokenManagement()
@@ -53,7 +53,7 @@ services.Configure<ClientCredentialsClient>("invoices", client =>
 });
 ```
 
-Or use the `IConfigureNamedOptions` if you need access to the DI container during registration, e.g.:
+Or use the `IConfigureNamedOptions` if you need access to the ASP.NET Core service provider during registration, e.g.:
 
 ```cs
 public class ClientCredentialsClientConfigureOptions : IConfigureNamedOptions<ClientCredentialsClient>

src/content/docs/accesstokenmanagement/advanced/user-tokens.md

@@ -12,7 +12,7 @@ The most common way to use the access token management for interactive web appli
 
 ## General options
 
-You can pass in some global options when registering token management in DI.
+You can pass in some global options when registering token management in the ASP.NET Core service provider.
 
 * `ChallengeScheme` - by default the OIDC configuration is inferred from the default challenge scheme. This is recommended approach. If for some reason your OIDC handler is not the default challenge scheme, you can set the scheme name on the options
 * `UseChallengeSchemeScopedTokens` - the general assumption is that you only have one OIDC handler configured. If that is not the case, token management needs to maintain multiple sets of token artefacts simultaneously. You can opt in to that feature using this setting.

src/content/docs/accesstokenmanagement/blazor-server.md

@@ -21,9 +21,9 @@ Fortunately, Duende.AccessTokenManagement provides a straightforward solution to
 
 Since the tokens cannot be managed in the authentication session, you need to store them somewhere else. The options include an in-memory data structure, a distributed cache like redis, or a database. Duende.AccessTokenManagement describes this store for tokens with the *IUserTokenStore* interface. In non-blazor scenarios, the default implementation that stores the tokens in the session is used. In your Blazor server application, you'll need to decide where you want to store the tokens and implement the store interface.
 
-The store interface is very simple. `StoreTokenAsync` adds a token to the store for a particular user, `GetTokenAsync` retrieves the user's token, and *ClearTokenAsync* clears the tokens stored for a particular user. A sample implementation that stores the tokens in memory can be found in the *ServerSideTokenStore* in the [*BlazorServer* sample](https://github.com/DuendeSoftware/foss/tree/main/access-token-management/samples/BlazorServer).
+The store interface is straightforward. `StoreTokenAsync` adds a token to the store for a particular user, `GetTokenAsync` retrieves the user's token, and *ClearTokenAsync* clears the tokens stored for a particular user. A sample implementation that stores the tokens in memory can be found in the *ServerSideTokenStore* in the [*BlazorServer* sample](https://github.com/DuendeSoftware/foss/tree/main/access-token-management/samples/BlazorServer).
 
-Register your token store in the DI container and tell Duende.AccessTokenManagement to integrate with Blazor by calling `AddBlazorServerAccessTokenManagement<TTokenStore>`:
+Register your token store in the ASP.NET Core service provider and tell Duende.AccessTokenManagement to integrate with Blazor by calling `AddBlazorServerAccessTokenManagement<TTokenStore>`:
 
 ```cs
 builder.Services.AddOpenIdConnectAccessTokenManagement()
@@ -64,7 +64,7 @@ Once registered and initialized, Duende.AccessTokenManagement will keep the stor
 
 ## Retrieving And Using Tokens
 
-If you've registered your token store with `AddBlazorServerAccessTokenManagement`, Duende.AccessTokenManagement will register the services necessary to attach tokens to outgoing HTTP requests automatically, using the same API as a non-blazor application. You inject an HTTP client factory and resolve named HTTP clients where ever you need to make HTTP requests, and you register the HTTP client's that use access tokens in the DI system with our extension method:
+If you've registered your token store with `AddBlazorServerAccessTokenManagement`, Duende.AccessTokenManagement will register the services necessary to attach tokens to outgoing HTTP requests automatically, using the same API as a non-blazor application. You inject an HTTP client factory and resolve named HTTP clients where ever you need to make HTTP requests, and you register the HTTP client's that use access tokens in the ASP.NET Core service provider with our extension method:
 
 ```cs
 builder.Services.AddUserAccessTokenHttpClient("demoApiClient", configureClient: client =>

src/content/docs/accesstokenmanagement/web-apps.md

@@ -176,7 +176,7 @@ public async Task<IActionResult> CallApi()
 
 ### HTTP Client Factory
 
-Last but not least, if you registered clients with the factory, you can simply use them. They will try to make sure that a current access token is always sent along. If that is not possible, ultimately a 401 will be returned to the calling code.
+Last but not least, if you registered clients with the factory, you can use them. They will try to make sure that a current access token is always sent along. If that is not possible, ultimately a 401 will be returned to the calling code.
 
 ```cs
 public async Task<IActionResult> CallApi()

src/content/docs/accesstokenmanagement/workers.md

@@ -19,7 +19,7 @@ Have a look for the `Worker` project in the [samples folder](https://github.com/
 
 Start by adding a reference to the `Duende.AccessTokenManagement` NuGet package to your application.
 
-You can add the necessary services to the DI system by calling `AddClientCredentialsTokenManagement()`. After that you can add one or more named client definitions by calling `AddClient`.
+You can add the necessary services to the ASP.NET Core service provider by calling `AddClientCredentialsTokenManagement()`. After that you can add one or more named client definitions by calling `AddClient`.
 
 ```cs
 // default cache

src/content/docs/bff/architecture/ui-hosting.md

@@ -47,7 +47,7 @@ development time. Visual Studio includes SPA templates that start up a SPA and p
 Samples of Duende.BFF that take this approach using [React](/bff/samples#reactjs-frontend)
 and [Angular](/bff/samples#angular-frontend) are available.
 
-Microsoft's templates are easy-to-use at dev time from Visual Studio. They allow you to simply run the solution, and the
+Microsoft's templates are easy-to-use at dev time from Visual Studio. They allow you to run the solution, and the
 template proxies requests to the front end for you. At deploy time, that proxy is removed and the static assets of the
 site are served by the static file middleware.
 

src/content/docs/bff/fundamentals/options.md

@@ -97,7 +97,7 @@ builder.Services.AddBff(options =>
 * ***EnableSessionCleanup***
 
     Indicates if expired server side sessions should be cleaned up.
-    This requires an implementation of IUserSessionStoreCleanup to be registered in the DI system.
+    This requires an implementation of IUserSessionStoreCleanup to be registered in the ASP.NET Core service provider.
     Defaults to *false*.
 
 * ***SessionCleanupInterval***

src/content/docs/bff/fundamentals/session/management/index.md

@@ -16,7 +16,7 @@ Duende.BFF adds endpoints for performing typical session-management operations s
 
 In addition, Duende.BFF adds an implementation of the OpenID Connect back-channel notification endpoint to overcome the restrictions of third party cookies in front-channel notification in modern browsers.
 
-You enable the endpoints by adding the relevant services into the DI container:
+You enable the endpoints by adding the relevant services into the ASP.NET Core service provider:
 
 ```csharp
 // Program.cs

src/content/docs/bff/fundamentals/session/management/silent-login.md

@@ -21,7 +21,7 @@ The expected usage pattern is that the application code loads in the browser and
 
 This non-interactive design relies upon the use of an *iframe* to make the silent login request.
 The result of the silent login request in the *iframe* will then use *postMessage* to notify the parent window of the outcome.
-If the result is that a session has been established, then the application logic can either re-trigger a call to the *User Endpoint*, or simply reload the entire page (depending on the preferred design). If the result is that a session has not been established, then the application redirects to the login endpoint to log the user in interactively.
+If the result is that a session has been established, then the application logic can either re-trigger a call to the *User Endpoint*, or reload the entire page (depending on the preferred design). If the result is that a session has not been established, then the application redirects to the login endpoint to log the user in interactively.
 
 To trigger the silent login, the application code must have an *iframe* and then set its *src* to the silent login endpoint.
 For example in your HTML:

src/content/docs/bff/fundamentals/session/server-side-sessions.md

@@ -61,7 +61,7 @@ builder.Services.AddBff(options => {
     .AddServerSideSessions();
 ```
 
-This requires an implementation of [*IUserSessionStoreCleanup*](/bff/extensibility/sessions#user-session-store-cleanup) in the DI system.
+This requires an implementation of [*IUserSessionStoreCleanup*](/bff/extensibility/sessions#user-session-store-cleanup) in the ASP.NET Core service provider.
 
 If using Entity Framework Core, then the *IUserSessionStoreCleanup* implementation is provided for you when you use *AddEntityFrameworkServerSideSessions*.
 Just enable session cleanup:

src/content/docs/bff/upgrading/bff-v2-to-v3.md

@@ -57,7 +57,7 @@ Here are common scenario's for implementing your own *IHttpTransformerFactory* a
 
 If you used a custom implementation of `IHttpTransformerFactory` to change the default behavior of
 `MapRemoteBffApiEndpoint()`,
-for example to add additional transforms, then you can now inject a custom delegate into the DI container:
+for example to add additional transforms, then you can now inject a custom delegate into the ASP.NET Core service provider:
 
 ```csharp
 services.AddSingleton<BffYarpTransformBuilder>(CustomDefaultYarpTransforms);

src/content/docs/identitymodel/endpoints/discovery.md

@@ -129,19 +129,16 @@ var disco = await cache.GetAsync();
 if (disco.IsError) throw new Exception(disco.Error);
 ```
 
-You can specify the cache duration using the `CacheDuration` property
-and also specify a custom discovery policy by passing in a
-`DiscoveryPolicy` to the constructor.
+You can specify the cache duration using the `CacheDuration` property and also specify a custom discovery policy by
+passing in a `DiscoveryPolicy` to the constructor.
 
 ### Caching And HttpClient Instances
 
-By default, the discovery cache will create a new instance of
-`HttpClient` every time it needs to access the discovery endpoint. You
-can modify this behavior in two ways, either by passing in a pre-created
-instance into the constructor, or by providing a function that will
-return an `HttpClient` when needed.
+By default, the discovery cache will create a new instance of `HttpClient` every time it needs to access the discovery
+endpoint. You can modify this behavior in two ways, either by passing in a pre-created instance into the constructor,
+or by providing a function that will return an `HttpClient` when needed.
 
-The following code will set up the discovery cache in DI and will use the
+The following code will set up the discovery cache in the ASP.NET Core service provider and will use the
 `HttpClientFactory` to create clients:
 
 ```csharp

src/content/docs/identityserver/aspnet-identity.md

@@ -39,9 +39,9 @@ builder.Services.AddIdentityServer()
 This configures IdentityServer to use the ASP.NET Identity implementations of [IUserClaimsPrincipalFactory](https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.identity.iuserclaimsprincipalfactory-1) to convert the user data into claims, `IResourceOwnerPasswordValidator` to support the [password grant type](/identityserver/tokens/password-grant/), and `IProfileService` which uses the `IUserClaimsPrincipalFactory` to add [claims](/identityserver/fundamentals/claims) to tokens.
 It also configures some of ASP.NET Identity's options for use with IdentityServer (such as claim types to use and authentication cookie settings).
 
-If you need to use your own implementation of `IUserClaimsPrincipalFactory`, then that is supported. Our implementation of the `IUserClaimsPrincipalFactory` will use the decorator pattern to encapsulate yours. For this to work properly, ensure that your implementation is registered in the DI system prior to calling the IdentityServer `AddAspNetIdentity` extension method.
+If you need to use your own implementation of `IUserClaimsPrincipalFactory`, then that is supported. Our implementation of the `IUserClaimsPrincipalFactory` will use the decorator pattern to encapsulate yours. For this to work properly, ensure that your implementation is registered in the ASP.NET Core service provider prior to calling the IdentityServer `AddAspNetIdentity` extension method.
 
-The `IUserProfileService` interface has two methods that IdentityServer uses to interact with the user store. The profile service added for ASP.NET Identity implements `GetProfileDataAsync` by invoking the `IUserClaimsPrincipalFactory` implementation registered in the dependency injection container. The other method on `IProfileService` is `IsActiveAsync` which is used in various places in IdentityServer to validate that the user is (still) active. There is no built-in concept in ASP.NET Identity to inactive users, so our implementation is simply hard coded to return `true`. If you extend the ASP.NET Identity user with enabled/disabled functionality you should derive from our `ProfileService<TUser>` and override *IsUserActiveAsync(TUser user)* to check your custom enabled/disabled flags.
+The `IUserProfileService` interface has two methods that IdentityServer uses to interact with the user store. The profile service added for ASP.NET Identity implements `GetProfileDataAsync` by invoking the `IUserClaimsPrincipalFactory` implementation registered in the dependency injection container. The other method on `IProfileService` is `IsActiveAsync` which is used in various places in IdentityServer to validate that the user is (still) active. There is no built-in concept in ASP.NET Identity to inactive users, so our implementation is hard coded to return `true`. If you extend the ASP.NET Identity user with enabled/disabled functionality you should derive from our `ProfileService<TUser>` and override *IsUserActiveAsync(TUser user)* to check your custom enabled/disabled flags.
 
 ## Template
 Alternatively, you can use the `isaspid` [template](/identityserver/overview/packaging#templates) to create a starter IdentityServer host project configured to use ASP.NET Identity. See the [Quickstart Documentation](/identityserver/quickstarts/5-aspnetid/) for a detailed walkthrough.

src/content/docs/identityserver/configuration/dcr.md

@@ -73,7 +73,7 @@ needs an implementation of this interface. You can either use the built-in
 Entity Framework based implementation, or implement the interface yourself. See
 [the IClientConfigurationStore reference](/identityserver/reference/stores/) for
 more details. If you wish to use the built-in implementation, install its NuGet
-package and add it to DI.
+package and add it to the ASP.NET Core service provider.
 
 ```bash title=Terminal
 dotnet add package Duende.IdentityServer.Configuration.EntityFramework
@@ -128,7 +128,7 @@ needs an implementation of this interface. You can either use the built-in
 Entity Framework-based implementation, or implement the interface yourself. See
 [the IClientConfigurationStore reference](/identityserver/reference/stores/client-store/) for
 more details. If you wish to use the built-in implementation, install its NuGet
-package and add it to DI.
+package and add it to the ASP.NET Core service provider.
 
 ```bash title=Terminal
 dotnet add package Duende.IdentityServer.Configuration.EntityFramework

src/content/docs/identityserver/data/configuration.md

@@ -28,7 +28,7 @@ The stores used in Duende IdentityServer are:
 
 ## Registering Custom Stores
 
-Custom implementations of the stores must be registered in the DI system.
+Custom implementations of the stores must be registered in the ASP.NET Core service provider.
 There are [convenience methods](/identityserver/reference/di/#configuration-stores) for registering these.
 For example:
 
@@ -49,7 +49,7 @@ same data.
 
 Duende IdentityServer provides [convenience methods](/identityserver/reference/di#caching-configuration-data) to
 enable caching data from the various stores.
-The caching implementation relies upon an `ICache<T>` service and must also be added to DI.
+The caching implementation relies upon an `ICache<T>` service and must also be added to the ASP.NET Core service provider.
 For example:
 
 ```cs

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

@@ -15,7 +15,7 @@ Duende IdentityServer is backed by two kinds of data:
 * [Configuration Data](/identityserver/data/configuration/)
 * [Operational Data](/identityserver/data/operational/)
 
-Data access is abstracted by store interfaces that are registered in the DI system.
+Data access is abstracted by store interfaces that are registered in the ASP.NET Core service provider.
 These store interfaces allow IdentityServer to access the data it needs at runtime when processing requests.
 You can implement these interfaces yourself and thus can use any database you wish.
 If you prefer a relational database for this data, then we provide [EntityFramework Core](/identityserver/data/ef/) implementations.

src/content/docs/identityserver/data/operational.md

@@ -38,7 +38,7 @@ The persistence for grants is abstracted behind two interfaces:
 
 ### Registering Custom Stores
 
-Custom implementations of `IPersistedGrantStore`, and/or `IDeviceFlowStore` must be registered in the DI system.
+Custom implementations of `IPersistedGrantStore`, and/or `IDeviceFlowStore` must be registered in the ASP.NET Core service provider.
 For example:
 
 ```cs
@@ -77,7 +77,7 @@ The [ISigningKeyStore](/identityserver/reference/stores/signing-key-store/) is t
 
 ### Registering a custom signing key store
 
-To register a custom signing key store in the DI container, there is a `AddSigningKeyStore` helper on the `IIdentityServerBuilder`.
+To register a custom signing key store in the ASP.NET Core service provider, there is a `AddSigningKeyStore` helper on the `IIdentityServerBuilder`.
 For example:
 
 ```cs
@@ -114,7 +114,7 @@ The methods on the [IServerSideSessionStore](/identityserver/reference/stores/se
 
 ### Registering a custom store
 
-To register a custom server-side session store in the DI container, there is a `AddServerSideSessionStore` helper on the `IIdentityServerBuilder`.
+To register a custom server-side session store in the ASP.NET Core service provider, there is a `AddServerSideSessionStore` helper on the `IIdentityServerBuilder`.
 It is still necessary to call `AddServerSideSessions` to enable the server-side session feature.
 For example:
 

src/content/docs/identityserver/diagnostics/events.md

@@ -33,7 +33,7 @@ builder.Services.AddIdentityServer(options =>
 });
 ```
 
-To emit an event use the `IEventService` from the DI container and call the `RaiseAsync` method, e.g.:
+To emit an event use the `IEventService` from the ASP.NET Core service provider and call the `RaiseAsync` method, e.g.:
 
 ```cs
 public async Task<IActionResult> Login(LoginInputModel model)
@@ -53,8 +53,8 @@ public async Task<IActionResult> Login(LoginInputModel model)
 
 ### Custom sinks
 
-Our default event sink will simply serialize the event class to JSON and forward it to the ASP.NET Core logging system.
-If you want to connect to a custom event store, implement the `IEventSink` interface and register it with DI.
+Our default event sink will serialize the event class to JSON and forward it to the ASP.NET Core logging system.
+If you want to connect to a custom event store, implement the `IEventSink` interface and register it with the ASP.NET Core service provider.
 
 The following example uses [Seq](https://getseq.net) to emit events: