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]
