I'm clearly a lot less optimistic about this draft than others on this thread, but I will give my 2¢ anyway.
I see called out in the intro that the "approving party" is likely to be the user running the client. In that case, there is no benefit to this flow over either CIMD or an idea that Justin and I were playing around with called "Pushed Client Registration" https://www.ietf.org/archive/id/draft-richer-oauth-pushed-client-registration-00.html which pushes the client reg info in the PAR request. If the approving party is not the user, but the operator of the AS, then this can't realistically be expected to be used during an OAuth transaction anyway. I am struggling to understand the uses of this that aren't better solved using Client ID Metadata Document. Aaron On Mon, Jul 20, 2026 at 7:32 PM Emelia S. <emelia= [email protected]> wrote: > Yeah, that would make sense! In the "CIMD Service" idea in the CIMD > Appendix A, the reference implementation actually uses JSON to CBOR > encoding to generate a CID (content identifier) from the CIMD pushed to the > service, such that changes are super easy to detect, and deduplication is > easy. Obviously that's a very specific thing to that reference > implementation, but the reason for it is because JSON is unordered, keys > can be in any order without a change to the document meaning. CBOR hashes > stabilise the key sorting so same document but different ordering = same > CID. > > https://github.com/ThisIsMissEm/cimd-service/ > > - Emelia > > On 20 Jul 2026, at 19:17, Jaryn Sabey <[email protected]> wrote: > > A thought on the approval step, following Neil’s question: as drafted, > AB-DCR specifies how approval happens (202, verification URI, polling) but > not what evidence it leaves behind. If the approval is load-bearing (and > the enterprise onboarding cases CIMD §7.2 gestures at suggest it is), the > artifact that matters afterward is a verifiable record of who approved, > under what policy, bound to exactly what was approved. > > Concretely: bind the approval to a hash of the canonical registered > document. For the CIMD composition Emelia describes, that would be the > document as fetched at approval time. This answers “what did the approver > actually see” (the client-asserted-values problem), and it gives §8.4 a > clean semantics: an updated document provably differs from the approved > one, so AS policy can decide whether the prior approval carries forward > under key continuity or requires re-approval, and either decision is itself > recordable. Denials deserve the same treatment: a signed refusal carrying > its ground is worth as much to an auditor as the approval. > > Neil’s “any user can approve a client for everyone” concern also gets > easier to reason about when approvals are attributable records rather than > side effects. The AS policy Max describes becomes checkable after the fact, > not just enforceable in the moment. > > FWIW, I’ve been working exactly this evidence layer for authority > transitions generally, in draft-sabey-succession-receipts (policy-gated > transitions, refused before recorded, portable offline-verifiable receipts > hash-bound to what was approved). Happy to compare notes if any of it maps. > > Jaryn > > On Jul 20, 2026, at 10:49 AM, Emelia S. <[email protected]> wrote: > > Hi all, > > In the new -02 of the CIMD draft, published recently, we have a new two > new sections of §7.2 (pre-registration) and §8.4 (changes in client > metadata), both of which could actually work really nicely with this > proposal. Essentially a "push" to AS for a given CIMD saying "I want to > enrol this CIMD with the AS" and "I want to update the AS on a changed > CIMD", as for how that process happens (the knowledge of which AS's exist > for a given CIMD, a server-based or app-based client can track metrics for > users/AS as to have data to say "send updates to these AS's" whilst > remaining with no exact formal arrangement between AS and Client, that is > the client is still able to use any AS that conforms to it's needs. > > For this case we'd be doing a push of the Client Identifier URL, not the > contents of the document, whereas DCR would be the push of the > content. Where AB-DCR's status codes would map: > > - 201 → AS fetched immediately, pre-registration/refresh accepted, no > approval needed (open policy) > - 202 + registration code / verification URI → AS requires a human to > review the fetched document before trusting it (the enterprise onboarding > case §7.2 already gestures at) > - 429 + Retry-After → same backoff signal > - 400 → fetch failed, document invalid, etc. (this one's actually more > natural for CIMD than for DCR, since "the AS tried to fetch and it 404'd" > is a real distinct failure mode you don't have in classic DCR) > > So I think it'd be a nice complement. In practice I've not really seen the > DCR management protocol particularly used, it may be something IDP's / AS's > bigger than I have worked with have used, I'm not sure. It'd be great to > have some stats on usage of the various specs to further inform writing new > specs, maybe that's a topic for IETF 126 this week? Just like a survey that > we can publish through our networks and hopefully gain insights on. > > Auth on push probably also needs to be thought through here, perhaps > reusing mechanisms like JWKS signing or the new client attestation draft > (CBAC? CABC?), and then the client can effectively auth for the content's > in the current document using the same signing keys if doing an update. I > think DCR management may already specify that, but it's been a long time > since I've fully read that spec. > > Yours, > Emelia > > > On 20 Jul 2026, at 13:19, Max Gerber <[email protected]> > wrote: > > A few scattered thoughts: > - The latest spec > <https://modelcontextprotocol.io/specification/draft/basic/authorization/client-registration#dynamic-client-registration> > of > MCP has deprecated DCR in favor of CIMD. It is only included for backward > compatibility now. > - I would appreciate concrete examples of how AB-DCR compares to CIMD, and > where AB-DCR might be more appropriate to use. Off the top of my head - > this would be primarily for clients unable to host a CIMD URL? So primarily > native applications or CLI tools that are not associated with a website or > domain? > - I would be interested in exploring mechanisms that combine the approval > of the client with an authorization grant, so that the user doesn't need to > click through multiple flows back-to-back. > > Niel wrote: > > > clients are not tied to one particular user, so this seems dangerous if > any user can approve a client for everyone > > I think this is an issue the AS is already equipped to solve. The AS must > already have a policy defining which user or developer can register a > client manually, and that same policy should extend to which user can > approve a client registration. If the AS allows any developer to self-serve > sign up and create a client, then that same policy should govern client > approval. If the AS requires developers to be onboarded in some manner, > those developers should be onboarded before making the client globally > available. Additionally, several ASs currently have concepts of > organization-bound or user-bound clients, which can only be used with a > subset of users as determined by AS policy. > > On Mon, Jul 20, 2026 at 10:55 AM Neil Madden <[email protected]> > wrote: > >> It would be good to understand exactly what approval you are expecting to >> happen during this flow? The draft says “an explicit approval step >> performed by an approving party, typically the user running the client”. >> But clients are not tied to one particular user, so this seems dangerous if >> any user can approve a client for everyone. >> >> Dynamic client registration always has the problem of what exactly the AS >> or an approver is supposed to base their decision on, when all they have is >> client-asserted values. Software statements improve this somewhat, where >> supported. The only approval steps I can think of that make sense are >> things like reviewing policy/privacy documents etc for compliance. But >> that’s not something that can be completed in a few minutes while the >> client sits around polling for a response. >> >> On 20 Jul 2026, at 05:41, Dellaert, Philippe <pdellaer= >> [email protected]> wrote: >> >> >> Hi all, >> >> As you might have noticed, I’ve submitted a new Internet-Draft: >> Approval-Based Dynamic Client Registration: >> https://datatracker.ietf.org/doc/draft-dellaert-oauth-approval-based-dcr/ >> >> Dynamic Client Registration provides a way for new clients to register >> themselves using an open registration mechanism, or registering using an >> Initial Access Token for extra security. For certain clients like native >> applications, CLI tools, or applications at scale, providing an IAT is not >> always an option and open registration is something many operators prefer >> to avoid. >> >> I propose an approval-based registration using the existing DCR >> registration endpoint where the client opts-in for this new mode. If the >> authorization server’s policy supports and requires an approval before the >> client is registered, it returns a registration code, a verification code >> and a verification URI. The client polls the registration endpoint while an >> approver approves or denies the registration request out of band using the >> verification code and the verification URI. Once approved, on the next >> poll, the client receives a normal DCR response. >> >> A lot of this is inspired by the Device Authorization Grant (RFC 8628) >> and the Deferred Token Response draft. I do diverge from these proposals by >> using specific HTTP response codes instead of using error responses. >> Registration success remains 201, a pending registration waiting for >> approval returns 202, both for initial request and polling, and 429 with a >> Retry-After response header is used to indicate to the client to slow down >> the requests. 400 is still used for errors. >> >> I’d welcome feedback from the group, and especially from the authors of >> Dynamic Client Registration as this is an addition to DCR, and from the >> authors of Device Authorization Grant and Deferred Token Response as they >> are a source of inspiration. I have cc’d the DCR and DTR authors out of >> courtesy, not out of any expectation. >> >> Regards, >> Philippe >> _______________________________________________ >> 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] >> > _______________________________________________ > 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] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
