Why a new client?

A few client libraries already exist for .NET, including:

• For ASP.NET Core, an OAuth 2.0 base handler developed by Microsoft that we massively use for the aspnet-contrib project (more than 80 OAuth 2.0 services are supported at the time of writing!)
• For ASP.NET Core, an OpenID Connect handler developed by Microsoft.
• For ASP.NET 4.x/OWIN, an OpenID Connect middleware maintained by Microsoft.
• For console and GUI applications, a certified OpenID Connect client developed by Duende Software.
• For Blazor WASM applications, an OpenID Connect integration based on the oidc-client-js library.

So why do we need another one? Am I reinventing the wheel by introducing another OIDC client stack?

Well, that's definitely a legit question. First, I have to say that these implementations work just fine and that I've used them happily other the years. Actually, I even contributed to some of these implementations multiple times so I have a fairly good experience working with them.

In a nutshell, here's what motivated me:

• While all these libraries offer very specialized implementations, none of them offers a unified experience that allowing sharing a common code base usable on, say, ASP.NET Core and Blazor WASM applications: what you learned about the ASP.NET Core OIDC handler is not applicable to Blazor WASM, that uses a completely different OIDC client stack under the hood.

• The OIDC integration for Blazor WASM uses oidc-client-js, that was archived in June 2021 and is no longer supported. While the Blazor OIDC wrapper itself is supported by Microsoft, the library it uses under the hood is not and won't receive any bug or security fix, which is a bit surprising to me, considering its author is still sponsored by Microsoft.

• While it's supported by Microsoft, the Blazor OIDC wrapper doesn't actually get much love and suffers from annoying design issues that affect OpenIddict users that the team is unwilling to fix.

• The OAuth 2.0 base handler for ASP.NET Core offers a straightforward API for creating derived OAuth 2.0 clients that we successfully used in the aspnet-contrib social providers. Unfortunately, its simplicity comes at a cost: it's not composable. Concretely, it means that every time we need to customize something (e.g adding a parameter to the token request), we end up duplicating more code than what we should (e.g to add a token request parameter, you also need to take care of sending the HTTP request and handling the response, which is something the OAuth 2.0 base handler does for you if you don't override the OAuthHandler<T>.ExchangeCodeAsync(OAuthCodeExchangeContext context) method).

• There's also another downside with the OAuth 2.0 base handler: it doesn't support OpenID Connect. Yet, we received contributions to add OAuth 2.0 providers that also support OpenID Connect: while ASP.NET Core has a dedicated OIDC handler that is more appropriate for these cases, many people like the simpler registration story the OAuth 2.0 base handler and the aspnet-contrib providers offer. Retrospectively, we shouldn't have accepted these contributions as these providers don't benefit from the additional security checks a real OpenID Connect implementation requires (e.g nonce, at_hash or c_hash validation, etc.)

• The OAuth 2.0 base handler doesn't support the OAuth 2.0 Authorization Server Metadata specification that backported the OpenID Connect server discovery feature to the OAuth 2.0 world and that allows finding the location of the authorization and token endpoints dynamically, without having to hardcode them. While the adoption is slow, I'd expect more and more services to support it in the next few years.

Can you tell me more about this new client?

Put simply, the OpenIddict client is closely modeled after the OpenIddict server and validation stacks and reuses many of their core concepts, including their extremely powerful events model, their modular approach and the host/transport-agnostic design of the core server and validation packages.

Concretely:

• The OpenIddict client will be usable with any OAuth 2.0 and OpenID Connect server (based on OpenIddict or not) and will heavily use client/server negotiation to adapt its validation routines to the targeted authorization servers to guarantee maximum compatibility while ensuring the best level of security.

• The OpenIddict client currently supports ASP.NET Core 2.1 and higher and native support for ASP.NET 4.x/OWIN will be added in the next few weeks. I also started working on a Blazor WASM prototype and while there'll be limitations (e.g Blazor WASM's encryption/signing support is extremely limited), things are really promising.

• The code, implicit and hybrid flows are all natively supported (except response_type=token, which is unsafe) and OpenIddict has built-in logic to select the best flow to use (unlike the ASP.NET Core OIDC handler that uses the hardcoded response_type=id_token). It's worth noting the OpenIddict client was designed to allow implementing additional flows (like the OpenID Connect Client-Initiated Backchannel Authentication Flow) without requiring massive design changes.

• The OpenIddict client will allow supporting multiple static authorization servers (I currently don't plan on adding dynamic client registration support, but it's something that may be added in a future version).

• The OpenIddict client uses a different approach for handling authorization callbacks: while the OAuth 2.0 and OIDC handlers developed by Microsoft typically handle everything for you by flowing the ClaimsPrincipal extracted from identity tokens/userinfo responses to another authentication handler (in most cases, an instance of the cookies authentication handler), the OpenIddict client won't have this logic and will offer exactly the same approach as the OpenIddict server stack by encouraging users to be involved in the creation of the authentication cookie during the callback handling.

Concretely, the OpenIddict client will offer a pass-through mode to allow handling callbacks in a custom MVC action or minimal API handler. Here's an example of such an action:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96

[HttpGet("~/signin-oidc"), HttpPost("~/signin-oidc")]
public async Task<ActionResult> Callback()
{
    // Retrieve the authorization data validated by OpenIddict as part of the callback handling.
    var result = await HttpContext.AuthenticateAsync(OpenIddictClientAspNetCoreDefaults.AuthenticationScheme);
    // Multiple strategies exist to handle OAuth 2.0/OpenID Connect callbacks, each with their pros and cons:
    //
    //   * Directly using the tokens to perform the necessary action(s) on behalf of the user, which is suitable
    //     for applications that don't need a long-term access to the user's resources or don't want to store
    //     access/refresh tokens in a database or in an authentication cookie (which has security implications).
    //     It is also suitable for applications that don't need to authenticate users but only need to perform
    //     action(s) on their behalf by making API calls using the access tokens returned by the remote server.
    //
    //   * Storing the external claims/tokens in a database (and optionally keeping the essentials claims in an
    //     authentication cookie so that cookie size limits are not hit). For the applications that use ASP.NET
    //     Core Identity, the UserManager.SetAuthenticationTokenAsync() API can be used to store external tokens.
    //
    //     Note: in this case, it's recommended to use column encryption to protect the tokens in the database.
    //
    //   * Storing the external claims/tokens in an authentication cookie, which doesn't require having
    //     a user database but may be affected by the cookie size limits enforced by most browser vendors
    //     (e.g Safari for macOS and Safari for iOS/iPadOS enforce a per-domain 4KB limit for all cookies).
    //
    //     Note: this is the approach used here, but the external claims are first filtered to only persist
    //     a few claims like the user identifier. The same approach is used to store the access/refresh tokens.
    // Important: if the remote server doesn't support OpenID Connect and doesn't expose a userinfo endpoint,
    // result.Principal.Identity will represent an unauthenticated identity and won't contain any claim.
    //
    // Such identities cannot be used as-is to build an authentication cookie in ASP.NET Core (as the
    // antiforgery stack requires at least a name claim to bind CSRF cookies to the user's identity) but
    // the access/refresh tokens can be retrieved using result.Properties.GetTokens() to make API calls.
    if (result.Principal.Identity is not ClaimsIdentity { IsAuthenticated: true })
    {
        throw new InvalidOperationException("The external authorization data cannot be used for authentication.");
    }
    // Build an identity based on the external claims and that will be used to create the authentication cookie.
    //
    // By default, all claims extracted during the authorization dance are available. The claims collection stored
    // in the cookie can be filtered out or mapped to different names depending the claim name or its issuer.
    var claims = result.Principal.Claims
        .Select(claim => claim switch
        {
            // Applications can map non-standard claims issued by specific issuers to a standard equivalent.
            { Type: "non_standard_user_id", Issuer: "https://example.com/" }
                => new Claim(Claims.Subject, claim.Value, claim.ValueType, claim.Issuer),
            _ => claim
        })
        .Where(claim => claim switch
        {
            // Preserve the "name" and "sub" claims.
            { Type: Claims.Name or Claims.Subject } => true,
            // Applications that use multiple client registrations can filter claims based on the issuer.
            { Type: "custom_claim", Issuer: "https://example.com/" } => true,
            // Don't preserve the other claims.
            _ => false
        });
    var identity = new ClaimsIdentity(claims,
        authenticationType: CookieAuthenticationDefaults.AuthenticationScheme,
        nameType: Claims.Name,
        roleType: Claims.Role);
    // If needed, the tokens returned by the authorization server can be stored in the authentication cookie.
    // To make cookies less heavy, tokens that are not used can be filtered out before creating the cookie.
    var tokens = result.Properties.GetTokens().Where(token => token switch
    {
        // Preserve the access and refresh tokens returned in the token response, if available.
        {
            Name: OpenIddictClientAspNetCoreConstants.Tokens.BackchannelAccessToken or
                  OpenIddictClientAspNetCoreConstants.Tokens.BackchannelRefreshToken
        } => true,
        // Ignore the other tokens.
        _ => false
    });
    var properties = new AuthenticationProperties
    {
        RedirectUri = result.Properties.RedirectUri
    };
    properties.StoreTokens(tokens);
    // Note: "return SignIn(...)" cannot be directly used in this case, as the cookies handler doesn't allow
    // redirecting from an endpoint that doesn't match the path set in CookieAuthenticationOptions.LoginPath.
    // For more information about this restriction, visit https://github.com/dotnet/aspnetcore/issues/36934.
    await HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, new ClaimsPrincipal(identity), properties);
    return Redirect(properties.RedirectUri ?? "/");
}

By doing that, developers will have greater control over what's actually stored in their authentication cookies without requiring a claims mapping feature similar to what's used by the MSFT OIDC handler, that can sometimes be hard to use when you need to restore claims that are removed by the OIDC handler to help ensure the resulting authentication cookies don't hit cookie size limits.

• The OpenIddict client will be fully suitable for delegation-only scenarios where authentication is not needed or where the identification of the user who authorized the client is not possible (typically, OAuth 2.0-only servers that don't have a userinfo endpoint). In this case, no information about the user will be available but the tokens will still be available to perform any API call on his behalf.

• Currently, only the authorization/authentication part is fully implemented: userinfo will come in the next few weeks and logout support at a later date.

What's next?

I plan on working on a prototype evaluating the OpenIddict client as a potential replacement of the OAuth 2.0 base handler developed by Microsoft for the aspnet-contrib social providers. While the OpenIddict client is certainly a bit more complex, doing so would have interesting advantages:

• By being natively compatible with multiple environments (ASP.NET Core, ASP.NET 4.x, Blazor WASM), a broader audience of developers could be reached at no additional cost. This could be a nice migration option for those using the OWIN OAuth providers (by which the aspnet-contrib providers were initially inspired), that are sadly no longer under active development.

• Unlike the OAuth 2.0 base handlers, the OpenIddict client natively supports the client_secret_basic client authentication method, which would save us from having code that is needed just to attach the client credentials to the Authorization header of token requests in all the providers that don't support client_secret_post.

• By being natively composable, the events model could be used to eliminate code is not strictly required for the social providers to work (e.g if we need to simply attach a custom parameter, we shouldn't have to also send the HTTP request and handle the response in each provider).

• The story for social providers supporting both OAuth 2.0 and OpenID Connect would be much better than with the OAuth 2.0 base handler, as they would automatically benefit from all the validation checks implemented in the core OpenIddict client without requiring custom code.

• As the OpenIddict client supports both static and dynamic server configuration, social providers that implement discovery could be easily updated to use dynamic configuration, which is not possible with the OAuth 2.0 base handler (that requires hardcoded endpoints).

This will certainly be points I'll discuss with Martin Costello - who co-owns the aspnet-contrib OAuth 2.0 providers with me - once I have a fully working prototype.

You can see the OpenIddict client in action in the sandbox project. If you're interesting in sharing your feedback, please don't hesitate to do so by posting a message in the dedicated GitHub discussion.

By looking at the reactions under the blog post, on GitHub or on Reddit, the least we can say is that people are always quite passionate when it comes to how Microsoft treats these topics. Some like that decision while a few others feel "betrayed" and consider this move a "bait and switch":

Despite this move, my personal opinion hasn't changed: I was very happy when Microsoft announced they would use IdentityServer4 in 2018 and the commitment to use the new dual-licensed version of IdentityServer in .NET 6 (instead of writing their own OIDC server from scratch) is, in my opinion, a step in the right direction in changing their relationship with the .NET community: Microsoft can't provide everything out-of-the-box and promoting third-party projects is a great approach.

The fact Microsoft keeps sponsoring the IdentityServer project – for $12,000/year at the time of writing – is also an excellent signal sent to the community. Even if you've never liked Microsoft's love/hate relationship with OSS, it would be very hard to deny that the company has positively changed in this regard.

That said, I'd be lying if I didn't admit I was quite disappointed when reading that blog post: OpenIddict – the OpenID Connect server I maintain – wasn't even mentioned as a potential free and open source alternative that can be used on-premises or hosted in a cloud application.

This omission is not an oversight: Barry and the rest of the ASP.NET team know my work and we informally discussed potential options that could have helped secure their supply chain, should they have included something based on OpenIddict in the ASP.NET templates: even options like making OpenIddict a co-owned project were on the table.

This omission has a reason, clearly explained in the blog post: Microsoft wants you to use their cloud offers: Azure AD and Azure AD B2C. In fact, the ASP.NET team is already working on migration guides to help users move to Azure AD as part of their .NET 6 effort (fun fact: the thread has been locked so that only members of the .NET team can reply).

The crucial thing to note here is that Azure AD – or the equivalents offered by Okta, Auth0, Firebase or Amazon – are not just OpenID Connect servers like IdentityServer or OpenIddict (that typically rely on a membership stack like ASP.NET Core Identity): they also aim at replacing your users database.

Relying on a SaaS product to take care of your users database is not a bad idea in itself: most of the security aspects are managed for you by the cloud vendors, that will transparently maintain the software and hardware, keep your users database safe and try their best to protect your application against bad actors. This argument alone is often enough to justify the move to cloud solutions like Azure AD:

Microsoft already has a team and a product in that area, Azure Active Directory, which allows 500,000 objects for free. The ASP.NET team feels a managed cloud solution remains the best practical option for developers – the security is managed, you don’t store credentials locally with the risks that presents.

After all, Azure AD has a free plan with up to 500,000 users (*), so this should be a no-brainer, right? Not so fast: these services are always free for a reason: their business model relies on the fact a fraction of their customers will end up exceeding the limits of the free plan. At that point, customers basically have three options:

• Remove as many users as needed to avoid reaching the limit (e.g by removing "inactive" accounts, but this typically only works for a while).
• Pay for the service. At the time of writing, Microsoft charges an insanely high $6/user rate for those on a paid plan.
• Move to a different vendor with a different pricing model.

The thing is moving to a different vendor is never an easy task as cloud vendors typically do their best to make that a difficult process: while you're generally allowed to export non-sensitive parts of your users database (e.g to re-import it in a different service), there's a thing you often have no control over: password hashes:

• Azure AD and Okta don't allow you to retrieve them. In practice, this means you'll need to reset all your user passwords, which is generally horrible from a user experience perspective.
• Auth0 offers an option to export users with their passwords, but this requires contacting the support. To deter you from doing that, their documentation explicitly says that "they are unable to accept or guarantee requests for exports at a specific time and date". Oh and guess what? It's not possible if you're on a free plan! And now that Auth0 was acquired by Okta for $6,5B, who knows how long this ability will stay?

While cloud-based identity offers are captive environments, things are completely different with IdentityServer and OpenIddict, that are often used in conjunction with ASP.NET Core Identity: you own the database and user passwords are stored in a format that could even be implemented in a non-.NET environment (after all, it uses PBKDF under the hood).

When using an open-source solution you can run locally, you have full control over your data. With a cloud offer, the story is completely different. Don't get lured by free plans: if you're interested in a cloud offer, make sure the pricing model of paid plans is adequate for your case before even considering it (and even then, be prepared for a potential price increase at any point).

(*) Actually, the free plan's limit is 50,000 objects. If you need additional entries, you have to ask the Azure support to extend the limit, which is something they do at their own discretion.

One year and a half after releasing the first OpenIddict 3.0 alpha bits, I'm very pleased to announce that 3.0 is now generally available!

This release is unquestionably OpenIddict's most exciting milestone, as both the server and validation stacks were rewritten from scratch to adopt a whole new event-oriented model, which should give OpenIddict 3.0 much more flexibility and extensibility than the aspnet-contrib OpenID Connect server and validation middleware it replaces.

If you're interested in reading more about the changes introduced in this release, I wrote a few blog posts describing the most important ones:

• Creating an OpenID Connect server proxy with OpenIddict 3.0's degraded mode
• Adding OpenIddict 3.0 to an OWIN application
• Introducing OpenIddict 3.0 beta1
• OpenIddict 3.0 beta2 is out
• Introducing localization support in OpenIddict 3.0 beta3 (note: localization support had to be removed in rc1 to keep the error descriptions returned by OpenIddict standard-compliant)
• Introducing Quartz.NET support and new languages in OpenIddict 3.0 beta4
• Using the OrchardCore OpenID management feature with an existing OpenIddict deployment
• OpenIddict 3.0 beta6 is out
• Introducing OpenIddict 3.0's first release candidate version

As announced in Introducing OpenIddict 3.0 beta1, the OpenIddict 2.x and aspnet-contrib OpenID Connect server/validation middleware are now considered legacy/obsolete packages and won't receive bug fixes or security updates.

Whether you're still on ASP.NET 4.x (via OWIN/Katana), ASP.NET Core 2.1 on .NET Framework or .NET Core, ASP.NET Core 3.1 or are already using ASP.NET Core 5.0, migrating to OpenIddict 3.0 should never be a blocking factor, thanks to its broader-than-ever platforms support!

If you need additional time to migrate to OpenIddict 3.0 and are interesting in chatting about your options, feel free to ping me at contact@kevinchalet.com.

I'd like to thank Sébastien Ros, mridentity, Andrew, gustavdw, Gillardo, Dovydas Navickas and Christian Schmitt for sponsoring me on GitHub, which allows me to dedicate more time to OpenIddict! You guys have no idea how much I appreciate that.

Merry Christmas everyone!

All the changes introduced in this release can be found on GitHub.

While this release almost exclusively focused on fixing bugs and eliminating pain points, an important change affected our localization story: starting with OpenIddict 3.0 RC1, the error descriptions returned by OpenIddict itself will no longer be translated.

Thanks to an external report, I discovered that the localization support introduced in OpenIddict 3.0 beta3 was causing issues when returned as part of the standard WWW-Authenticate response header. Worse, it was violating the OAuth 2.0 core specification, that requires that all error_descriptions (not just the ones returned in WWW-Authenticate) only include US-ASCII characters: even diacritics like é (that are common in French) are not allowed. In practice, that means we can sadly only return English error descriptions and that's why localization support had to be removed in this release.

That said, I still believe having localized content is extremely useful and makes a library like OpenIddict more inclusive and developer-friendly. As such, we'll opt for a different approach in the next RC: the OpenIddict server and validation stacks will be updated to always include a unique error_uri pointing to openiddict.com, which will allow documenting every returned error over time.

What's next?

OpenIddict 3.0 RTM is expected to ship mid-December. Before that, a second release candidate version should be released early December.

OpenIddict 2.x and the aspnet-contrib OAuth 2.0/OpenID Connect server/extensions will no longer be supported and won't receive free security updates/bug fixes as soon as 3.0 is officially released (only users benefiting from a support contract will still receive updates). As such, it is very important for users of these packages to start evaluating OpenIddict 3.0 RC1 as soon as possible, so that potential bugs affecting their scenarios can be fixed in the RTM version.

All the changes introduced in this release can be found on GitHub, but here's a recap of the most important ones:

OpenIddict now supports response type permissions

In previous versions, the response_type values an application was allowed to use were always inferred from the grant types. For instance, if a client was granted the authorization_code grant type permission, it was automatically allowed to use response_type=code (that corresponds to the "pure" authorization code). If it was granted the implicit permission, it was also allowed to use response_type=id_token and depending on its type (confidential or public), response_type=id_token token and response_type=token.

While convenient, this approach lacked granularity. In OpenIddict 3.0 beta6, this mechanism is replaced by explicit response type permissions. Response type permissions are granted exactly the same way as the other permissions:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

await manager.CreateAsync(new OpenIddictApplicationDescriptor
{
    ClientId = "mvc",
    ClientSecret = "901564A5-E7FE-42CB-B10D-61EF6A8F3654",
    ConsentType = ConsentTypes.Explicit,
    DisplayName = "MVC client application",
    DisplayNames =
    {
        [CultureInfo.GetCultureInfo("fr-FR")] = "Application cliente MVC"
    },
    PostLogoutRedirectUris =
    {
        new Uri("https://localhost:44381/signout-callback-oidc")
    },
    RedirectUris =
    {
        new Uri("https://localhost:44381/signin-oidc")
    },
    Permissions =
    {
        Permissions.Endpoints.Authorization,
        Permissions.Endpoints.Logout,
        Permissions.Endpoints.Token,
        Permissions.GrantTypes.AuthorizationCode,
        Permissions.GrantTypes.RefreshToken,
        Permissions.ResponseTypes.Code, // New permission
        Permissions.Scopes.Email,
        Permissions.Scopes.Profile,
        Permissions.Scopes.Roles,
        Permissions.Prefixes.Scope + "demo_api"
    },
    Requirements =
    {
        Requirements.Features.ProofKeyForCodeExchange
    }
});

Introducing response type permissions was also a good opportunity for removing the OpenIddict-specific hybrid client type, that was used by confidential clients that also wanted to retrieve an access token directly from the authorization endpoint. In beta6, the hybrid type is no longer supported and must be replaced by explicit Permissions.ResponseTypes.CodeIdTokenToken or Permissions.ResponseTypes.CodeToken permissions.

Users who have many clients to migrate can use this script to infer the "best" response type permissions based on the already allowed grant types:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.DependencyInjection;
using OpenIddict.Abstractions;
using static OpenIddict.Abstractions.OpenIddictConstants;
namespace MigrationScript
{
    public static class Program
    {
        public static async Task Main(string[] args)
        {
            var services = new ServiceCollection();
            services.AddOpenIddict()
                .AddCore(options =>
                {
                    options.UseEntityFrameworkCore()
                           .UseDbContext<DbContext>();
                });
            services.AddDbContext<DbContext>(options =>
            {
                options.UseSqlServer("Server=(localdb)\\mssqllocaldb;Database=aspnet5-openiddict-sample-12340be6-0442-4622-b782-a7412bb7d045;Trusted_Connection=True;MultipleActiveResultSets=true");
                options.UseOpenIddict();
            });
            using var provider = services.BuildServiceProvider();
            using var scope = provider.CreateScope();
            var manager = scope.ServiceProvider.GetRequiredService<IOpenIddictApplicationManager>();
            foreach (var application in await GetApplicationsAsync(manager))
            {
                // Ignore applications that already have at least one response type permission.
                var permissions = new HashSet<string>(await manager.GetPermissionsAsync(application), StringComparer.Ordinal);
                if (permissions.Any(permission => permission.StartsWith(Permissions.Prefixes.ResponseType)))
                {
                    continue;
                }
                // If a application was granted the authorization code grant permission, allow it to use the code response type.
                if (await manager.HasPermissionAsync(application, Permissions.GrantTypes.AuthorizationCode))
                {
                    permissions.Add(Permissions.ResponseTypes.Code);
                }
                if (await manager.HasPermissionAsync(application, Permissions.GrantTypes.Implicit))
                {
                    // Allow all applications that were granted the implicit
                    // grant permission to use the "id_token" response types.
                    permissions.Add(Permissions.ResponseTypes.IdToken);
                    // Applications that were also granted the code grant type permission
                    // are allowed to use the "code id_token" response type permission.
                    if (await manager.HasPermissionAsync(application, Permissions.GrantTypes.AuthorizationCode))
                    {
                        permissions.Add(Permissions.ResponseTypes.CodeIdToken);
                    }
                    // Allow public and hybrid clients to retrieve an access token directly from the
                    // authorization endpoint by granting them the "id_token token" and "token" permissions.
                    if (await manager.HasClientTypeAsync(application, ClientTypes.Public) ||
                        await manager.HasClientTypeAsync(application, "hybrid"))
                    {
                        permissions.Add(Permissions.ResponseTypes.IdTokenToken);
                        permissions.Add(Permissions.ResponseTypes.Token);
                    }
                    // Hybrid applications that were also granted the code grant type permission
                    // are allowed to use the "code id_token token" and "code token" types.
                    if (await manager.HasClientTypeAsync(application, "hybrid") &&
                        await manager.HasPermissionAsync(application, Permissions.GrantTypes.AuthorizationCode))
                    {
                        permissions.Add(Permissions.ResponseTypes.CodeIdTokenToken);
                        permissions.Add(Permissions.ResponseTypes.CodeToken);
                    }
                }
                var descriptor = new OpenIddictApplicationDescriptor();
                await manager.PopulateAsync(descriptor, application);
                // If the application is an hybrid client, replace it by a confidential client.
                // Hybrid client types were removed in OpenIddict 3.0 beta6 and replaced by
                // response type permissions, that allow defining whether a confidential client
                // is allowed to retrieved an access token from the authorization endpoint
                // (i.e without having to send its client credentials to retrieve an access token).
                if (await manager.HasClientTypeAsync(application, "hybrid"))
                {
                    descriptor.Type = ClientTypes.Confidential;
                }
                // Replace the permissions on the descriptor.
                descriptor.Permissions.Clear();
                descriptor.Permissions.UnionWith(permissions);
                // Update the application.
                await manager.PopulateAsync(application, descriptor);
                await manager.UpdateAsync(application);
            }
            static async Task<List<object>> GetApplicationsAsync(IOpenIddictApplicationManager manager)
            {
                var applications = new List<object>();
                await foreach (var application in manager.ListAsync())
                {
                    applications.Add(application);
                }
                return applications;
            }
        }
    }
}

The hybrid flow is no longer enabled when enabling both the authorization code and implicit flows

In previous versions, the hybrid flow was automatically enabled when enabling both the authorization code and implicit flows. In beta6, it now must be enabled explicitly, like the other flows:

1
2
3
4
5

services.AddOpenIddict()
    .AddServer(options =>
    {
        options.AllowHybridFlow();
    });

Rolling refresh tokens are now enabled by default and allow for a configurable leeway

In 3.0 beta6, refresh tokens were revamped and the following changes were made:

• The rolling refresh tokens mechanism now allows for a small leeway to avoid revoking entire token chains when concurrent requests are received (by default, it is set to 15 seconds but can be changed using OpenIddictServerBuilder.SetRefreshTokenReuseLeeway()).

• The rolling refresh tokens mechanism no longer revokes previously issued tokens, it just marks refresh tokens as redeemed when they are used.

• Rolling refresh tokens are now enabled by default to make OpenIddict compliant with the OAuth 2.0 best current practices, that require implementing either rotation or sender-constrained tokens. Developers who prefer disabling rolling refresh tokens can do so by calling OpenIddictServerBuilder.DisableRollingRefreshTokens().

• The refresh token lifetime extension mechanism was removed: even when rolling refresh tokens are disabled, a new refresh token will now be generated and returned for each refresh token request, which guarantees that the client application always gets a refresh tokens (and subsequent access tokens) containing the latest claims.

The EF Core and EF 6 entities now use DateTime instead of DateTimeOffset

Due to incomplete support in the Oracle MySQL and Npgsql Entity Framework providers, the EF Core and EF 6 entities no longer use DateTimeOffset. Developers migrating to OpenIddict 3.0 beta6 will need to add a migration to move from DateTimeOffset to DateTime.

Proof Key for Code Exchange (PKCE) can now be enforced globally

Previous versions of OpenIddict 3.0 already allowed making PKCE mandatory per-client, but in beta6, there's now a global option:

1
2
3
4
5
6

services.AddOpenIddict()
    .AddServer(options =>
    {
        // Force all client applications to use Proof Key for Code Exchange (PKCE).
        options.RequireProofKeyForCodeExchange();
    });

Tokens no longer contain a jti claim

To make tokens lighter, a jti claim is no longer generated and persisted in the tokens generated by OpenIddict 3.0 beta6.

Special thanks to Johann Wimmer for his great contribution to the tests projects, that are now compiled with nullable reference types enabled!

Even though both implement the OpenID Connect and OAuth 2.0 specifications, OpenIddict and IdentityServer4 are very different under the hood and have different approaches: IdentityServer4 was designed as a general and ready-to-use identity provider for ASP.NET Core while OpenIddict 3.0 aims at offering a fully modular OpenID Connect server and validation stack that can be used not only on ASP.NET Core 2.1 (.NET Framework and .NET Core), 3.1 and 5.0, but also in legacy ASP.NET >= 4.6.1 applications using OWIN/Katana.

Internally, the two server stacks don't have much in common: IdentityServer4 uses a traditional and linear services-based approach (with request/token validators and response generators) while OpenIddict 3.0 uses a completely different model based on events and asynchronous events handlers: each handler is responsible of a very specific task (e.g ensuring a redirect_uri is not malformed and doesn't include a fragment) and all the handlers can be removed, reordered and even replaced by custom handlers for those who need to override the default logic used by OpenIddict 3.0.

Unlike IdentityServer4, OpenIddict doesn't ship with any membership stack integration, which is something developers must implement themselves. In the OpenIddict world, this is typically done by adding an authorization controller that serves as bridge between the user authentication part (generally implemented using ASP.NET Core Identity) and the OpenID Connect authorization part. Concretely, OpenIddict only knows about ClaimsPrincipal instances and you're responsible of providing ClaimsPrincipals containing the claims you want OpenIddict to use in your tokens.

You probably guessed it by now: OpenIddict 3.0 is very different from IdentityServer4 and those hoping for a free look-alike will likely be disappointed. Fortunately, implementing an OpenID Connect server using OpenIddict is not hard, and generally consists in copying a few files from the openiddict-samples repository.

There's however something that IdentityServer4 users will likely miss: an equivalent of the popular Skoruba.IdentityServer4.Admin project that offers a GUI to manage users, roles, clients and authorizations. While there's indeed no direct equivalent in OpenIddict itself, the OrchardCore project has a native OpenID module based on OpenIddict that includes a clients management feature. This feature is still young and quite limited (read, not as complete as Skoruba.IdentityServer4.Admin), but it's actively developed and contributions are always welcome.

In this blog post, I'll demonstrate how this management GUI can be used with an existing OpenIddict server (typically located in another project).

So here we go:

Download the OpenIddict samples solution

For that, clone the https://github.com/openiddict/openiddict-samples repository.

For this tutorial, we'll use the Velusia.Server demo, a very typical ASP.NET Core application that implements code flow support. Launch it via Visual Studio or using dotnet run and make sure the openiddict-velusia-sample database is correctly created by Entity Framework Core in your local (localdb)\MSSQLLocalDB SQL Server instance.

Create a new empty ASP.NET Core project, reference the OrchardCore CMS metapackage and register the OrchardCore services and middleware

To simplify things, we'll opt for the "complete" OrchardCore CMS approach, that offers a GUI-based setup experience. For that, reference the following package:

1
2
3
4
5
6
7
8
9
10
11

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="OrchardCore.Application.Cms.Targets" Version="1.0.0" />
  </ItemGroup>
</Project>

Then, update your Startup class to register the OrchardCore CMS services and middleware:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
namespace OrchardCoreDemo
{
    public class Startup
    {
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddOrchardCms();
        }
        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            app.UseOrchardCore();
        }
    }
}

At this point, you're ready to launch the application and configure OrchardCore:

Fill in the form and press "finish setup".

Enable the OpenID management feature in the features admin

Once set up, log in and click on "Dashboard" to access the administration interface. Then, click on "Features" under "Configuration":

In the features admin, type "OpenID" to filter the available features and enable the "OpenID management interface" feature:

Reference the OpenIddict Entity Framework Core stores and register them

At this stage, if you visit the client applications administration page, you should see an empty list:

That's expected: by default, the management interface points to the local OrchardCore database and not (yet) to openiddict-velusia-sample.

To fix that, we'll need to reference the OpenIddict Entity Framework Core package, so that the management UI can directly communicate with the openiddict-velusia-sample database. For that, reference the following packages:

1
2
3
4
5
6
7
8
9
10
11
12
13

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="5.0.0" />
    <PackageReference Include="OpenIddict.EntityFrameworkCore" Version="3.1.0" />
    <PackageReference Include="OrchardCore.Application.Cms.Targets" Version="1.0.0" />
  </ItemGroup>
</Project>

Final part: adding an EF Core DbContext pointing to the openiddict-velusia-sample database and registering the OpenIddict EF Core stores using the OrchardCore APIs:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
namespace OrchardCoreDemo
{
    public class MyContext : DbContext
    {
        public MyContext(DbContextOptions<MyContext> options)
            : base(options)
        {
        }
    }
    public class Startup
    {
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddOrchardCms()
                .ConfigureServices(services =>
                {
                    services.AddDbContext<MyContext>(options =>
                    {
                        options.UseSqlServer("Server=(localdb)\\mssqllocaldb;Database=openiddict-velusia-sample;Trusted_Connection=True;MultipleActiveResultSets=true");
                        options.UseOpenIddict();
                    });
                    services.AddOpenIddict()
                        .AddCore()
                        .UseEntityFrameworkCore()
                        .UseDbContext<MyContext>();
                }, order: 10000);
        }
        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            app.UseOrchardCore();
        }
    }
}

Restart the application and visit the applications administration page. If everything is correctly configured, you should see the MVC client application entry corresponding to the Velusia.Client demo application registered by Velusia.Server.

From here, you can easily update the application entry by clicking on "Edit":

Voilà!

All the changes introduced in this release can be found on GitHub, but here's a recap of the most important ones:

OpenIddict now ships with a native Quartz.NET 3.2 integration

To help with housecleaning and remove authorization and token entries that are no longer valid from the database, OpenIddict now comes with a new OpenIddict.Quartz plugin that you can enable in a few lines of code.

First, you need to register the Quartz.NET services and configure it to use DI and an in-memory store:

1
2
3
4
5
6

services.AddQuartz(options =>
{
    options.UseMicrosoftDependencyInjectionJobFactory();
    options.UseSimpleTypeLoader();
    options.UseInMemoryStore();
});

Then, you need to enable the Quartz/.NET generic host integration.

1

services.AddQuartzHostedService(options => options.WaitForJobsToComplete = true);

Finally, you'll need to register the OpenIddict job:

1
2

services.AddOpenIddict()
    .AddCore(options => options.UseQuartz());

Once registered, the OpenIddict job will start removing invalid entries approximately 2 minutes after the application starts and will do that every hour (assuming your app is still running).

Special thanks to Quartz.NET's maintainer, Marko Lahma, for reviewing the PR that added this feature and for the great job he did with Quartz.NET 3.2 (that was released earlier today).

OpenIddict now speaks 12 languages!

Thanks to fantastic contributions from the community, 10 additional languages have been added in this release:

options.EnableAuthorizationEndpointCaching() and options.EnableLogoutEndpointCaching() have a new name

Feedback indicated that options.EnableAuthorizationEndpointCaching() and options.EnableLogoutEndpointCaching()'s current name was not ideal. To fix that, these methods were renamed to options.EnableAuthorizationRequestCaching() and options.EnableLogoutRequestCaching().

This post is also a good opportunity to thank Sébastien Ros, Andrew and Mr.i, who now sponsor me on GitHub. Thank you very much!

All the changes introduced in this release can be found on GitHub, but here's a recap of the most important ones:

The core, server and validation features now offer built-in localization support

As announced in a previous post, OpenIddict was fully updated to use the .NET Platform localization extensions to return localized error descriptions and validation messages, which will be particularly useful in multilingual projects like Orchard Core.

At the time of writing, OpenIddict 3.0 beta3 comes with English and French resources, but additional languages will likely be added in the next versions.

To enable localization support in ASP.NET Core, simply register the request localization middleware (ideally, put it at the top of your Configure(IApplicationBuilder app) method):

1
2
3
4
5
6

app.UseRequestLocalization(options =>
{
    options.AddSupportedCultures("en-US", "fr-FR");
    options.AddSupportedUICultures("en-US", "fr-FR");
    options.SetDefaultCulture("en-US");
});

Conversely, developers who don't need localization support and prefer keeping their deployments as small as possible can remove the localized satellite assemblies by simply adding <SatelliteResourceLanguages>en</SatelliteResourceLanguages> in their .csproj file.

OpenIddict is now decorated with nullable reference types annotations

Following a general trend across the .NET community, all the OpenIddict libraries are now compiled with nullable reference types support enabled.

Authorizations are no longer revoked when detecting a rolling refresh token replay

In previous versions of OpenIddict, sending a rolling refresh token twice always resulted in the revocation of the entire tokens chain and the revocation of the associated authorization. To make the rolling tokens option more convenient to use, the authorization associated to a refresh token is no longer revoked when it is sent multiple times.

DisableSlidingExpiration() was renamed to DisableSlidingRefreshTokenExpiration()

To make clearer the fact the sliding expiration mechanism applies to refresh tokens, the DisableSlidingExpiration() helper was renamed to DisableSlidingRefreshTokenExpiration() in OpenIddict 3.0 beta3.

All the changes introduced in this release can be found on GitHub, but here's a recap of the most important ones:

System.Linq.Async was removed from the OpenIddict.Core dependencies

Due to a namespace conflict between Entity Framework Core and System.Linq.Async (maintained by the RX team), we had to remove the dependency the OpenIddict.Core package had on this package, as explained in this GitHub thread.

This is not specific to OpenIddict and other popular libraries like Stripe.NET had to make a similar decision. As such, I strongly encourage the EF and RX teams to work together to find a better solution to this issue, that has a serious impact on the .NET ecosystem.

The automatic initialization logic was removed from the MongoDB integration

In OpenIddict 1.x/2.x, the 4 collections used by the MongoDB stores were automatically initialized during the first use of the stores.

In OpenIddict 3.0 beta2, this logic was removed for performance reasons and consistency with the other stores. Instead, MongoDB users are encouraged to initialize their database once using a setup script. The following C# script can be used to initialize the 4 OpenIddict collections:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98

using System.Threading;
using System.Threading.Tasks;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Options;
using MongoDB.Driver;
using OpenIddict.MongoDb;
using OpenIddict.MongoDb.Models;
namespace MongoDbSetup
{
    public static class Program
    {
        public static async Task Main(string[] args)
        {
            var services = new ServiceCollection();
            services.AddOpenIddict()
                .AddCore(options => options.UseMongoDb());
            services.AddSingleton(new MongoClient("mongodb://localhost:27017").GetDatabase("openiddict"));
            var provider = services.BuildServiceProvider();
            var context = provider.GetRequiredService<IOpenIddictMongoDbContext>();
            var options = provider.GetRequiredService<IOptionsMonitor<OpenIddictMongoDbOptions>>().CurrentValue;
            var database = await context.GetDatabaseAsync(CancellationToken.None);
            var applications = database.GetCollection<OpenIddictMongoDbApplication>(options.ApplicationsCollectionName);
            await applications.Indexes.CreateManyAsync(new[]
            {
                new CreateIndexModel<OpenIddictMongoDbApplication>(
                    Builders<OpenIddictMongoDbApplication>.IndexKeys.Ascending(application => application.ClientId),
                    new CreateIndexOptions
                    {
                        Unique = true
                    }),
                new CreateIndexModel<OpenIddictMongoDbApplication>(
                    Builders<OpenIddictMongoDbApplication>.IndexKeys.Ascending(application => application.PostLogoutRedirectUris),
                    new CreateIndexOptions
                    {
                        Background = true
                    }),
                new CreateIndexModel<OpenIddictMongoDbApplication>(
                    Builders<OpenIddictMongoDbApplication>.IndexKeys.Ascending(application => application.RedirectUris),
                    new CreateIndexOptions
                    {
                        Background = true
                    })
            });
            var authorizations = database.GetCollection<OpenIddictMongoDbAuthorization>(options.AuthorizationsCollectionName);
            await authorizations.Indexes.CreateOneAsync(new CreateIndexModel<OpenIddictMongoDbAuthorization>(
                Builders<OpenIddictMongoDbAuthorization>.IndexKeys
                    .Ascending(authorization => authorization.ApplicationId)
                    .Ascending(authorization => authorization.Scopes)
                    .Ascending(authorization => authorization.Status)
                    .Ascending(authorization => authorization.Subject)
                    .Ascending(authorization => authorization.Type),
                new CreateIndexOptions
                {
                    Background = true
                }));
            var scopes = database.GetCollection<OpenIddictMongoDbScope>(options.ScopesCollectionName);
            await scopes.Indexes.CreateOneAsync(new CreateIndexModel<OpenIddictMongoDbScope>(
                Builders<OpenIddictMongoDbScope>.IndexKeys.Ascending(scope => scope.Name),
                new CreateIndexOptions
                {
                    Unique = true
                }));
            var tokens = database.GetCollection<OpenIddictMongoDbToken>(options.TokensCollectionName);
            await tokens.Indexes.CreateManyAsync(new[]
            {
                new CreateIndexModel<OpenIddictMongoDbToken>(
                    Builders<OpenIddictMongoDbToken>.IndexKeys.Ascending(token => token.ReferenceId),
                    new CreateIndexOptions<OpenIddictMongoDbToken>
                    {
                        // Note: partial filter expressions are not supported on Azure Cosmos DB.
                        // As a workaround, the expression and the unique constraint can be removed.
                        PartialFilterExpression = Builders<OpenIddictMongoDbToken>.Filter.Exists(token => token.ReferenceId),
                        Unique = true
                    }),
                new CreateIndexModel<OpenIddictMongoDbToken>(
                    Builders<OpenIddictMongoDbToken>.IndexKeys
                        .Ascending(token => token.ApplicationId)
                        .Ascending(token => token.Status)
                        .Ascending(token => token.Subject)
                        .Ascending(token => token.Type),
                    new CreateIndexOptions
                    {
                        Background = true
                    })
            });
        }
    }
}

Authorization codes are now reference tokens

With response_mode=form_post being impacted by same-site, some applications are moving back to the query response mode (the default mode for the authorization code flow). To avoid token length issues with clients using response_mode=query and having strict query string limits, authorization codes are now reference tokens in OpenIddict 3.0 beta2.

As part of this change, the options.UseReferenceTokens() setting was also split into options.UseReferenceAccessTokens() and options.UseReferenceRefreshTokens() for more flexibility and options.UseRollingTokens() was renamed to options.UseRollingRefreshTokens() for clarity.

The OpenIddict server Data Protection integration now offers more options

In OpenIddict 3.0 beta1, the OpenIddict server Data Protection integration allowed you to opt out of the ASP.NET Core Data Protection token format when creating new tokens thanks to the options.PreferDefaultTokenFormat() option.

In beta2, this option was split into multiple options for more control over the token format (JWT or Data Protection) used to produce the different token types supported by OpenIddict:

• options.PreferDefaultAccessTokenFormat().
• options.PreferDefaultAuthorizationCodeFormat().
• options.PreferDefaultDeviceCodeFormat().
• options.PreferDefaultRefreshTokenFormat().
• options.PreferDefaultUserCodeFormat().

What changed?

Some of the major changes introduced in this release were described in the OpenIddict 3.0 roadmap (the detailed list can be found on GitHub), but here's a recap of the most important ones:

The aspnet-contrib OAuth 2.0 server/validation/introspection handlers and OpenIddict were merged into a single codebase

This is the most important change of this release: ASOS – the low-level OpenID Connect server framework used in OpenIddict 1.0/2.0 – and the aspnet-contrib validation and introspection middleware were all merged into OpenIddict.

To ensure OpenIddict can be used as a replacement for ASOS (for which people usually write their own persistence layer, at least to validate things like client_id and redirect_uri), a new degraded mode was introduced to allow using the OpenIddict server components without all the additional logic that relies on the OpenIddict managers/stores (e.g client authentication, client validation, token storage).

For more information about this feature, read my previous post: Creating an OpenID Connect server proxy with OpenIddict 3.0's degraded mode.

OpenIddict has been decoupled from ASP.NET Core and now natively supports OWIN/Katana and ASP.NET 4.x

In OpenIddict 1.0/2.0, the core and the EF 6/EF Core/MongoDB stores were already decoupled from ASP.NET Core. In 3.0, the server and validation features have been revamped to avoid depending on ASP.NET Core. Instead, ASP.NET Core integration is now provided by separate packages named OpenIddict.Server.AspNetCore and OpenIddict.Validation.AspNetCore. For convenience, a metapackage named OpenIddict.AspNetCore can be referenced to import the OpenIddict core, server and validation packages and their ASP.NET Core integration with a single PackageReference.

Unlike the previous versions, OpenIddict 3.0 will also support multiple ASP.NET Core versions: 2.1, 3.1 and 5.0.

Decoupling OpenIddict from ASP.NET Core was also a great opportunity to make it natively compatible with OWIN/Katana, which will allow using its server or validation features in any ASP.NET (non-core) 4.6.1 application. OWIN/Katana integration is provided by the OpenIddict.Server.Owin and OpenIddict.Validation.Owin packages, which follows the same pattern as the ASP.NET Core hosts.

Here's the framework/runtime combinations that will be officially supported in 3.0:

For more information about OWIN/Katana and ASP.NET 4.x support, read this dedicated post: Adding OpenIddict 3.0 to an OWIN application.

OpenIddict now uses JSON Web Token (JWT) as the default token format

In OpenIddict 1.0/2.0, the ASP.NET Core Data Protection stack is always used to encrypt the authorization codes, refresh tokens and access tokens, unless you explicitly opt for JWT access tokens with options.UseJsonWebTokens().

In 3.0, OpenIddict will now use encrypted JWT as the default token format for all the token types. Developers who need to disable access token encryption will be able to do so using options.DisableAccessTokenEncryption():

1
2
3
4
5

services.AddOpenIddict()
    .AddServer(options =>
    {
        options.DisableAccessTokenEncryption();
    });

ASP.NET Core Data Protection tokens are still supported in 3.0 and even recommended if you migrate from 1.0/2.0 (to ensure tokens produced by older versions can still be read after migrating to 3.0) or if you enable device flow support, as they provide additional protection against token leakage. To enable Data Protection support, simply call options.UseDataProtection() in both the server and validation options:

1
2
3
4
5
6
7
8
9
10

services.AddOpenIddict()
    .AddServer(options =>
    {
        options.UseDataProtection();
    })
    .AddValidation(options =>
    {
        options.UseDataProtection();
    });

JSON.NET was replaced by System.Text.Json

All the OpenIddict libraries have been updated to use System.Text.Json (developed by Microsoft) instead of JSON.NET.

While it's a relatively new library (that still lacks features like a writable DOM), the performance boost it offers is impressive and makes System.Text.Json a fantastic candidate for replacing JSON.NET in OpenIddict.

Here's a tiny benchmark showing the difference between deserializing a OpenIdConnectMessage – the type used in OpenIddict 2.0 – with JSON.NET and deserializing its equivalent in 3.0 (where OpenIddictMessage was optimized and is now internally powered by System.Text.Json).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

[MarkdownExporterAttribute.GitHub, MemoryDiagnoser]
public class Benchmark
{
    [Benchmark(Baseline = true)]
    public OpenIdConnectMessage OpenIddict20()
    {
        return JsonConvert.DeserializeObject<OpenIdConnectMessage>(@"{
  ""redirect_uris"": [
    ""https://client.example.org/callback"",
    ""https://client.example.org/callback2""
  ],
  ""client_name"": ""My Example Client"",
  ""token_endpoint_auth_method"": ""client_secret_basic"",
  ""logo_uri"": ""https://client.example.org/logo.png"",
  ""jwks_uri"": ""https://client.example.org/my_public_keys.jwks"",
  ""example_extension_parameter"": ""example_value""
}");
    }
    [Benchmark]
    public OpenIddictMessage OpenIddict30()
    {
        return JsonSerializer.Deserialize<OpenIddictMessage>(@"{
  ""redirect_uris"": [
    ""https://client.example.org/callback"",
    ""https://client.example.org/callback2""
  ],
  ""client_name"": ""My Example Client"",
  ""token_endpoint_auth_method"": ""client_secret_basic"",
  ""logo_uri"": ""https://client.example.org/logo.png"",
  ""jwks_uri"": ""https://client.example.org/my_public_keys.jwks"",
  ""example_extension_parameter"": ""example_value""
}");
    }
}

As you can see, the performance gain is excellent: not only it is 35% faster, but it also allocates much less memory!

1
2
3
4
5

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19041.264 (2004/?/20H1)
Intel Core i9-9900K CPU 3.60GHz (Coffee Lake), 1 CPU, 16 logical and 8 physical cores
.NET Core SDK=5.0.100-preview.4.20258.7
  [Host]     : .NET Core 3.1.4 (CoreCLR 4.700.20.20201, CoreFX 4.700.20.22101), X64 RyuJIT
  DefaultJob : .NET Core 3.1.4 (CoreCLR 4.700.20.20201, CoreFX 4.700.20.22101), X64 RyuJIT

... and serialization is even more impressive!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

[MarkdownExporterAttribute.GitHub, MemoryDiagnoser]
public class Benchmark
{
    [Benchmark(Baseline = true)]
    public string OpenIddict20()
    {
        return JsonConvert.SerializeObject(new OpenIdConnectMessage
        {
            ["redirect_uri"] = new[]
            {
                "https://client.example.org/callback",
                "https://client.example.org/callback2"
            },
            ["client_name"] = "My Example Client",
            ["token_endpoint_auth_method"] = "client_secret_basic",
            ["logo_uri"] = "https://client.example.org/logo.png",
            ["jwks_uri"] = "https://client.example.org/my_public_keys.jwks",
            ["example_extension_parameter"] = "example_value"
        });
    }
    [Benchmark]
    public string OpenIddict30()
    {
        return JsonSerializer.Serialize(new OpenIddictMessage
        {
            ["redirect_uri"] = new[]
            {
                "https://client.example.org/callback",
                "https://client.example.org/callback2"
            },
            ["client_name"] = "My Example Client",
            ["token_endpoint_auth_method"] = "client_secret_basic",
            ["logo_uri"] = "https://client.example.org/logo.png",
            ["jwks_uri"] = "https://client.example.org/my_public_keys.jwks",
            ["example_extension_parameter"] = "example_value"
        });
    }
}

1
2
3
4
5

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19041.264 (2004/?/20H1)
Intel Core i9-9900K CPU 3.60GHz (Coffee Lake), 1 CPU, 16 logical and 8 physical cores
.NET Core SDK=5.0.100-preview.4.20258.7
  [Host]     : .NET Core 3.1.4 (CoreCLR 4.700.20.20201, CoreFX 4.700.20.22101), X64 RyuJIT
  DefaultJob : .NET Core 3.1.4 (CoreCLR 4.700.20.20201, CoreFX 4.700.20.22101), X64 RyuJIT

OpenIddict now supports the device authorization grant

Standardized in 2019, the device authorization grant (aka device flow) is now natively supported by OpenIddict 3.0.

Enabling reference tokens is no longer required to use immediate access token revocation

In 1.0/2.0, developers who needed immediate access token revocation support had to use reference tokens. As of 3.0, this is no longer required: even self-contained JWT or Data Protection access tokens can be revoked, as OpenIddict 3.0 now always creates a database entry for all token types.

Like in previous versions, the API projects needing immediate access token revocation need to either have a direct access to OpenIddict's database or use introspection:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

services.AddOpenIddict()
    .AddCore(options =>
    {
        // ...
    })
    .AddServer(options =>
    {
        // ...
    })
    .AddValidation(options =>
    {
        // Import the configuration from the local OpenIddict server instance.
        options.UseLocalServer();
        // For applications that need immediate access token or authorization
        // revocation, the database entry of the received tokens and their
        // associated authorizations can be validated for each API call.
        // Enabling these options may have a negative impact on performance.
        options.EnableAuthorizationEntryValidation();
        options.EnableTokenEntryValidation();
        // Register the ASP.NET Core host.
        options.UseAspNetCore();
    });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

services.AddOpenIddict()
    .AddValidation(options =>
    {
        // Note: the validation handler uses OpenID Connect discovery
        // to retrieve the address of the introspection endpoint.
        options.SetIssuer("http://localhost:12345/");
        // Configure the validation handler to use introspection and register the client
        // credentials used when communicating with the remote introspection endpoint.
        options.UseIntrospection()
               .SetClientId("resource_server_1")
               .SetClientSecret("846B62D0-DEF9-4215-A99D-86E6B8DAB342");
        // Register the System.Net.Http integration.
        options.UseSystemNetHttp();
        // Register the ASP.NET Core host.
        options.UseAspNetCore();
    });

OpenIddict's managers and stores now use IAsyncEnumerable<T>

The application, authorization, scope and token managers (located in OpenIddict.Core) and all the Entity Framework 6, Entity Framework 6 and MongoDB stores now natively support IAsyncEnumerable<T>. While this is a massive binary/source breaking change, migrating to IAsyncEnumerable<T> allows stores to implement streamed enumerations, which was not possible in OpenIddict 2.0 (that uses Task<ImmutableArray<T>> instead of IAsyncEnumerable<T>).

The Entity Framework 6, Entity Framework Core and MongoDB entities have been renamed

To make more obvious the fact the OpenIddict entities are designed for a specific ORM/database, the application, authorization, scope and tokens entities have all been renamed to include the name of their corresponding store (e.g OpenIddictApplication -> OpenIddictMongoDbApplication).

The OpenIddict endpoints are all non-pass-through by default

In previous versions of OpenIddict, the authorization, logout, token and userinfo endpoints were always pass-through: OpenIddict validated the requests for you, but you needed to add an MVC controller – typically named AuthorizationController – or a custom middleware to handle them later in the ASP.NET Core pipeline.

Starting in 3.0, none of the OpenIddict endpoints is pass-through by default, which helps with debugging as OpenIddict will now throw an exception if the request is not handled using the events model and if the pass-through mode was not enabled, instead of letting ASP.NET Core return a 404 response.

To enable pass-through for a specific endpoint, use the methods provided by OpenIddictServerAspNetCoreBuilder or OpenIddictServerOwinBuilder:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

services.AddOpenIddict()
    .AddServer(options =>
    {
        // When using ASP.NET Core:
        options.UseAspNetCore()
               .EnableAuthorizationEndpointPassthrough()
               .EnableLogoutEndpointPassthrough()
               .EnableTokenEndpointPassthrough()
               .EnableUserinfoEndpointPassthrough()
               .EnableVerificationEndpointPassthrough();
        // When using OWIN/Katana:
        options.UseOwin()
               .EnableAuthorizationEndpointPassthrough()
               .EnableLogoutEndpointPassthrough()
               .EnableTokenEndpointPassthrough()
               .EnableUserinfoEndpointPassthrough()
               .EnableVerificationEndpointPassthrough();
    });

Status code pages middleware integration is no longer enabled by default

In 3.0, integration with the ASP.NET Core status code pages middleware is now opt-in:

1
2
3
4
5
6

services.AddOpenIddict()
    .AddServer(options =>
    {
        options.UseAspNetCore()
               .EnableStatusCodePagesIntegration();
    });

Returning custom parameters via AuthenticationProperties.Parameters is now supported

Returning custom parameters was already supported in 1.0/2.0, but they had to be stored as strings in AuthenticationProperties.Items with a special suffix. This mechanism is no longer supported, but returning custom bool, long, string, string[] or JsonElement parameters is now much simpler:

1
2
3
4
5
6
7
8
9
10
11
12

var properties = new AuthenticationProperties(
    items: new Dictionary<string, string>(),
    parameters: new Dictionary<string, object>
    {
        ["boolean_parameter"] = true,
        ["integer_parameter"] = 42,
        ["string_parameter"] = "Bob l'Eponge",
        ["array_parameter"] = JsonSerializer.Deserialize<JsonElement>(@"[""Contoso"",""Fabrikam""]"),
        ["object_parameter"] = JsonSerializer.Deserialize<JsonElement>(@"{""parameter"":""value""}")
    });
return SignIn(principal, properties, OpenIddictServerAspNetCoreDefaults.AuthenticationScheme);

What's next?

There'll likely be a few other beta releases before RTM to ensure everything is working as intended and to add features like localization support. All the samples contained in the openiddict-samples have already been updated to target OpenIddict 3.0 beta1 and new samples will be progressively added to cover the newly supported scenarios (e.g device flow).

Considerable effort has been dedicated to making sure that all users of ASOS, the aspnet-contrib extensions or OpenIddict have a migration path to 3.0 – whether they are using the latest ASP.NET Core version and the latest .NET Core runtime, are stuck with 2.1 on .NET Framework or still use ASP.NET 4.6.1 with OWIN/Katana.

As such, I'll no longer offer free support for OpenIddict 1.0/2.0 or the aspnet-contrib packages that were merged into OpenIddict as part of this release once the 3.0 RTM packages ship (in a few months). The 2 aspnet-contrib repositories will also be archived.

The following NuGet packages will be eventually flagged as obsolete to inform users that they are no longer actively developed or supported:

With that in mind, I encourage everyone to start migrating to OpenIddict 3.0 beta1 and testing it in a non-production environment.

What can you do to help?

While super exciting, this release has been way more time-consuming than I had initially anticipated, and there are still many important things to do, like adding documentation and a migration guide to help developers update their applications to OpenIddict 3.0.

For that, I need your help: please consider contributing to the effort or sponsoring me, so I can spend more time working on OpenIddict. Without external help, I likely will not have enough spare time to work on things that would benefit the community, like documentation.

If you're interested in getting dedicated support or want to discuss sponsoring options, don't hesitate to reach me at contact@kevinchalet.com.

Up-to-date samples for ASP.NET 4.x and OWIN can be found in the openiddict/openiddict-samples repository:

• Fornax: authorization code flow demo using ASP.NET Web Forms 4.8 and OWIN/Katana, with a .NET console acting as the client.
• Kalarba: resource owner password credentials demo using OWIN/Katana, ASP.NET Web API and the OpenIddict degraded mode.

Last year, I announced that OpenIddict would become compatible with OWIN/Katana – and thus usable in any ASP.NET 4.x non-Core application – as part of the 3.0 release. While using OpenIddict in an OWIN application shouldn't be much different than using it in an ASP.NET Core application, there's actually a part than will slightly differ between the two platforms: dependency injection.

Globally introduced in ASP.NET Core 1.0, dependency injection support was not a thing in OWIN. Yet, OpenIddict itself depends on dependency injection for all its features: core, server and token validation. To work around the lack of official DI support, OpenIddict 3.0 will support two approaches: one working with the Autofac DI container and one without. This blog post briefly describes how to do that.

To keep things simple, we'll create a tiny self-hosted .NET 4.7.2 OWIN application, but of course, these 2 approaches also work in any ASP.NET application, no matter what's the host used: HttpListener, System.Web or even third-party options like Nowin.

For that, create a new application with the following .csproj, that contains the basic things we'll need: the Microsoft DI primitives used by OpenIddict, the OWIN self-host and hosting abstractions and the OpenIddict OWIN metapackage (that itself references the core, server and validation packages, plus the OWIN integration assembly):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net472</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="3.1.4" />
    <PackageReference Include="Microsoft.Owin.Host.HttpListener" Version="4.1.0" />
    <PackageReference Include="Microsoft.Owin.Hosting" Version="4.1.0" />
    <PackageReference Include="OpenIddict.Owin" Version="3.0.0-beta1.20311.67" />
  </ItemGroup>
</Project>

Then, add the entry point...

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

using System;
using Microsoft.Owin.Hosting;
namespace OpenIddictWebApiDemo
{
    public static class Program
    {
        public static void Main(string[] args)
        {
            const string address = "http://localhost:58779/";
            using (WebApp.Start<Startup>(address))
            {
                Console.WriteLine($"Server is running on {address}, press CTRL+C to stop.");
                Console.ReadLine();
            }
        }
    }
}

... and the Startup class:

1
2
3
4
5
6
7
8
9
10
11

using Owin;
namespace OpenIddictWebApiDemo
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
        }
    }
}

At this point, no matter the option you'll opt for, you'll need to instantiate a ServiceCollection and register the OpenIddict server and validation services (exactly like how you'd do in a ASP.NET Core application):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

public void Configuration(IAppBuilder app)
{
    var services = new ServiceCollection();
    services.AddOpenIddict()
        .AddServer(options =>
        {
            options.AllowPasswordFlow();
            options.EnableDegradedMode();
            options.AcceptAnonymousClients();
            options.SetTokenEndpointUris("/connect/token");
            options.AddDevelopmentEncryptionCertificate()
                   .AddDevelopmentSigningCertificate();
            options.UseOwin()
                   .DisableTransportSecurityRequirement();
            options.AddEventHandler<ValidateTokenRequestContext>(builder =>
                builder.UseInlineHandler(context =>
                {
                    // Client authentication is used in this sample,
                    // so there's nothing to validate here.
                    return default;
                }));
            options.AddEventHandler<HandleTokenRequestContext>(builder =>
                builder.UseInlineHandler(context =>
                {
                    if (!context.Request.IsPasswordGrantType())
                    {
                        throw new InvalidOperationException("The specified grant type is not supported.");
                    }
                    // Validate the username/password parameters.
                    // In a real world application, you'd use likely use a key derivation function like PBKDF2 to slow
                    // the client secret validation process down and a time-constant comparer to prevent timing attacks.
                    if (!string.Equals(context.Request.Username, "alice@wonderland.com", StringComparison.Ordinal) ||
                        !string.Equals(context.Request.Password, "P@ssw0rd", StringComparison.Ordinal))
                    {
                        context.Reject(
                            error: Errors.InvalidGrant,
                            description: "The username/password couple is invalid.");
                        return default;
                    }
                    var principal = new ClaimsPrincipal(new ClaimsIdentity(OpenIddictServerOwinDefaults.AuthenticationType));
                    principal.SetClaim(Claims.Subject, "Bob");
                    context.Principal = principal;
                    return default;
                }));
        })
        .AddValidation(options =>
        {
            options.UseLocalServer();
            options.UseOwin();
        });
}

If you try to run the project as-is, all you'll get is a 404 error, as there's still a thing we need to do: integrating OpenIddict into OWIN's request processing pipeline.

Using OpenIddict 3.0 with Autofac (recommended option)

Unlike most other DI containers, Autofac has an excellent OWIN integration story that keeps things very clean and well-integrated. To use Autofac with OWIN, reference the following packages:

1
2

<PackageReference Include="Autofac.Owin" Version="5.0.1" />
<PackageReference Include="Autofac.Extensions.DependencyInjection" Version="6.0.0" />

Then, update your Configuration method to create the IContainer, import the ServiceCollection and register the Autofac OWIN middleware:

1
2
3
4
5
6
7
8
9
10
11
12

public void Configuration(IAppBuilder app)
{
    var services = new ServiceCollection();
    // ...
    var builder = new ContainerBuilder();
    builder.Populate(services);
    var container = builder.Build();
    app.UseAutofacMiddleware(container);
}

This is the beauty of this option: nothing else is required.

Using OpenIddict 3.0 without Autofac

Without Autofac, things will get a bit more complicated, as you'll need to manage per-request scopes yourself. While we'll use the Microsoft DI container to achieve that, this approach is also doable with any other DI container that provides an IServiceProvider implementation.

For that, we'll have to add a middleware creating a service scope per request and injecting it in the OWIN environment with the System.IServiceProvider key (the value that the OpenIddict server and validation OWIN integrations expect). We'll also need to call app.UseOpenIddictServer() and app.UseOpenIddictValidation(), that register the OpenIddict OWIN authentication handlers.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

public void Configuration(IAppBuilder app)
{
    var services = new ServiceCollection();
    // ...
    var container = services.BuildServiceProvider();
    app.Use(async (context, next) =>
    {
        var scope = container.CreateScope();
        // Store the per-request service provider in the OWIN environment.
        context.Set(typeof(IServiceProvider).FullName, scope.ServiceProvider);
        try
        {
            // Invoke the rest of the pipeline.
            await next();
        }
        finally
        {
            // Remove the scoped service provider from the OWIN environment.
            context.Set<IServiceProvider>(typeof(IServiceProvider).FullName, null);
            // Dispose of the scoped service provider.
            if (scope is IAsyncDisposable disposable)
            {
                await disposable.DisposeAsync();
            }
            else
            {
                scope.Dispose();
            }
        }
    });
    app.UseOpenIddictServer();
    app.UseOpenIddictValidation();
}

To ensure things are working properly, you can use Postman and send a token request:

Configure ASP.NET Web API to use token authentication (optional)

If your application uses ASP.NET Web API, a couple additional things will need to be configured:

• The OWIN host MUST be used to register the ASP.NET Web API integration. Concretely, this means you must ensure your application doesn't reference the Microsoft.AspNet.WebApi.WebHost package. Instead, use the Microsoft.AspNet.WebApi.Owin package and call app.UseWebApi() at the end of your Startup.Configuration(IAppBuilder app) method:

1
2
3
4
5
6
7
8
9

public void Configuration(IAppBuilder app)
{
    // ...
    var configuration = new HttpConfiguration();
    configuration.MapHttpAttributeRoutes();
    app.UseWebApi(configuration);
}

• To use token authentication for all Web API actions, the HostAuthenticationFilter can be registered globally to always call the OpenIddict validation handler:

1
2
3
4
5
6
7
8
9
10
11
12

public void Configuration(IAppBuilder app)
{
    // ...
    var configuration = new HttpConfiguration();
    configuration.MapHttpAttributeRoutes();
    // Configure ASP.NET Web API to use token authentication.
    configuration.Filters.Add(new HostAuthenticationFilter(OpenIddictValidationOwinDefaults.AuthenticationType));
    app.UseWebApi(configuration);
}

• Alternatively, HostAuthenticationFilter can be applied per-action or per-controller using HostAuthenticationAttribute:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[HostAuthentication(OpenIddictValidationOwinDefaults.AuthenticationType)]
[RoutePrefix("api")]
public class ResourceController : ApiController
{
    [Authorize, HttpGet]
    [Route("message")]
    public IHttpActionResult GetMessage()
    {
        var principal = (ClaimsPrincipal) User;
        var name = principal.FindFirst(Claims.Name).Value;
        return Content(HttpStatusCode.OK, $"{name} has been successfully authenticated.");
    }
}

As part of this task, a new feature was added to OpenIddict: the degraded mode (also known as the ASOS-like or bare mode). Put simply, this mode allows using OpenIddict's server without any backing database. Once enabled, all the features that rely on the OpenIddict application, authorization, scope and token managers (contained in the OpenIddict.Core package) are automatically disabled, which includes things like client_id/client_secret or redirect_uri validation, reference tokens and token revocation support. In other words, this mode allows switching from an "all you can eat" offer to a "pay-to-play" approach.

A thread, posted on one of the aspnet-contrib repositories gave me a perfect opportunity to showcase this particular feature. The question asked by the commenters was simple: how can I use an external authentication provider like Steam (that implements the legacy OpenID 2.0 protocol) with my own API endpoints?

Steam doesn't issue any access token you could directly use with your API endpoints. Actually, access tokens are not even a thing in OpenID 2.0, which is a pure authentication protocol that doesn't offer any authorization capability (unlike OAuth 1.0/2.0 or OpenID Connect).

So, how do we solve this problem? The most common approach typically consists in creating your own authorization server between your frontend application and the remote authentication provider (here, Steam). This way, when the application needs to authenticate a user, the user is redirected to the authorization server, that delegates the actual authentication part to another party. Once authenticated by that party, the user is redirected back to the main authorization server, that issues an access token to the client application.

This a super common scenario, that can be implemented using standard protocols like OpenID Connect and well-known implementations like OpenIddict or IdentityServer. However, these options are sometimes considered "overkill" for such simple scenarios. After all, why would you need a fully-fledged OIDC server – with login, registration or consent views – when all you want is to delegate the actual authentication to another server in a totally transparent and almost invisible way?

Rolling your own protocol is tempting... but a very bad idea, as you can't benefit from all the security measures offered by standard flows like OAuth 2.0/OpenID Connect's authorization code flow, whose threat model is clearly identified for many years now. As you may have guessed by now, this is precisely where OpenIddict 3.0's degraded mode can come in handy.

Implementing a minimalist OpenID Connect server with OpenIddict 3.0

Add the Steam authentication integration

First, we'll start by creating an ASP.NET Core 3.1 API application and by adding the aspnet-contrib Steam provider and an instance of the cookies authentication handler (that will be used to store the user identity retrieved from Steam).

For that, add the following dependency in your .csproj:

1
2
3
4
5
6
7
8
9
10
11

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="AspNet.Security.OpenId.Steam" Version="3.0.0" />
  </ItemGroup>
</Project>

Then, update ConfigureServices to register the Steam and cookies authentication handlers:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
    services.AddAuthentication()
        .AddCookie()
        .AddSteam(options =>
        {
            options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
            // To get additional claims from Steam's authentication APIs,
            // register your application and set the application key.
            //
            // options.ApplicationKey = "application_key";
        });
}

You'll also need to update Configure to call app.UseAuthentication():

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    app.UseHttpsRedirection();
    app.UseRouting();
    app.UseAuthentication();
    app.UseAuthorization();
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
    });
}

Add the OpenIddict server and JWT validation components

Now, we'll need to add the OpenID Connect server part. For that, add the following packages:

1
2
3

<PackageReference Include="OpenIddict.Server.AspNetCore" Version="3.0.0-beta1.20311.67" />
<PackageReference Include="OpenIddict.Validation.AspNetCore" Version="3.0.0-beta1.20311.67" />
<PackageReference Include="OpenIddict.Validation.ServerIntegration" Version="3.0.0-beta1.20311.67" />

Next, tweak ConfigureServices to register the OpenIddict ASP.NET Core server and validation services, with only the options we need: the authorization code flow allowed, the authorization and token endpoints active and the degraded mode enabled:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

services.AddOpenIddict()
    .AddServer(options =>
    {
        options.AddDevelopmentEncryptionCertificate()
               .AddDevelopmentSigningCertificate();
        options.AllowAuthorizationCodeFlow();
        options.SetAuthorizationEndpointUris("/connect/authorize")
               .SetTokenEndpointUris("/connect/token");
        options.EnableDegradedMode();
        options.UseAspNetCore();
    })
    .AddValidation(options =>
    {
        options.UseLocalServer();
        options.UseAspNetCore();
    });

At this point, trying to launch the application will result in an exception being thrown:

InvalidOperationException: No custom authorization request validation handler was found. When enabling the degraded mode, a custom IOpenIddictServerHandler<ValidateAuthorizationRequestContext> must be implemented to validate authorization requests (e.g to ensure the client_id and redirect_uri are valid).

This is expected: when using the degraded mode, you must add custom code to validate things that are normally validated for you by OpenIddict, which includes the client_id or redirect_uri, that must be checked to ensure users are not redirected to unsafe/unknown addresses.

To fix that error, we'll need to register a handler for the ValidateAuthorizationRequest event. Since we enabled the token endpoint, we'll also need one to validate token requests.

There are multiple ways to create and register event handlers in OpenIddict: you can create a dedicated class implementing the generic IOpenIddictServerHandler<TContext> interface – which allows using dependency injection – or you can use inline event handlers.

To keep things simple, we'll use inline event handlers (directly defined in ConfigureServices) and static hard-coded checks:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

services.AddOpenIddict()
    .AddServer(options =>
    {
        // ...
        options.AddEventHandler<ValidateAuthorizationRequestContext>(builder =>
            builder.UseInlineHandler(context =>
            {
                if (!string.Equals(context.ClientId, "console_app", StringComparison.Ordinal))
                {
                    context.Reject(
                        error: Errors.InvalidClient,
                        description: "The specified 'client_id' doesn't match a registered application.");
                    return default;
                }
                if (!string.Equals(context.RedirectUri, "http://localhost:7890/", StringComparison.Ordinal))
                {
                    context.Reject(
                        error: Errors.InvalidClient,
                        description: "The specified 'redirect_uri' is not valid for this client application.");
                    return default;
                }
                return default;
            }));
        options.AddEventHandler<ValidateTokenRequestContext>(builder =>
            builder.UseInlineHandler(context =>
            {
                if (!string.Equals(context.ClientId, "console_app", StringComparison.Ordinal))
                {
                    context.Reject(
                        error: Errors.InvalidClient,
                        description: "The specified 'client_id' doesn't match a registered application.");
                    return default;
                }
                // This demo is used by a single public client application.
                // As such, no client secret validation is performed.
                return default;
            }));
    });

Final and most interesting part: gluing everything together, so that OpenIddict can redirect users to Steam and generate an authorization response containing an authorization code that the client application will be able to use to redeem an access token. To implement that, we need to use the HandleAuthorizationRequest event:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

options.AddEventHandler<HandleAuthorizationRequestContext>(builder =>
    builder.UseInlineHandler(async context =>
    {
        var request = context.Transaction.GetHttpRequest() ??
            throw new InvalidOperationException("The ASP.NET Core request cannot be retrieved.");
        // Retrieve the security principal created by the Steam handler and stored in the authentication cookie.
        // If the principal cannot be retrieved, this indicates that the user is not logged in. In this case,
        // an authentication challenge is triggered to redirect the user to Steam's authentication endpoint.
        var principal = (await request.HttpContext.AuthenticateAsync(SteamAuthenticationDefaults.AuthenticationScheme))?.Principal;
        if (principal == null)
        {
            await request.HttpContext.ChallengeAsync(SteamAuthenticationDefaults.AuthenticationScheme);
            context.HandleRequest();
            return;
        }
        var identity = new ClaimsIdentity(TokenValidationParameters.DefaultAuthenticationType);
        // Use the "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" claim
        // (added by the Steam handler to store the user identifier) as the OIDC "sub" claim.
        identity.AddClaim(new Claim(Claims.Subject, principal.GetClaim(ClaimTypes.NameIdentifier)));
        // If needed, you can copy more claims from the cookies principal to the bearer principal.
        // To get more claims from the Steam handler, you'll need to set the application key.
        // Mark all the added claims as being allowed to be persisted in the access token,
        // so that the API controllers can retrieve them from the ClaimsPrincipal instance.
        foreach (var claim in identity.Claims)
        {
            claim.SetDestinations(Destinations.AccessToken);
        }
        // Attach the principal to the authorization context, so that an OpenID Connect response
        // with an authorization code can be generated by the OpenIddict server services.
        context.Principal = new ClaimsPrincipal(identity);
    }));

Creating a .NET demo console

To test our minimalist OpenID Connect proxy, we'll now create a separate .NET Core 3.1 console referencing the IdentityModel.OidcClient package:

1
2
3
4
5
6
7
8
9
10
11
12
13

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <LangVersion>8.0</LangVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="IdentityModel.OidcClient" Version="4.0.0-preview.1.3" />
  </ItemGroup>
</Project>

There are typically 2 ways to handle authorization responses in desktop/mobile applications (i.e applications that don't run inside a browser):

• Running a local HTTP server: this works well for desktop applications, but might be hard to implement in certain enterprise environments with strict firewall configurations.

• Registering an application-specific URI scheme (e.g: myapp://): this is the best approach... and pretty much the only option on most mobile operating systems, where the first option is not always possible, for security reasons.

Since the first option is easier to implement, it's the one we will choose for this demo client:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73

using System;
using System.Diagnostics;
using System.Net;
using System.Threading.Tasks;
using IdentityModel.OidcClient;
using static IdentityModel.OidcConstants;
namespace OpenIddictClientDemo
{
    public static class Program
    {
        public static async Task Main(string[] args)
        {
            Console.WriteLine("Press any key to start the authentication process.");
            Console.ReadKey();
            // Create a local web server used to receive the authorization response.
            using var listener = new HttpListener();
            listener.Prefixes.Add("http://localhost:7890/");
            listener.Start();
            var options = new OidcClientOptions
            {
                Authority = "https://localhost:44322/",
                ClientId = "console_app",
                LoadProfile = false,
                RedirectUri = "http://localhost:7890/",
                Scope = StandardScopes.OpenId
            };
            var client = new OidcClient(options);
            var state = await client.PrepareLoginAsync();
            // Launch the system browser to initiate the authentication dance.
            Process.Start(new ProcessStartInfo
            {
                FileName = state.StartUrl,
                UseShellExecute = true
            });
            // Wait for an authorization response to be posted to the local server.
            while (true)
            {
                var context = await listener.GetContextAsync();
                context.Response.StatusCode = 204;
                context.Response.Close();
                var result = await client.ProcessResponseAsync(context.Request.Url.Query, state);
                if (result.IsError)
                {
                    Console.WriteLine("An error occurred: {0}", result.Error);
                }
                else
                {
                    Console.WriteLine("\n\nClaims:");
                    foreach (var claim in result.User.Claims)
                    {
                        Console.WriteLine("{0}: {1}", claim.Type, claim.Value);
                    }
                    Console.WriteLine();
                    Console.WriteLine("Access token:\n{0}", result.AccessToken);
                    break;
                }
            }
            Console.ReadLine();
        }
    }
}

Testing the authentication process

For that, start the two applications (server and client). Once the client is started, press a key to start the authentication process. When doing so, the default browser will be launched and you'll be redirected to the authorization server. If you're not already logged in, you'll be immediately invited to authenticate using your Steam account:

After logging in, an authorization response will be returned to the client console, that will automatically send a token request to finish the process:

And voilà, you're now ready to create your first APIs! To accept the JWT bearer tokens issued by OpenIddict, don't forget to decorate your controllers/actions with:

1

[Authorize(AuthenticationSchemes = OpenIddictValidationAspNetCoreDefaults.AuthenticationScheme)]

To make migration a bit less painful, Microsoft published a "transport security best practices" paper that list a few solutions that help avoid handshake errors related to the use of legacy TLS versions that are no longer considered safe.

One of the proposed solutions is to update your project to target .NET Framework 4.7: in this case, you'll have nothing else to do, as .NET 4.7 applications automatically default to whatever the operating system they run on offers and considers safe (which currently includes TLS 1.2 and will later include TLS 1.3).

Unfortunately, such an option requires re-compiling the application, which is not always feasible. Thankfully, you can also force an existing application to use the system default TLS versions without having to re-compile it (assuming it doesn't explicitly set the SSL/TLS versions it prefers via ServicePointManager).

The best practices paper lists a few options, but my favourite one is the one that consists in simply updating the configuration file associated with the application executable, as it's easy to do and doesn't impact anything else on the machine.

For that, locate the configuration file associated to the executable of the application you want to add TLS 1.2 support to: it's always named [name of the executable].exe.config. If there's no such file, create one. Once located or created, update its content to enable the compatibility switch required to support TLS 1.2:

1
2
3
4
5
6

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=false"/>
  </runtime>
</configuration>

What changed since RC3?

A security bug was fixed

A few days ago, a vulnerability impacting application permissions was publicly reported by nurhat on GitHub (many thanks to him!).

In a nutshell, scope permissions were not correctly enforced for public clients using the password flow and custom grant types (confidential clients or clients using the code or client credentials flows were not impacted).

A fix was immediately added to the nightly builds and is present in the RTM release.

Built-in entity caches are now included

OpenIddict now comes with built-in entity caching to avoid having to send multiple requests to retrieve the same entities. Concretely, if your AuthorizationController uses APIs like OpenIddictApplicationManager.FindByClientIdAsync(request.ClientId), the corresponding application will be directly retrieved from the cache and the resulting operation will be extremely cheap.

To ensure this feature works with non-thread-safe stores and stores that rely on context-affinity (like Entity Framework 6.x or Entity Framework Core), these built-in caches are scoped so that cached entities are not reused across requests.

While definitely not recommended, this feature can be disabled via the OpenIddict core options:

1
2
3
4
5
6
7

services.AddOpenIddict()
    .AddCore(options =>
    {
        // ...
        options.DisableEntityCaching();
    })

The event model was slightly reworked

Based on feedback, the event model used by the server and validation handlers was slightly reworked so that it's now more explicit whether next handlers are allowed to be invoked by OpenIddict or not.

Concretely, both IOpenIddictServerEventHandler.HandleAsync() and IOpenIddictValidationEventHandler.HandleAsync() now return an enum value indicating whether the other handlers can be invoked. Here's an example of the new syntax:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

public class PasswordGrantTypeEventHandler : IOpenIddictServerEventHandler<HandleTokenRequest>
{
    public Task<OpenIddictServerEventState> HandleAsync(HandleTokenRequest notification)
    {
        var request = notification.Context.Request;
        if (!request.IsPasswordGrantType())
        {
            // Allow other handlers to process the event.
            return Task.FromResult(OpenIddictServerEventState.Unhandled);
        }
        // Validate the user credentials.
        // Note: to mitigate brute force attacks, you SHOULD strongly consider
        // applying a key derivation function like PBKDF2 to slow down
        // the password validation process. You SHOULD also consider
        // using a time-constant comparer to prevent timing attacks.
        if (request.Username != "alice@wonderland.com" || request.Password != "P@ssw0rd")
        {
            notification.Context.Reject(
                error: OpenIddictConstants.Errors.InvalidGrant,
                description: "The specified credentials are invalid.");
            // Don't allow other handlers to process the event.
            return Task.FromResult(OpenIddictServerEventState.Handled);
        }
        // Create a new ClaimsIdentity holding the user identity.
        var identity = new ClaimsIdentity(
            notification.Context.Scheme.Name,
            OpenIddictConstants.Claims.Name,
            OpenIddictConstants.Claims.Role);
        // Add a "sub" claim containing the user identifier, and attach
        // the "access_token" destination to allow OpenIddict to store it
        // in the access token, so it can be retrieved from your controllers.
        identity.AddClaim(OpenIddictConstants.Claims.Subject,
            "71346D62-9BA5-4B6D-9ECA-755574D628D8",
            OpenIddictConstants.Destinations.AccessToken);
        identity.AddClaim(OpenIddictConstants.Claims.Name, "Alice",
            OpenIddictConstants.Destinations.AccessToken);
        // ... add other claims, if necessary.
        var principal = new ClaimsPrincipal(identity);
        var ticket = new AuthenticationTicket(principal, notification.Context.Scheme.Name);
        ticket.SetScopes(OpenIddictConstants.Scopes.OfflineAccess);
        notification.Context.Validate(ticket);
        // Don't allow other handlers to process the event.
        return Task.FromResult(OpenIddictServerEventState.Handled);
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public class RefreshTokenGrantTypeEventHandler : IOpenIddictServerEventHandler<HandleTokenRequest>
{
    public async Task<OpenIddictServerEventState> HandleAsync(HandleTokenRequest notification)
    {
        var request = notification.Context.Request;
        if (!request.IsRefreshTokenGrantType())
        {
            // Allow other handlers to process the event.
            return OpenIddictServerEventState.Unhandled;
        }
        var scheme = notification.Context.Scheme.Name;
        var principal = (await notification.Context.HttpContext.AuthenticateAsync(scheme))?.Principal;
        var ticket = new AuthenticationTicket(principal, scheme);
        notification.Context.Validate(ticket);
        // Don't allow other handlers to process the event.
        return OpenIddictServerEventState.Handled;
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14

services.AddOpenIddict()
    .AddCore(options =>
    {
        // ...
    })
    .AddServer(options =>
    {
        // ...
        options.AddEventHandler<PasswordGrantTypeEventHandler>()
               .AddEventHandler<RefreshTokenGrantTypeEventHandler>();
    })
    .AddValidation();

What package(s) should I reference?

OpenIddict supports both ASP.NET Core 1.x and 2.x so if you're still on the former version, no need to hurry: both versions basically offer the same feature set, with only a few API differences. For clarity, the OpenIddict packages use the 1.x pattern for the ASP.NET Core 1.x-compatible version and 2.x for ASP.NET Core 2.x.

Here's the complete list of packages published as part of this release:

Support lifecycle

Both OpenIddict 1.0 and 2.0 will be supported for as long as the ASP.NET Core version they are written for gets updates from Microsoft. You can find their support policy on Microsoft.com.

What's next?

While I'll probably mostly focus on improving OrchardCore's OpenID module (which is based on OpenIddict) during the next few weeks, OpenIddict itself will also get updates, including NHibernate 5 stores (that will likely be OpenIddict 2.0-only as NHibernate doesn't offer a netstandard1.x TFM that would be required to work with .NET Core 1.x).

Depending on the demand, stores for RavenDB or other databases might also be part of the next update. Don't hesitate to contact me if you'd like to see a particular database supported in the next version.

As an avid WMC user, I have built 3 HTPC machines and recorded thousands of TV programs (movies, series, documentaries, etc.). As such, when Microsoft announced in May 2015 that Windows Media Center would no longer be developed (almost 6 year after disbanding the development team!) – and thus would not be part of Windows 10 – I refused to migrate to Windows 10, despite Microsoft's offers encouraging users to upgrade their OS for free.

The fact Windows Media Center was not available on Windows 10 – even as a paid feature like it was on Windows 8.x – was a major blocker for many users. To work around this limitation, enthusiasts decided to create an unofficial port of Windows Media Center for Windows 10.

While unofficial, the port worked just fine. But over time, Microsoft started to update some of the system components Windows Media Center relied on, causing annoying bugs. For instance, the introduction of breaking changes in Windows 10 1803 made watching a .wtv file (WMC's TV file format) recorded on Windows 7 completely impossible.

While investigating, I discovered that the issue was caused by a change in MSVidCtl.dll, the system-wide DLL containing the DirectShow components needed by WMC for all its TV-related features. After replacing the faulty DLL by an older version, WMC was able to play old recordings like a charm.

This phenomenom, that occurs every time API or functional changes are introduced in a DLL a program depends on, has a name: DLL Hell.

You shall not replace system DLLs

The thing is, replacing a system-owned DLL is far from ideal: while it solves the initial problem quite easily, it's not future-proof as any major Windows update will end up overwriting the replaced DLL. The same thing will happen if the user (or the system on his behalf) runs the sfc.exe utility, that will detect the modification and revert it. It may also cause issues in other applications depending on new APIs that are only part of the newest version of the replaced DLL.

Since replacing a system DLL was not a good option, I eventually opted for the other approach: forcing Windows Media Center to load its own version of MSVidCtl.dll instead of the global one stored in System32.

Typically, you'd achieve that by simply dropping the DLL in the application's root folder (in our case, C:\Windows\ehome). This usually works because the DLL loader first looks for the DLL in the directory the application was loaded from.

Enter the marvelous world of COM

In this case, this didn't work: Windows Media Center kept loading the MSVidCtl DLL contained in the System32 folder. Why? Because MSVidCtl.dll is actually a very special DLL: it's a Component Object Model DLL. Unlike other DLLs, COM DLLs are almost never loaded via LoadLibrary (at least, not directly): instead, they are assigned a GUID that corresponds to a special entry in the registry that contains the absolute path of the COM DLL. When an application wants to instantiate a COM component, it usually imports Ole32.dll and calls CoCreateInstance with the unique GUID: the COM loader locates the entry in the registry and loads the DLL from the associated path.

Since the path is absolute, trying to add a MSVidCtl.dll in the ehome folder was completely pointless: the loader would never look for it.

DLL redirection and side-by-side assemblies

To mitigate this issue, Microsoft offers 2 mechanisms that allow overriding the default search order used by Windows' DLL loader even when the specified path is absolute:

• DLL redirection: by creating an empty .local file/folder whose name is the same as the executable (in our case, ehshell.exe.local), one can easily force the OS to load DLLs from the application folder: it's dead simple and works flawlessly, even for COM DLLs. Unfortunately, it has a major caveat: it doesn't work when the application has an application manifest (there's a registry switch to override that but turning it on would impact the entire system, certainly not a good thing to do).

• Side-by-side assemblies: first introduced in Windows 98 Second Edition, it allows an application to define its dependencies in its application manifest (and explicitly opt for a specific DLL version). DLL dependencies can be either stored in the same directory as the application (in this case, they are known as private assemblies) or in a special shared directory called winsxs. Starting with Windows XP, it also allows defining registration-free COM components: unlike classical COM components, they don't have an entry in the registry and thus are not registered globally. Instead, they are defined in the application manifest: when the COM loader finds an entry in the manifest for the specified GUID, it loads the corresponding DLL and doesn't apply the default registry loading routine.

In our case, the first option is sadly not applicable: all the Windows Media Center executables come with an embedded manifest used to enable the DPI-aware mode. For instance, here's the manifest embedded in ehshell.exe:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- Copyright (c) Microsoft Corporation -->
<assembly xmlns="urn:schemas-microsoft-com:asm.v3" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
<assemblyIdentity name="Microsoft.Windows.MultiMedia.EhShell" processorArchitecture="amd64" version="5.1.0.0" type="win32"/>
<description>Windows Media Center Shell</description>
<application>
    <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"> 
            <dpiAware>true</dpiAware> 
    </asmv3:windowsSettings>
</application>
  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="asInvoker"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>
</assembly>

Removing the manifest to make the .local approach work would be very easy, but we'd loose all the benefits of the DPI-aware mode: definitely not an option.

Defining registration-free COM components

While powerful, defining registration-free COM components is far from being trivial and is rather error-prone.

Extracting the TypeLib tables

First, you need to extract the TypeLib table from the COM DLL you want to use. For convenience, it's almost always embedded as a binary resource in the COM DLLs themselves. To extract these resources, you can use the popular Resource Hacker tool. In some cases, a single COM DLL might expose multiple TypeLib tables: you'll have to extract them all and merge them later. MSVidCtl.dll is one of them:

Generating assembly manifests

Then, you need to use the Manifest Tool coming with Visual Studio to generate the manifest files from the COM definitions.

For that, open a VS command prompt and run the following commands:

1
2

mt -tlb:TYPELIB1.bin -dll:MSVidCtl.dll -out:Manifest1.manifest
mt -tlb:TYPELIB2.bin -dll:MSVidCtl.dll -out:Manifest2.manifest

Merging assembly manifests

In a perfect world, you'd also use mt.exe to merge the 2 manifests into a single one:

1

mt -manifest:Manifest1.manifest -manifest:Manifest2.manifest -out:Microsoft.Windows.Video.Control.manifest

Unfortunately, the two manifests actually contain multiple elements with the same TypeLib identifier, making them impossible to merge automatically:

Manifest2.manifest : manifest authoring error c1010001: Values of attribute "tlbid" not equal in different manifest snippets.

To work around this limitation, I manually merged the two XML files using Notepad++ and wrote a tiny C# script to remove the duplicate entries:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

var path = @"[path pointing to the merged XML manifest file]";
var document = XDocument.Load(path);
foreach (var stub in document.Root.Elements(XName.Get("comInterfaceExternalProxyStub", "urn:schemas-microsoft-com:asm.v1")).ToList())
{
    var name = stub.Attribute("name");
    if (string.IsNullOrEmpty(name?.Value))
    {
        throw new InvalidOperationException();
    }
    var duplicates = document.Root.Elements(XName.Get("comInterfaceExternalProxyStub", "urn:schemas-microsoft-com:asm.v1"))
        .Where(element => element.Attributes()
            .Any(attribute => attribute.Name == "name" && attribute.Value == name.Value))
        .ToArray();
    if (duplicates.Length > 1)
    {
        duplicates[0].SetAttributeValue("tlbid", null);
        for (var index = 1; index < duplicates.Length; index++)
        {
            duplicates[index].Remove();
        }
    }
}
document.Save(path);

Fixing the resulting manifest

This is not done yet: if you try to use the resulting manifest as-is, Windows Media Center will simply crash as the mt utility misses an important part of the COM definitions: the threading model of the COM classes.

The good news is that this information can be retrived from the registry of a Windows 7 machine (or on Windows 10 pre-1803). To make that process much easier, I wrote a second tiny script updating the manifest from the data found in the registry:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

var path = @"[path pointing to the merged XML manifest file]";
var document = XDocument.Load(path);
foreach (var file in document.Root.Elements(XName.Get("file", "urn:schemas-microsoft-com:asm.v1")))
{
    foreach (var component in file.Elements(XName.Get("comClass", "urn:schemas-microsoft-com:asm.v1")))
    {
        var id = component.Attribute("clsid");
        using (var root = Registry.ClassesRoot.OpenSubKey("CLSID"))
        using (var clsid = root.OpenSubKey(id.Value))
        using (var ipc = clsid?.OpenSubKey("InprocServer32"))
        {
            var model = ipc?.GetValue("ThreadingModel").ToString();
            if (string.IsNullOrEmpty(model))
            {
                continue;
            }
            component.SetAttributeValue("threadingModel", model);
        }
    }
}
document.Save(path);

After cleaning the XML manifest a bit, here's what I ended up with:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity name="Microsoft.Windows.Video.Control" version="1.0.0.0" />
  <file name="MSVidCtl.dll">
    <comClass clsid="{1C15D484-911D-11D2-B632-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Analog TV Tuner Device Class" threadingModel="Apartment" />
    <comClass clsid="{A2E3074E-6C3D-11D3-B653-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control BDA Tuner Device Class" threadingModel="Apartment" />
    <comClass clsid="{37B0353C-A4C8-11D2-B634-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control File Playback Device Class" threadingModel="Apartment" />
    <comClass clsid="{011B3619-FE63-4814-8A84-15A194CE9CE3}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MSVidWebDVD Class" threadingModel="Apartment" />
    <comClass clsid="{FA7C375B-66A7-4280-879D-FD459C84BB02}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MSVidWebDVDAdm Class" threadingModel="Apartment" />
    <comClass clsid="{37B03543-A4C8-11D2-B634-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Video Renderer(DX7/8) Class" threadingModel="Apartment" />
    <comClass clsid="{24DC3975-09BF-4231-8655-3EE71F43837D}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Video Renderer 9(DX9) Class" threadingModel="Apartment" />
    <comClass clsid="{C45268A2-FA81-4E19-B1E3-72EDBD60AEDA}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Enhanced Video Renderer(DX10) Class" threadingModel="Apartment" />
    <comClass clsid="{37B03544-A4C8-11D2-B634-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Audio Renderer Class" threadingModel="Apartment" />
    <comClass clsid="{4A5869CF-929D-4040-AE03-FCAFC5B9CD42}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Stream Buffer Engine Sink Class" threadingModel="Apartment" />
    <comClass clsid="{9E77AAC4-35E5-42A1-BDC2-8F3FF399847C}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Stream Buffer Engine Sink Class" threadingModel="Apartment" />
    <comClass clsid="{AD8E510D-217F-409B-8076-29C5E73B98E8}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Stream Buffer Engine Playback Device Class" threadingModel="Apartment" />
    <comClass clsid="{FD351EA1-4173-4AF4-821D-80D4AE979048}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Stream Buffer Engine V2 Playback Device Class" threadingModel="Apartment" />
    <comClass clsid="{BB530C63-D9DF-4B49-9439-63453962E598}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Encoder" threadingModel="Apartment" />
    <comClass clsid="{5740A302-EF0B-45CE-BF3B-4470A14A8980}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control iTV Capture" threadingModel="Apartment" />
    <comClass clsid="{9E797ED0-5253-4243-A9B7-BD06C58F8EF3}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control iTV Playback" threadingModel="Apartment" />
    <comClass clsid="{86151827-E47B-45EE-8421-D10E6E690979}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Closed Captions Analysis" threadingModel="Apartment" />
    <comClass clsid="{7F9CB14D-48E4-43B6-9346-1AEBC39C64D3}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Standard Closed Captioning" threadingModel="Apartment" />
    <comClass clsid="{92ED88BF-879E-448F-B6B6-A385BCEB846D}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control CCSI Closed Captioning" threadingModel="Apartment" />
    <comClass clsid="{334125C0-77E5-11D3-B653-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Standard Data Services for Broadcast IP through NDIS stack" threadingModel="Apartment" />
    <comClass clsid="{0149EEDF-D08F-4142-8D73-D23903D21E90}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Encoder" threadingModel="Apartment" />
    <comClass clsid="{C5702CD6-9B79-11D3-B654-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for Analog Capture to Data Services" threadingModel="Apartment" />
    <comClass clsid="{38F03426-E83B-4E68-B65B-DCAE73304838}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for Data Services to Stream Buffer Sink" threadingModel="Apartment" />
    <comClass clsid="{0429EC6E-1144-4BED-B88B-2FB9899A4A3D}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for DataServices To XDS" threadingModel="Apartment" />
    <comClass clsid="{3540D440-5B1D-49CB-821A-E84B8CF065A7}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for TV Tuner to XDS" threadingModel="Apartment" />
    <comClass clsid="{B0EDF163-910A-11D2-B632-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Class" threadingModel="Apartment" />
    <comClass clsid="{C5702CCC-9B79-11D3-B654-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Input Device Collection Class" threadingModel="Apartment" />
    <comClass clsid="{C5702CCD-9B79-11D3-B654-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Output Device Collection Class" threadingModel="Apartment" />
    <comClass clsid="{C5702CCE-9B79-11D3-B654-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Video Renderer Device Collection Class" threadingModel="Apartment" />
    <comClass clsid="{C5702CCF-9B79-11D3-B654-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Audio Renderer Device Collection Class" threadingModel="Apartment" />
    <comClass clsid="{C5702CD0-9B79-11D3-B654-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Feature Collection Class" threadingModel="Apartment" />
    <comClass clsid="{2764BCE5-CC39-11D2-B639-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Generic Composition Class" threadingModel="Apartment" />
    <comClass clsid="{E18AF75A-08AF-11D3-B64A-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for Analog Capture to Overlay Mixer" threadingModel="Apartment" />
    <comClass clsid="{267DB0B3-55E3-4902-949B-DF8F5CEC0191}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for WebDVD to Overlay Mixer" threadingModel="Apartment" />
    <comClass clsid="{8D04238E-9FD1-41C6-8DE3-9E1EE309E935}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for WebDVD to Audio Renderer" threadingModel="Apartment" />
    <comClass clsid="{6AD28EE1-5002-4E71-AAF7-BD077907B1A4}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for Mpeg2 Decoder to Closed Captioning" threadingModel="Apartment" />
    <comClass clsid="{9F50E8B1-9530-4DDC-825E-1AF81D47AED6}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for Analog Capture to Stream Buffer Sink" threadingModel="Apartment" />
    <comClass clsid="{ABE40035-27C3-4A2F-8153-6624471608AF}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for Digital Capture to Stream Buffer Sink" threadingModel="Apartment" />
    <comClass clsid="{92B94828-1AF7-4E6E-9EBF-770657F77AF5}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for iTV to Stream Buffer Sink" threadingModel="Apartment" />
    <comClass clsid="{3EF76D68-8661-4843-8B8F-C37163D8C9CE}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for CCA to Stream Buffer Sink" threadingModel="Apartment" />
    <comClass clsid="{A0B9B497-AFBC-45AD-A8A6-9B077C40D4F2}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for Encoder to Stream Buffer Sink" threadingModel="Apartment" />
    <comClass clsid="{B401C5EB-8457-427F-84EA-A4D2363364B0}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for File Playback to Video Renderer" threadingModel="Apartment" />
    <comClass clsid="{CC23F537-18D4-4ECE-93BD-207A84726979}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for File Playback to Audio Renderer" threadingModel="Apartment" />
    <comClass clsid="{28953661-0231-41DB-8986-21FF4388EE9B}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for TV Tuner to Encoder" threadingModel="Apartment" />
    <comClass clsid="{3C4708DC-B181-46A8-8DA8-4AB0371758CD}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for SBE Source to Video renderer" threadingModel="Apartment" />
    <comClass clsid="{942B7909-A28E-49A1-A207-34EBCBCB4B3B}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for TV Tuner to CCA" threadingModel="Apartment" />
    <comClass clsid="{73D14237-B9DB-4EFA-A6DD-84350421FB2F}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for Digital Capture to CCA" threadingModel="Apartment" />
    <comClass clsid="{5D8E73F7-4989-4AC8-8A98-39BA0D325302}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for Digital Capture to ITV" threadingModel="Apartment" />
    <comClass clsid="{2291478C-5EE3-4BEF-AB5D-B5FF2CF58352}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for Stream Buffer Source to ITV" threadingModel="Apartment" />
    <comClass clsid="{9193A8F9-0CBA-400E-AA97-EB4709164576}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for Stream Buffer Source to CC" threadingModel="Apartment" />
    <comClass clsid="{991DA7E5-953F-435B-BE5E-B92A05EDFC42}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Stream Buffer Source to Generic Sink Composition Class" threadingModel="Apartment" />
    <comClass clsid="{C4BF2784-AE00-41BA-9828-9C953BD3C54A}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for CC to Video Renderer" threadingModel="Apartment" />
    <comClass clsid="{D76334CA-D89E-4BAF-86AB-DDB59372AFC2}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MS Video Control Custom Composition for CC to Audio Renderer" threadingModel="Apartment" />
    <comClass clsid="{577FAA18-4518-445E-8F70-1473F8CF4BA4}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MSEventBinder Class" threadingModel="Apartment" />
    <comClass clsid="{CAAFDD83-CEFC-4E3D-BA03-175F17A24F91}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="MSVidStreamBufferRecordingControl" threadingModel="Apartment" />
    <comClass clsid="{CB4276E6-7D5F-4CF1-9727-629C5E6DB6AE}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="Automation compliant scalable rectangle Class" />
    <comClass clsid="{6E40476F-9C49-4C3E-8BB9-8587958EFF74}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="dummy class to expose base interface to VB" />
    <comClass clsid="{30997F7D-B3B5-4A1C-983A-1FE8098CB77D}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="dummy class to expose base interface to VB" />
    <comClass clsid="{AC1972F2-138A-4CA3-90DA-AE51112EDA28}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="dummy class to expose base interface to VB" />
    <comClass clsid="{95F4820B-BB3A-4E2D-BC64-5B817BC2C30E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="dummy class to expose base interface to VB" />
    <comClass clsid="{1990D634-1A5E-4071-A34A-53AAFFCE9F36}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="dummy class to expose base interface to VB" />
    <comClass clsid="{7748530B-C08A-47EA-B24C-BE8695FF405F}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="dummy class to expose base interface to VB" />
    <comClass clsid="{87EB890D-03AD-4E9D-9866-376E5EC572ED}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" description="dummy class to expose base interface to VB" />
    <comClass clsid="{D02AAC50-027E-11D3-9D8E-00C04F72D980}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="SystemTuningSpace Class" threadingModel="Both" />
    <comClass clsid="{5FFDC5E6-B83A-4B55-B6E8-C69E765FE9DB}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="dummy class to expose base tuning space i/f to VB" />
    <comClass clsid="{CC829A2F-3365-463F-AF13-81DBB6F3A555}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Channel ID Tuning Space Class" threadingModel="Both" />
    <comClass clsid="{A2E30750-6C3D-11D3-B653-00C04F79498E}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="ATSC Digital Broadcast Tuning Space Class" threadingModel="Both" />
    <comClass clsid="{D9BB4CEE-B87A-47F1-AC92-B08D9C7813FC}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Digital Cable Tuning Space Class" threadingModel="Both" />
    <comClass clsid="{8A674B4C-1F63-11D3-B64C-00C04F79498E}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Analog Radio Tuning Space Class" threadingModel="Both" />
    <comClass clsid="{F9769A06-7ACA-4E39-9CFB-97BB35F0E77E}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Auxiliary Inputs Tuning Space Class" threadingModel="Both" />
    <comClass clsid="{8A674B4D-1F63-11D3-B64C-00C04F79498E}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Analog TV Tuning Space Class" threadingModel="Both" />
    <comClass clsid="{C6B14B32-76AA-4A86-A7AC-5C79AAF58DA7}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="DVB Tuning Space Class" threadingModel="Both" />
    <comClass clsid="{B64016F3-C9A2-4066-96F0-BD9563314726}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="DVB Satellite Tuning Space Class" threadingModel="Both" />
    <comClass clsid="{A1A2B1C4-0E3A-11D3-9D8E-00C04F72D980}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Component Types Collection Class" threadingModel="Both" />
    <comClass clsid="{823535A0-0318-11D3-9D8E-00C04F72D980}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="ComponentType Class" threadingModel="Both" />
    <comClass clsid="{1BE49F30-0E1B-11D3-9D8E-00C04F72D980}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="LanguageComponentType Class" threadingModel="Both" />
    <comClass clsid="{418008F3-CF67-4668-9628-10DC52BE1D08}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="MPEG2ComponentType Class" threadingModel="Both" />
    <comClass clsid="{A8DCF3D5-0780-4EF4-8A83-2CFFAACB8ACE}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="ATSCComponentType Class" threadingModel="Both" />
    <comClass clsid="{809B6661-94C4-49E6-B6EC-3F0F862215AA}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Components Collection Class" threadingModel="Both" />
    <comClass clsid="{59DC47A8-116C-11D3-9D8E-00C04F72D980}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Component Class" threadingModel="Both" />
    <comClass clsid="{055CB2D7-2969-45CD-914B-76890722F112}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="MPEG2 Component Class" threadingModel="Both" />
    <comClass clsid="{28AB0005-E845-4FFA-AA9B-F4665236141C}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Analog Audio Component Class" threadingModel="Both" />
    <comClass clsid="{B46E0D38-AB35-4A06-A137-70576B01B39F}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="dummy class to expose base tune request i/f to VB" />
    <comClass clsid="{3A9428A7-31A4-45E9-9EFB-E055BF7BB3DB}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Channel Tune Request" threadingModel="Both" />
    <comClass clsid="{0369B4E5-45B6-11D3-B650-00C04F79498E}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Channel Tune Request" threadingModel="Both" />
    <comClass clsid="{0369B4E6-45B6-11D3-B650-00C04F79498E}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="ATSC Channel Tune Request" threadingModel="Both" />
    <comClass clsid="{26EC0B63-AA90-458A-8DF4-5659F2C8A18A}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Digital Cable Channel Tune Request" threadingModel="Both" />
    <comClass clsid="{0955AC62-BF2E-4CBA-A2B9-A63F772D46CF}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="dummy class to expose mpeg2 request i/f to VB" threadingModel="Both" />
    <comClass clsid="{2C63E4EB-4CEA-41B8-919C-E947EA19A77C}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Factory for creating IMPEG2TuneRequest" threadingModel="Apartment" />
    <comClass clsid="{0888C883-AC4F-4943-B516-2C38D9B34562}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="dummy class to expose base locator i/f to VB" />
    <comClass clsid="{6E50CC0D-C19B-4BF6-810B-5BD60761F5CC}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="dummy class to expose base digital locator i/f to VB" />
    <comClass clsid="{49638B91-48AB-48B7-A47A-7D0E75A08EDE}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Analog Locator" threadingModel="Both" />
    <comClass clsid="{8872FF1B-98FA-4D7A-8D93-C9F1055F85BB}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="ATSC Locator" threadingModel="Both" />
    <comClass clsid="{03C06416-D127-407A-AB4C-FDD279ABBE5D}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Digital Cable Locator" threadingModel="Both" />
    <comClass clsid="{9CD64701-BDF3-4D14-8E03-F12983D86664}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="DVB-Terrestrial Locator" threadingModel="Both" />
    <comClass clsid="{EFE3FA02-45D7-4920-BE96-53FA7F35B0E6}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="DVB-Terrestrial 2 Locator" threadingModel="Both" />
    <comClass clsid="{1DF7D126-4050-47F0-A7CF-4C4CA9241333}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="DVB-Satellite Locator" threadingModel="Both" />
    <comClass clsid="{C531D9FD-9685-4028-8B68-6E1232079F1E}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="DVB-Cable Locator" threadingModel="Both" />
    <comClass clsid="{6504AFED-A629-455C-A7F1-04964DEA5CC4}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="ISDB-Satellite Locator" threadingModel="Both" />
    <comClass clsid="{15D6504A-5494-499C-886C-973C9E53B9F1}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="DVB Tune Request" threadingModel="Both" />
    <comClass clsid="{8A674B49-1F63-11D3-B64C-00C04F79498E}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Create property bag backed by registry" threadingModel="Both" />
    <comClass clsid="{0B3FFB92-0919-4934-9D5B-619C719D0202}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="DShow Broadcast Event Service Object" threadingModel="Both" />
    <comClass clsid="{6438570B-0C08-4A25-9504-8012BB4D50CF}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="BDA ITuner Marshaling utility object" threadingModel="Both" />
    <comClass clsid="{E77026B0-B97F-4CBB-B7FB-F4F03AD69F11}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Utility object for Tuning Model Object Xml deserialization or serialization" threadingModel="Both" />
    <comClass clsid="{C20447FC-EC60-475E-813F-D2B0A6DECEFE}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Extensible Eventing Service object" threadingModel="Both" />
    <comClass clsid="{8E8A07DA-71F8-40C1-A929-5E3A868AC2C6}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" description="Eventing Service object(used for unmarshal)" />
    <typelib tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" version="1.0" helpdir="" flags="HASDISKIMAGE" />
    <typelib tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" version="1.0" helpdir="" flags="HASDISKIMAGE" />
  </file>
  <comInterfaceExternalProxyStub name="_IMSVidCtlEvents" iid="{B0EDF164-910A-11D2-B632-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020420-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidAnalogTuner2" iid="{37647BF7-3DDE-4CC8-A4DC-0D534D3D0037}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidAnalogTuner" iid="{1C15D47E-911D-11D2-B632-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidTuner" iid="{1C15D47D-911D-11D2-B632-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidVideoInputDevice" iid="{1C15D47F-911D-11D2-B632-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidInputDevice" iid="{37B0353D-A4C8-11D2-B634-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidDevice" iid="{1C15D47C-911D-11D2-B632-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="ITuneRequest" iid="{07DDC146-FC3D-11D2-9D8C-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="ITuningSpace" iid="{061C6E30-E622-11D2-9493-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IEnumGUID" iid="{0002E000-0000-0000-C000-000000000046}" proxyStubClsid32="{0002E000-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IEnumMoniker" iid="{00000102-0000-0000-C000-000000000046}" proxyStubClsid32="{00000102-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMoniker" iid="{0000000F-0000-0000-C000-000000000046}" proxyStubClsid32="{0000000F-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IPersistStream" iid="{00000109-0000-0000-C000-000000000046}" proxyStubClsid32="{00000109-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IPersist" iid="{0000010C-0000-0000-C000-000000000046}" proxyStubClsid32="{0000010C-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IStream" iid="{0000000C-0000-0000-C000-000000000046}" proxyStubClsid32="{0000000C-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="ISequentialStream" iid="{0C733A30-2A1C-11CE-ADE5-00AA0044773D}" proxyStubClsid32="{0C733A30-2A1C-11CE-ADE5-00AA0044773D}" />
  <comInterfaceExternalProxyStub name="IBindCtx" iid="{0000000E-0000-0000-C000-000000000046}" proxyStubClsid32="{0000000E-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IRunningObjectTable" iid="{00000010-0000-0000-C000-000000000046}" proxyStubClsid32="{00000010-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IEnumString" iid="{00000101-0000-0000-C000-000000000046}" proxyStubClsid32="{00000101-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IComponentTypes" iid="{0DC13D4A-0313-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IEnumComponentTypes" iid="{8A674B4A-1F63-11D3-B64C-00C04F79498E}" proxyStubClsid32="{8A674B4A-1F63-11D3-B64C-00C04F79498E}" />
  <comInterfaceExternalProxyStub name="IComponentType" iid="{6A340DC0-0311-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="ILocator" iid="{286D7F89-760C-4F89-80C4-66841D2507AA}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IComponents" iid="{39A48091-FFFE-4182-A161-3FF802640E26}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IEnumComponents" iid="{2A6E2939-2595-11D3-B64C-00C04F79498E}" proxyStubClsid32="{2A6E2939-2595-11D3-B64C-00C04F79498E}" />
  <comInterfaceExternalProxyStub name="IComponent" iid="{1A5576FC-0E19-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidAnalogTunerEvent" iid="{1C15D486-911D-11D2-B632-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidTunerEvent" iid="{1C15D485-911D-11D2-B632-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidInputDeviceEvent" iid="{37B0353E-A4C8-11D2-B634-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidGraphSegment" iid="{238DEC54-ADEB-4005-A349-F772B9AFEBC4}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{238DEC54-ADEB-4005-A349-F772B9AFEBC4}" />
  <comInterfaceExternalProxyStub name="IEnumFilters" iid="{56A86893-0AD4-11CE-B03A-0020AF0BA770}" proxyStubClsid32="{56A86893-0AD4-11CE-B03A-0020AF0BA770}" />
  <comInterfaceExternalProxyStub name="IBaseFilter" iid="{56A86895-0AD4-11CE-B03A-0020AF0BA770}" proxyStubClsid32="{56A86895-0AD4-11CE-B03A-0020AF0BA770}" />
  <comInterfaceExternalProxyStub name="IMediaFilter" iid="{56A86899-0AD4-11CE-B03A-0020AF0BA770}" proxyStubClsid32="{56A86899-0AD4-11CE-B03A-0020AF0BA770}" />
  <comInterfaceExternalProxyStub name="IReferenceClock" iid="{56A86897-0AD4-11CE-B03A-0020AF0BA770}" proxyStubClsid32="{56A86897-0AD4-11CE-B03A-0020AF0BA770}" />
  <comInterfaceExternalProxyStub name="IEnumPins" iid="{56A86892-0AD4-11CE-B03A-0020AF0BA770}" proxyStubClsid32="{56A86892-0AD4-11CE-B03A-0020AF0BA770}" />
  <comInterfaceExternalProxyStub name="IPin" iid="{56A86891-0AD4-11CE-B03A-0020AF0BA770}" proxyStubClsid32="{56A86891-0AD4-11CE-B03A-0020AF0BA770}" />
  <comInterfaceExternalProxyStub name="IEnumMediaTypes" iid="{89C31040-846B-11CE-97D3-00AA0055595A}" proxyStubClsid32="{89C31040-846B-11CE-97D3-00AA0055595A}" />
  <comInterfaceExternalProxyStub name="IFilterGraph" iid="{56A8689F-0AD4-11CE-B03A-0020AF0BA770}" proxyStubClsid32="{56A8689F-0AD4-11CE-B03A-0020AF0BA770}" />
  <comInterfaceExternalProxyStub name="IMSVidGraphSegmentContainer" iid="{3DD2903D-E0AA-11D2-B63A-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{3DD2903D-E0AA-11D2-B63A-00C04F79498E}" />
  <comInterfaceExternalProxyStub name="IGraphBuilder" iid="{56A868A9-0AD4-11CE-B03A-0020AF0BA770}" proxyStubClsid32="{56A868A9-0AD4-11CE-B03A-0020AF0BA770}" />
  <comInterfaceExternalProxyStub name="IEnumMSVidGraphSegment" iid="{3DD2903E-E0AA-11D2-B63A-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{3DD2903E-E0AA-11D2-B63A-00C04F79498E}" />
  <comInterfaceExternalProxyStub name="IMSVidFilePlayback2" iid="{2F7E44AF-6E52-4660-BC08-D8D542587D72}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidFilePlayback" iid="{37B03539-A4C8-11D2-B634-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidPlayback" iid="{37B03538-A4C8-11D2-B634-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidFilePlaybackEvent" iid="{37B0353A-A4C8-11D2-B634-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidPlaybackEvent" iid="{37B0353B-A4C8-11D2-B634-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidWebDVD" iid="{CF45F88B-AC56-4EE2-A73A-ED04E2885D3C}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidRect" iid="{7F5000A6-A440-47CA-8ACC-C0E75531A2C2}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{7F5000A6-A440-47CA-8ACC-C0E75531A2C2}" />
  <comInterfaceExternalProxyStub name="IMSVidWebDVDEvent" iid="{B4F7A674-9B83-49CB-A357-C63B871BE958}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidWebDVDAdm" iid="{B8BE681A-EB2C-47F0-B415-94D5452F0E05}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidVideoRenderer2" iid="{6BDD5C1E-2810-4159-94BC-05511AE8549B}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidVideoRenderer" iid="{37B03540-A4C8-11D2-B634-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidOutputDevice" iid="{37B03546-A4C8-11D2-B634-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IVMRImageCompositor" iid="{7A4FB5AF-479F-4074-BB40-CE6722E43C82}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{7A4FB5AF-479F-4074-BB40-CE6722E43C82}" />
  <comInterfaceExternalProxyStub name="IVMRMixerBitmap" iid="{1E673275-0257-40AA-AF20-7C608D4A0428}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{1E673275-0257-40AA-AF20-7C608D4A0428}" />
  <comInterfaceExternalProxyStub name="IVMRSurfaceAllocator" iid="{31CE832E-4484-458B-8CCA-F4D7E3DB0B52}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{31CE832E-4484-458B-8CCA-F4D7E3DB0B52}" />
  <comInterfaceExternalProxyStub name="IVMRSurfaceAllocatorNotify" iid="{AADA05A8-5A4E-4729-AF0B-CEA27AED51E2}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{AADA05A8-5A4E-4729-AF0B-CEA27AED51E2}" />
  <comInterfaceExternalProxyStub name="IMSVidVideoRendererEvent" iid="{37B03545-A4C8-11D2-B634-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidOutputDeviceEvent" iid="{2E6A14E2-571C-11D3-B652-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidDeviceEvent" iid="{1C15D480-911D-11D2-B632-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidVMR9" iid="{D58B0015-EBEF-44BB-BBDD-3F3699D76EA1}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidEVR" iid="{15E496AE-82A8-4CF9-A6B6-C561DC60398F}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMFVideoPresenter" iid="{29AFF080-182A-4A5D-AF3B-448F3A6346CB}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{29AFF080-182A-4A5D-AF3B-448F3A6346CB}" />
  <comInterfaceExternalProxyStub name="IMFClockStateSink" iid="{F6696E82-74F7-4F3D-A178-8A5E09C3659F}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{F6696E82-74F7-4F3D-A178-8A5E09C3659F}" />
  <comInterfaceExternalProxyStub name="IMFVideoMediaType" iid="{B99F381F-A8F9-47A2-A5AF-CA3A225A3890}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{B99F381F-A8F9-47A2-A5AF-CA3A225A3890}" />
  <comInterfaceExternalProxyStub name="IMFMediaType" iid="{44AE0FA8-EA31-4109-8D2E-4CAE4997C555}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{44AE0FA8-EA31-4109-8D2E-4CAE4997C555}" />
  <comInterfaceExternalProxyStub name="IMFAttributes" iid="{2CD2D921-C447-44A7-A13C-4ADABFC247E3}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{2CD2D921-C447-44A7-A13C-4ADABFC247E3}" />
  <comInterfaceExternalProxyStub name="IStorage" iid="{0000000B-0000-0000-C000-000000000046}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{0000000B-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IEnumSTATSTG" iid="{0000000D-0000-0000-C000-000000000046}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{0000000D-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IRecordInfo" iid="{0000002F-0000-0000-C000-000000000046}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{0000002F-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="ITypeInfo" iid="{00020401-0000-0000-C000-000000000046}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020401-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="ITypeComp" iid="{00020403-0000-0000-C000-000000000046}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020403-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="ITypeLib" iid="{00020402-0000-0000-C000-000000000046}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020402-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidEVREvent" iid="{349ABB10-883C-4F22-8714-CECAEEE45D62}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidAudioRenderer" iid="{37B0353F-A4C8-11D2-B634-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidAudioRendererEvent" iid="{37B03541-A4C8-11D2-B634-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidGenericSink2" iid="{6B5A28F3-47F1-4092-B168-60CABEC08F1C}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidGenericSink" iid="{6C29B41D-455B-4C33-963A-0D28E5E555EA}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidStreamBufferSink3" iid="{4F8721D7-7D59-4D8B-99F5-A77775586BD5}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidStreamBufferSink2" iid="{2CA9FC63-C131-4E5A-955A-544A47C67146}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidStreamBufferSink" iid="{159DBB45-CD1B-4DAB-83EA-5CB1F4F21D07}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidStreamBufferRecordingControl" iid="{160621AA-BBBC-4326-A824-C395AEBC6E74}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidStreamBufferSinkEvent4" iid="{1B01DCB0-DAF0-412C-A5D1-590C7F62E2B8}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidStreamBufferSinkEvent3" iid="{735AD8D5-C259-48E9-81E7-D27953665B23}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidStreamBufferSinkEvent2" iid="{3D7A5166-72D7-484B-A06F-286187B80CA1}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidStreamBufferSinkEvent" iid="{F798A36B-B05B-4BBE-9703-EAEA7D61CD51}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidStreamBufferSource" iid="{EB0C8CF9-6950-4772-87B1-47D11CF3A02F}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidStreamBufferSource2" iid="{E4BA9059-B1CE-40D8-B9A0-D4EA4A9989D3}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidStreamBufferSourceEvent" iid="{50CE8A7D-9C28-4DA8-9042-CDFA7116F979}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidStreamBufferSourceEvent2" iid="{7AEF50CE-8E22-4BA8-BC06-A92A458B4EF2}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidStreamBufferSourceEvent3" iid="{CEABD6AB-9B90-4570-ADF1-3CE76E00A763}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidStreamBufferV2SourceEvent" iid="{49C771F9-41B2-4CF7-9F9A-A313A8F6027E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidEncoder" iid="{C0020FD4-BEE7-43D9-A495-9F213117103D}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidFeature" iid="{37B03547-A4C8-11D2-B634-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidClosedCaptioning3" iid="{C8638E8A-7625-4C51-9366-2F40A9831FC0}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidClosedCaptioning2" iid="{E00CB864-A029-4310-9987-A873F5887D97}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidClosedCaptioning" iid="{99652EA1-C1F7-414F-BB7B-1C967DE75983}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidDataServices" iid="{334125C1-77E5-11D3-B653-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidXDS" iid="{11EBC158-E712-4D1F-8BB3-01ED5274C4CE}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidXDSEvent" iid="{6DB2317D-3B23-41EC-BA4B-701F407EAF3A}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidFeatureEvent" iid="{3DD2903C-E0AA-11D2-B63A-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidCompositionSegment" iid="{1C15D483-911D-11D2-B632-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{1C15D483-911D-11D2-B632-00C04F79498E}" />
  <comInterfaceExternalProxyStub name="IObjectWithSite" iid="{FC4801A3-2BA9-11CF-A229-00AA003D7352}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{FC4801A3-2BA9-11CF-A229-00AA003D7352}" />
  <comInterfaceExternalProxyStub name="IMSVidCtl" iid="{B0EDF162-910A-11D2-B632-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidInputDevices" iid="{C5702CD1-9B79-11D3-B654-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidOutputDevices" iid="{C5702CD2-9B79-11D3-B654-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidVideoRendererDevices" iid="{C5702CD3-9B79-11D3-B654-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidAudioRendererDevices" iid="{C5702CD4-9B79-11D3-B654-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidFeatures" iid="{C5702CD5-9B79-11D3-B654-00C04F79498E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSEventBinder" iid="{C3A9F406-2222-436D-86D5-BA3229279EFB}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMSVidDevice2" iid="{87BD2783-EBC0-478C-B4A0-E8E7F43AB78E}" tlbid="{B0EDF154-910A-11D2-B632-00C04F79498E}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="ITuningSpaceContainer" iid="{5B692E84-E2F1-11D2-9493-00C04F72D980}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="ITuningSpaces" iid="{901284E4-33FE-4B69-8D63-634A596F3756}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IEnumTuningSpaces" iid="{8B8EB248-FC2B-11D2-9D8C-00C04F72D980}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{8B8EB248-FC2B-11D2-9D8C-00C04F72D980}" />
  <comInterfaceExternalProxyStub name="IBDAComparable" iid="{B34505E0-2F0E-497B-80BC-D43F3B24ED7F}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{B34505E0-2F0E-497B-80BC-D43F3B24ED7F}" />
  <comInterfaceExternalProxyStub name="IBDACreateTuneRequestEx" iid="{C0A4A1D4-2B3C-491A-BA22-499FBADD4D12}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{C0A4A1D4-2B3C-491A-BA22-499FBADD4D12}" />
  <comInterfaceExternalProxyStub name="IATSCTuningSpace" iid="{0369B4E2-45B6-11D3-B650-00C04F79498E}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IAnalogTVTuningSpace" iid="{2A6E293C-2595-11D3-B64C-00C04F79498E}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IDigitalCableTuningSpace" iid="{013F9F9C-B449-4EC7-A6D2-9D4F2FC70AE5}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IAnalogRadioTuningSpace2" iid="{39DD45DA-2DA8-46BA-8A8A-87E2B73D983A}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IAnalogRadioTuningSpace" iid="{2A6E293B-2595-11D3-B64C-00C04F79498E}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IAuxInTuningSpace" iid="{E48244B8-7E17-4F76-A763-5090FF1E2F30}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IAuxInTuningSpace2" iid="{B10931ED-8BFE-4AB0-9DCE-E469C29A9729}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IDVBTuningSpace2" iid="{843188B4-CE62-43DB-966B-8145A094E040}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IDVBTuningSpace" iid="{ADA0B268-3B19-4E5B-ACC4-49F852BE13BA}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IDVBSTuningSpace" iid="{CDF7BE60-D954-42FD-A972-78971958E470}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="ILanguageComponentType" iid="{B874C8BA-0FA2-11D3-9D8E-00C04F72D980}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMPEG2ComponentType" iid="{2C073D84-B51C-48C9-AA9F-68971E1F6E38}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IATSCComponentType" iid="{FC189E4D-7BD4-4125-B3B3-3A76A332CC96}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IComponentsOld" iid="{FCD01846-0E19-11D3-9D8E-00C04F72D980}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMPEG2Component" iid="{1493E353-1EB6-473C-802D-8E6B8EC9D2A9}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IAnalogAudioComponentType" iid="{2CFEB2A8-1787-4A24-A941-C6EAEC39C842}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IChannelIDTuneRequest" iid="{156EFF60-86F4-4E28-89FC-109799FD57EE}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IChannelTuneRequest" iid="{0369B4E0-45B6-11D3-B650-00C04F79498E}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IATSCChannelTuneRequest" iid="{0369B4E1-45B6-11D3-B650-00C04F79498E}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IDigitalCableTuneRequest" iid="{BAD7753B-6B37-4810-AE57-3CE0C4A9E6CB}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMPEG2TuneRequest" iid="{EB7D987F-8A01-42AD-B8AE-574DEEE44D1A}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMPEG2TuneRequestFactory" iid="{14E11ABD-EE37-4893-9EA1-6964DE933E39}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IDigitalLocator" iid="{19B595D8-839A-47F0-96DF-4F194F3C768C}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IAnalogLocator" iid="{34D1F26B-E339-430D-ABCE-738CB48984DC}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IATSCLocator2" iid="{612AA885-66CF-4090-BA0A-566F5312E4CA}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IATSCLocator" iid="{BF8D986F-8C2B-4131-94D7-4D3D9FCC21EF}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IDigitalCableLocator" iid="{48F66A11-171A-419A-9525-BEEECD51584C}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IDVBTLocator" iid="{8664DA16-DDA2-42AC-926A-C18F9127C302}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IDVBTLocator2" iid="{448A2EDF-AE95-4B43-A3CC-747843C453D4}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IDVBSLocator2" iid="{6044634A-1733-4F99-B982-5FB12AFCE4F0}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IDVBSLocator" iid="{3D7C353C-0D04-45F1-A742-F97CC1188DC8}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IDVBCLocator" iid="{6E42F36E-1DD2-43C4-9F78-69D25AE39034}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IISDBSLocator" iid="{C9897087-E29C-473F-9E4B-7072123DEA14}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IDVBTuneRequest" iid="{0D6F567E-A636-42BB-83BA-CE4C1704AFA2}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="ICreatePropBagOnRegKey" iid="{8A674B48-1F63-11D3-B64C-00C04F79498E}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{8A674B48-1F63-11D3-B64C-00C04F79498E}" />
  <comInterfaceExternalProxyStub name="IBroadcastEvent" iid="{3B21263F-26E8-489D-AAC4-924F7EFD9511}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{3B21263F-26E8-489D-AAC4-924F7EFD9511}" />
  <comInterfaceExternalProxyStub name="IRegisterTuner" iid="{359B3901-572C-4854-BB49-CDEF66606A25}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{359B3901-572C-4854-BB49-CDEF66606A25}" />
  <comInterfaceExternalProxyStub name="ITuner" iid="{28C52640-018A-11D3-9D8E-00C04F72D980}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{28C52640-018A-11D3-9D8E-00C04F72D980}" />
  <comInterfaceExternalProxyStub name="IPersistTuneXmlUtility" iid="{990237AE-AC11-4614-BE8F-DD217A4CB4CB}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{990237AE-AC11-4614-BE8F-DD217A4CB4CB}" />
  <comInterfaceExternalProxyStub name="IPersistTuneXmlUtility2" iid="{992E165F-EA24-4B2F-9A1D-009D92120451}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{992E165F-EA24-4B2F-9A1D-009D92120451}" />
  <comInterfaceExternalProxyStub name="IESEventService" iid="{ED89A619-4C06-4B2F-99EB-C7669B13047C}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{ED89A619-4C06-4B2F-99EB-C7669B13047C}" />
  <comInterfaceExternalProxyStub name="IESEvent" iid="{1F0E5357-AF43-44E6-8547-654C645145D2}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{1F0E5357-AF43-44E6-8547-654C645145D2}" />
  <comInterfaceExternalProxyStub name="IESEvents" iid="{ABD414BF-CFE5-4E5E-AF5B-4B4E49C5BFEB}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{ABD414BF-CFE5-4E5E-AF5B-4B4E49C5BFEB}" />
  <comInterfaceExternalProxyStub name="IESEventFactory" iid="{506A09B8-7F86-4E04-AC05-3303BFE8FC49}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{506A09B8-7F86-4E04-AC05-3303BFE8FC49}" />
  <comInterfaceExternalProxyStub name="IMarshal2" iid="{000001CF-0000-0000-C000-000000000046}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{000001CF-0000-0000-C000-000000000046}" />
  <comInterfaceExternalProxyStub name="IMarshal" iid="{00000003-0000-0000-C000-000000000046}" tlbid="{9B085638-018E-11D3-9D8E-00C04F72D980}" proxyStubClsid32="{00000003-0000-0000-C000-000000000046}" />
</assembly>