Session Date/Time: 06 Jan 2025 17:00

OAUTH

Summary

The OAUTH Working Group held an interim meeting to discuss the "OAUTH Client ID Scheme" draft (draft-aaron-oauth-client-id-scheme). The discussion centered on standardizing a mechanism for clients to publish metadata and use a URL as their client_id, particularly in scenarios where client pre-registration is not feasible. A significant portion of the discussion revolved around the ambiguity arising from existing deployments that already use HTTPS URLs as client_id in various contexts (e.g., OpenID Federation, client metadata documents), and how to introduce a clear scheme without breaking backward compatibility or introducing new security vulnerabilities. No formal decisions were made, but an action item was assigned to the author to refine the draft with explicit consideration of the proposed solutions.

Key Discussion Points

Client ID Metadata Context: The discussion built upon the "Client ID Metadata" draft (draft-aaron-oauth-client-metadata), which proposes a method for OAUTH clients to publish their metadata at a URL and then use that URL as the client_id in authorization requests. This is beneficial for ecosystems where pre-registration of clients is impractical (e.g., self-hosted applications, microservices).
Ambiguity of HTTPS URLs as Client IDs: Previous discussions highlighted that several existing specifications and deployments already use HTTPS URLs as client_id values, including OpenID Federation and client metadata documents. This creates ambiguity for an Authorization Server (AS) attempting to interpret a given client_id.
"Client ID Scheme" Draft Proposal: The new draft aims to extract and standardize the scheme:value syntax for client IDs, originally defined in OpenID for Verifiable Presentations (VP). This syntax allows for explicit identification of the client ID's type (e.g., did:, redirect:, https:).
- The OpenID for VP specification currently limits the https scheme primarily to OpenID Federation.
- The draft proposes defining https as a scheme for systems that only need to support one interpretation (either OpenID Federation or client ID metadata).
Parameter vs. Prefix (Scheme:Value): A query was raised about using a separate client_id_type parameter instead of a scheme:value prefix. Participants noted that this was extensively discussed in the OpenID for VP working group. The conclusion was that a single scheme:value string for client_id is preferable to avoid security issues (e.g., mixing/matching parameters by attackers) and simplify its use in other contexts like JWT claims.
Resolving HTTPS Ambiguity - Initial Proposal: The draft's initial proposal for resolving https ambiguity was for Authorization Servers expecting conflicting uses to operate with different issuer URLs and corresponding authorization endpoints. This implies that clients would implicitly know which method to use based on the issuer URL they target.
- Concerns: Participants (e.g., Brian) expressed discomfort with this, stating it could limit the flexibility of generalized AS products/services that wish to support multiple resolution methods under a single top-level issuer domain, adding configuration and maintenance complexity.
Alternative Proposal - Explicit Prefixes for HTTPS: An alternative was proposed (e.g., Emilia) to introduce explicit prefixes for specific HTTPS URL interpretations (e.g., metadata:https://example.com or federation:https://example.com).
- This approach would treat bare https: (e.g., https://example.com) as an opaque value, allowing AS to define their default behavior (e.g., error, default to one type).
- This provides an "upgrade path" for existing deployments to adopt explicit prefixes while maintaining some backward compatibility with bare HTTPS URLs.
- This approach was seen as potentially cleaner and more consistent, resolving concerns about the awkwardness of the current scheme:value model and its potential confusion with URI schemes.
Discussion on Terminology (URI, URL, Scheme): There was some discussion regarding the consistent use of "URI," "URL," and "scheme," and whether the "scheme" in scheme:value should always align with official URI schemes. This highlighted potential for confusion in the draft's language.
"Client_URL" Parameter Proposal: A suggestion (e.g., Dick) to introduce a new client_url parameter in the authorization request for un-pre-registered clients was discussed.
- This was largely dismissed as it wouldn't fully solve the internal ambiguity of the URL's interpretation and would require significant breaking changes for existing ecosystems that already use client_id for this purpose. The sentiment was that standards should document existing practice where possible, rather than force new, incompatible mechanisms.
Relationship with Existing Deployments: The importance of accommodating existing, widely deployed solutions (like OpenID Federation) that use bare HTTPS URLs as client_id was a recurring theme. The challenge is to introduce clarity and consistency for the future without disrupting current operations.

Decisions and Action Items

No Formal Decisions: No formal decisions were made during this meeting.
Action Item (Aaron): The author of the "OAUTH Client ID Scheme" draft is tasked with documenting the various proposals and alternative approaches discussed (especially regarding the handling of HTTPS URL ambiguity, including explicit prefixes and treatment of bare HTTPS URLs), capturing their pros and cons. This will facilitate further discussion and refinement of the draft. Engagement with implementers for feedback on these alternatives is encouraged.
Administrative Note: The "Client ID Metadata" draft (draft-aaron-oauth-client-metadata) has recently expired and needs to be refreshed or resubmitted by the author to remain on the working group track.

Next Steps

Aaron to update the "OAUTH Client ID Scheme" draft based on the discussion and the assigned action item, providing clear options for handling HTTPS URL client ID ambiguity.
Further discussions on the refined proposals are expected to occur on the OAUTH mailing list and/or at future interim meetings.