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] >>> <mailto:[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 >>>>> <[email protected] >>>>> <mailto:[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] <mailto:[email protected]> >>>>> To unsubscribe send an email to [email protected] >>>>> <mailto:[email protected]> >>>> _______________________________________________ >>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[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]
