Scopes not forwarded to DCR endpoint and duplication of RedirectUris

Start with HttpClientTransport and its OAuth and DynamicClientRegistrationOptions handling, then trace how ResourceMetadata.ScopesSupported reaches the DCR request. Verify the requested scopes are forwarded and determine how the OAuth and DCR RedirectUri values should be reconciled; done means both behaviors are covered without requiring duplicate configuration.

I have implemented an MCP server and added DCR support to my Duende Identity Server, and it all kind of works with the MCP Server and MCP Client in the SDK. However, one issue seems to be with scopes. The server declares it's supported scopes:

.AddMcp(options =>
{
    options.ResourceMetadata = new()
    {
        Resource = new Uri(serverUrl),
        AuthorizationServers = { new Uri(chronosIdp) },       
        ScopesSupported = ["mcp:tools"]
    };
});

However, in the request that my DCR endpoint receives, Scopes is null. Shouldn't the HttpClientTransport take the scopes from the MCP Server and add these to the DCR request?

Right now I can add them manually here, but a normal MCP tool user wouldn't know what scopes to request - that's why the MCP server declares them:

var transport = new HttpClientTransport(new()
{
    Endpoint = new Uri(serverUrl),
    Name = "Secure Chronos Client",
    OAuth = new()
    {
        Scopes = [ "mcp:tools", "chronosapi"], // shouldn't need to do this!
        RedirectUri = new Uri("http://localhost:1179/callback"),
        AuthorizationRedirectDelegate = HandleAuthorizationUrlAsync,
        DynamicClientRegistration = new DynamicClientRegistrationOptions
        {
            ClientName = "Chronos MCP Client",
            ClientUri = new Uri("http://localhost:1179/callback")            
        },
    }
}, httpClient, consoleLoggerFactory);

var client = await McpClient.CreateAsync(transport, loggerFactory: consoleLoggerFactory);

Also it seems a bit redundant to specify the same RedirectUri in the OAuth object AND the DCR object - they are necessarily the same so maybe if the DCR property is present the OAuth object can use the info there - or vice versa. Just to make it easier to set up correctly.