[OAUTH-WG] Re: New Internet-Draft: Approval-Based Dynamic Client Registration

Jaryn Sabey Tue, 21 Jul 2026 06:24:24 -0700

Thi,

That’s a sharp reframing, and I think you’re right about the mechanism: the key doesn’t carry provenance, it is the instance identity, and its ability to sign is the attestation that its conditions still hold. “The key working proves its validity” collapses a lot - if version is a reconstruction condition, v2 signing with v1’s key isn’t something you detect and forbid, it simply can’t happen.

Where I’d draw the line is liveness versus history. The key working proves the conditions hold now, to whoever checks it now. But if re-approval isn’t one of those conditions - only version-compatibility is - then v2 presenting a working key looks identical whether the user re-approved or the endorsement was silently carried forward; the key can’t separate them. And if re-approval is a condition, the key working does imply it happened - but it proves that to the checker in the moment, not to an auditor afterward, as a record that outlives the key and doesn’t rest on the issuer’s word. Either way, “which instances did this user authorize, and was the v2 rollout re-approved or inherited?” is a question about the past, and a key is only ever evidence about the present.

That’s the durable surface I meant, and I think it sits under your mechanism rather than against it the same way it sits under the assertion carriers earlier in the thread. Your key is the live enforcement at the endpoint, where the hardware property holds; a signed record of the endorsement acts minted, refused, revoked, re-endorsed at upgrade is the accountability someone can check afterward, offline, without trusting the issuer’s logs, and in the environments where the endpoint can’t see the conditions at all. Refusals are the sharpest case: a key that never existed because the issuer declined to endorse is, at the endpoint, indistinguishable from any other reason it isn’t there. The only way that “no” becomes checkable is if it was written down in a form that doesn’t require trusting the writer.

So your design makes the present self-proving the strongest possible answer to “are the conditions holding right now.” The durable record answers the orthogonal question: “what did the governing system decide, and can I verify it later without taking its word for it.” The two want to meet right at the upgrade, where the key deliberately keeps nothing about whether authority was re-approved or inherited.

Would genuinely like to get into the detail the reconstruction-conditions model is an interesting version.

Jaryn

On Jul 21, 2026, at 5:44 AM, Thi Nguyen-Huu <[email protected]> wrote:

Karl,

> the RS sees at most a key thumbprint, which rotates with the key and carries no provenance

Agreed, and I think the cause sits one layer below the token: a thumbprint carries no provenance because the key can be copied. If the key exists nowhere else, the thumbprint is a stable instance identity by itself.

And if the same key disappears when the conditions of the instance are no longer met, there is nothing to revoke.

This approach — the key exists nowhere else, and it disappears when its conditions are no longer met — puts the decision at the endpoint, which is where the conditions are: the one that can see them fail is the one that can stop the access.

This is the approach I described on this list last week (the key under DPoP or mTLS-bound tokens). It needs hardware for the first characteristic, so it does not apply in every environment. And an assertion layer stays essential for what the endpoint cannot see. But where it applies, the key underneath the mechanism you already use carries live identity assurance by itself.

Jaryn — on the durable side: this key can be long-lived, it can be re-used for every operation. But it only works while its conditions hold. Every new operation re-constructs the key with all conditions checked, so if the version of the agent is one of those conditions, v2 cannot use v1's key. You can see that from the key, not from a log — the key working proves its validity.

Happy to go into the detail if useful.

Cheers

Thi Nguyen-Huu | CEO

Tel: +1 905.502.7000 x 3288 | Toll Free: 888.879.5879
[email protected] | www.winmagic.com

WinMagic Corp. | 11-80 Galaxy Blvd.

Toronto, ON | M9W 4Y8 | Canada | www.winmagic.com

From: Jaryn Sabey <[email protected]>
Sent: Tuesday, July 21, 2026 3:40 AM
To: Karl McGuinness <[email protected]>
Cc: Emelia S. <[email protected]>; Jeff Lombardo <[email protected]>; Aaron Parecki <[email protected]>; Philippe Dellaert <[email protected]>; Max Gerber <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]
Subject: [OAUTH-WG] Re: New Internet-Draft: Approval-Based Dynamic Client Registration

You don't often get email from [email protected]. Learn why this is important

CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe.

Karl’s framing clarifies the whole thread for me:

once the user is the attestation authority and an enrollment service is the instance issuer, the stack above CIMD is complete at runtime, and everything in it is deliberately ephemeral (short-lived assertions, rotating thumbprints, expiring tokens).

What that stack leaves behind, by design, is nothing. The enterprise cases in this thread will eventually need the durable side of the same design:

a verifiable record of the approval ceremony and of the issuer’s endorsement acts (minted, refused, revoked, re-endorsed after an agent upgrade), so that “which instances did this user authorize, and did the v2 rollout carry the endorsement forward or re-run the approval?” has an answer an auditor can check without trusting the issuer’s logs.

That’s not a competing mechanism; it’s the audit surface of the instance-issuer model, and it composes with any of the assertion carriers discussed here.

Jaryn

On Jul 20, 2026, at 11:57 PM, Karl McGuinness <[email protected]> wrote:

Hi Emelia,

CIMD's identity stays generic/shared as intended; instance and user binding happen at the layers above it that perform client authentication.

+1, I think this is the right model: the shared identity stays put, and the binding problems get solved by the authentication and authorization layers above it.

One clarification on Jeff's earlier comment, since the draft is probably new to most here:

Having a differentiated CIMD needs some enrollment with the provider of the client (here ACME), something which is not always possible. Therefore this also leaves Karl McGuinness's Client Instance Assertion draft as a not usable solution.

Client Instance Assertion (https://datatracker.ietf.org/doc/draft-mcguinness-oauth-client-instance-assertion/) doesn't need a differentiated CIMD per instance; avoiding that is its central design decision. One client_id covers many runtime instances, and instances are differentiated at the token endpoint by a short-lived assertion from an "instance issuer" the client's metadata endorses. That endorsement comes from the client's metadata in either registration model the draft supports: the published CIMD, or RFC 7591-shaped metadata registered at the AS, so a deployment that can't get anything from ACME can still adopt it by registering the agent locally. Either way the identity stays shared: one registration covering every instance, never a registration per instance. And the instance key is never published; it rides as a cnf thumbprint inside the assertion.

Building on the ABCA point: agreed that we can start using it, and the instance-issuer model is designed to enable exactly that kind of composition rather than new registration machinery. The AI Agent Instance profile (https://datatracker.ietf.org/doc/draft-mcguinness-oauth-ai-agent-instance/) is one example: the same agent instance claims ride in either a Client Instance Assertion or an ABCA Client Attestation in DPoP combined mode, with the same claims and token surfacing on both carriers. Jeff's user_code ceremony could be another: an enrollment service that authenticates the resource owner, runs the approval once, and mints instance assertions afterward is an instance issuer in the draft's terms. The user becomes the attestation authority, and AS token processing stays standard.

One nit on the ABCA-only stack: ABCA authenticates the instance at the token endpoint but defines no representation of it in the issued token. With DPoP the RS sees at most a key thumbprint, which rotates with the key and carries no provenance; it's not a stable, attested instance identity. Surfacing the validated instance in the token (act.sub when acting for a user, sub when self-acting, sender-constrained to the instance key) is the missing layer, and that's the layer these drafts add.

Net: CIMD for the generic identity, PAR for request integrity, the resource owner's grant-level approval, instance evidence via ABCA or an instance assertion, and the instance surfaced in the issued token. I think that covers Jeff's case with no per-instance registrations and nothing per-instance to publish, but I may be lacking the full story.

Best,

Karl

On Mon, Jul 20, 2026 at 10:31 PM Emelia S. <emelia=[email protected]> wrote:

Hi Jeff,

I think this (if it is a) device code grant flow is already achievable, but there's a finer point: the per-instance/resource-owner binding here is done via:

Attestation-Based Client Authentication [1] in DPoP/PoP mode, to bind the authorization to a specific instance key, carried through on every subsequent request
Device code grant's existing approval step to bind the authorization to a specific resource owner (I think Aaron has a draft that explains how DPoP/PoP's work with Device Code Grant Flow.
Pushed Authorization Requests to lock down request parameters ahead of the flow, preventing user tampering.

CIMD's identity stays generic/shared as intended; instance and user binding happen at the layers above it that perform client authentication.

ABCA is still a draft, but that doesn't mean we can't start to use it — I think AB-DCR may duplicate something that ABCA + CIMD + PAR may make already possible.

[1] https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/

Yours,

Emelia Smith

On 21 Jul 2026, at 07:13, Lombardo, Jeff <jeffsec=[email protected]> wrote:

Hi Aaron,

Thanks for the feedback.

Here are some answers on my peer Draft.

As far as I understand it, https://www.ietf.org/archive/id/draft-richer-oauth-pushed-client-registration-00.html has been proposed for “ephemeral or transactional OAuth 2.0 client to signal to the AS that the client does not need or expect to have an identified state outside the existence of any issued access and refresh tokens” which sounds logic under the assumption of your use case. The fact that is piggyback on PAR as the only objective are issuance of tokens is fair.

The live use case behind this proposal provides the ability to bind a general AI Agent (client), provided by ACME and that could not possess a differentiated CIMD per installed instance (i.e. generic https://acme.abc/my-ai-agent), to a subject / resource owner.

This answer your question: the approving party is the resource owner (user running the client).

Having a differentiated CIMD needs some enrollment with the provider of the client (here ACME), something which is not always possible. Therefore this also leaves Karl McGuinness'sClient Instance Assertion draft as a not usable solution.

The behavior proposed here is:

Starting a DCR registration flow as usual but with a new parameter
Pausing the process with a similar approach as for Deferred Token Response, except it embeds also a user_code à la Device Code Grant Flow to be redeemed by an authenticated resource owner / user running the client.
The Resource owner effectively redeem the code after proper authentication at the OP
Once redeemed, the client can through its Polling retrieve its set of unique client id and associated credential

There is some place for being to support client that could generate a secret client side
Still we will have to live with the constraint that the Client cannot advertise the public part of its credential publicly as it cannot posses a specific CIMD

If the process is successful, as indicated, the client is now registered AND bound to the user, which unlocks additional capabilities as the origin, purpose, and usage controls possess more contextual information.

Jeff

Jean-François “Jeff” Lombardo | Amazon Web Services

Architecte Principal de Solutions, Stratégie de Sécurité
Principal Solution Architect, Security Strategy
Montréal, Canada

Commentaires à propos de notre échange? Exprimez-vous ici.

Thoughts on our interaction? Provide feedback here.

From: Aaron Parecki <[email protected]>
Sent: July 20, 2026 8:08 PM
To: Philippe Dellaert <[email protected]>
Cc: Jaryn Sabey <[email protected]>; Max Gerber <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: [EXT] [OAUTH-WG] Re: New Internet-Draft: Approval-Based Dynamic Client Registration

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque.

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 <mgerber=[email protected]> wrote:

A few scattered thoughts:
- The latest spec 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]

_______________________________________________
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-WG] Re: New Internet-Draft: Approval-Based Dynamic Client Registration

Reply via email to