Hi all, There was some discussion about adding “server contribution” in the DPoP proof. I was wondering if the “challenge” server response described in section 6 can include such a contribution (e.g., a server generated nonce).
Best, Nikos From: OAuth <oauth-boun...@ietf.org> On Behalf Of Brian Campbell Sent: Friday, May 1, 2020 10:03 PM To: oauth <oauth@ietf.org> Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-01.txt I've pushed out a -01 revision of DPoP hopefully allowing folks enough time to read it before the interim meeting on Monday (apologies that it wasn't sooner but the edits took longer than expected or hoped). For ease of reference the changes in this revision are summarized below. There are, of course, still outstanding issues and discussion points that I hope to make some progress on during the interim meeting on Monday. -01 * Editorial updates * Attempt to more formally define the DPoP Authorization header scheme * Define the 401/WWW-Authenticate challenge * Added "invalid_dpop_proof" error code for DPoP errors in token request * Fixed up and added to the IANA section * Added "dpop_signing_alg_values_supported" authorization server metadata * Moved the Acknowledgements into an Appendix and added a bunch of names (best effort) ---------- Forwarded message --------- From: <internet-dra...@ietf..org <mailto:internet-dra...@ietf.org> > Date: Fri, May 1, 2020 at 12:24 PM Subject: New Version Notification for draft-ietf-oauth-dpop-01.txt To: Torsten Lodderstedt <tors...@lodderstedt.net <mailto:tors...@lodderstedt.net> >, David Waite <da...@alkaline-solutions.com <mailto:da...@alkaline-solutions.com> >, John Bradley <ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com> >, Brian Campbell <bcampb...@pingidentity.com <mailto:bcampb...@pingidentity.com> >, Daniel Fett <m...@danielfett.de <mailto:m...@danielfett.de> >, Michael Jones <m...@microsoft.com <mailto:m...@microsoft.com> > A new version of I-D, draft-ietf-oauth-dpop-01.txt has been successfully submitted by Brian Campbell and posted to the IETF repository. Name: draft-ietf-oauth-dpop Revision: 01 Title: OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP) Document date: 2020-05-01 Group: oauth Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-dpop-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-01 Abstract: This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> . The IETF Secretariat CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth