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"<wparad= > [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 <https://aka.ms/LearnAboutSenderIdentification> > > 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 > <https://www.google.com/maps/search/Am+Stadtpark+9?entry=gmail&source=g>, > 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]
