SEP-837: Update authorization spec to clarify client type requirements

[mikekistler]

Is your feature request related to a problem? Please describe.

Implement support for SEP-837, which is planned for inclusion in the 2026-06-30 version of the MCP spec.

Describe the solution you'd like

Compliance with the 2026-06-30 version of the MCP spec within two weeks of its release.

[mikekistler]

Implementation Details

SEP-837 adds a MUST requirement for MCP clients to include application_type during Dynamic Client Registration when interacting with OIDC-flavored authorization servers.

Required changes:

1. Add application_type to DynamicClientRegistrationRequest (src/ModelContextProtocol.Core/Authentication/DynamicClientRegistrationRequest.cs):

   [JsonPropertyName("application_type")]
   public string? ApplicationType { get; init; }

2. Add ApplicationType to DynamicClientRegistrationOptions (src/ModelContextProtocol.Core/Authentication/DynamicClientRegistrationOptions.cs) so callers can configure it:

   public string? ApplicationType { get; set; }

3. Wire it up in ClientOAuthProvider.PerformDynamicClientRegistrationAsync to populate the field from options.

4. Consider defaulting to "native" — since the C# SDK is primarily used for desktop apps, CLI tools, and locally-hosted servers, defaulting to "native" aligns with the spec's guidance that desktop/CLI/localhost apps SHOULD use "native".

5. Handle registration failures gracefully — the spec says clients MUST handle rejection due to redirect URI constraints and SHOULD surface meaningful errors. The current code already throws with the error content, so this is likely already covered.

[jayaraman-venkatesan]

@mikekistler
Before I pick this up, I noticed another SDK implemented this differently and wanted to check with you on step 4 of your implementation comment (the default value)

SDK survey (as of 2026-05-26):

SDK	Status
python-sdk	Not implemented
typescript-sdk	Not implemented
java-sdk	Not implemented
kotlin-sdk	Not implemented
go-sdk	Implemented — PR #904, merged 2026-04-27

The Go SDK is the only one that's shipped this, and it doesn't hard-code a default. Instead it infers application_type from the registered redirect URIs:

// auth/authorization_code.go
func inferApplicationType(redirectURIs []string) string {
    // loopback (localhost, 127.0.0.1, [::1]) or custom-scheme  → "native"
    // remote https://                                          → "web"
    // mixed                                                    → "" (let AS apply OIDC default)
}

And at config time, if the caller has explicitly set ApplicationType and it conflicts with the inferred value, registration fails fast with a local error instead of letting the AS reject the request.

Which would you prefer for the C# SDK?

[mikekistler]

@jayaraman-venkatesan Good catch! I think the behavior in the Go SDK is preferable to what I specified for Step 4. Actually I'm pretty sure Copilot wrote that and I just pasted it in -- I don't think I would have written:

since the C# SDK is primarily used for desktop apps, CLI tools, and locally-hosted servers,

[jayaraman-venkatesan]

On that case, can you please assign it to me, I can work on this @mikekistler