Hi Warren, Thank you for narrowing it down that way, it is very helpful. As you say, the AS side is not the issue. An AS can mint an SD-JWT VC today, and generation and verification of both the SD-JWT and the DPoP proof are already specified. Creating a DPoP proof for an SD-JWT on the client side is not difficult either. The gap is at the next step, on the verifier side.
First, the format. An SD-JWT presentation always ends with a "~", even without any disclosures, so it is not a plain JWT. It fits the HTTP header syntax, but an existing DPoP resource server that parses the token as a JWT will not accept it as is. In this respect, a JOSE-secured W3C VC, being a plain JWT, is cleaner. Introspection would avoid the format issue, but then the resource server would contact the issuer on every presentation, which is the kind of structure credentials are meant to avoid. Second, key binding. In RFC 9901, whether to require Key Binding is up to the verifier's policy, and the only mechanism it defines is the KB-JWT. So a resource server can choose not to require SD-JWT Key Binding and check DPoP instead, but nothing currently says that the DPoP proof provides equivalent binding. Interestingly, an ath computed over the presented SD-JWT covers exactly the same bytes as sd_hash, so I believe it already provides nearly the same guarantee in practice. In short, the first is closer to an implementation matter, while the second is what is actually missing at the specification level. It is not a missing property in the SD-JWT spec, but the lack of a rule stating that, for an SD-JWT presented to a resource server, the DPoP proof can serve as the key binding. This is also why I have been considering setting selective disclosure aside and starting from a plain JWT format such as a JOSE-secured W3C VC, although I realize that in that case there would be very little left for a specification to define. Thank you again. Best regards, Su-hyeon -----Original Message----- From: "Warren Parad"<[email protected]> To: "Su-hyeon Forten Lee"<[email protected]>; Cc: "Yaron ZEHAVI"<[email protected]>; <[email protected]>; Sent: 2026-09-29 (화) 23:26:04 (GMT+09:00) Subject: Re: [OAUTH-WG] Re: New draft: Presenting Issuer-Signed JWT Credentials to Resource Servers with DPoP no problem, but I like this path you've now laid out. If you are interested in AS minting and distributing a VC, what stops your AS from doing that today via the SD-JWT? Do you control the AS? If so, you can make that change, but which step of the process would be a problem specifically? Is it attempting to add a DPoP signature on top of a sent SD-JWT? from the client, is that the problem. That's the only step which seems like it could be a problem, because of course the generation and verification of the SD-JWT exists, as well as the RFC for generation and verification of DPoP, so the problem you must be alluding to is a challenge creating an DPoP signature for the SD-JWT, which step is explicitly the issue, is it a missing property in the SD-JWT spec? On Tue, Sep 29, 2026 at 4:20 PM Su-hyeon Forten Lee <[email protected]> wrote: Hi Warren, Thank you for the question, and for taking the time to lay out the possibilities so clearly. The first one you describe, using OAuth to generate an access token that works as a credential, captures what I meant very precisely. I think this WG's SD-JWT VC is the most suitable format, but to be candid, one of the things I ultimately have in mind is a JOSE-secured W3C VC. From an engineering point of view, I am looking for a single artifact that works unchanged in both worlds: issued by an AS, accepted as a token by a DPoP resource server, and accepted as a credential by a VC verifier outside OAuth. Along the same lines, I am exploring whether the DPoP proof can take the place of the verifiable presentation that the VC side normally uses for holder binding. Verification with the AS's JWKs and the DPoP proof are the means to that end, and my interest is mainly in reusing what OAuth already provides. There are several challenges and pieces of work involved, but a representative one is defining a set of fields that work the same way for both a credential and an access token, such as iss, sub, exp and cnf, along with typ to tell the two kinds of token apart and status information. As you know, the biggest hurdle was aud, and thanks to the comments in this thread I feel I am finding a way through it. Whether this turns out to be work for the OAuth WG or for somewhere else, I have already gained a great deal of insight from this discussion. Thank you again. Best regards, Su-hyeon -----Original Message----- From: "Warren Parad"<[email protected]> To: "Su-hyeon Forten Lee"<[email protected]>; Cc: "Yaron ZEHAVI"<[email protected]>; <[email protected]>; Sent: 2026-09-29 (화) 22:48:29 (GMT+09:00) Subject: Re: [OAUTH-WG] Re: New draft: Presenting Issuer-Signed JWT Credentials to Resource Servers with DPoP What do you mean by "flow over existing OAuth infrastructure" exactly? When you say that, it sounds more like you are interested in the generation and distribution of credentials by an AS. Using OAuth to generate an access token that works as credentials. Or are you talking about how to verify the credentials using a JWK supplied by an AS? Or maybe you are just interested in being able to generate DPoP header values for your credentials. DPoP is limited to OAuth, but nothing would stop you from creating an OpenID4VP version (if that was your preference), but that would be likely out of scope for the OAuth working group. On Tue, Sep 29, 2026 at 2:29 PM Su-hyeon Forten Lee <[email protected]> wrote: Hi Yaron, Thank you very much for taking the time to write such a thoughtful and detailed review. I really appreciate it, and I learned a great deal from it. I agree with the concerns you raise, and reading them carefully, I came to think that the key question is how the use case is defined. The request-response flow with its nonce, issuer recognition, selective disclosure and privacy, wallets acting on behalf of people, and governance limiting which credential types a wallet can obtain all apply to credentials held in wallets and presented through OpenID4VP, and in those cases I fully agree that OpenID4VP is the right tool. What this draft has in mind is a narrower case. The holder is a non-human client that controls its own key, and the credential is issued by an authorization server or IdP the resource server already trusts, so from the resource server's point of view it sits in the same place as an access token. Although the resource server does not request the credential, it can still supply its own nonce through DPoP-Nonce, and the cnf key is set and signed by an issuer it already trusts, so my understanding is that holder binding is established in the same way as for a DPoP-bound access token. If you see a gap there, I would be very grateful for your guidance. Your comments made me realize this scope did not come through clearly enough in the draft, and I will make it explicit in the next revision. I also realize that within this scope the credential is very close to an access token. Coming from the credential side, what I would still like to do is find some first step that lets verifiable credentials flow over existing OAuth infrastructure, and this narrow case seemed the safest place to start. I would value your perspective on whether this is a reasonable way to begin. On audience, thank you for the concrete suggestions. I will reflect both approaches you described, multiple resource values yielding a multi-valued aud and an agreed aud value within one trust domain, and recommend a fresh mint with an accurate aud across unrelated resource servers, as you advised. Thank you again for your time and generosity. Best regards, Su-hyeon -----Original Message----- From: "Yaron ZEHAVI"<[email protected]> To: "Su-hyeon Forten Lee"<[email protected]>; "Warren Parad"<[email protected]>; Cc: "[email protected]"<[email protected]>; Sent: 2026-09-29 (화) 19:26:32 (GMT+09:00) Subject: [OAUTH-WG] Re: New draft: Presenting Issuer-Signed JWT Credentials to Resource Servers with DPoP Dear Su-hyeon, While a resource server can indeed be a credential verifier, the exchange of credential presentations in OpenID4VP is different from using access tokens: Clients send tokens to resource servers in unsolicited HTTP calls, while OpenID4VP credential presentation is a response to a credential request which contains a nonce to be included in the signed presentation response as replay protection mechanism. A resource server cannot safely accept a credential unless obtained through a presentation request it created, as it can’t establish holder binding. The basic idea to use credential key binding as DPoP might be feasible, but: Credentials are not access tokens, so their structure might be unsuitable for processing by resource servers (e.g issuer not recognized). Sending the entire credential and not a presentation of selected attributes could hinder subject’s privacy. Credentials are stored in wallets, so in human OBO use-cases the agent / client would have a presentation and not control the keys to make presentations. Non human wallet holders would control both the credentials and their keys, but would encounter previously mentioned challenges as well as governance frameworks would likely limit eligible wallets which can obtain certain credential types (e.g won’t issue an EU PID credential representing a natural person to an agent’s wallet). That said, the audience challenge you mention could be solved in other ways, such as: Requesting tokens with resource request parm specifying multiple values à obtains token with multi-value aud Multiple resource servers in the same trust domain could accept an agreed aud value, making the token usable for them all Where multiple unrelated resource servers are concerned, a fresh mint with accurate aud value is the most secure approach. I hope this helps Yaron Classification: GENERAL From: Su-hyeon Forten Lee <[email protected]> Sent: Monday, September 28, 2026 3:23 PM To: Warren Parad <[email protected]> Cc: [email protected] Subject: [OAUTH-WG] Re: New draft: Presenting Issuer-Signed JWT Credentials to Resource Servers with DPoP You don't often get email from [email protected]. Learn why this is important This message is from an external sender - be cautious, particularly with links and attachments. Hi Warren, Thank you for the feedback, I appreciate you taking the time. I think you are right that, seen from OAuth, nothing here is new, and I should have made that clearer up front: in a way, that is what the document is trying to say. On aud, I should be candid that this was the part I struggled with most. The access tokens DPoP is used with in practice require aud, and making it optional in the draft may well have been a stretch. My thinking was that the holder is the right party to decide the audience; that is what a presentation is. But the only aud available is inside the issuer-signed JWT, and the holder cannot set it without breaking the issuer's signature, unless one adopts a holder-signed wrapper as in the VP model, which is what I was trying to avoid. The DPoP proof's htu binds the request, but it is not an audience. I do not have a good answer yet, and it needs more thought. I come from the credential side, where it is often assumed that a verifier needs to run OpenID4VP. What I hoped to record is that a DPoP-capable resource server can already serve as a presentation verifier for SD-JWT-based credentials, with only a few small rules: matching cnf.jwk against cnf.jkt, computing ath over the presented SD-JWT including its disclosures so that the DPoP proof serves as the key binding, and distinguishing such a credential from an access token by typ. I suspect I found exciting what is simply ordinary in OAuth, and the draft shows it. I will revise several parts with this in mind. Thanks again for the comments. Best regards, Su-hyeon -----Original Message----- From: "Warren Parad"<[email protected]> To: "이수현"<[email protected]>; Cc: <[email protected]>; Sent: 2026-09-28 (월) 21:47:57 (GMT+09:00) Subject: [OAUTH-WG] Re: New draft: Presenting Issuer-Signed JWT Credentials to Resource Servers with DPoP What does the audience matter here? The audience claim is optional, what are you trying to do that DPoP doesn't already support, that's the part which isn't clear for me. I'm also not sure what agents have to do with this, A client interacts with multiple resource servers RS, but what ends up in the token is responsibility of the AS, if you don't want audience in the token, your AS doesn't have to put one there, right? So I'm still not really sure what can't be done today, or what the change is that the draft advocates for. As a bit of feedback, it feels like most if not all of the draft is defining what already exists as a summary of OAuth, JWTs, and DPoP, and I'm not sure why. On Mon, Sep 28, 2026 at 12:57 PM 이수현 <[email protected]> wrote: Hi Warren, Thank you for taking the time to read it, and fair point: the introduction is too abstract. Some context: I come from the credential side. In MCP and A2A, OAuth is the first-class mechanism, and from where I sit the goal is for credentials to fit into that as closely as possible. OpenID4VP is excellent where a verifier needs to negotiate with a wallet, but that is not this use case. What struck me is that a DPoP proof already has essentially the same structure as the key binding in a verifiable presentation, so an ordinary DPoP-capable resource server is, in effect, already a presentation verifier. Concretely: a user delegates to an agent, and the agent calls several resource servers (e.g. MCP tool servers) in the same trust domain. With access tokens, the agent needs a separate audience-restricted token for each resource server. The draft lets the AS, or an IdP the resource servers already trust, issue one holder-bound credential that the agent presents to each resource server directly with DPoP, with revocation through a status list. If the issuer sets aud, it is enforced as usual, and it can list the set of resource servers the credential is meant for. If aud is omitted, the credential is more flexible, at the cost of per-resource audience restriction. Does this make the use case clearer? If you think an existing mechanism already covers it, I would appreciate a pointer. Best regards, Su-hyeon -----Original Message----- From: "Warren Parad"<[email protected]> To: "이수현"<[email protected]>; Cc: <[email protected]>; Sent: 2026-09-28 (월) 19:00:47 (GMT+09:00) Subject: Re: [OAUTH-WG] New draft: Presenting Issuer-Signed JWT Credentials to Resource Servers with DPoP I'm pretty confused by this. I don't really understand what defines or the specific use case that is different from the existing mechanisms. I think the most poignant question for me would be related to this statement in the draft: The gap is most visible for AI agents. What gap? On Mon, Sep 28, 2026 at 11:31 AM 이수현 <[email protected]> wrote: Hi all, I have posted a new individual draft: https://datatracker.ietf.org/doc/draft-lee-oauth-dpop-credential-presentation/ It lets a client present an issuer-signed JWT credential directly to a resource server using DPoP (RFC 9449), with no authorization server or OpenID4VP flow in between. The wire format is that of a DPoP-bound access token; the draft adds only three rules: the issuer is an AS or IdP the resource server already trusts, the credential may carry no issuer-set audience, and the resource server checks its status. The motivation is clients that can simply submit a credential, such as AI agents calling MCP or A2A endpoints, for which OpenID4VP is more than needed. It follows the pattern of draft-ietf-oauth-attestation-based-client-auth, but for the holder's credential rather than client authentication. Comments are very welcome. Best regards, Su-hyeon Forten Lee _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected] This message and any attachment ("the Message") are confidential. If you have received the Message in error, please notify the sender immediately and delete the Message from your system, any use of the Message is forbidden. Correspondence via e-mail is primarily for information purposes. RBI neither makes nor accepts legally binding statements via e-mail unless explicitly agreed otherwise. Information pursuant to § 14 Austrian Companies Code: Raiffeisen Bank International AG; Registered Office: Am Stadtpark 9, 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial Court of Vienna (Handelsgericht Wien). _______________________________________________ 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]
