Jijie, Thank you for this. You have put the question more precisely than I did, and the Section 9 point is well taken.
Yes, that is the gap I meant, and I think reusing Section 9 is the answer. On the nonce, the value belongs to the resource server that issues and checks it, not to DPoP. When the same resource server verifies both the DPoP proof and the KB-JWT, and both are signed with the key in cnf, a nonce it supplied under Section 9 is a nonce the verifier provided in RFC 9901's sense, whichever header carried it. On aud, the natural value is the resource identifier the resource server already expects in the token's aud (the RFC 8707 / RFC 9728 identifier), so that the KB-JWT names the same party the token does. Thanks again for taking the time to work through it. Best, Su-hyeon -----Original Message----- From: "Jijie Wei"<[email protected]> To: "oauth"<[email protected]>; Cc: "nine01223"<[email protected]>; Sent: 2026-10-07 (수) 23:29:46 (GMT+09:00) Subject: [OAUTH-WG] Re: New draft: Presenting Issuer-Signed JWT Credentials to Resource Servers with DPoP Su-hyeon, On the nonce half. For an unsolicited call the delivery is defined, though not in RFC 9901: RFC 9449 Section 9 has the resource server answer a request that carries no nonce, using a 401 with the use_dpop_nonce error and a DPoP-Nonce header, and the client retries with that value in the proof. So a resource server can supply a nonce to a client that never asked it for one. What that leaves open is aud. The proof binds htu and htm, not the audience of the credential, and RFC 9901 leaves a KB-JWT's aud to the protocol in use. So is the gap you mean the KB-JWT equivalent of Section 9 -- an HTTP-level nonce and audience binding defined for a direct credential presentation -- and would reusing Section 9 be the intended answer, or does that not carry, because the challenge and the nonce belong to DPoP rather than to the credential? [Drafted with AI assistance; I have checked every point and agree with it.] Best, Jijie Wei _______________________________________________ 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]
