Hi all,
I owe the working group a review of the "OAuth Profile for Open Public Clients", and apologies for sending this so late after the last IETF meeting, and the night before this IETF meeting.
Please note that I have not followed all of the discussion about this draft on the mailing list or recent meetings. If any of my suggestions have already been discussed and decided against, the justification for the decision would be worth noting in the draft for future reference.
My feedback is ordered most significant to least significant.
Overall, this spec is in good shape. It avoids defining new OAuth mechanisms, it establishes no new relationships between OAuth roles and it uses the standard Resource Owner / Client / AS / RS model.
Client Registration
My largest piece of feedback is about the use of Dynamic Client Registration. The use of DCR in "open world" OAuth will lead to significant operational burden. I believe I already shared this feedback a couple of years ago. Since then, there has been another large scale deployment of DCR that has since moved away to an alternative.
The initial version of the MCP spec from March 2025 required MCP clients register using DCR. Many of the authorization servers that immediately added support for it have since come to regret the challenges with operating it long term, and there are many other authorization servers that refused to add support in the first place, requiring manual configuration instead.
In the time between then and now, the OAuth working group has adopted Client ID Metadata Document (CIMD) https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/ which provides a way for a client to publish its metadata at a URL and use that URL as the OAuth client_id. Both the BlueSky/atproto ecosystem as well as the MCP ecosystem now recommend CIMD as the default client registration option. Since both of these ecosystems are also "open world" OAuth like the email ecosystem, it would also be a natural fit here.
While it is not yet an RFC, it is already getting quite a lot of adoption, and I expect that to continue.
Despite the client_id being a URL, this works just fine with desktop and native apps. The URL would be hosted on the app's website, and since most apps have a website you can download them from, this isn't a problem in practice. And for the clients that are already web based, this is a natural fit. Which also leads me to the next point...
Client Authentication
I realize that most of the clients that will implement this spec are desktop/mobile clients, so will be considered public clients since they won't have a way to be provisioned with credentials. However there will also be clients that are running on a web server, in which case they do have the ability to manage credentials.
Paired with CIMD, a web-based client would publish its public key and link to it from the jwks_uri property in the CIMD, and would then be able to strongly authenticate all outgoing requests using private_key_jwt (described in Section 8.2 https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.html#section-8.2). For these clients, it means the client metadata is not only hosted at a URL, but the metadata can actually be considered to be authenticated so is much more trustworthy than both unauthenticated CIMD metadata and especially DCR metadata. The other nice thing about this is if an authorization server doesn't care about client authentication it can just ignore the header and process the request identical to a client that doesn't use client authentication.
offline_access scope
The offline_access scope is not defined in any OAuth RFC, it originates from the OpenID Connect Core spec. Using it in a non-OIDC OAuth profile is fine, but registering it in the IANA "OAuth Scope" registry is probably not appropriate. I think you can just remove this from the IANA registration section and the references to it in the scope sections are sufficient.
DPoP
Requiring DPoP would provide meaningfully stronger security, as token theft is a realistic threat against long-running desktop clients. The draft acknowledges DPoP's value but leaves it optional. Given that the minimum access token lifetime is one hour (see below), a stolen token has significant value. DPoP substantially limits the risk.
Combining with the feedback above, an option could be to require DPoP for public clients, but leave it optional for clients using client authentication published in the CIMD.
Token Lifetime
Most OAuth security guidance recommends short-lived access tokens, in the order of minutes, not hours. Setting a minimum of 1 hour in the spec is unusual and goes against the direction of most OAuth security profiles. This isn't necessarily a dealbreaker, but is at least worth justifying in a little more detail.
If you are using DPoP, you can also generally justify longer-lived access tokens, so another option is to have different recommendations depending on whether DPoP is used.
Pushed Authorization Requests
Pushed Authorization Requests (RFC 9126) prevents authorization request parameters from appearing in browser history and eliminates certain parameter-manipulation attacks. For this use case, where the client constructs the full authorization URL locally before handing it to the browser, PAR would provide meaningful additional protection. To my earlier point, if there was a conscious decision to not require PAR, it would be worth noting the reasons at the very least.
Discovery from Email Address
There is a mention in Security Considerations that "The issuer is expected to be autodetected from the user's email address", but there is no description of how this is expected to be done. I see that this mechanism is described in the "Automatic Configuration of Email, Calendar, and Contact Server Settings" draft, but there should probably be a reference to that from somewhere in this profile.
Missing reference to RFC 9700 (OAuth Security BCP)
The spec references RFC 6819 as the OAuth threat model but not RFC 9700 (OAuth 2.0 Security Best Current Practices, published 2025). RFC 9700 supersedes much of RFC 6819's threat analysis and is the current normative security reference. This should be added.
Thanks, and I am happy to discuss any of this further during the meeting or if you find me during any breaks this week.
