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]<mailto:[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]<mailto:[email protected]>>
To: "이수현"<[email protected]<mailto:[email protected]>>;
Cc: <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>>
To: "이수현"<[email protected]<mailto:[email protected]>>;
Cc: <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[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]
