Thanks for the detailed review Justin! We've incorporated your feedback and published a new version:
https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.html As part of this review there were a couple of suggestions/questions that felt like they warrant some discussion in the working group, which I will bring up at IETF 126. These are already captured as GitHub issues on the draft. Aaron On Fri, May 15, 2026 at 3:29 PM Justin Richer <[email protected]> wrote: > Hi all, I read through CIMD and wanted to provide some feedback. Overall I > think it’s a great spec, and my team is busy implementing and applying it > in a few places. I do think it could use better framing and a handful of > updates. Attached is my review, organized by section. > > Huge thanks to the authors for pushing this forward! > > — Justin > > > Overall: > > I think this is missing a discussion on the kinds of clients where this > approach makes sense, and where it does not. Namely, if a client is > relatively well-known and has an established home, like a website, then > this works great. For other clients, including those in §4.2, it's not as > great a fit. I think it's fine for this specification to not work for a > class of clients - and it should be upfront about it instead of pretending > it fits well. > > §3 > > This feels like it should be a list, not a paragraph. Try reformatting and > see if that works? > > Globally redefining "client identifier" seems a bridge too far for this > spec to do in isolation, consider perhaps defining "Client Identifier URI" > or something specific to CIMD so as not to imply that ALL client > identifiers are now URLs. > > Refer to the URI spec (RFC3986) for URI parts. The "username or password" > is called the "userinfo" subcomponent of the authority, for example. And > "port" is also part of the authority. > > "Port" should probably have some matching done to it — like defaults of > 443 being equivalent to non included — or it should be direct string > comparison only as implied by §4.1 and default port processing expressly > disallowed. Really, leaning on the URI definitions will help this too. > > "This specification places no restrictions" after a bunch of restrictions > is … weird. Perhaps be more specific about what "no restrictions" are > included in "no restrictions" like URL shorteners or stability. That said, > most shorteners use redirects to work, which breaks the resolution > restriction in §4, can we square that circle? > > §4 > > It's not clear why fetching the document is a "should". I know it can be > associated by hand, so I think maybe that's what this SHOULD is trying to > get at. Perhaps call out that it MUST be associated with a set of client > metadata, which is available at the URL, and the AS SHOULD fetch it > automatically within security considerations. > > §4.1 > > "The client metadata document MUST be served with a 200 OK HTTP status > code" this is a requirement of the fetch process not the document. > > Does "the URL of the document" mean the URL used to fetch the document, > exactly? This sounds like it's something the AS (fetcher) needs to > validate, then — call out both of these more explicitly. > > Suggest that the discussion on client secrets be pulled out as a separate > section to highlight its importance here. Also add discussion on private > keys, but public keys are allowable. > > I see no discussion of software_Statement and how it would fit with this > work, suggest we add discussion of how (or if) they fit together. I > personally think they could be layered with some cautions on the > trustworthiness of the software_statement (since it's no longer presented > inline by the client). > > Suggest that you separate the "what's in the doc" from "how you get the > doc" in this section overall. > > §4.2 > > While I see the practical appeal, the CIMD-service really just feels like > a weird way to do static registration but use a side door to do so. This > also seems like it directly contradicts the trust model proposed by this > specification. I would recommend removal of this beyond discussion in > security considerations, or add it as an appendix to describe how > CIMD-as-a-service could be built and offered by a party, and discuss the > security and reputation implications thereof. > > §4.3 > > What if the server isn't fetching it, under some circumstances allowed by > §4? Are there any validation requirements (that might need its own section > alongside 4.1) > > §4.5 > > By "exact match" I assume this means string-match, either call that out or > point to the logic in the core OAuth specs that say so. > > This also implies that only redirect-based grants are allowed to be used, > but I don't see that called out anywhere in here. Could I use CIMD for > client_credentials or token exchange? Device flow? CIBA? Why or why not? > > §6 > > Generally speaking, there shouldn't be any normative text in security > considerations. Especially the MAYs here are pointless and more explanatory > than requirement anyway. Stick to non-normative text in this section and > put the normative requirements further up. > > §6.5 > > "except when the authorization server itself is also running on a loopback > address and the resolved address matches the same loopback interface" — > couldn't this be used to force an AS to call a loopback function from the > outside via a client-provided value? I'm failing to see what the use case > to allow this cutout is. Development is a different world where > restrictions like this are routinely relaxed, but here it reads like this > should be a normal cutout for the protocol. > > §6.6 > > "Authorization servers SHOULD limit the response size" — how does the AS > limit the size of a file it does not control? Do you mean limit processing > to the first 5k and erroring or discarding the rest? > > §6.8 > > Suggest adding a discussion of allowlists, especially of domain patterns — > eg, "anything from foo.com". The framing of different policies for > different states of client trust is a good one, keep that. > > §6.9 > > This doesn't seem like a security consideration, but an implementation > consideration. > > More to the point, the AS needs to be able to differentiate between > clients registered via CIMD and clients registered by other means. Client > ID prefix is only one aspect of this, as there might be AS's that do use > https:// for clients (such as vanity IDs or stable developer-facing > identifiers), but don't fetch the data. Suggest calling out that "do I > fetch this or not" is the key difference. > > §6.10 > > This doesn't seem like a security consideration, but an implementation > consideration. I would argue that it leverages the namespacing and other > aspects of CIMD while not relying on automated systems — so I would suggest > not framing it as "Defeating the purpose". This discussion could be helped > by separating the "fetch" from "format" as suggested above. > > §?? > > This is missing privacy considerations, please add them. In particular, AS > fetching or providing to the end user any URLs dynamically handed over by > the client in a CIMD could lead to leaking user usage patterns or > information. > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
