Expose OAuth discovery and registration results for application-owned flows #1371

Could rmcp expose complete discovery and registration results for applications that use its protocol helpers but own the surrounding OAuth lifecycle?

The use case is a client that has its own versioned credential persistence, refresh coordination, consent UI, and HTTP policy. It would like to reuse rmcp's discovery and registration rather than duplicate them, then use the resulting data with lower-level OAuth operations. This is distinct from supplying a custom CredentialStore to the SDK-managed authorization flow.

I checked main at 5d9935d. Two public-API gaps make that composition difficult:

• AuthorizationMetadataResolution exposes AS metadata and discovery provenance, but not the discovered protected-resource identifier or the selected advertised authorization-server identifier. Resource scopes also remain private, and select_scopes() applies policy rather than returning the separate discovery inputs.
• AuthorizationManager::register_client() parses the public ClientRegistrationResponse, then returns an OAuthClientConfig and configures the manager. The returned config retains the client ID/secret, but uses the requested redirect URI and drops the server-returned redirect list, client name, and extension fields such as token_endpoint_auth_method.

This means a caller cannot obtain all the resource/issuer/registration facts through those public operations without independently repeating discovery or intercepting and parsing HTTP responses.

An additive approach might be:

• Extend the existing discovery result with the resource identifier and selected advertised AS identifier, with explicit absence semantics for direct-AS discovery and legacy fallback. If separate challenge/resource scopes are exposed, coordinate that representation with the scope-selection work below. Return facts from the same discovery operation, rather than assembling a result from later mutable manager state.
• Expose a registration operation returning the existing ClientRegistrationResponse. Define it as registration-only, leaving the current register_client() convenience method to delegate to it and perform its existing configuration step. This should share one request/parsing implementation and preserve the current method's signature.

The registration result would mean the parsed server response, not a claim that every redirect or authentication method is acceptable to the application. Its validation guarantees and handling of secret-bearing fields should be explicit. Existing convenience flows and default policy could remain unchanged.

Related work I found:

• #1041 already exposes discovery provenance; this would extend that result rather than add a competing API.
• #962 uses the discovered resource internally, while #1113 proposes an override. Public discovery output is a different requirement.
• #1352 addresses initial scope selection. I would coordinate any scope-source exposure with it, rather than implement another selection policy or tracker.
• #1355 / #1358 address DCR authentication-method selection, and #1255 addresses credential restoration. Returning the actual registration response would complement those changes, not replace them.

Potential regression tests would cover a discovered resource different from the configured endpoint; explicit absence on non-PRM paths; ordinary versus challenge-seeded discovery; repeated discovery without stale result fields; preservation of returned registration redirects/name/extensions; one discovery/registration request path; and compatibility of the existing convenience methods.

This proposal does not change issuer-selection/fallback behavior, private-destination policy, automatic retries, or credential persistence. Those can be discussed separately; it should not duplicate the active scope or transport-policy work.

Would additive result APIs along these lines fit the SDK? I can contribute focused discovery-result and registration-result PRs once the intended API boundary is agreed. If an existing issue or planned API already covers these exact outputs, a pointer would help avoid duplicate work.