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