From nobody Sun Jun 6 16:53:15 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1AF3A2D6E; Sun, 6 Jun 2021 16:53:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Meral Shirazipour via Datatracker To: Cc: draft-ietf-oauth-par.all@ietf.org, last-call@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162302358393.24354.13228659797920499541@ietfa.amsl.com> Reply-To: Meral Shirazipour Date: Sun, 06 Jun 2021 16:53:04 -0700 Archived-At: Subject: [OAUTH-WG] Genart last call review of draft-ietf-oauth-par-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2021 23:53:04 -0000 Reviewer: Meral Shirazipour Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-oauth-par-08 Reviewer: Meral Shirazipour Review Date: 2021-06-06 IETF LC End Date: 2021-06-08 IESG Telechat date: NA Summary: This draft is ready to be published as Standards Track RFC. Major issues: Minor issues: Nits/editorial comments: -[Page 4], Sec 1.1, "because the the request "---->"because the request " Best Regards, Meral Shirazipour From nobody Mon Jun 7 07:58:22 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA533A197F for ; Mon, 7 Jun 2021 07:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvvZJ6w1SNp2 for ; Mon, 7 Jun 2021 07:58:10 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B884F3A1981 for ; Mon, 7 Jun 2021 07:58:09 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id v22so25417911lfa.3 for ; Mon, 07 Jun 2021 07:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=doZiwQD5exTLQQtgjhHc2SwUJaAE5cyG1pkqk4yszVE=; b=a+ifqXm3tJEPg0Frf8jGJpryW0277JTNswX6XNFbBYQJKwtganuPNUINxnHmjC4JNp 2z9+2eAevXcGZLAqQrPvmJ+kOiC5PGVscjU2piPAhoiNVJLGe44vV3ANEBZpcQVxXyl4 1Xi1OY50pI4uFdevsWlO14AYzzSBXSN0LBGeGSS3ji+9I5xn6wVoD6nBCBBAT6JGTjze rOtZKTemgEQjPP7UKvweDH+20Ky9dnIO9U3U06LI/ESBLzILz3ZzO4Vdt6DR6a2p6602 Ezkr44gtlPKi00qpojIZ9RKk4vlTGqxaD96S97KVfbBr12ZpblCJ4X5Fvv/SVSjcd7xN qd/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=doZiwQD5exTLQQtgjhHc2SwUJaAE5cyG1pkqk4yszVE=; b=WFNDiEI8HhLdw6cgF9D26tIxDbyT8r7gZhIwG9TkSTpdzw46hNQnRbsWKp5YFNNB9c HTGE4j5MXzZNrJICbmzO52LjfYLmnMspur7RpVHFB9/hcm6ExWnLydK3OzRSP/uO1f38 IKZGmU0k9M+yGsLWWrj6k68BQ7FZ98HoMGxO+WkdcE2RDiwzuACo7Vd+SJWHITxKdKDh NOqwjyHirOf3qMkkpfV/Pya1qoRC2/CFEzE45JRaorsMJ2QIxctL3OMCaYO3DDNr+tMu u+hBcPKJNIVwhiXcRMH1c574aEUyzH0S9VTIll1MmdZb/afwOEAMrA+MD8oYbCjTF+tx MrnA== X-Gm-Message-State: AOAM530UHDS3tc+ubxVf6E6MRi/VnYa3WRDTiGgbm0TlWhIYQWVrT4E7 ZUsDG/v2OwDujVMKoWXouhif3AVUEWeZfX5KTflAJXu5zXRjvxWKdKRcO1rl7IuQ2zxVlZrJsEN mlilDU1nDMTpcCg== X-Google-Smtp-Source: ABdhPJxUFHKGv9w/73n6pzmOnccv37YrBsGwYDtlYXW8X293Pgjnwvue69vc2ptruMdbsgYnUTi2gE5ORuDUueeImss= X-Received: by 2002:ac2:5e64:: with SMTP id a4mr6906394lfr.657.1623077882757; Mon, 07 Jun 2021 07:58:02 -0700 (PDT) MIME-Version: 1.0 References: <162302358393.24354.13228659797920499541@ietfa.amsl.com> In-Reply-To: <162302358393.24354.13228659797920499541@ietfa.amsl.com> From: Brian Campbell Date: Mon, 7 Jun 2021 08:57:36 -0600 Message-ID: To: Meral Shirazipour Cc: gen-art , draft-ietf-oauth-par.all@ietf.org, last-call@ietf.org, oauth Content-Type: multipart/alternative; boundary="000000000000a51ad505c42e44c9" Archived-At: Subject: Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-par-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 14:58:14 -0000 --000000000000a51ad505c42e44c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review, Meral. We'll get that issue fixed in the next revision. On Sun, Jun 6, 2021 at 5:53 PM Meral Shirazipour via Datatracker < noreply@ietf.org> wrote: > Reviewer: Meral Shirazipour > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area Revie= w > Team > (Gen-ART) reviews all IETF documents being processed by the IESG for the > IETF > Chair. Please treat these comments just like any other last call comment= s. > > For more information, please see the FAQ at > . > > Document: draft-ietf-oauth-par-08 > > Reviewer: Meral Shirazipour > Review Date: 2021-06-06 > IETF LC End Date: 2021-06-08 > IESG Telechat date: NA > > Summary: This draft is ready to be published as Standards Track RFC. > > Major issues: > > Minor issues: > > Nits/editorial comments: > -[Page 4], Sec 1.1, "because the the request "---->"because the request " > > Best Regards, > Meral Shirazipour > > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000a51ad505c42e44c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review, Meral. We'll get that issue fix= ed in the next revision.

On Sun, Jun 6, 2021 at 5:53 PM Meral Shirazip= our via Datatracker <noreply@ietf.or= g> wrote:
Reviewer: Meral Shirazipour
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area Review = Team
(Gen-ART) reviews all IETF documents being processed by the IESG for the IE= TF
Chair.=C2=A0 Please treat these comments just like any other last call comm= ents.

For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq&g= t;.

Document: draft-ietf-oauth-par-08

Reviewer: Meral Shirazipour
Review Date: 2021-06-06
IETF LC End Date: 2021-06-08
IESG Telechat date: NA

Summary: This draft is ready to be published as Standards Track RFC.

Major issues:

Minor issues:

Nits/editorial comments:
-[Page 4], Sec 1.1, "because the the request "---->"becau= se the request "

Best Regards,
Meral Shirazipour




<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000a51ad505c42e44c9-- From nobody Mon Jun 7 13:18:47 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C853A0CDA for ; Mon, 7 Jun 2021 13:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcSYJiIwexLu for ; Mon, 7 Jun 2021 13:18:31 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2B143A0CD3 for ; Mon, 7 Jun 2021 13:18:30 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id x14so9583532ljp.7 for ; Mon, 07 Jun 2021 13:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=lv5+Jo/x5adEGFrUBM81k/QgbfKWWZaIGNvVaTMEhsE=; b=IAe4blj8uYfBSRU+LJvYzNcvBRrI3MW5teP8G9N8mT8p8w9APPRPfl0qM7M+N7WjVE JgvSY6fEi5PPWLSS3iseHCruAdOApwOoCmNn77bDUGUV7lk7826mj3xGdRE1ncZafiTN 9hSHUG30eQcAsq0LrLRWw4q1AQdX0Jk8nSgU3ZVtWWQEWY2T/KKexFItuXg5cr6wCQtz g3UtBL8IpMsPnv21JnAIWUHsyaQm0hIgzOVYPYS+daRP1El0LaOKkZiop1tnSA/CtbXf X+EGENXNd4ba8vZmmTk3OcpRUZT6V/SAKNZLnpqNqDGChfYBkT29ziU3LwSiBj5zONKz v+gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lv5+Jo/x5adEGFrUBM81k/QgbfKWWZaIGNvVaTMEhsE=; b=ubHNHZWjs28v7rT3w0pSFe/FuvhcQRlwkMymJ2C704Zw7fkDT+WDtbK1WM+lGCUjuT A2p5Mq9uSzAYuwKXqrjqshYLQPDa30wOwOm3MJAj02xxRmMUcV9VOyWquoUnMvnDG800 0rxDOOvq7y175PHpkVka00Fd1cVFa99pnOr0wljQrN9UzMK+JIEHMaeAJLHR6pP1lLdE oosqT7YhR9zLYLND8cuGE2Wof93PcHp+3AZEgTw3Acwy2CvzLOW0dKYEys2alewqfund Zuz3kaXPbMNvnVVF8IMrJJZd7EWI3HImKVc45ZGfi4tVfzdSmv0jadG3HPTajTz5dwsa mbNw== X-Gm-Message-State: AOAM532Qhvvd3SoNgDQu+Hay7S6Q7PkXm+ZW8HsZjl+2TF5rtbG8g1ks WaH7OVAUTDrskM4j7Ht6w9qg95NKjB6fKn9HJGKZXgKC1iE= X-Google-Smtp-Source: ABdhPJzIbk+cJqTdUVU5BrRUCfT6GR7xNKwjGaKAh1DpZs3Qv/uulmWgwo3xu2YTmFC/fATQiNHQO19q8+Ogkh9XY68= X-Received: by 2002:a05:651c:318:: with SMTP id a24mr15953473ljp.381.1623097108266; Mon, 07 Jun 2021 13:18:28 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Mon, 7 Jun 2021 16:18:17 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000092ffdc05c432bee6" Archived-At: Subject: [OAUTH-WG] WG Last Call on the RAR Document X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 20:18:45 -0000 --00000000000092ffdc05c432bee6 Content-Type: text/plain; charset="UTF-8" All, This is to start a *WG Last Call *on the *RAR* document, that ends *June 22nd.* https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-05 Please, review the document and provide your feedback on the mailing list. A feedback that states that you have reviewed the document and have no concerns would also be very helpful. Regards, Rifaat & Hannes --00000000000092ffdc05c432bee6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

This is to start a WG Last Call on the = RAR document, that ends June 22nd.
https://datatracker.ietf= .org/doc/html/draft-ietf-oauth-rar-05

Please, review the documen= t and provide your feedback on the mailing list.
A feedback that states= that you have reviewed the document and have no concerns would also be ver= y helpful.

Regards,
=C2=A0Rifaat & Hannes
--00000000000092ffdc05c432bee6-- From nobody Tue Jun 8 02:07:19 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F16B43A2902; Tue, 8 Jun 2021 02:07:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.31.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <162314323386.24325.13195076892860417878@ietfa.amsl.com> Date: Tue, 08 Jun 2021 02:07:13 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-iss-auth-resp-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 09:07:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Authorization Server Issuer Identification Authors : Karsten Meyer zu Selhausen Daniel Fett Filename : draft-ietf-oauth-iss-auth-resp-01.txt Pages : 10 Date : 2021-06-08 Abstract: This document specifies a new parameter "iss" that is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. The "iss" parameter serves as an effective countermeasure to "mix-up attacks". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-iss-auth-resp-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-iss-auth-resp-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 8 02:16:33 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59993A2951 for ; Tue, 8 Jun 2021 02:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hackmanit.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-a8vDIG00nM for ; Tue, 8 Jun 2021 02:16:25 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018823A294F for ; Tue, 8 Jun 2021 02:16:24 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id m18so20749625wrv.2 for ; Tue, 08 Jun 2021 02:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackmanit.de; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=3Bh13S5kurVzVViWwnoVE8wF70LI1dNFdxcPX0VOOsk=; b=bkVt77FkuHAabudJBXOj3GJPJukdIH7SdzRoIc2Gwctx/3RDsYbO3onAcIBIji6QY/ gps4DIdg9TGybgiuYIRsHyuxnWSW+irIM/9nNKrkqQJGUjclONRfmXaEJy4HQMovJ18i MrN3r4UpV4OE2uQrwwn9Jjv8Fd8jDjgmERsAw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=3Bh13S5kurVzVViWwnoVE8wF70LI1dNFdxcPX0VOOsk=; b=YeZGfrrPorHHLMs36F/7RyFZ6S7Ao+e4F2VmCNpNNiaX/hZ7lvPgDPr4lDnTgy8yyB TD4nCJGuIn11m6akDrX8Ref31A684VyECYGad88V+yJfpFTFS/w7V6h0GtXD2Y7+kWIe e8w8K6mhFMIBsYIPY+235BRbP6gMtlbs9n+YMdNwlTfpfOrspxKd+S8A5RXaOa6+VzJl GUzuKD6YG5EPiGKdwee8gHDwbyNuiCRgclkimo/8lGiO2TGc96hlSDfbG3vN73yG0BEL R00Nt39nw0VAJjdeni9GemzsCs127OatcejGXt0vqtfLnJMGlV9MK2OAxSLLdflR326f ctlQ== X-Gm-Message-State: AOAM533N82I3P7rx+en9DkUQW4PVzfuI4UKemaLrBFHKoR2Wa2/7vIeN pw3ggIZyx96FRdr7MhmMkfmPdIZe763JXqBr X-Google-Smtp-Source: ABdhPJzXjaaHXmz+c9RPL1HpitKPbGKi6vQQNdhAZ21hcKeMhBu2HlHlT67NcCvD+Z5RQPZPZuamzQ== X-Received: by 2002:adf:f805:: with SMTP id s5mr21032176wrp.231.1623143781392; Tue, 08 Jun 2021 02:16:21 -0700 (PDT) Received: from [10.10.11.10] (b2b-37-24-87-133.unitymedia.biz. [37.24.87.133]) by smtp.gmail.com with ESMTPSA id m65sm17470751wmm.19.2021.06.08.02.16.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Jun 2021 02:16:20 -0700 (PDT) To: oauth@ietf.org References: <162314323386.24325.13195076892860417878@ietfa.amsl.com> From: Karsten Meyer zu Selhausen Message-ID: <09d68452-2d88-b349-7668-ab439d662740@hackmanit.de> Date: Tue, 8 Jun 2021 11:16:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <162314323386.24325.13195076892860417878@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kL0E2YUFDO0JtSuUmbpx1iAGAFSwKLgZO" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-iss-auth-resp-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 09:16:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kL0E2YUFDO0JtSuUmbpx1iAGAFSwKLgZO Content-Type: multipart/mixed; boundary="9QrUyRa0kNy9sg2dE93S5dqiLJ3z0s1hQ"; protected-headers="v1" From: Karsten Meyer zu Selhausen To: oauth@ietf.org Message-ID: <09d68452-2d88-b349-7668-ab439d662740@hackmanit.de> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-iss-auth-resp-01.txt References: <162314323386.24325.13195076892860417878@ietfa.amsl.com> In-Reply-To: <162314323386.24325.13195076892860417878@ietfa.amsl.com> --9QrUyRa0kNy9sg2dE93S5dqiLJ3z0s1hQ Content-Type: multipart/alternative; boundary="------------1470CD95B592568EEE6C0040" Content-Language: en-US This is a multi-part message in MIME format. --------------1470CD95B592568EEE6C0040 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, thank you for your feedback. In this version we addressed your comments on the JARM note and=20 clarified the mix-up description. We also changed the title of the draft to make it a little shorter. Best regards, Karsten On 08.06.2021 11:07, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Web Authorization Protocol WG of the I= ETF. > > Title : OAuth 2.0 Authorization Server Issuer Identi= fication > Authors : Karsten Meyer zu Selhausen > Daniel Fett > Filename : draft-ietf-oauth-iss-auth-resp-01.txt > Pages : 10 > Date : 2021-06-08 > > Abstract: > This document specifies a new parameter "iss" that is used to > explicitly include the issuer identifier of the authorization serve= r > in the authorization response of an OAuth authorization flow. The > "iss" parameter serves as an effective countermeasure to "mix-up > attacks". > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-oauth-iss-auth-resp-01.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-iss-auth-resp-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Karsten Meyer zu Selhausen Senior IT Security Consultant Phone: +49 (0)234 / 54456499 Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, = Security Training M=C3=B6chten Sie sich f=C3=BCr ein Projekt mit dem Thema Single Sign-On o= der den Standards OAuth und OpenID Connect vertraut machen? Dann melden Sie sich jetzt an f=C3=BCr Ihre Einf=C3=BChrung in Single Sig= n-On, OAuth und OpenID Connect am Mittwoch, 09.06.2021, von 10:00 - 14:30= Uhr! https://www.hackmanit.de/de/schulungen/uebersicht/139-einfuehrung-in-sing= le-sign-on-oauth-und-openid-connect Hackmanit GmbH Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus) 44789 Bochum Registergericht: Amtsgericht Bochum, HRB 14896 Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S= omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz --------------1470CD95B592568EEE6C0040 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi all,=

thank you for your feedback.

In this version we addressed your comments on the JARM note and clarified the mix-up description.

We also changed the title of the draft to make it a little shorter.

Best regards,
Karsten

On 08.06.2021 11:07, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
This draft is a work item of the Web Authorization Protocol WG of the IET=
F.

        Title           : OAuth 2.0 Authorization Server Issuer Identific=
ation
        Authors         : Karsten Meyer zu Selhausen
                          Daniel Fett
	Filename        : draft-ietf-oauth-iss-auth-resp-01.txt
	Pages           : 10
	Date            : 2021-06-08

Abstract:
   This document specifies a new parameter "iss" that is used to
   explicitly include the issuer identifier of the authorization server
   in the authorization response of an OAuth authorization flow.  The
   "iss" parameter serves as an effective countermeasure to "mix-up
   attacks".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draf=
t-ietf-oauth-iss-auth-resp/

There is also an HTML version available at:
https://www.ietf.org/archive/id=
/draft-ietf-oauth-iss-auth-resp-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url=
2=3Ddraft-ietf-oauth-iss-auth-resp-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
OAuth mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--=20
Karsten Meyer zu Selhausen
Senior IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	htt=
ps://hackmanit.de | IT Security Consulting, Penetration Testing, Secu=
rity Training

M=C3=B6chten Sie sich f=C3=BCr ein Projekt mit dem Thema Single Sign-On o=
der den Standards OAuth und OpenID Connect vertraut machen?
Dann melden Sie sich jetzt an f=C3=BCr Ihre Einf=C3=BChrung in Single Sig=
n-On, OAuth und OpenID Connect am Mittwoch, 09.06.2021, von 10:00 - 14:30=
 Uhr!
https://www.hackmanit.de/de/schulungen/uebersicht/139-einfuehrung-=
in-single-sign-on-oauth-und-openid-connect

Hackmanit GmbH
Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S=
omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
--------------1470CD95B592568EEE6C0040-- --9QrUyRa0kNy9sg2dE93S5dqiLJ3z0s1hQ-- --kL0E2YUFDO0JtSuUmbpx1iAGAFSwKLgZO Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEDtqqxgHePX8hI3D4RTXA59sW8UgFAmC/NWIFAwAAAAAACgkQRTXA59sW8Uh+ IxAAjKK1yxbUZ09S5TqH+MTKJ8H5HD5o/Y4HsPY+rWHiWdS1E2cyYqykJiGWezTUlVygjuiG6i+Q 7W1X7eZquPNY/h4RZCE7VWGBRCkh1MS67gjX5UrzD++YcwtMBzACRSfWjhCo2jpJ288SHLwemPIu 7T+bMldxdd6aui1F77FYT+H2idRgwKvd1dtGuac8ZGuz+wP3rsX6h4PkMkDKV5cTaS/qly6R6saM JbJzlV4rYqglCSZwygD6sH1c8y9lZgH3IZwBNkvdz9Rt0JWFQSYVzEg/9bKiWtbgJGyqgQcDEYTa 1mYe+zgXt3dwRAYSRPSHESkyQiaZYMmN44fdrD2tdHkov4gShGyMESpvNfznBcyF5Vdk78e0yhg1 BdqluixRyWPBPuEvQ8ZpQyZq41QV5/iIU/DHd52JE0vxo56WOMnCqRkwe7fYDh6IPCkCai6zxdo3 9mLA260O1qoMGTa+e9Al6rDzAZRh/IhDg1lBKO0XD5qi4I18GWZF9ESioALDxSbZ47+FVExVkagy /rf7mOqQCkNU63dGPabGgDWhxMNvPKUNOTtY+UihMQp8QTSgYIRFMKd+t2JfQC1MN4cbD1HknF5w o+EwsCYSC1BaqfS71wAL2IK5n673a9EjJ/TBht50B8sEcGV3YEgZ6qSEIH7nnWb72CiTm3V8dsnw 6PA= =p9Jw -----END PGP SIGNATURE----- --kL0E2YUFDO0JtSuUmbpx1iAGAFSwKLgZO-- From nobody Tue Jun 8 03:34:12 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DDA3A2BD5 for ; Tue, 8 Jun 2021 03:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.738 X-Spam-Level: X-Spam-Status: No, score=-0.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, WORD_INVIS=1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rp0AICalH4Kp for ; Tue, 8 Jun 2021 03:34:05 -0700 (PDT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E6E3A2BD3 for ; Tue, 8 Jun 2021 03:34:04 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id a11so31097813ejf.3 for ; Tue, 08 Jun 2021 03:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3BgxV803lF0ly0ApNnbPCz9UDNTOQ/hWExdrLY3hX6c=; b=WmT1qelj0ZpFBGoXPwAmPiOGVpZpJnnGMRu2P+5MynCcspLqP6C+EqAUw51TQ3z91Q cPkW1S1iHXCl2OZLBxJS+/Y46giyWqKJaLq6X9OFnu//lcjTLADMadbmQbEBVuj5QpRW ZQf581AWJwVdnDrBeb10yyQKIxab+sRkTXnpw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3BgxV803lF0ly0ApNnbPCz9UDNTOQ/hWExdrLY3hX6c=; b=f2wUL6I8cURIYCCcORYl4JIrXxIe1HIsoX2OBgu8b6utZmsbJAlNBxNXzos/fKVFZC x0hLN9sqQ6R6pPAKNzS52ojFypOD4iTorMbu4eChwcmqEfitr4yBqJRwJsxbCZiw/RiS 0X71/3Br/EG1DVAieKmXOXjtnL/7AFUJKZFCXkev/H644/EVOD+wNe1Mt90klUOJG+AV uOFhQwhNIepV2jDGpZtf5limr9YCh9zliwmtZjpiE/7BZPgqonNwnbE59h00jrRFXZ35 mG6O9RcwCrQPvoLtcB8JvYBBDbExlZurmZ/QyO/rtmEvTDNgB6uGlWqyTo7O1iiOAUN/ O7xg== X-Gm-Message-State: AOAM533PPY0+/kBySf439AU8QAlqAmEBa+TW/UcJAESNFGmVvjjeJquv ABqeT+qzwAPezp11xYPF7Zzb3LqrwWRmbV12/0j+0V2UjkQ8id+Y4QjjmCu0pw1SWN3xH4JorpI FzBybSZ9WyvKBvsZYJqSPtrrK1lw= X-Google-Smtp-Source: ABdhPJxcEEjbCQUgaLffE4Rhp7VNJ2QlTsvvRWZnBfmR9kp9R5BAjwH+o8oJZwlftswEzCOUdCixojyI8/3krucN+UM= X-Received: by 2002:a17:906:1c49:: with SMTP id l9mr22682745ejg.39.1623148441796; Tue, 08 Jun 2021 03:34:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Tonge Date: Tue, 8 Jun 2021 12:33:50 +0200 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="0000000000004a959805c43eb208" Archived-At: Subject: Re: [OAUTH-WG] WG Last Call on the RAR Document X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 10:34:11 -0000 --0000000000004a959805c43eb208 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear RAR authors Thank you for your work on this draft - I believe it will be very helpful to many ecosystems and am in favour of its progression. A few nits: *Whole Document* - "payment initiation" is I think a PSD2 specific term, I'm not sure about its use in the document, perhaps just "payment API" is sufficient? If it is used, perhaps it needs a definition? *Introduction* - "enables the AS to *mint* RS-specific" - I wonder whether "mint" is a well enough understood term? *Section 2* - final example in 2.1 - is the array of authorization details supposed to be under the `resources` key? *Section 3* - Should PAR be added to 6747,8628 and CIBA in section 3? I know it is referenced in 12.4, but I think that RAR and PAR fit very well together and it would be better to call out earlier on in the spec ( it is mentioned extensively in the security and privacy considerations and so I think therefore should be mentioned earlier) - I suggest that mention is made in section 3 that the RO may grant a subset of the request authorization details. This is mentioned in section 7.1 but I feel it should be addressed in the authorization section. *Section 7* The title for section 7.1 could maybe adjusted to simply "Authorization details in Token Response" as it deals with both enrichment and a subset being returned. In addition I don't think it is clear whether an AS is required to enrich the authorization details. The statement is made > In order to allow the client to determine the accounts it is entitled to access, the authorization server will add this information to the respective authorization details object. However a more standard approach currently is that the Client would simply query an `/accounts` endpoint and would receive accounts to which it has been given access to - without having to know their identifiers up front. There could be a situation where a resource owner grants access to all their accounts (including accounts opened in the future). Having the AS be required to fill in the account identifiers in the token response could be restrictive. I think this kind of enrichment is nice, but I suggest that it be made clear that it is optional. *Section 12* * - *typo: "follwowing" -> "following" Dave On Mon, 7 Jun 2021 at 22:19, Rifaat Shekh-Yusef wrote: > All, > > This is to start a *WG Last Call *on the *RAR* document, that ends *June > 22nd.* > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-05 > > Please, review the document and provide your feedback on the mailing list= . > A feedback that states that you have reviewed the document and have no > concerns would also be very helpful. > > Regards, > Rifaat & Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Dave Tonge CTO [image: Moneyhub Enterprise] t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772 . Moneyhub Financial Technology Limited 2018 =C2=A9 DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company. --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --0000000000004a959805c43eb208 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear RAR authors

Thank you= for your work on this draft - I believe it will be very helpful to many ec= osystems and am in favour of its progression.

A few nits:

Whole Document
=C2=A0- "payment initiation&q= uot; is I think a PSD2 specific term, I'm not sure about its use in the= document, perhaps just "payment API" is sufficient? If it is use= d, perhaps it needs a definition?
=C2=A0
Introduction
- "enables the AS to mint RS-specific" - I wonder wheth= er "mint" is a well enough understood term?

Sec= tion 2
=C2=A0- final example in 2.1 - is the array of authorizatio= n details supposed to be under the `resources` key?

Secti= on 3
=C2=A0- Should PAR be added to 6747,8628 and CIBA in section = 3? I know it is referenced in 12.4, but I think that RAR and PAR fit very w= ell together and it would be better to call out earlier on in the spec ( it= is mentioned extensively in the security and privacy=C2=A0considerations a= nd so I think therefore should be mentioned earlier)
=C2=A0- I suggest= that mention is made in section 3 that the RO may grant a subset of the re= quest authorization details. This is mentioned in section 7.1 but I feel it= should be addressed in the authorization section.=C2=A0

= Section 7
The title for section 7.1 could maybe adjusted to simply= "Authorization details in Token Response" as it deals with both = enrichment and a subset being returned.
In addition I don't think = it is clear whether an AS is required to enrich the authorization details. = The statement is made

>=C2=A0=C2=A0In order to allow the client to determine = the
=C2=A0 =C2=A0accounts it is entitled to access, the authori= zation server will add
=C2=A0 =C2=A0this information to the respective a= uthorization details object.

However a more = standard approach currently is that the Client would simply query an `/acco= unts` endpoint and would receive accounts to which it has been given=C2=A0a= ccess to - without having to know their identifiers up front. There could b= e a situation where a resource owner grants access to all their accounts (i= ncluding accounts opened in the future). Having the AS be required to fill = in the account identifiers in the token response could be restrictive. I th= ink this kind of enrichment is nice, but I suggest that it be made clear th= at it is optional.

Section 12
=C2=A0- typo: "follwowing" -> "following"

Dave



<= br>
On Mon,= 7 Jun 2021 at 22:19, Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:
All,=

This is to start a WG Last Call on the RAR document, = that ends June 22nd.
https://datatracker.ietf.or= g/doc/html/draft-ietf-oauth-rar-05

Please, review the document a= nd provide your feedback on the mailing list.
A feedback that states th= at you have reviewed the document and have no concerns would also be very h= elpful.

Regards,
=C2=A0Rifaat & Hannes
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
<= div dir=3D"ltr">
Dave Tonge
CTO
3D"Moneyhub
t:=C2=A0+44 (0)117 280 5120

<= div style=3D"line-height:1.4">Moneyhub En= terprise is a trading style of Moneyhub Financial Technology Limited which = is authorised and regulated by the Financial Conduct Authority ("FCA&q= uot;).=C2=A0Moneyhub Financial Technology is entered on the Financial Servi= ces Register=C2=A0(FRN=C2=A0809360) at fca.or= g.uk/register. Moneyhub=C2=A0Financial Technology is registered in England & = Wales, company registration number=C2=A0=C2=A006909772=C2=A0.
Moneyhub=C2=A0Financial Technology Lim= ited 2018=C2=A0=C2=A9

DISCLAIMER: This email (including any attachments) is subject to copy= right, and the information in it is confidential. Use of this email or of a= ny information in it other than by the addressee is unauthorised and unlawf= ul. Whilst reasonable efforts are made to ensure that any attachments are v= irus-free, it is the recipient's sole responsibility to scan all attach= ments for viruses. All calls and emails to and from this company may be mon= itored and recorded for legitimate purposes relating to this company's = business. Any opinions expressed in this email (or in any attachments) are = those of the author and do not necessarily represent the opinions of Moneyh= ub Financial Technology Limited or of any other group company.
=

Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

= DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


--0000000000004a959805c43eb208-- From nobody Tue Jun 8 05:47:36 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23653A2FAD for ; Tue, 8 Jun 2021 05:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlhkhOy-uhNZ for ; Tue, 8 Jun 2021 05:47:30 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BE583A2FAC for ; Tue, 8 Jun 2021 05:47:29 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id f30so31905100lfj.1 for ; Tue, 08 Jun 2021 05:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nLpZ6uiWYXg8WjhOWunIIBQXAur0uVOE44wO/+vbuHY=; b=e1Wt3gY1LcmKT7ZWSEqiYqRsooIxGB3KETrWCXAnNRhSfWNMj2Lzhj7yvnJjH8kkF2 DZjNHmDKdcTB5jIR9GfI1DHfv+l/rGMgqF77E0ja5fgo/YVC01wt24+0EIvi+/KZBqEv ylPBGZkM+wU8ZVztlyuKW3e7gYlUh8eCJQQyJuQFus5tD2qpjV1CxTdlN4HxgkNTnkKB PE4PavelijWGqybPLLWsRb8TUWs5GqDJTfltXxm5891q/kGydGh4TyO2AQL92u6mP5a6 p6UPN0RWwVb3mMYbYJ5oaJHDH9MYM0TRJjwNt+K4aFWp82jYJHtfYl11BKbP3aw803p2 +p4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nLpZ6uiWYXg8WjhOWunIIBQXAur0uVOE44wO/+vbuHY=; b=OAtnKK56pKHEABOwJDeD6NqPZpKMpwKPNSGrR56rcsJ8W+43kYDXZiOa7by8EI8qIq WTk1q4vM1Cvb8HrCE9NNJm0b68Yl+U9OSIWvhMUIzxAiOnio5n4Eq5hC8ThE/5EceW0L huWbc1860DVyr238ufFK44x4Q1hYr4mxCe/FyiI12jwU5s6LKbNIjC3fq9p+qI/H0KS2 x/vM1vI2ZRvvOrCB7UBAHkMKn5xAvq1zrt76tLOo7U6iLwUis2n/av0TLfcmqnNbtr0x b3gqmmgHWSOddujpvaUJc+2/rBRQh4AsBSt4FyWnvqNYZqmLRHLdbPDERhYCMHL4qG9V OX/w== X-Gm-Message-State: AOAM530FkT0sesiqfZhaO7QvIPx8O7YFFJDTZ2Sx06mJTmeaGxOa0M27 88TEnJBYsVXsTsJJD+teOudrdXn5a6VUE5sZ/1hDr/9v X-Google-Smtp-Source: ABdhPJxk/WuYIikxXjiAnRz2CbCZf2MFUZ3/7Ch2s0yaAT3MsXboZsd+Lr4gJsg5KsTsV9/2KC6zcogw2SrqIXmGAiY= X-Received: by 2002:a05:6512:16a8:: with SMTP id bu40mr13493754lfb.170.1623156446237; Tue, 08 Jun 2021 05:47:26 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Tue, 8 Jun 2021 08:47:14 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000064990905c4408f1b" Archived-At: Subject: [OAUTH-WG] WG Last Call for the Authorization Server Issuer Identification document X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 12:47:35 -0000 --00000000000064990905c4408f1b Content-Type: text/plain; charset="UTF-8" All, This is to start a *WG Last Call *for the *Authorization Server Issuer Identification* document, that ends *June 23rd*. https://www.ietf.org/archive/id/draft-ietf-oauth-iss-auth-resp-01.html Please, review the document and provide your feedback on the mailing list. A feedback that states that you have reviewed the document and have no concerns would also be very helpful. Regards, Rifaat & Hannes --00000000000064990905c4408f1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

This is to start a WG Last Call for the= Authorization Server Issuer Identification document, that ends J= une 23rd.
https://www.ietf.org/archive/id/= draft-ietf-oauth-iss-auth-resp-01.html

Please, review the docume= nt and provide your feedback on the mailing list.
A feedback that states= that you have reviewed the document and have no concerns would also be ver= y helpful.

Regards,
=C2=A0Rifaat & Hannes

<= /div> --00000000000064990905c4408f1b-- From nobody Tue Jun 8 08:26:13 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597333A33FC for ; Tue, 8 Jun 2021 08:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5O2y1vAJLB3B for ; Tue, 8 Jun 2021 08:26:05 -0700 (PDT) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF273A33F7 for ; Tue, 8 Jun 2021 08:26:04 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id i4so30779033ybe.2 for ; Tue, 08 Jun 2021 08:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=07cFXto6RUV2p3E9ae0JFKTvjtfweV6vsJJjh8FNQUE=; b=GFC+ed+epZmm8WKjlK8BLMsr9H17xuKra7hhuaLWz+Lf3lM/JND68sbKsE2u4Q7QIz XSuMEXQdai/XE5GRJtFf+3T3BJpCQ04C2D/bzumTeD5l7MfIBlGRtURdzahPfpCso7Vh r2vLeoqDdz1KGiFT6fec+2SxR4cb0k/tq5NKHqSkHQlxbkW8k4P6G2jHPIUFzLJaBU30 I/Gf6PbjkWFBA1vioa/hqoHq9tkWAfEGcDK9as9KS4iMCegGyfW9ktFfU+H8/LEj2GLk 3xo1PZFelpUKsBa957w3bs8GWY2OBmstH3FCXFlHdiiLS/Janqkd3NbYD5/vMo4vFmuv 7rlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=07cFXto6RUV2p3E9ae0JFKTvjtfweV6vsJJjh8FNQUE=; b=ft+p66tQY4kN5RjBjeGkz1C23MlP4CL3+aqcHhYZAYwX3W3Eq4huzy90YWob+6S631 sktVWsbq43mwmwcyVfOuBIlhaCiwZm/a3c3Wxx3mdq2KHLXdFDYXZ6oDS9pDLgg67+sv eBwA/Wdf05w7GNypM13bEgRGypbPeRdah9Ua8S2mEJ1pwyjPF/CtOZJNb8jcfni3X227 vk1o92//8/k3eWKVKJpXSMDACqsg3UReziLYxlYL/YL2mAfcxZYVnLZAH00ugLHZtsTB eJCGKACc157F6f+oeeFlw/NObYwwMDaoxVvBFHORVXL8d7ORfNljeWTnGyVavdmDZSoe /nEA== X-Gm-Message-State: AOAM532D/FAVOMoiVfHdziUizOYyHawxrMNo8hYI4SPMdHsITUf8dvQ6 ZbFQjPmv+YAmiNuwrTX5OHv0eWu5gqmq2nMi/xiK X-Google-Smtp-Source: ABdhPJwBfQHKFENlGEPesRA/9rzOJM9cmJuK/gvs3wvIWC465nUy9HmmpVRedS4ECSAGsRWaMKBlHJrPTLQXfg2VfUM= X-Received: by 2002:a25:aa66:: with SMTP id s93mr21226859ybi.260.1623165962464; Tue, 08 Jun 2021 08:26:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Tue, 8 Jun 2021 17:25:51 +0200 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="0000000000009ac5fa05c442c6a0" Archived-At: Subject: Re: [OAUTH-WG] WG Last Call for the Authorization Server Issuer Identification document X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 15:26:10 -0000 --0000000000009ac5fa05c442c6a0 Content-Type: text/plain; charset="UTF-8" Reviewed, no concerns. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Tue, Jun 8, 2021 at 2:48 PM Rifaat Shekh-Yusef wrote: > All, > > This is to start a *WG Last Call *for the *Authorization Server Issuer > Identification* document, that ends *June 23rd*. > https://www.ietf.org/archive/id/draft-ietf-oauth-iss-auth-resp-01.html > > Please, review the document and provide your feedback on the mailing list. > A feedback that states that you have reviewed the document and have no > concerns would also be very helpful. > > Regards, > Rifaat & Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000009ac5fa05c442c6a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reviewed, no concerns.

<= /tr>

Warren Parad

Founder, CTO

Secure your user data= with IAM authorization as a service. Implement=C2=A0Authress.

=

= On Tue, Jun 8, 2021 at 2:48 PM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:
All,

T= his is to start a WG Last Call for the Authorization Server Issue= r Identification document, that ends June 23rd.
https://www.ietf.org/archive/id/draft-ietf-oauth-iss-auth-resp= -01.html

Please, review the document and provide your feedback o= n the mailing list.
A feedback that states that you have reviewed the do= cument and have no concerns would also be very helpful.

Regards,
= =C2=A0Rifaat & Hannes

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000009ac5fa05c442c6a0-- From nobody Tue Jun 8 09:30:42 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA123A35F9 for ; Tue, 8 Jun 2021 09:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=backbase.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Te1Yyd94KE8v for ; Tue, 8 Jun 2021 09:30:27 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8133A35CF for ; Tue, 8 Jun 2021 09:30:26 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id f11so32897761lfq.4 for ; Tue, 08 Jun 2021 09:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=backbase.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=xdI91lSCeWXC+T64HDZNP0UizbeKGl9W8mL2tWuYstU=; b=UUiDEUKS2nrOYheOxe77cPctB0SuGBk3AdKYjZRgM1Nxm1PWRfHi070jzF4hqgMNR1 IxJMu62Dz5m2n9G3Ls4MggR07JzAk3eXWwhHhJK61zSPbAsZBfRCFT/k1V+EB5iz522D TGKGfw6o67996bj30PksDeZd9Rl5EcmgztvnUnfTmZranoPtxuJWHbjDllkaaJPb1Y8F 160MVd3qpx1zGl5jdGmG5IZjisC0yinKh1cBQizkj7036Yjg3Fx49+/3bQJKil58WMZq XEokGxJSiFVrxZrtaL35LPwuqaSjJaJrJklVyYwm93/qBNX2I02IwzcLIGt8PFvDZaCN ch6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xdI91lSCeWXC+T64HDZNP0UizbeKGl9W8mL2tWuYstU=; b=GbbyRIokZA7I0zD8y+kqYtfFO1DXOpt6tq2mccy6pfILcaNfeK7XN0mmZYWSBZ6Sh5 Rlvz0T6OR4ef5treFjRkBbIJjEWywSNIzPY0XT0cbGY8RcCfnspztNNOYpZLXO1e8gcP 3O4g+dyfx2vRnPnbFG33EcsFRgedP6AEv8puzzvEg8RsfTMgL0ERtY0jK2YzyLnwPQjP GDttwBDtEE3UiEvIHlGjmPZ7Yi1e4hGdErxwSGmOkn1XPju9TG5/Ql9W3lD23qSI06kz oBfYiUQ3tOLw6aAnO4SZMjmA6FFe66JzozQURLqsnX4N7OByqr0HbW/qt22I6kZMcyjF u7AA== X-Gm-Message-State: AOAM533ioH3WxH+5uEZtEacC8x6/XPQCTVoE/5mk4U1GO4okR/eK9vPn EboT+O8KZQGn6LCAhPxdyfPDMuo1Ou9Ef+9q0FYcP4YrtrDEnQ== X-Google-Smtp-Source: ABdhPJwR+e6GrooOtkHoIhQmu4g6E6EQU4mkanl9wK+auzkPmz+6hXgS8dFAp//7N5X2gkOeftuJllUV3SCDy8hCyvE= X-Received: by 2002:a05:6512:38cc:: with SMTP id p12mr15800924lft.4.1623169823836; Tue, 08 Jun 2021 09:30:23 -0700 (PDT) MIME-Version: 1.0 From: Dmitry Telegin Date: Tue, 8 Jun 2021 19:30:13 +0300 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000c2a70d05c443accf" Archived-At: Subject: [OAUTH-WG] DPoP key rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 16:30:40 -0000 --000000000000c2a70d05c443accf Content-Type: text/plain; charset="UTF-8" Hi, I'm Dmitry Telegin, I'm currently working on DPoP implementation in Keycloak on behalf of my company, Backbase. Takashi Norimatsu of Hitachi supervises this process as the head of the Keycloak FAPI SIG. With the current DPoP design, once the keypair has been generated on the user agent and the initial token set has been obtained (using authorization_code grant), the whole chain of the subsequent access/refresh tokens will be bound to this particular keypair. That means, the keypair should be persisted on the user agent for the duration of the session. OTOH, sessions could be rather long-lived, especially if we take offline tokens [1] into account. In a nutshell, offline access provides a non-expiring refresh token. This could be highly relevant e.g. for mobile applications that would employ offline tokens to help users avoid logging in every time. The longer the session lasts, the higher the probability of key leakage is. Currently, the only way to switch to a new DPoP keypair is to start a new session (i.e. log in again). Do you think it might be worth incorporating some sort of key rotation concept into DPoP design? The most obvious way to perform key rotation is to do that during token refresh. For that, we could make the refresh_token grant honour the additional DPoP proof that would supersede the current one. From the technical PoV, it could be as easy as supplying two proofs within the DPoP header: DPoP: eyJ0eXAiO... eyJ0eXAiO... Or we can go with a single (old) DPoP proof, containing the new proof (to supersede the current one) as a claim (or vice versa). We'd appreciate any feedback from the WG. Also apologize if this ML is not the appropriate place to discuss issues like this. Regards, Dmitry Telegin Senior Backend Engineer, Backbase R&D B.V. [1] https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess --000000000000c2a70d05c443accf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I'm Dmitry Telegin, = I'm currently=20 working on DPoP implementation in Keycloak on behalf of my company,=20 Backbase. Takashi Norimatsu of Hitachi supervises this process=20 as the head of the Keycloak FAPI SIG.

With the=20 current DPoP design, once the keypair has been generated on the user=20 agent and the initial token set has been obtained (using=20 authorization_code grant), the whole chain of the subsequent=20 access/refresh tokens will be bound to this particular keypair. That=20 means, the keypair should be persisted on the user agent for the=20 duration of the session.

OTOH, sessions could=20 be rather long-lived, especially if we take offline tokens [1] into=20 account. In a nutshell, offline access provides a non-expiring refresh=20 token. This could be highly relevant e.g. for mobile applications that=20 would employ offline tokens to help users avoid logging in every time.

The longer the session lasts, the higher the probability of key leakage is. Currently, the only way to switch to a new DPoP keypair is to start a=20 new session (i.e. log in again). Do you think it might be worth=20 incorporating some sort of key rotation concept into DPoP design?

The most obvious way to perform key rotation is to do that during token=20 refresh. For that, we could make the refresh_token grant honour the=20 additional DPoP proof that would supersede the current one. From the=20 technical PoV, it could be as easy as supplying two proofs within the=20 DPoP header:

DPoP: eyJ0eXAiO... eyJ=
0eXAiO...

Or=
 we can go with a single (old) DPoP proof, containing the new proof (to sup=
ersede the current one) as a claim (or vice versa).

We'd appreciate any feed=
back from the WG. Also apologize if this ML is not the appropriate place to=
 discuss issues like this.

Regards,
Dmitry Telegin
Senior Backend Engineer, Backbase R&D B.V.<=
br>
--000000000000c2a70d05c443accf-- From nobody Fri Jun 11 13:20:56 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1695C3A1463 for ; Fri, 11 Jun 2021 13:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzbbQdEHa893 for ; Fri, 11 Jun 2021 13:20:49 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F733A145F for ; Fri, 11 Jun 2021 13:20:48 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id i10so10325839lfj.2 for ; Fri, 11 Jun 2021 13:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PLL2fxIm29d+ABkBUziLmFOlA/xCDSCZuo8ZMgQd8GE=; b=d0Y9mbhxHaemrtL0IzJ+4p6bt98LxDB3W4u0MAlMrj14o++aR0EVA2yV/69XUAOPzK maBYV09WQqJ93+h06BVE+pAzqiHcWCdtmCxd8fBKYcmo79uTeuB3qcirveaKqKLQPVbD a0P+SqDleUwNv8MZC85CzrUsp0p4dKGgVkEqOjFVa8a327/YhdDgdPT9bSYEpZnTyd/X kFplenZrcZoDq+a3Jkr7WiUWHEFZH32byQrwyjn9ZB9ENENZHH1BdBcA2aMmZ3mn7CZ0 vY0+9XsO0lV4A2llIYyn/PeFWTqp56lkq1crezysml4dcEQLJUU3dCUZFBz8UOI5rTAl 2SOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PLL2fxIm29d+ABkBUziLmFOlA/xCDSCZuo8ZMgQd8GE=; b=Kf8dhYYJ0Sad9C5CVogAqZjZEOFdKaCsAsg1Rf79+uH6NjgktWpUuAnuXRDnFq1ZJz LJAOopDD67+kduoBXRqvF6tfX25hOgiH9T07EJDs0mcdBI2pjEnGYJAeD0m7BtHBK0th wDIH0el1o9PmFZtPnQxX5Hehk0NFR5cvdh5qo3QkD8XFxsaNHUkzc/y+bUHRPlF9MQKv sV2Ns9W/Mq6shXAuE1RKTjnd2nUCBn9SLX1R/lDklbdBOp9gxtr1bj1nfyTsM3w57Icz HwfYk4c5hE++MuShb4zvIWNvMhPTIcaeHglaOjya2BF4eaUA+NvtRPvvUOJ1BDyPMhJR l3Uw== X-Gm-Message-State: AOAM532BcjS3/6pZpcq2L4U5tA5V4ojlPc9oijj+qap22Qu9TLdVmNlg vaf27HHnTPwy719wvbuOaPxJkVtbILo84fvocJuaTTyQqraN+xAsaAa4k8K4kH4skOmXPEzMcxG FWJVPDcvBRUm5iw== X-Google-Smtp-Source: ABdhPJy5vjxf2E5IORVlfniBRFi3berKoygnwDjy7pdvsbNwtl2WvIdvL49ofgyXbyIO5VNSEtsK57k6KkFbb3XmxQc= X-Received: by 2002:a19:f504:: with SMTP id j4mr3882604lfb.242.1623442846003; Fri, 11 Jun 2021 13:20:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Fri, 11 Jun 2021 14:20:19 -0600 Message-ID: To: Dmitry Telegin Cc: oauth Content-Type: multipart/alternative; boundary="000000000000264b5405c4833eb2" Archived-At: Subject: Re: [OAUTH-WG] DPoP key rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 20:20:54 -0000 --000000000000264b5405c4833eb2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dmitry, This ML is indeed the appropriate place for this kind of thing. You raise a legitimate question, however, the general rough consensus thinking has been that allowing for DPoP key rotation for refresh tokens and public clients (the only case where it's relevant) didn't add enough value to justify the added complexity. It doesn't help with the threat model for in-browser applications. And mobile applications have really good options for key storage - to the point that the kind of event that might compromise a DPoP key would involve a lot more than key rotation to cleanup from. On Tue, Jun 8, 2021 at 10:31 AM Dmitry Telegin wrote: > Hi, > > I'm Dmitry Telegin, I'm currently working on DPoP implementation in > Keycloak on behalf of my company, Backbase. Takashi Norimatsu of Hitachi > supervises this process as the head of the Keycloak FAPI SIG. > > With the current DPoP design, once the keypair has been generated on the > user agent and the initial token set has been obtained (using > authorization_code grant), the whole chain of the subsequent access/refre= sh > tokens will be bound to this particular keypair. That means, the keypair > should be persisted on the user agent for the duration of the session. > > OTOH, sessions could be rather long-lived, especially if we take offline > tokens [1] into account. In a nutshell, offline access provides a > non-expiring refresh token. This could be highly relevant e.g. for mobile > applications that would employ offline tokens to help users avoid logging > in every time. > > The longer the session lasts, the higher the probability of key leakage > is. Currently, the only way to switch to a new DPoP keypair is to start a > new session (i.e. log in again). Do you think it might be worth > incorporating some sort of key rotation concept into DPoP design? > > The most obvious way to perform key rotation is to do that during token > refresh. For that, we could make the refresh_token grant honour the > additional DPoP proof that would supersede the current one. From the > technical PoV, it could be as easy as supplying two proofs within the DPo= P > header: > > DPoP: eyJ0eXAiO... eyJ0eXAiO... > > Or we can go with a single (old) DPoP proof, containing the new proof (to= supersede the current one) as a claim (or vice versa). > > We'd appreciate any feedback from the WG. Also apologize if this ML is no= t the appropriate place to discuss issues like this. > > Regards, > > Dmitry Telegin > > Senior Backend Engineer, Backbase R&D B.V. > > [1] https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000264b5405c4833eb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dmitry,

This ML is indeed the approp= riate place for this kind of thing. You raise a legitimate question, howeve= r, the general rough consensus thinking has been that allowing for DPoP key= rotation for refresh tokens and public clients (the only case where it'= ;s relevant) didn't add enough value to justify the added complexity. I= t doesn't help with the threat model for in-browser applications. And m= obile applications have really good options for key storage - to the point = that the kind of event that might compromise a DPoP key would involve a lo= t more than key rotation to cleanup from.=C2=A0


On Tue, Jun 8, 2021 at 10:31 AM Dmitry Telegin <dmitryt=3D40backbase.com@= dmarc.ietf.org> wrote:
Hi,

I'm Dm= itry Telegin, I'm currently=20 working on DPoP implementation in Keycloak on behalf of my company,=20 Backbase. Takashi Norimatsu of Hitachi supervises this process=20 as the head of the Keycloak FAPI SIG.

With the=20 current DPoP design, once the keypair has been generated on the user=20 agent and the initial token set has been obtained (using=20 authorization_code grant), the whole chain of the subsequent=20 access/refresh tokens will be bound to this particular keypair. That=20 means, the keypair should be persisted on the user agent for the=20 duration of the session.

OTOH, sessions could=20 be rather long-lived, especially if we take offline tokens [1] into=20 account. In a nutshell, offline access provides a non-expiring refresh=20 token. This could be highly relevant e.g. for mobile applications that=20 would employ offline tokens to help users avoid logging in every time.

The longer the session lasts, the higher the probability of key leakage is. Currently, the only way to switch to a new DPoP keypair is to start a=20 new session (i.e. log in again). Do you think it might be worth=20 incorporating some sort of key rotation concept into DPoP design?

The most obvious way to perform key rotation is to do that during token=20 refresh. For that, we could make the refresh_token grant honour the=20 additional DPoP proof that would supersede the current one. From the=20 technical PoV, it could be as easy as supplying two proofs within the=20 DPoP header:

DPoP: eyJ0eXAiO... eyJ=
0eXAiO...

Or=
 we can go with a single (old) DPoP proof, containing the new proof (to sup=
ersede the current one) as a claim (or vice versa).

We'd appreciate any feed=
back from the WG. Also apologize if this ML is not the appropriate place to=
 discuss issues like this.

Regards,
Dmitry Telegin
Senior Backend Engineer, Backbase R&D B.V.<=
br>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000264b5405c4833eb2-- From nobody Mon Jun 14 09:40:01 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF5B3A2A61 for ; Mon, 14 Jun 2021 09:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkVqllaP9IXe for ; Mon, 14 Jun 2021 09:39:51 -0700 (PDT) Received: from sonic308-9.consmr.mail.ne1.yahoo.com (sonic308-9.consmr.mail.ne1.yahoo.com [66.163.187.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77473A2A6E for ; Mon, 14 Jun 2021 09:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1623688789; bh=Mzq7zj09bhpBW9APfNCyTevCC1w5m0jrdXMqu96YEBg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject:Reply-To; b=DvE9PnssrI4kALeJCjRTzdePKLvfa5MSv8YxnFcqhJsUbtOtVAfJUJJD8hMW/iwBYoAOJ+Z6FnaxfNTwXiKwTFyHGr0jC4RWZySKXBMOxvgAK1+fCiMIopCHz4ePWCUA+iTWtwF8guD5MRpfUZivH1A/BXVfr+/LmzZcVmTzHD5dEjZNLx2lJthQl1K2KAhZ6jVWwYH64kq4ub2bgh3KxhqJc9K947IyLvWCHMY1/gRLrcj7WF4pSn7TubAsVEAqQuVl1DhaYfsmtiF/J04u8Y+Ms1FSRKGAE8yH4/1XdKZpbztHiSfvtCDJ9GckOn+TTwb9CVzt7evNYDvJMxTqmA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623688789; bh=TrtzKd5E4B3Eth8No+jWrW4K/HKwUVoCz9NIcswjVSn=; h=X-Sonic-MF:Subject:To:From:Date:From:Subject; b=mFA56Skv68V1XLiZRWIMtbAB5Fhe7zK8ShbylwebBn1X/u0cLrOwN06VYwkQdDij1/O49QNHGthD3Q4yjdJ9r9IKZObh7A2D2HtwK6vVhBjW2I7HnvZ8/fxlqDcMztSz233PKMjq68r5M3DyrSQv7dVj08De/zf7Dh/TR5Pq+MHdf2JCisAiI7pXJLUre7qJHR6ilsCQEM2g/EFaT6EdCCmfh8pFzimmPGoAb+mIabrZawS9pMWfBoFe7dHC64mL7Xe4BYCZp7bWXcIPXm18Mxag/4XoatH85czXl/xGYq/tmdiaD9G97eOck1/Ch0qBuOxTlqXwjLxHgZatCnwxmA== X-YMail-OSG: 3TpDk9kVM1k6z_dDDsptKcY26LSgZfR_2CseIw4qEsFKUYvxfLxZ.m8LcBSQ6kA 2huUZSzPZ5vamTjHRKyS_R7F8Pl6RZJhCOdavnqwBuRjysEZIfJdXVtIwNKNVVb91UAlKHc1kwou NQ6TGZmgqXChKgm_2oF1co2Vx2tDT.vTZzc.ngpWog3fHoz2ogtpnOOBNeak9bAKPsTKyUyQE6J3 fiqaj6wJI.YI4da9qlLBr.y0mF3PKYsAnHLWLx_8GnfM3NmHE6A5SjjC.k2ROG6geSw7re492_ex mITwvV2DohgRRGUbRXvGzDpVR97MhcZYSaRiZ6pJkhEgJ3JDjPoa.aYx9Cd4SNNKENjUPOoEcwcL CbQto948OLQKqk3kgzDODeq98GmlpMSaxe4htVwqkyS7M0VHR0IgVl_YVu_dM9vGuFrQ4z1W.dAe gnirfEN5FtR3GNU5rhAhxJdqw1xr2i0nl6au5V6DB8bJGgXkHZCwxe4kxeWSgT5cwpSpMkH7Xpvh FSt20hH8ePbxKuyNn1rcOZ.gWw2JtB8auGQm6zoKL6PeHCLLsdW.tlvfRx9SvtUIoXZV8zwYHUgM ifLK5eVNfZEPI5jMNQ61OSBSb0KdxPNFL4.GPF6.F.zMYiut.6u30P0r9qWRZJH00EhqeaUzspfQ .pVGFhpqlmt_o.pqYgiIQMXiGKP.a4qXn14uv86VDMliZtQRgE3L.Tu9DyzFaaW0zwPLPdyDWTFv 8EbGlhmz_.sqdrNyA9_v1jjB5_Uv4HFlxj4HfSAAWMsrWawxFwY7Fc0.Tftv.VZ_00cDILJMlyLo EUGhOqXXWG1GkyQ1zaFw5KUTHQnSyFE48KUsBI5ET0GCoZknXGgiMFRg78B2e8GXfo5kfTIYAcdZ FkJBrGZWAImEVwX6gbpaiE_Wpbkl5J1g7oTxhXQzjo1VfaJWzBSEDzvLrWkh3KJMWHefkfuFly4A pzOEA7FyFuVLWf_onFQAqjsVy2i6EPCkVW9cHwObDrmeZNmLATun5UAYBH6mxbtmYaP35AT9web2 Y92AjwUS.DReHtKhWtXiUDE.Vel9voY7uoY7EYLSsYhdjpBw15rq5yd6NCiISaFpe88c20XX5onY sOFxe.PWJDt4jAbPg1_oTVaKQPAg7h7zdaMVAUEjN038K.t_SD6boCl.2gKfQus8GQGGlwCGvOKm V5ydfsy0GlKrm3ZDGTOUA8M8F2dmfsvhBMHB2w9CT.y.31PEopsUDKexpmQZKfnFOAWm4tAFqnZy 0ekuEkRvG.mg0qdJgHE43OvEqvQYiJ7iBEYDzBr2jL.DWIGa4OZTKWlR7Ja5U53R5Xc3ctnbaZas .FGeJdOT1uy2MJrITr99QuA3PY2.N5Tceq2MWS6U2OEkMV_FUByyqtXpkWOXCGSil9BbZTTRQy5J Fp7C63_sOYyFOxFRXIkrv0LGAbn09yPSDa5q.X7TPVre_g8.XuzTfj_OMHS2UammyCCzhZjUxBOF SAQlWxOTWfx4O0XgiNKJ1GUwF_wtTuvi4Bqlcw7X4tEhQnkyOSDpN.TEF9p82egwX5wXmRHYrM9o umLOBOnzE2eYkHO1Ea6nYCcRrUw2dm0_RiFver0_qBjZYDqNtRxZUtyLujCvKMBRTegu0nFH.gPg TXoUPZxo9nb37c1WtomDsxRZMLbk.nG5gm1llpsT4mBh3fNTzVYgB1saDDSCYC.8KHTOuMmDDr5G dHIT4b0Wd.rm1wRRLu_QSQeezZs.5.w68w.Jc313KehaNpy_zBG8Uvr2x9K6pl4aIC_9.xkvCq1l xbsBlxRwDkevNkUIpoKy0UII1DcQTBWa0d_t0hy_LySQFW9NhOvXEPv8AAUj.gFMkS_PpR9QdR8P PtZiB9ZlJvgdnZXPK48xgaA2pccwp0O1gXI_sINZSDmthqQmro7ucpencYlM2zbjNpb9PAtnqcQa kC0UW_nKwIxsrKVGH0VOzfYoBGj69BBbUkB9.fza3wKBRIKxymdRsQnMt6qxj.EIpvHrQupvL921 DCiClEYxzsJ59upgN41DSnEGmcXzTtz5_30lspDMGfdkygFWlAYsbI.0g0UilBnkZptfsnnV4jAw abjEvr.cSGx1bGPhyX_DMMs2X1BQMYtLiB.Copm.AS1kf6iKnyXmPsfRxZX4VbSMKvcUJfrvQ4Py pZdI6H61ngLybBJ55SSpwOwSzl2b2cD.J_AIDsvpD3KX.etvHCkXBHHDtmnTbChoM9LqcTMP.43M yU8IT_VlNeGoZFbJUO_n4qcATTzO050fT5IIeOdJ9P0t8eyfidj22xBaDAj583QOUu_xTi5_.Jo7 wIypVwyGYoCyl8p.HDtcFIt7ukyr.WqKc6GjMbJfLAgNIjQ1tJ67ojrvfDy3sSTi45RWip2vydqu TOVpIydOnu0Hg3IqL7PhgG80B4iNQi.L1zB_6a2XwB5JUtLmYqoEvCLK71IB9TjO83A-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Mon, 14 Jun 2021 16:39:49 +0000 Received: by kubenode520.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0ed1ef1ec94255bfe75bc8f1c199be6f; Mon, 14 Jun 2021 16:29:42 +0000 (UTC) To: Brian Campbell , Dmitry Telegin Cc: oauth References: From: George Fletcher Organization: AOL LLC Message-ID: <48695e18-80bf-28eb-c8ac-2fb25aad8a45@aol.com> Date: Mon, 14 Jun 2021 12:29:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------37FE9BF03F80A3053D28690C" Content-Language: en-US X-Mailer: WebService/1.1.18469 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [OAUTH-WG] DPoP key rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 16:39:59 -0000 This is a multi-part message in MIME format. --------------37FE9BF03F80A3053D28690C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit There has also been some limited discussion on whether it's useful for mobile applications to create a relationship between keys used for Dynamic Client Registration (DCR) and the associated keys for DPoP headers. DCR does have mechanisms for rotating client instance keys and hence if the keys for DPoP are the same then this might be a mechanisms to support rotation for mobile applications. Note that while both Android and iOS have hardware support for keys... the keys themselves have limitations on how they can be used, so depending on your use case, the hardware backed keys may not suffice. Thanks, George On 6/11/21 4:20 PM, Brian Campbell wrote: > Hi Dmitry, > > This ML is indeed the appropriate place for this kind of thing. You > raise a legitimate question, however, the general rough consensus > thinking has been that allowing for DPoP key rotation for refresh > tokens and public clients (the only case where it's relevant) didn't > add enough value to justify the added complexity. It doesn't help with > the threat model for in-browser applications. And mobile applications > have really good options for key storage - to the point that the kind > of event that might compromise a DPoP key would involve a lot more > than key rotation to cleanup from. > > > > On Tue, Jun 8, 2021 at 10:31 AM Dmitry Telegin > > wrote: > > Hi, > > I'm Dmitry Telegin, I'm currently working on DPoP implementation > in Keycloak on behalf of my company, Backbase. Takashi Norimatsu > of Hitachi supervises this process as the head of the Keycloak > FAPI SIG. > > With the current DPoP design, once the keypair has been generated > on the user agent and the initial token set has been obtained > (using authorization_code grant), the whole chain of the > subsequent access/refresh tokens will be bound to this particular > keypair. That means, the keypair should be persisted on the user > agent for the duration of the session. > > OTOH, sessions could be rather long-lived, especially if we take > offline tokens [1] into account. In a nutshell, offline access > provides a non-expiring refresh token. This could be highly > relevant e.g. for mobile applications that would employ offline > tokens to help users avoid logging in every time. > > The longer the session lasts, the higher the probability of key > leakage is. Currently, the only way to switch to a new DPoP > keypair is to start a new session (i.e. log in again). Do you > think it might be worth incorporating some sort of key rotation > concept into DPoP design? > > The most obvious way to perform key rotation is to do that during > token refresh. For that, we could make the refresh_token grant > honour the additional DPoP proof that would supersede the current > one. From the technical PoV, it could be as easy as supplying two > proofs within the DPoP header: > > |DPoP: eyJ0eXAiO... eyJ0eXAiO... | > > |Or we can go with a single (old) DPoP proof, containing the new > proof (to supersede the current one) as a claim (or vice versa). | > > |We'd appreciate any feedback from the WG. Also apologize if this > ML is not the appropriate place to discuss issues like this. | > > |Regards, | > > |Dmitry Telegin | > > |Senior Backend Engineer, Backbase R&D B.V. | > > [1] > https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > /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./ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------37FE9BF03F80A3053D28690C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit There has also been some limited discussion on whether it's useful for mobile applications to create a relationship between keys used for Dynamic Client Registration (DCR) and the associated keys for DPoP headers. DCR does have mechanisms for rotating client instance keys and hence if the keys for DPoP are the same then this might be a mechanisms to support rotation for mobile applications.

Note that while both Android and iOS have hardware support for keys... the keys themselves have limitations on how they can be used, so depending on your use case, the hardware backed keys may not suffice.

Thanks,
George

On 6/11/21 4:20 PM, Brian Campbell wrote:
Hi Dmitry,

This ML is indeed the appropriate place for this kind of thing. You raise a legitimate question, however, the general rough consensus thinking has been that allowing for DPoP key rotation for refresh tokens and public clients (the only case where it's relevant) didn't add enough value to justify the added complexity. It doesn't help with the threat model for in-browser applications. And mobile applications have really good options for key storage - to the point that the kind of event that might compromise a DPoP key would involve a lot more than key rotation to cleanup from. 



On Tue, Jun 8, 2021 at 10:31 AM Dmitry Telegin <dmitryt=40backbase.com@dmarc.ietf.org> wrote:
Hi,

I'm Dmitry Telegin, I'm currently working on DPoP implementation in Keycloak on behalf of my company, Backbase. Takashi Norimatsu of Hitachi supervises this process as the head of the Keycloak FAPI SIG.

With the current DPoP design, once the keypair has been generated on the user agent and the initial token set has been obtained (using authorization_code grant), the whole chain of the subsequent access/refresh tokens will be bound to this particular keypair. That means, the keypair should be persisted on the user agent for the duration of the session.

OTOH, sessions could be rather long-lived, especially if we take offline tokens [1] into account. In a nutshell, offline access provides a non-expiring refresh token. This could be highly relevant e.g. for mobile applications that would employ offline tokens to help users avoid logging in every time.

The longer the session lasts, the higher the probability of key leakage is. Currently, the only way to switch to a new DPoP keypair is to start a new session (i.e. log in again). Do you think it might be worth incorporating some sort of key rotation concept into DPoP design?

The most obvious way to perform key rotation is to do that during token refresh. For that, we could make the refresh_token grant honour the additional DPoP proof that would supersede the current one. From the technical PoV, it could be as easy as supplying two proofs within the DPoP header:

DPoP: eyJ0eXAiO... eyJ0eXAiO...


Or we can go with a single (old) DPoP proof, containing the new proof (to supersede the current one) as a claim (or vice versa).


We'd appreciate any feedback from the WG. Also apologize if this ML is not the appropriate place to discuss issues like this.


Regards,

Dmitry Telegin

Senior Backend Engineer, Backbase R&D B.V.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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. 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------37FE9BF03F80A3053D28690C-- From nobody Mon Jun 14 10:59:07 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BB13A2CBC for ; Mon, 14 Jun 2021 10:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aueb.gr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ql6gIYUyVOBR for ; Mon, 14 Jun 2021 10:58:52 -0700 (PDT) Received: from blade-b3-vm-relay.servers.aueb.gr (blade-b3-vm-relay.servers.aueb.gr [195.251.255.106]) by ietfa.amsl.com (Postfix) with ESMTP id 28EB63A2C8E for ; Mon, 14 Jun 2021 10:58:51 -0700 (PDT) Received: from blade-a1-vm-smtp.servers.aueb.gr (blade-a1-vm-smtp.servers.aueb.gr [195.251.255.217]) by blade-b3-vm-relay.servers.aueb.gr (Postfix) with ESMTP id 99D6AD27; Mon, 14 Jun 2021 20:58:49 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aueb.gr; s=201901; t=1623693529; bh=9k9FJ/wo+kmmvsOuADQmwtpboRS9D3gMUxCNfha2wKA=; h=From:To:References:In-Reply-To:Subject:Date:From; b=KAZ+KORsVMb2YjDZUx4Qw5q+HUWYHB6H8VITc1EboNY5GScpjF+ko0lnRCyylxUY7 YGup60QJGpf7yLYu/0YdhizxX2VIlqxL7CXbNyzgxDcLAWV5indxqELhMZ0UhoGAaF Ax/slIYv1nZ2FtJJwXd1Loe8eHmGIfZIE0hD2aT/uy8laZH25oYwMB5otJueI7AhnU vrXbs4dZogPtx5HwDECgJzNVjguomAPRaYr5CrbrCM9zIKoPaf+Yt4mHpJOrpa6q6+ xNZzhZE13GO2aB7Py7nD4KEPH2Ct7eFG/Fb1SHFbrD62Lau6zyUhiaIa/68kVFV2vt Y7lzoT8I6v+Hg== Received: from Desktop (athedsl-4547100.home.otenet.gr [94.70.46.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fotiou@aueb.gr) by blade-a1-vm-smtp.servers.aueb.gr (Postfix) with ESMTPSA id 4B2B25DE; Mon, 14 Jun 2021 20:58:48 +0300 (EEST) From: "Nikos Fotiou" To: "'Dmitry Telegin'" , References: In-Reply-To: Date: Mon, 14 Jun 2021 20:58:46 +0300 Message-ID: <006b01d76146$ed160fd0$c7422f70$@aueb.gr> X-Mailer: Microsoft Outlook 16.0 Content-Language: el MIME-Version: 1.0 Thread-Index: AQFaQ3FoMVzcuO99SsbHZAUpbEAatawOBbQw Content-Type: multipart/signed; boundary="----=_NextPart_000_0064_01D76160.114D43F0"; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1 Archived-At: Subject: Re: [OAUTH-WG] DPoP key rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 17:59:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0064_01D76160.114D43F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0065_01D76160.114D43F0" ------=_NextPart_001_0065_01D76160.114D43F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, For a research project we have implemented key rotation by leveraging = =E2=80=9CToken Introspection=E2=80=9D (see section 6.2 here = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03#section-6.= 2 ) Of course the drawback of this approach is that the authorization = server must always know the current key of the client. =20 Best, Nikos =20 From: OAuth On Behalf Of Dmitry Telegin Sent: Tuesday, June 8, 2021 7:30 PM To: oauth@ietf.org Subject: [OAUTH-WG] DPoP key rotation =20 Hi, =20 I'm Dmitry Telegin, I'm currently working on DPoP implementation in = Keycloak on behalf of my company, Backbase. Takashi Norimatsu of Hitachi = supervises this process as the head of the Keycloak FAPI SIG. =20 With the current DPoP design, once the keypair has been generated on the = user agent and the initial token set has been obtained (using = authorization_code grant), the whole chain of the subsequent = access/refresh tokens will be bound to this particular keypair. That = means, the keypair should be persisted on the user agent for the = duration of the session. =20 OTOH, sessions could be rather long-lived, especially if we take offline = tokens [1] into account. In a nutshell, offline access provides a = non-expiring refresh token. This could be highly relevant e.g. for = mobile applications that would employ offline tokens to help users avoid = logging in every time. =20 The longer the session lasts, the higher the probability of key leakage = is. Currently, the only way to switch to a new DPoP keypair is to start = a new session (i.e. log in again). Do you think it might be worth = incorporating some sort of key rotation concept into DPoP design? =20 The most obvious way to perform key rotation is to do that during token = refresh. For that, we could make the refresh_token grant honour the = additional DPoP proof that would supersede the current one. From the = technical PoV, it could be as easy as supplying two proofs within the = DPoP header: =20 DPoP: eyJ0eXAiO... eyJ0eXAiO... Or we can go with a single (old) DPoP proof, containing the new proof = (to supersede the current one) as a claim (or vice versa). We'd appreciate any feedback from the WG. Also apologize if this ML is = not the appropriate place to discuss issues like this. Regards, Dmitry Telegin Senior Backend Engineer, Backbase R&D B.V. [1] https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess ------=_NextPart_001_0065_01D76160.114D43F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

For a research project we have = implemented key rotation by leveraging =E2=80=9CToken = Introspection=E2=80=9D (see section 6.2 here https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03= #section-6.2 ) Of course the drawback of this approach is that the = authorization server must always know the current key of the = client.

 

Best,

Nikos

 

From: OAuth = <oauth-bounces@ietf.org> On Behalf Of Dmitry = Telegin
Sent: Tuesday, June 8, 2021 7:30 PM
To: = oauth@ietf.org
Subject: [OAUTH-WG] DPoP key = rotation

 

Hi,

 

I'm Dmitry Telegin, I'm currently working on DPoP = implementation in Keycloak on behalf of my company, Backbase. Takashi = Norimatsu of Hitachi supervises this process as the head of the Keycloak = FAPI SIG.

 

With the current DPoP design, once the keypair has = been generated on the user agent and the initial token set has been = obtained (using authorization_code grant), the whole chain of the = subsequent access/refresh tokens will be bound to this particular = keypair. That means, the keypair should be persisted on the user agent = for the duration of the session.

 

OTOH, sessions could be rather long-lived, especially = if we take offline tokens [1] into account. In a nutshell, offline = access provides a non-expiring refresh token. This could be highly = relevant e.g. for mobile applications that would employ offline tokens = to help users avoid logging in every time.

 

The longer the session lasts, the higher the = probability of key leakage is. Currently, the only way to switch to a = new DPoP keypair is to start a new session (i.e. log in again). Do you = think it might be worth incorporating some sort of key rotation concept = into DPoP design?

 

The most obvious way to perform key rotation is to do = that during token refresh. For that, we could make the refresh_token = grant honour the additional DPoP proof that would supersede the current = one. From the technical PoV, it could be as easy as supplying two proofs = within the DPoP header:

 

DPoP: eyJ0eXAiO... =
eyJ0eXAiO...
Or we can go with a single =
(old) DPoP proof, containing the new proof (to supersede the current =
one) as a claim (or vice versa).
We'd appreciate any feedback =
from the WG. Also apologize if this ML is not the appropriate place to =
discuss issues like this.
Regards,
Dmitry =
Telegin
Senior Backend Engineer, =
Backbase R&D B.V.
------=_NextPart_001_0065_01D76160.114D43F0-- ------=_NextPart_000_0064_01D76160.114D43F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEj4w ggQxMIIDGaADAgECAgEAMA0GCSqGSIb3DQEBBQUAMIGVMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7 SGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3Jp dHkxQDA+BgNVBAMTN0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMg Um9vdENBIDIwMTEwHhcNMTExMjA2MTM0OTUyWhcNMzExMjAxMTM0OTUyWjCBlTELMAkGA1UEBhMC R1IxRDBCBgNVBAoTO0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMg Q2VydC4gQXV0aG9yaXR5MUAwPgYDVQQDEzdIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2gg SW5zdGl0dXRpb25zIFJvb3RDQSAyMDExMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA qVMA4y6m9o76YNgtlT74LCpUTs25hGGUWE+PPYvkQ/N1iY1R5MM30oqITXketxLdQ3hKipLm10jV D6Q6KUQ1uAf2aB1VzThR8IwkMYWvg8l96Xev7Rp7nRf5s504UA+mWnmRgK83rqbTMfu1JgmdPFrv UcUr35Zd6zIeAtpwSexuDMiaN4338TZgSyYsgp7QePMND2OkUTDh+SsnEgfY6r0YYpiwWTd9vu7z IFFCWoPvk7ppFfFinZ+ZOYKht3Qui9TFC3sv8MgK2j15CpqTHKUocnORQ5qn0U2FhLmpdI8UQMfc 3qxBZGy0GZsCY20kZI9EsiXqzl10DGMyXI2H5QIDAQABo4GJMIGGMA8GA1UdEwEB/wQFMAMBAf8w CwYDVR0PBAQDAgEGMB0GA1UdDgQWBBSmkUL9E2FKI54IpCnl2BMEI+5BJTBHBgNVHR4EQDA+oDww BYIDLmdyMAWCAy5ldTAGggQuZWR1MAaCBC5vcmcwBYEDLmdyMAWBAy5ldTAGgQQuZWR1MAaBBC5v cmcwDQYJKoZIhvcNAQEFBQADggEBAB/veUHhe24/soyGN0JKThw3Ho1muiSByU8SDyHAA5eGJW1d 0yIpqGyiDanrPQZbmTrHzMOaNH+rDshOHOH65NzNDb6/JP5s52vCDcgGnk6NYSimav3l9mLqGDxO oFOdsjqc66WckRa2TYLgDAVIqWz1zPjLnUm08AKl/XAD7Yohpa4ThknDM3O+hzt0ixdFJkwWkYP+ Z33NTWNn+vMDEpZ4Bo2xZ+2OP76fTwL1swkv80yH3yrLlXwBzKw2er+ic3r3j8G1mqEUso8znw3v Itxme4S9RRcGPTzKuXc0j8rqzz8xPuOI44BJJciXtZ2amU2wPPhKAJtk3Z85S9En17gwggbQMIIE uKADAgECAhBAB3aGT+I5a2zJV9kPcbUZMA0GCSqGSIb3DQEBCwUAMIGPMQswCQYDVQQGEwJHUjFE MEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0 LiBBdXRob3JpdHkxOjA4BgNVBAMTMUF0aGVucyBVbml2ZXJzaXR5IG9mIEVjb25vbWljcyBhbmQg QnVzaW5lc3MgQ0EgUjIwHhcNMTkxMjEyMTQxNzU4WhcNMjExMjExMTQxNzU4WjCCAQkxCzAJBgNV BAYTAkdSMQ8wDQYDVQQHDAZBdGhlbnMxNDAyBgNVBAoMK0F0aGVucyBVbml2ZXJzaXR5IG9mIEVj b25vbWljcyBhbmQgQnVzaW5lc3MxQTA/BgNVBAsMOENsYXNzIEIgLSBQcml2YXRlIEtleSBjcmVh dGVkIGFuZCBzdG9yZWQgaW4gc29mdHdhcmUgQ1NQMQ8wDQYDVQQEDAZGT1RJT1kxETAPBgNVBCoM CE5JS09MQU9TMRMwEQYDVQQFEwozODY2OTQxMjIxMRgwFgYDVQQDDA9OSUtPTEFPUyBGT1RJT1kx HTAbBgkqhkiG9w0BCQEWDmZvdGlvdUBhdWViLmdyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAgLLzGBqZBB4A0EYdBSjLSUYjNMZYSS14Z4+Esf6iK7wrSw8pOfjLBMqtJOywazPxWgmm vhk6PaCLhZYgwPqdGQk3z+m3Hm2ao9fnFghTIBhXyypOJVCEVNblcY1r6+HZZLZZ/Z5NnMLuNKK+ uWQ7dRR/GZDOFGcnOtcmMx9GKrgSrawVOsghzBRg5wLbvCaCNJsJ90mRYsyUjkg9OglG2dzZ7Bi0 2BzozUwP69dFaKG7ml12C9FwQiaBURg3dDbgl7AuGY1AZcqBAPwKNni0Jkpl5XL2JzjbzQj73EbT FMrsgG1PbGw/uZgQyCqAVHS1HiIJhyMTn7cttd5CobkMMwIDAQABo4IBqTCCAaUwHwYDVR0jBBgw FoAUd2BZxxknkkBQvIKZbY8+SdAQ9CowbQYIKwYBBQUHAQEEYTBfMDoGCCsGAQUFBzAChi5odHRw Oi8vcmVwby5oYXJpY2EuZ3IvY2VydHMvSGFyaWNhQXVlYkNBUjIuY3J0MCEGCCsGAQUFBzABhhVo dHRwOi8vb2NzcC5oYXJpY2EuZ3IwGQYDVR0RBBIwEIEOZm90aW91QGF1ZWIuZ3IwWAYDVR0gBFEw TzAIBgYEAI96AQEwQwYNKwYBBAGBzxEBAQICATAyMDAGCCsGAQUFBwIBFiRodHRwczovL3JlcG8u aGFyaWNhLmdyL2RvY3VtZW50cy9DUFMwKQYDVR0lBCIwIAYIKwYBBQUHAwIGCCsGAQUFBwMEBgor BgEEAYI3CgMMMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmx2MS5oYXJpY2EuZ3IvSGFyaWNh QXVlYkNBUjIvY3JsdjEuZGVyLmNybDAdBgNVHQ4EFgQUcMJMYLF3+xjl9x4Fc4V2qRdAoVIwDgYD VR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQAo/QEb7ED5Z7e3qdVPfIdKRpnLQ+JH3V7w 4CKouEZkSjH2m+y0WOtMoF4cPCNrMH90n/IH9QuGcyYALRQTXAKsgF5s5TIeHc8fpFAesjoVjTHT ijK94b4ekh81jU/o8sRhsfWjPzAjzhSogWuh9yYox7fx0pvnux9lGE2+mVhE0xJqzP4N6zGmVsYY Og6YfOtjYK46lvT5WOKkdK9lD9S3vmws0BPOCirvIqc9/fzKngZMTcsXMEZp91z40SuUxn48P370 TKgvzIkmnDVB/iOobkdErAgp5j2o6s/Bt2m91VwLW3xOIV4F9y8BGOxsRqvRkv7wMKmhTjkAT+MV F7uw1S+vmeTeL+pdFUBAKJRizEqjCL6D7ZwpKszeMhi6Sx31ooOPpTOWtPh/fLfRRJBYNFcrYgMl Br0WWe1nIYajWskliR+5HNyNY8/zQApm9SGqr4VjaYdEwnU+NVLiZ2pikWyrg5B8QyqcJCNdZRez jOPqM6DN+t52HMSnqHFxsy6cqOfqOSAsitZT2LkBWVDj3TxkENnw04hPUS4ip48jMB0szuajEMmK qs5/uGY9EyQ3bHlDDWQxu/DULZJOcsZPX67mcOTLfXOXFnyW/gOGbvCgitlimm7xrDHmVWvB4AE7 XPK7ogjGmG1qEq7vnYOcgj93DGizi+QkmVMCJwpGYjCCBzEwggYZoAMCAQICCBjdh64fS7Z7MA0G CSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMg YW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3JpdHkxQDA+BgNVBAMTN0hlbGxl bmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgUm9vdENBIDIwMTEwHhcNMTUw NzI4MDcxMDQ4WhcNMjMwNzI2MDcxMDQ4WjCBjzELMAkGA1UEBhMCR1IxRDBCBgNVBAoTO0hlbGxl bmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgQ2VydC4gQXV0aG9yaXR5MTow OAYDVQQDEzFBdGhlbnMgVW5pdmVyc2l0eSBvZiBFY29ub21pY3MgYW5kIEJ1c2luZXNzIENBIFIy MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAjTO6hsbRRbmkpEjRUM1K7/Mn2XgBgh/T p6AbDXt5rS/oFBc/GJ5bCJFc7P1d1LHMSM1VT0advzlwE2xdnR0X9ThYKIm67gOAs1RUHxLqSYcr g2qkGdm1LadSwfn8KTDAxXynmVHhduU5jOTWS/LbX18EkZQ0tWiTEHxN+Uj7RFGzPrrEC6C3x+W/ jZ9uZEfjLOxC0FHkYGndlHWh2SnoJyKvcWXE1F3DEdsGhm7gK/wxRG70U1ryihV3upd43YNdxEzB BEP2RIR8UDPLt4UpdfmmTk9uVJR6waYYtpnF10PSpuMRXNqV2dtlXCz8OEuoWFSlJbUF7VmwiZID g5P7INZ9bRWercaBquvOdDk0hBcuUfadx7TfPQHRhhUAP9UGvGcJsX7gP/3R0eUMGC6QH+Ly5LKd fHpubVABNQnXcKXgVQtjJWGObSGsnz/X3PmhF+MYlQRtrT7852Paf0xnQ1klXaLpd04jRK/EoVrJ s9jZWggPatQsX9aWuXR7xWGqOR3kT7aetAwk3FgT896eUj5V1C5eJZy9b21SJm5ux2WtmrcpCtDc YSafDaJ/0toGUPnZZnDMyyKYbuQvNu7AVYcT5uFTu84JKTqjl8jrXb4PITFN7rjKPOb0geJm+RtT De9Shan4d0vty9xWUDvMV5utJPIkreaRdGDbbNJQkP0CAwEAAaOCAocwggKDMA8GA1UdEwEB/wQF MAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR3YFnHGSeSQFC8gpltjz5J0BD0KjBGBgNV HR8EPzA9MDugOaA3hjVodHRwOi8vY3JsdjEuaGFyaWNhLmdyL0hhcmljYVJvb3RDQTIwMTEvY3Js djEuZGVyLmNybDAfBgNVHSMEGDAWgBSmkUL9E2FKI54IpCnl2BMEI+5BJTBuBggrBgEFBQcBAQRi MGAwIQYIKwYBBQUHMAGGFWh0dHA6Ly9vY3NwLmhhcmljYS5ncjA7BggrBgEFBQcwAoYvaHR0cDov L3d3dy5oYXJpY2EuZ3IvY2VydHMvSGFyaWNhUm9vdENBMjAxMS5jcnQwggE3BgNVHSAEggEuMIIB KjCCASYGBFUdIAAwggEcMDIGCCsGAQUFBwIBFiZodHRwOi8vd3d3LmhhcmljYS5nci9kb2N1bWVu dHMvQ1BTLnBocDCB5QYIKwYBBQUHAgIwgdgwShZDSGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2Vh cmNoIEluc3RpdHV0aW9ucyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoGJVGhpcyBjZXJ0 aWZpY2F0ZSBpcyBzdWJqZWN0IHRvIEdyZWVrIGxhd3MgYW5kIG91ciBDUFMuIFRoaXMgQ2VydGlm aWNhdGUgbXVzdCBvbmx5IGJlIHVzZWQgZm9yIGFjYWRlbWljLCByZXNlYXJjaCBvciBlZHVjYXRp b25hbCBwdXJwb3Nlcy4wLQYDVR0eBCYwJKAiMAmCB2F1ZWIuZ3IwCYEHYXVlYi5ncjAKgQguYXVl Yi5ncjANBgkqhkiG9w0BAQsFAAOCAQEAhSXJoQDbTRBYH549pfk9+3CjT+HnAcFajp60aV8UYR63 DZflolPCDagaRxADLd3SpbOuGlRGNw+MgYpAp/d6i5BfVpjMVIhp5E7zr6TDJgVIwt2UxuLejfow umCNkRJD+RrdUcLKHzcPOfSD40MRHprehXT1bvyuka26ogF6U0T2uEDoOIaObV/RS9wgGx9y63/Q Ic/tsZNQ3pzcAbTecnax6ITfSvnnfeMol6IcS+rKxPwKjPPFQq93qT8w61qe+zEx54vRwJXi241e dkTmBTJddM5Cdhxxy98xYX+eYNnf5x96vVDQ1qc2wcecMHADZBrfVV/tx0Ev6hTlYBhOmzGCBEUw ggRBAgEBMIGkMIGPMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMgYW5k IFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3JpdHkxOjA4BgNVBAMTMUF0aGVucyBV bml2ZXJzaXR5IG9mIEVjb25vbWljcyBhbmQgQnVzaW5lc3MgQ0EgUjICEEAHdoZP4jlrbMlX2Q9x tRkwDQYJYIZIAWUDBAIBBQCgggJxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTIxMDYxNDE3NTg0NlowLwYJKoZIhvcNAQkEMSIEIGO/TrN159qxZvHi8tc/kjE8qkES Sch4f1MtR3NhSV+9MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAsGCWCGSAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMIG1BgkrBgEE AYI3EAQxgacwgaQwgY8xCzAJBgNVBAYTAkdSMUQwQgYDVQQKEztIZWxsZW5pYyBBY2FkZW1pYyBh bmQgUmVzZWFyY2ggSW5zdGl0dXRpb25zIENlcnQuIEF1dGhvcml0eTE6MDgGA1UEAxMxQXRoZW5z IFVuaXZlcnNpdHkgb2YgRWNvbm9taWNzIGFuZCBCdXNpbmVzcyBDQSBSMgIQQAd2hk/iOWtsyVfZ D3G1GTCBtwYLKoZIhvcNAQkQAgsxgaeggaQwgY8xCzAJBgNVBAYTAkdSMUQwQgYDVQQKEztIZWxs ZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2ggSW5zdGl0dXRpb25zIENlcnQuIEF1dGhvcml0eTE6 MDgGA1UEAxMxQXRoZW5zIFVuaXZlcnNpdHkgb2YgRWNvbm9taWNzIGFuZCBCdXNpbmVzcyBDQSBS MgIQQAd2hk/iOWtsyVfZD3G1GTANBgkqhkiG9w0BAQEFAASCAQBgxzdqfK3wZUPZRc8AMnzPM6xU rlzRiKNU+j5mxEXU9kgUXvdaLpKfH6xtYZHv072Ndu2KbpLCpU/T0t1A9R5wCFqKKxsy644HwQVG QzknXDAO9Ww2+xdkbX0eJ75LpnouZjxztKAj1vUAR3rypTIiRXumM7J16IpQ68D39VzGYTfn6eUt M08RltJ1A3mTa1Xcc0gsa8prOf6cDiALtAD9W0ACRo6kdHgDAWGMM4QVdLOLT6KAVhTcIt5G+UOC GReZIEVE2Ok+65yrb2aSW7SeLkhQS8yMYAzRyLjsseB+yQOUoApynbdiTHI31N58CskIZL2sg5hS 15bxMn4MagRKAAAAAAAA ------=_NextPart_000_0064_01D76160.114D43F0-- From nobody Tue Jun 15 03:00:31 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C013A292E for ; Tue, 15 Jun 2021 03:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_xk_C4zCuSP for ; Tue, 15 Jun 2021 03:00:23 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A76203A295B for ; Tue, 15 Jun 2021 03:00:23 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id h22-20020a05600c3516b02901a826f84095so1630277wmq.5 for ; Tue, 15 Jun 2021 03:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vBcDReAGP6Zyu5tQ/mY8HK9pq+9o3Sz9V0kz/k3K+fI=; b=CZ8B7qrMrg5G/FSmoE250lpdpy6NiNHSIztnYlx9OqmjquKt3YLLFvglcqsRfQuKly AtEBpdnqaAEwnMJG622eD6A6kRZATH1fay/1K4thwUckPV0UtN5zKETVJnpPEh/DvTNz Yc2wOynXmqiwqcY4SqQ0t3zbnyQoNRli13A1M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vBcDReAGP6Zyu5tQ/mY8HK9pq+9o3Sz9V0kz/k3K+fI=; b=dV2Yv2b7OA9xVSqphT1dIBtJMc/rc+fY1iaPhqow7yf5BL0uxV9PrYS0/v+8gJI5iS dNQAYpXRxDcvfOJRnKVPIYMt3JzvOWLEOxPFPAtxgofNQHrrJQ7Z0kKgsu2ENZE9qd+E yRN4fuVo1dO5Tz09stZiu0tJc3MTR7UkFhCnbuTtA32xIxYkRtdf5P79/N0rOuLclofp 10w+n66CKEhEnMtFqPVX2JZmIIFDp0ru9ZB8mGkVTWjxiTg+kjoXPSuZqmc8Kr0EfTi9 5bs/bf/fFEJQoCNy4nMmWWo38Yfz/10Md9zukGXRPSsBjyc7cZBy0EXhSGxu4U5lACGS jO9w== X-Gm-Message-State: AOAM533JcwhVycDFMM05nj9LnD4ghlOBi/MTzsHnvnoJw5LYJ8jIkbuj jqMpgSp5cn4JX7R56IqTWf09mgPpIqDPZDSr1+rbE7u7Z/Dx7QJ/2XsebrRrE/mdZqbuUmfIEQ= = X-Google-Smtp-Source: ABdhPJynl/YxHqZRKcg9j3FTJ8hPd/srGLK3xCcOJqrdwmi4ZIotxcGhurpdfIolQM2Xm508OT+KKw== X-Received: by 2002:a05:600c:20d:: with SMTP id 13mr22033537wmi.174.1623751220239; Tue, 15 Jun 2021 03:00:20 -0700 (PDT) Received: from [10.0.0.6] (113.87.75.194.dyn.plus.net. [194.75.87.113]) by smtp.gmail.com with ESMTPSA id l9sm15156844wme.21.2021.06.15.03.00.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Jun 2021 03:00:19 -0700 (PDT) From: Neil Madden Message-Id: <694D5C42-7360-4BED-8BD8-7ADF764354AB@forgerock.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Tue, 15 Jun 2021 11:00:19 +0100 In-Reply-To: Cc: Dmitry Telegin , oauth To: Brian Campbell References: X-Mailer: Apple Mail (2.3608.120.23.2.7) Content-Type: multipart/alternative; boundary="Apple-Mail=_61DCB9BB-B5F7-45C3-90C0-2120EC56132C" Archived-At: Subject: Re: [OAUTH-WG] DPoP key rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 10:00:29 -0000 --Apple-Mail=_61DCB9BB-B5F7-45C3-90C0-2120EC56132C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On 11 Jun 2021, at 21:20, Brian Campbell wrote: >=20 > Hi Dmitry,=20 >=20 > This ML is indeed the appropriate place for this kind of thing. You raise= a legitimate question, however, the general rough consensus thinking has b= een that allowing for DPoP key rotation for refresh tokens and public clien= ts (the only case where it's relevant) didn't add enough value to justify t= he added complexity. It doesn't help with the threat model for in-browser a= pplications. And mobile applications have really good options for key stora= ge - to the point that the kind of event that might compromise a DPoP key w= ould involve a lot more than key rotation to cleanup from. =20 >=20 I think this is probably true for most current signature schemes [*], but d= oes this assumption hold for post-quantum signature algorithms? e.g., I thi= nk for some hash-based signature schemes like SPHINCS there is a trade-off = between number of signatures and signature size - so a key that can never b= e rotated may have to have larger signatures to compensate to avoid exceedi= ng usage limits. I don=E2=80=99t know enough about the state of the art of = post-quantum signatures to say if this is a real issue or if those schemes = would be appropriate for DPoP in the first place, but perhaps we should get= an opinion from CFRG before baking in this assumption? [*] There are things like repeating or biased nonces in ECDSA that can leak= the private key without the storage being compromised, but I think such bu= gs would also require more than key rotation to recover from. =E2=80=94 Neil --=20 ForgeRock values your Privacy --Apple-Mail=_61DCB9BB-B5F7-45C3-90C0-2120EC56132C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" On 11 Jun 2021, at 21:20, = Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> w= rote:

Hi Dmitry, 

This ML is in= deed the appropriate place for this kind of thing. You raise a legitimate q= uestion, however, the general rough consensus thinking has been that allowi= ng for DPoP key rotation for refresh tokens and public clients (the only ca= se where it's relevant) didn't add enough value to justify the added comple= xity. It doesn't help with the threat model for in-browser applications. An= d mobile applications have really good options for key storage - to the poi= nt that the kind of event that might compromise a DPoP key would involve a = lot more than key rotation to cleanup from.  


I think this is = probably true for most current signature schemes [*], but does this assumpt= ion hold for post-quantum signature algorithms? e.g., I think for some hash= -based signature schemes like SPHINCS there is a trade-off between number o= f signatures and signature size - so a key that can never be rotated may ha= ve to have larger signatures to compensate to avoid exceeding usage limits.= I don=E2=80=99t know enough about the state of the art of post-quantum sig= natures to say if this is a real issue or if those schemes would be appropr= iate for DPoP in the first place, but perhaps we should get an opinion from= CFRG before baking in this assumption?

[*] There are things like = repeating or biased nonces in ECDSA that can leak the private key without t= he storage being compromised, but I think such bugs would also require more= than key rotation to recover from.

=E2=80=94 Neil

ForgeRock values your Privacy --Apple-Mail=_61DCB9BB-B5F7-45C3-90C0-2120EC56132C-- From nobody Thu Jun 17 12:05:28 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BDF3A2A90 for ; Thu, 17 Jun 2021 12:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKhZcsGhdn9Q for ; Thu, 17 Jun 2021 12:05:20 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50A73A2A87 for ; Thu, 17 Jun 2021 12:05:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C3E5AF40738; Thu, 17 Jun 2021 12:04:37 -0700 (PDT) To: dick.hardt@gmail.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.s.ietf@gmail.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: danielbarclay.oss@gmail.com, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210617190437.C3E5AF40738@rfc-editor.org> Date: Thu, 17 Jun 2021 12:04:37 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (6613) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 19:05:27 -0000 The following errata report has been submitted for RFC6749, "The OAuth 2.0 Authorization Framework". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6613 -------------------------------------- Type: Editorial Reported by: Daniel Barclay Section: 3.3 Original Text ------------- The value of the scope parameter is expressed as a list of space-delimited, case-sensitive strings Corrected Text -------------- The value of the scope parameter is expressed as a space-delimited list of case-sensitive strings Notes ----- The original/current seems to be a bit confusing. The value is not a collection of space-delimited strings (whatever a "space-delimited string" would be), but it a space-delimited (representation of) a collection of strings. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Thu Jun 17 12:14:55 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D223A2AAE for ; Thu, 17 Jun 2021 12:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8YmzMx5mUJy for ; Thu, 17 Jun 2021 12:14:49 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65EDF3A2AAD for ; Thu, 17 Jun 2021 12:14:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 08AD2F40738; Thu, 17 Jun 2021 12:14:04 -0700 (PDT) To: dick.hardt@gmail.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.s.ietf@gmail.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: danielbarclay.oss@gmail.com, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210617191404.08AD2F40738@rfc-editor.org> Date: Thu, 17 Jun 2021 12:14:04 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (6614) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 19:14:54 -0000 The following errata report has been submitted for RFC6749, "The OAuth 2.0 Authorization Framework". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6614 -------------------------------------- Type: Editorial Reported by: Daniel Barclay Section: 5.1 Original Text ------------- ... adding the following parameters to the entity-body of the HTTP response ... Corrected Text -------------- ... adding the following parameters as members to the JSON object in the entity-body of the HTTP response ... Notes ----- Saying "adding the following parameters to the entity-body" seems to be confusing, implying that HTTP entity bodies have parameters (at the level of semantics defined by HTTP), which they don't. The corrected text doesn't necessarily need to be what I proposed in the "Corrected Text" field, but it should probably at least refer to the data or (JSON) object inside the entity body instead of just referring to the entity body. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Thu Jun 17 12:27:58 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0D43A2AEC for ; Thu, 17 Jun 2021 12:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuFNOHT2yBTP for ; Thu, 17 Jun 2021 12:27:52 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F0E3A2B17 for ; Thu, 17 Jun 2021 12:27:51 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id d2so10566158ljj.11 for ; Thu, 17 Jun 2021 12:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=hDR3waCMDoM4BOhmifEsnUtSV92ArrFa9sA+HaARS/o=; b=K401OKBIEl9S5kYiousuR4WJUu2W6nxlfEeRkYGsg2DVP3Tez3PaNJBVX8yTJJX0Lx JRbhY8bXq/d5DhZwkJn51HlPkvryqTZm7bLGlbTRKyXIgy4cB2i+hEJWGhaHw814RrG+ UCiTORGMc7E2ysC7PYpyaA75BfLpP8zTzZvKUtaEzqCgeSRRjGYY2oSVS8dtcSFaEgS5 93kNMRdfSEP03XeF59wHVLRR8HK1CFylmRotSMWz69732esu1oSoq7QRjfIZDj+J9Z6B CsLoY4C/ibCRRVYM0QSzOLeLdUpn4Cd11FCTTRDWld21bAmPA/0A7l8AHkGtRfEkBQ4D EINQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hDR3waCMDoM4BOhmifEsnUtSV92ArrFa9sA+HaARS/o=; b=NKoL7ukw1nRKFHN9cOvIlop/g9YdWLTXj940umBEsn6ZPiN0kSFkFzEnVz5YqYD8p3 zd9y+kiJTVL73r4I3j5JvTYi11wcaD2KVCARx+3DlEiyukaIOhGKdSbgFRz98qPj1dyk 7f106V4DpgTjNMkbnTi/oO9QUdQ56/m3k8pnttIP+W0BuBl4ihVwzKY6mALt0B/DRQs1 IRJhhdjLisC3GVnrvLWynhnIBbBTOtsagbeqia3Zgv/vyzWVgjkfedugj41bkkFCdufG mVSXXS5+1V3R7Nj6oTeQUuv4xDKcju5L3rilHloWcFMorqv70TxHvlm7R/YziI4TgWWk 9qtg== X-Gm-Message-State: AOAM531ZBqWkpTUFHrzoGJkH17ltrVmRJwGBxzY9X4VxOibxuhBuyeT3 RzMFFpuwlY4/QCZMZ7Ijkuvg6VlxupWXDPydHHEQHAS3aeQRlKyjvxhz6BPVii6FR86xPwZ9LNZ XRZGLIWm+DiowpkbD5Ie0/A== X-Google-Smtp-Source: ABdhPJw+I80NpiquosTJmXOTlDfwmjp9UnuVzsVijZTy43DFGh7PCw3UYaBqfoH2k5/aRDIkMykLE8aS5HiHxUo8tAE= X-Received: by 2002:a2e:a0c2:: with SMTP id f2mr6183845ljm.36.1623958064067; Thu, 17 Jun 2021 12:27:44 -0700 (PDT) MIME-Version: 1.0 From: Brian Campbell Date: Thu, 17 Jun 2021 13:27:18 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000008a0f9e05c4fb3338" Archived-At: Subject: [OAUTH-WG] RAR WGLC editorial feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 19:27:57 -0000 --0000000000008a0f9e05c4fb3338 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In a PR to try and make it easy https://github.com/oauthstuff/draft-oauth-rar/pull/74/files#diff-cbb16c6731= a89f7daa2f8f1963f5c005633f4273846af12926d187292cb3a66b --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000008a0f9e05c4fb3338 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000008a0f9e05c4fb3338-- From nobody Thu Jun 17 12:33:29 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F323A2B42 for ; Thu, 17 Jun 2021 12:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vdokhh6PASAW for ; Thu, 17 Jun 2021 12:33:23 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3A23A2B41 for ; Thu, 17 Jun 2021 12:33:23 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 72D8AF4073A; Thu, 17 Jun 2021 12:32:40 -0700 (PDT) To: dick.hardt@gmail.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.s.ietf@gmail.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: danielbarclay.oss@gmail.com, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210617193240.72D8AF4073A@rfc-editor.org> Date: Thu, 17 Jun 2021 12:32:40 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (6615) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 19:33:28 -0000 The following errata report has been submitted for RFC6749, "The OAuth 2.0 Authorization Framework". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6615 -------------------------------------- Type: Editorial Reported by: Daniel Barclay Section: GLOBAL Original Text ------------- Condition descriptions like "The authorization server ... validates the authorization grant, and if valid, issues an access token." Corrected Text -------------- Adjusted descriptions like "The authorization server ... validates the authorization grant, and if it is valid, issues an access token." Notes ----- The wording pattern "A validates B, and if valid, does X" means "A validates B, and if A is valid, does X" and is confusing. Those descriptions' wording should be adjusted, probably to the pattern "A validates B, and if it is valid, does X" (or whatever else actually says what was meant to be specified). There are many occurrences with literally "and if valid"; it looks (from a quick search) like most, but not all, need adjustment. There are also several cases of "and if" followed by something other than "valid"--some seem correct, but a few might need adjustment. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Jun 18 11:13:46 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90813A1D3B for ; Fri, 18 Jun 2021 11:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7qyzEGOBnEP for ; Fri, 18 Jun 2021 11:13:40 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1303A1D37 for ; Fri, 18 Jun 2021 11:13:40 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id b37so15152436ljr.13 for ; Fri, 18 Jun 2021 11:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=2BQRC93OR7RbEWwzVxpBGoJW5f3MVgnqvRPRn+jVBwU=; b=Lk5iW1X887/NtR4FvQVkqGCeKWP8nCkkAR+paWVLKGIqzwYausHI6qoBP0S/LQMzxu /32ehx44sufF9bjyf58BBZNT3MEAnCQd6Pr2k8y6xA8cn8K6N0m0lgUu70bB8Dp6rs/X wBAwbTgAmgkmXbovw6QBshdqBbJzoCXjCuc0wsFPb5+jn4PlAcUFNV7iPhKAcd5WK5iT +kJA4S5VJRxX/ARLWJaIekkpDi20rQfnCE151qaH5i+l8ytlacoioP+yaEvKErcObzq8 4hLlspqMH46K1loywWfDvyRouMYKkv2G++nuhm1JNEGrutzXw+bI6T2Orp1HyIzwJW4Q eF3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2BQRC93OR7RbEWwzVxpBGoJW5f3MVgnqvRPRn+jVBwU=; b=bGLdgnnbdUV8GK5jpWdsI+cm2TDOxhIXoCDG1ZEGJRIsxpfyMxicPvuFGmrBY4/Bac X2bR+AuWtR/eKg5CcIB8MfJau/PUYVSov9AcDBMVegjiNjaPirsJwXbPWtQKbM1cQIdu En7QNy7FBcpWXIHf3f2ORjbspZ5xRNnBQdebxdwWZAbuaa/NWgVIBFhpDIbCZe2y8bIc 2wErorCT5DMFYCA1xip7hqKSL3WMjGnrpLIOa/gQIdzvPWK/YPTlBoab6JTnC+tPlz7U ibMhCGNMenQl1UN5y8sqaO0PUeY15gHEt3+sZWO5PKrFy2uZs519mG3FVINvxw5SyeHn BKHQ== X-Gm-Message-State: AOAM531k4GCoci1EH5RyonDJH5TP/EMZYImIUi98g/l+yobcWmbSPXcG e1TuQXdPKNW8Zv0R7aj4tpoc0CBDlNqxXBJ7ia0L2htU15UlRgnc2IwBkCGprTmIQLCvUFzr8AA 3vRqljkqg/JCTuKy6TQk8mA== X-Google-Smtp-Source: ABdhPJwAwYjwyTm8OOVefxgMOaANN7NLfgZkA5Li6cLjgJBcX90VC32ILbemEKsYEMuH7bZGSIGzZzgDZbY3uaLTbl8= X-Received: by 2002:a05:651c:33c:: with SMTP id b28mr10955693ljp.489.1624040017124; Fri, 18 Jun 2021 11:13:37 -0700 (PDT) MIME-Version: 1.0 From: Brian Campbell Date: Fri, 18 Jun 2021 12:13:11 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000052829a05c50e48e7" Archived-At: Subject: [OAUTH-WG] RAR WGLC comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 18:13:45 -0000 --00000000000052829a05c50e48e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In my reading and understanding of the text and intent, the content and meaning of a particular authorization details object are fully governed by its "type". And while the draft provides a set of common data elements intended to be usable across different types (locations, actions, datatypes, identifier, privileges) a specific type is free to define whatever suits its needs. A type definition may or may not involve those common elements and could even use the same name(s) with different meaning or structure. So, while I understand the motivation behind the RFC8707 resource parameter being usable in a token request to make the AS filter, the included authorization details of the resultant token based on the "locations" element[1], I'm a bit concerned about a layering problem here. The authorization details objects of the grant might not contain a "locations" element or might have one with a different meaning or structure. The draft also describes using the authorization_details token request parameter to specify the authorization details a client wants the AS to assign to a particular access token[2]. So the problematic resource parameter behaviour is also kind of redundant. I think maybe it should be removed. [*] described in https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-6.2 and mentioned at https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-1-8 and in https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-7-1 [2] https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-token-req= uest --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000052829a05c50e48e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In my reading and understanding of the text and intent, th= e content and meaning of a particular authorization details object are full= y governed by its "type". And while the draft provides a set of c= ommon data elements intended to be usable across different types (locations= , actions, datatypes, identifier, privileges) a specific type is free to de= fine whatever suits its needs. A type definition may or may not involve tho= se common elements and could even use the same name(s) with different meani= ng or structure.

So, while I understand the motivat= ion behind the RFC8707 resource parameter being usable in a token request = to make the AS filter, the included authorization details of the resultant = token based on the "locations" element[1], I'm a bit concern= ed about a layering problem here. The authorization details objects of the = grant might not contain a "locations" element or might have one w= ith a different meaning or structure. =C2=A0

The = draft also describes using the authorization_details token request paramete= r to specify the authorization details a client wants the AS to assign to a= particular access token[2]. So the problematic resource parameter behavi= our is also kind of redundant. I think maybe it should be removed.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000052829a05c50e48e7-- From tranthuan1222543@gmail.com Fri Jun 18 14:50:27 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02E33A106F for ; Fri, 18 Jun 2021 14:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.351 X-Spam-Level: * X-Spam-Status: No, score=1.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_FUTURE_12_24=3.199, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUPuRGKjLUzd for ; Fri, 18 Jun 2021 14:50:24 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4741F3A106D for ; Fri, 18 Jun 2021 14:50:24 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id w21so703629qkb.9 for ; Fri, 18 Jun 2021 14:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=eAojUAtmcgzMKOXBREFwZFaB+i5FRtNZURwg0m5O1jM=; b=KUoYl59kLzvgHOaOX+VaFClFExh2YrUdpuXZqam0k4Dm4sHi4FafK4a337SWBq9E5D RwTl16HNC/dHtOQzShpGCJOGXnxYY0lA1t8UZe/J/13GZNN6jWqeU38tta5bTSB9VNlh DAx3koYfEh134DcJMRB9fo3a2Tpx55crNZoWhdYNXOnGQJ0f6nSNJwvHINlm3zOeyAXI 89jL8xgJoE7b+8IcY54TzpvizwsDiUEbwlC7oTPSRoHIJ6WXIzUFpvs76UPni0AwenOE STvcWy0Goy3mD82ETtITzYTqIIUpCSSYY04wj2M+4KYK2Q4Vd9FerserFhkeAk9z5CfV 1zwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eAojUAtmcgzMKOXBREFwZFaB+i5FRtNZURwg0m5O1jM=; b=CVGO/YWaKb12Afs2gOckLQS3Wcua3A1DL8HRFmASGecw7XauWWu7GJbls0qk4KPMRc 5Nwm2YaCHzNgFEI1gRT3IyKIGNwuTb76FfI+0Eu2qP3YEKdFnAUtogDr3i0e9XRQWMaV xUCLoCSSIqLCjfl0cSIbMIf95NXhyYAtQtMEQPlNuWchAIyvoI2P/EvjOOfoVjaqDoie dkHJNGV9Usah8NIguK5FXZw0eK0so4VlrM0M/zW2l+XJtZBxlCxK0nX7TjVewJ68vxUR w9dV3qPU9zJelt4Y9lPGV6DP2XUEpsBjeYshcKDDulh5fgLgdLu9JVQlZG3ASC9hKtJt WmJA== X-Gm-Message-State: AOAM533UVkDuYFHz0cm5C67NZN4LcwaiNbqDmriMsxlWqDEv5YYh46KH BEDlVN3ErURcw534NQIIcHAO7yH9KOIPXnuyA/NERKKY X-Google-Smtp-Source: ABdhPJx708QaCnZ5a+LDB6KfF0i5hdYN8Q9zg9GpyNRLB5ZRGwr6Pp/IjYWGmLW6fRE2QCGjnVNL4iAAIdMAFdB2LCY= X-Received: by 2002:a37:a58b:: with SMTP id o133mr11241299qke.418.1624053022525; Fri, 18 Jun 2021 14:50:22 -0700 (PDT) MIME-Version: 1.0 From: thuan tran Date: Sat, 19 Jun 2021 04:49:35 -0700 Message-ID: To: oauth@ietfa.amsl.com Content-Type: multipart/alternative; boundary="000000000000810d5805c5114f8a" Archived-At: Subject: [OAUTH-WG] "Re " X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 21:58:33 -0000 --000000000000810d5805c5114f8a Content-Type: text/plain; charset="UTF-8" --000000000000810d5805c5114f8a Content-Type: text/html; charset="UTF-8"

--000000000000810d5805c5114f8a-- From nobody Fri Jun 18 14:59:01 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8003A10EC for ; Fri, 18 Jun 2021 14:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.351 X-Spam-Level: * X-Spam-Status: No, score=1.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_FUTURE_12_24=3.199, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKnoir2E8ADp for ; Fri, 18 Jun 2021 14:58:49 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6159B3A110F for ; Fri, 18 Jun 2021 14:58:49 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id bj15so12785735qkb.11 for ; Fri, 18 Jun 2021 14:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=u0Cgx653cIUoxwmdWpa9bRh/zt64FkoZf6J9OhQ4yic=; b=kqjnke8bYG8GOj09ZtbRCRhX7qFvKvKclbiDGUjccx7sas/4Bs5iNqXwkAKlcqNT2x p+3QIcSNH7FKbcJRVj8n2Ci4hTASH9Un0K1A2ZHHtLELeYvidpvzERkG9hn2Twi5LdME pas7BkBUbBWXQ0K7NVgwlsu38a3B3yI4Cd858nE4n1JzSQd2yjL9YqMXLMDaJFdO9Unz GgFEGwuPvKhwBtUWcAsa79drw7rpx/vEsYCZrx1IEGloxh4/pJZwwvBZsRqzEL2qqxNQ fXwQH+eDrhEiJcOm+y1zPngQzG2EU5Tkv4CjiRCF+Fd9OmAsdncTtPShcgqepTyJsI8/ D3PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=u0Cgx653cIUoxwmdWpa9bRh/zt64FkoZf6J9OhQ4yic=; b=Gl8qTxmLXEOhX8IxbM9wtgIQ/lI3LuJGdkatILVCFKE0pny9bFrWFQPxrlDVSWCZq0 +Q1hxaYJKmD+MxWLiqxxwHCVQHq9Il0BCLpATt4cIn4Kk6p8Vk4kjnUe1hIo2nXkR/ii fjudHFcGKj7ibpOEC9hLE7qKqDKCnapLL5kUA+zTDEyQJJmvBy1HGuboZufskrf6sjP0 wRHe2MrAF2ivdvXG+2GHpj+51sBlxEgfmJ7TYJHQGeluy1fJvMUOdFCm4a2IkhVmwXaD h/dASamtF8GiASWsJx3XCV9Rgx01M3RoruYLPlzUlXC6U/tyAIxG63TfqlwXM27AQfZw uhzg== X-Gm-Message-State: AOAM533qeQym5+aQDewRzK6tNx+7nO02ytknaSRpLVgypmJDQ3B5Qaux aSVca5u1HntLFdtJDv+DN5e7ZQi+FD6ZuY9Ar4XAU4lj X-Google-Smtp-Source: ABdhPJyoVeznP+TtNX1VVHBsvMtw82Y8qLBdwiHrAtHRTKqA9irNO4MNd+Z9fp3IVeVmIrF7CnHmkU/G+jmZrqRQng4= X-Received: by 2002:a05:620a:d42:: with SMTP id o2mr11408836qkl.233.1624053524433; Fri, 18 Jun 2021 14:58:44 -0700 (PDT) MIME-Version: 1.0 From: thuan tran Date: Sat, 19 Jun 2021 04:57:57 -0700 Message-ID: To: oauth@ietfa.amsl.com Content-Type: multipart/alternative; boundary="0000000000006b8d4905c5116dc5" Archived-At: Subject: [OAUTH-WG] "Re" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 21:59:00 -0000 --0000000000006b8d4905c5116dc5 Content-Type: text/plain; charset="UTF-8" --0000000000006b8d4905c5116dc5 Content-Type: text/html; charset="UTF-8"

--0000000000006b8d4905c5116dc5-- From nobody Fri Jun 18 15:07:44 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096093A114B for ; Fri, 18 Jun 2021 15:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.351 X-Spam-Level: * X-Spam-Status: No, score=1.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_FUTURE_12_24=3.199, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL_RR0__phkZ for ; Fri, 18 Jun 2021 15:07:39 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38DC3A114A for ; Fri, 18 Jun 2021 15:07:39 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id q190so11900757qkd.2 for ; Fri, 18 Jun 2021 15:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=sinzw27K+7IhuRMKJMcLq5yZe7oU9lZMRRMlydmBZ+w=; b=r81YnSaMum6i/zoy2HmDluNHsGWyj6Eh8NYkI7+gT1o3u7Ht3Cwt5anmsSx+d5ZHOR GftC6+LfC0F9NrwYuOnsOoLCZ1LYpyIEZTtsDWqOH5wPFq9NEuaRca4ytDEzf6FL6drX bJ/XRjLRmmoQT+NK4IcT/NCw1vSgLTIJGuKPAjGKpK3r9Oi8bOvLBDoqc+nEDjmBQLwi YCar6aAjBoiQmnjg3VOSquJ6MJ4RYoYojxvCJgU6bYN6SXV6rAHoyJ5m/Qq5qAM2Tysk iXHrsrJAEaZos6kIRBCQJIi1oI3Wrsq7G5XeEJiy6DOiLnc6KtPSGCRC6Y8dMOdEQU0/ IbCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sinzw27K+7IhuRMKJMcLq5yZe7oU9lZMRRMlydmBZ+w=; b=Z3X4oUVvm8Vs4fl1sH4FjI9jeYR5eWAONVp9fCV2jAKfKLR5n3IlaTYMtsFxs9yw63 ZpO0Xl5karS3gXKh2R8SzPxapGwg+LlSJ2oSmgcPQH3WTSrVrYNAyqIJculTU4UzBKyr KTMb0RToOQIrXcqI8kAHhM0dffT9YtAo0lEkmV2bblLhJIcMyA/xlWVBUEiyORFzrsvk h6GJm5johIIz9GwNDOfuHPlLQTQ0E7aRzdOIvZ6/TgsXgZfyPyBAL+VLGl9Ik1u78nf3 Xjjt2DHW4cjc69exZT0f4Okzlo04hsgs0yiosHdnBelWLKHMwVIETbKegApyk7lCdApg tcuQ== X-Gm-Message-State: AOAM530sqewjx0DDG7LhIBpkR1jz+SoriVk0cLXi1TQ0nHuzbwgQbL/G p19LL55/4TyVGB1xGQqfZPkPJmvUnMYEEbsGRxykxhDo X-Google-Smtp-Source: ABdhPJy++Scx6N0VsRYETYKW89PECnNocFAaPK9YcJKu5YHkx03jIrfxvXz1IDBX4NkKlC2ZWZvCfpChGLBWqkKBuUI= X-Received: by 2002:a05:620a:806:: with SMTP id s6mr12020886qks.201.1624054057881; Fri, 18 Jun 2021 15:07:37 -0700 (PDT) MIME-Version: 1.0 From: thuan tran Date: Sat, 19 Jun 2021 05:06:51 -0700 Message-ID: To: oauth@ietfa.amsl.com Content-Type: multipart/alternative; boundary="00000000000037551205c5118d2b" Archived-At: Subject: [OAUTH-WG] "Re" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 22:07:41 -0000 --00000000000037551205c5118d2b Content-Type: text/plain; charset="UTF-8" --00000000000037551205c5118d2b Content-Type: text/html; charset="UTF-8"

--00000000000037551205c5118d2b-- From nobody Sat Jun 19 00:17:53 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65583A25D4 for ; Sat, 19 Jun 2021 00:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.352 X-Spam-Level: * X-Spam-Status: No, score=1.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_FUTURE_12_24=3.199, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmnzUPQZwdWU for ; Sat, 19 Jun 2021 00:17:51 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE2543A25D1 for ; Sat, 19 Jun 2021 00:17:50 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id c10so4775627qvo.9 for ; Sat, 19 Jun 2021 00:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Qn6vSJzqZ+QDB/0sm/2N7gPfOOA2iU80urmCPpeviLI=; b=iBtIYKsVDa5Jr3qkjGjA3nxndwr7Aauv6HQU+HNT6YJDP1TjG0/CyzG03iSTsnRoSC ns/WlquZT71yH9tUNR+6FGwK2rKv5jQajzLZGmmSUlxI4Zk5TQ86zNyrF1rFRO2askMJ bgELe93QMuuxhcq46+UvAzOm5Kq74OYe/ubShShHUIqrc70CykoySp5Pdxv0C3D2ZW0H 8YZtmsBR15yUG+NQFY+PySHMTrM4H9h7M++D8sITFt6RXGBfyjS8X1+rv94vE2m10fAm XQtOJSD77FufsmZ6/yhTuq+L/SzzaXl+gpnEfeOttdCY3H4981GI+o0Cz3s3lvw6cCBz 6krw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Qn6vSJzqZ+QDB/0sm/2N7gPfOOA2iU80urmCPpeviLI=; b=oqsjuPeFcI3B3v6TKcOZ7fYsJIs72678IL9zaXSSpXe4C3yxAU1P5dVHo56/OdKhwI 9kgzI3A+XU86keGNmVRqdTIqkejk87uMMj6mTf3SQrfrEIUUL2q9VkhVRn2mQ7pZDoRZ gEImTM7k0y5CiMxK2aiE94DkmW4qybGp+ef6hV+XxaCquZrvnRkvP/ZSOkz6eI+FbcTn ui/KUVMt7pJMEzo8Wxksq0s9zg7bSFFw8wjqw0hPGJA7hmf1Yc2Jy9YsxaO1Pe15TsOi m9WtTjQb21OR6x2m9EJcuj3GTY7bqnMh0155CveYW0VkS7ClZcN271vRK7d9lmRoxfig k+6w== X-Gm-Message-State: AOAM531xX4ME6ldUVXP9tcRea+j0UsQWjkY9F/6OtJ8RlVUyseTAikxe fXXvawvD5tC5gtiumu4g6Al0hIQyzJzOpFiujTraIlQq X-Google-Smtp-Source: ABdhPJwv6wT4BjBx6ZdQsfEWQTeuqJeME/zvAvaa70P4GcjqAl+LD/v6K+cCKr2PcwrOSRycZad3YuKbBsOzcHO5gto= X-Received: by 2002:a0c:d841:: with SMTP id i1mr9357718qvj.44.1624087068562; Sat, 19 Jun 2021 00:17:48 -0700 (PDT) MIME-Version: 1.0 From: thuan tran Date: Sat, 19 Jun 2021 14:17:01 -0700 Message-ID: To: oauth@ietfa.amsl.com Content-Type: multipart/alternative; boundary="000000000000ce584f05c5193cab" Archived-At: Subject: [OAUTH-WG] "Re" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2021 07:17:52 -0000 --000000000000ce584f05c5193cab Content-Type: text/plain; charset="UTF-8" --000000000000ce584f05c5193cab Content-Type: text/html; charset="UTF-8"

--000000000000ce584f05c5193cab-- From tranthuan1222543@gmail.com Fri Jun 18 14:44:38 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1083A102E for ; Fri, 18 Jun 2021 14:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.351 X-Spam-Level: * X-Spam-Status: No, score=1.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_FUTURE_12_24=3.199, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDeb9zI0wOPx for ; Fri, 18 Jun 2021 14:44:37 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668B83A102D for ; Fri, 18 Jun 2021 14:44:37 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id w26so3375367qto.13 for ; Fri, 18 Jun 2021 14:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=rLdzldfqCDxmOTDzRkUkcyfjeq8DQKD0h+pIS0W8Qr8=; b=vHZK0Hd6230+ZulL30lQtQYAzioU/8+l3obNHWIBAyRHbdRv+Bi8E6qJWIG1ydpCnt XhO7MfILnuCn1ZGFAMJA8ch5+hzCzxo+VjRKQ/QjHn8BFlLi/AUJkf90Z99QxAJJWoRt zzrkbyOlFzOaBe7NlvZVqwSgs8IesCesFoTpQYCnKIANp+uv+50/DrZdDvXNgQMTSil6 Nun+OEdJdVWKn4dMsgr8qmrJpyCFr/v0DzF6tAWuq/PNBnaiFdbmjYO1ZUUaln9AbtjH kPRDumEF1sidajOS9EZrwUOrbn8grVn3LWwHiYE//+O46smllA0+jia1Uwbs3CkDh4+A BG1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rLdzldfqCDxmOTDzRkUkcyfjeq8DQKD0h+pIS0W8Qr8=; b=O0jvIB3wxLnhjIdNG7sKckSBuCVpTcjjT6oMqOyWbmQyr8BA8YHQxUIkcmrsL6ayn0 YcoukLTdHBOG7xxpUDQ5p68xQ86dCJLnigW9CUOb4h8dAkZCBENBqEp+Zx9NQojo0Uko FwDFe+AktATUtr1fvp1JyDQ0OhKHklc6dyfTDoSm81q2a1o6RgqOgDqKhhWGMw1nyaEv 12ZmM7untWEERY+ZtGxC/SJaH0WVi1vEUPRNFHPAzbZZccx5abEMhdrEXi3H6Oz+HtMV ofl8/oT2QDPI1vIFmGxJdtwVdbJwavVS8wuVnowShrRjoSuLQc41yLhXpWPC3WcigLTj yBOw== X-Gm-Message-State: AOAM532nzx9HYTcLi/kfKvRfyDivGmve5o5W7BLCBwIJaCsEzlC+Z2Cu 5YIipp6gLPBTKZNN0Fw8zn4jvlqaPGNOKq7KUxLpyphQ X-Google-Smtp-Source: ABdhPJxPixMZzop9G/RlFe9xNDAuszxRjkZRO5DPtJPsu9EQ/AiO9O8ERuNaaP6DTZEdSK/ZP2mSlBSHQlX3JQdvMGI= X-Received: by 2002:a05:622a:c6:: with SMTP id p6mr12772605qtw.99.1624052675708; Fri, 18 Jun 2021 14:44:35 -0700 (PDT) MIME-Version: 1.0 From: thuan tran Date: Sat, 19 Jun 2021 04:43:48 -0700 Message-ID: To: oauth@ietfa.amsl.com Content-Type: multipart/alternative; boundary="000000000000d50b1c05c5113aa2" Archived-At: Subject: [OAUTH-WG] I have been browsed through facebook browser X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2021 07:23:06 -0000 --000000000000d50b1c05c5113aa2 Content-Type: text/plain; charset="UTF-8" --000000000000d50b1c05c5113aa2 Content-Type: text/html; charset="UTF-8"

--000000000000d50b1c05c5113aa2-- From nobody Sat Jun 19 00:23:36 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772393A2610 for ; Sat, 19 Jun 2021 00:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.352 X-Spam-Level: * X-Spam-Status: No, score=1.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_FUTURE_12_24=3.199, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMUEix3gGKAF for ; Sat, 19 Jun 2021 00:23:16 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E603A2607 for ; Sat, 19 Jun 2021 00:23:15 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id f70so16689950qke.13 for ; Sat, 19 Jun 2021 00:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=NRGlZLHmRxTyaU3qkXqYRo4FwpljXJLo5Vy/RtUadWM=; b=FBVYKxtK1rmIOTw78E5kYUyXp9Eg/fFk2kMkwqv8A63HWJZLEw5S7WTnxdkaSwlCpz XSivlWvf2faC40/9obJepAHb6Q8lCbn7OGw3K4YELufr5SVpo8ckv4l/e9WOOrmPfbFR 5RQPb5j2sPt35UaoQLDM/WNglEh04zG/2/FqZ6yTt7aEhfaTbM1ncjIKxN9iuEccQ93k Nxvt4QvGKbCZ8dINs0bIIyqLVTrNBl5b754vrUyMXKmdwaWI92LdjMBkAuHkEwtNBRlC gjwc152VHBroDNYRxly23XKBsK5IsuucQ5FTUSo732TxNPVbzbPEYIVM6YWlgD+1qB6k /84Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NRGlZLHmRxTyaU3qkXqYRo4FwpljXJLo5Vy/RtUadWM=; b=U34F6qxIEeCIJTEGXJluBv9QvmQ6yMThqHFYxzYHgCcFlHvExrmCzj1MMw6OzMOHEJ IUjtdA0xnAaEyu5waqZl5bdv4BUVhyhCexiJkqZ9iWHGTPujtO4U6iEDn4vGyFk6HMWz I78QXuF/KF931l48FENwfvA6CWQmW2Vh3EbaoxwkxLpSSO8PfHcivxtGg6624ADr5PFb NZNROuUJxXx4kLu0Ted6Q6/jEyN843AMzOVWs6fHcJmHNwkwiitaOgSkVYrqlOv5bQxw Kz4h8YCiHP3UG4cs4Dgauw3II/9n9FUj1wAmzZX4aXfmDokVgXejrGSeswhg9TF0snK7 fT9A== X-Gm-Message-State: AOAM533t8Me5R6OxAtlcSwwiojXKu+xSauVGistVygpWKCzbVq7tclLX L1tDobdQ9LC2mIzhPDvD1uIhhaMBok1Q2ydHbEkuMIZk X-Google-Smtp-Source: ABdhPJwqhlpL68AGVeUd2fwGZUD+GA5mn3vzpAFOlqeaneryJX30rJ8dasmTe7c6fxVzFrNjWIHUxczSdjJrTc/Za/U= X-Received: by 2002:a37:a58b:: with SMTP id o133mr12776821qke.418.1624087392847; Sat, 19 Jun 2021 00:23:12 -0700 (PDT) MIME-Version: 1.0 From: thuan tran Date: Sat, 19 Jun 2021 14:22:24 -0700 Message-ID: To: oauth@ietfa.amsl.com Content-Type: multipart/alternative; boundary="000000000000228b5a05c51950e8" Archived-At: Subject: [OAUTH-WG] "Re" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2021 07:23:33 -0000 --000000000000228b5a05c51950e8 Content-Type: text/plain; charset="UTF-8" --000000000000228b5a05c51950e8 Content-Type: text/html; charset="UTF-8"

--000000000000228b5a05c51950e8-- From nobody Sat Jun 19 06:36:29 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9103A3A0FF7 for ; Sat, 19 Jun 2021 06:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4Akt7pa2k-i for ; Sat, 19 Jun 2021 06:36:22 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A793A0FF5 for ; Sat, 19 Jun 2021 06:36:22 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id s6so12421982edu.10 for ; Sat, 19 Jun 2021 06:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=6ihmlzLvhMBcaM/Ge7I+BYn/hlP8gnmYGGVdcxwJwM0=; b=PJ2g72mYcWxF1AY3ejs6Ba25ADiab8VwathJUhTtT6QW16SUuk8eDGzNODwLa4rM0T w0z3i90swhdM8ln96kBFYCByMIEYthKcza49rjNHnFek5xt5WAV2YVdehXKvi80V2UWH VyMwqmZbVQaBgzTfXIo8+Ri5kCJxmb2QFQBEhvuqZM4drT+zEdJHC4yH0isYv55y6uNo TDxQnHbWbNsXEeLNuA/vVPPv3p3g6ubolzjrUcK/DDS6vnvHjV4gouFHUv5LdyTI3olA SLSR6DWLlqWpIyRAtMWO6LWwqMa8UvfMWxsAlzPVGJjgUtx4ol+ct/W2t87i94O2w2Ws nPeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=6ihmlzLvhMBcaM/Ge7I+BYn/hlP8gnmYGGVdcxwJwM0=; b=nMenFKBzyoOO30gK9CwRB3a0DdQxpLaBcPMWriZA1VAihJ1zoGMnCRxpkz1hTYKguw KvJ6cP45Z5PqSNote08HOXqoEK2DBnoRasu/YxpsnVUoPrxbx6cBwAMCxJuXx7HHPUGl Mk7hXq9jrxUpyqIYxutkjKn9Ggd0hmaVNP+Bxt/UIsptC6oE3a9HV10IRlVRPSGTMtKS gWn24LpUixFjqkBhYr4AKzMFHHVjGa6JZ487QKQn/9xzMQ+KkIHzL/lnpWlL+o4ftOut bZcluFsnZvvVGnmts0mpNdaCaeoPosA3UmQ//3LzbKluHw3ECXCDBqfsEwv8siruNtDV uHuw== X-Gm-Message-State: AOAM530jQwr1uFPVf0zVLGPj0ih6bC3ACGuT20tv4gRd2jrEFB158EKg k3vEN406U/erZLRZ92eolgWV+QTE4pCUmA== X-Google-Smtp-Source: ABdhPJwF1YbNE8j6Ed45ymKJNqCazgAx42JQawRVMyaINDAxYLK5ey63KuccvFXdUiVwlv6Fp34YSw== X-Received: by 2002:a05:6402:543:: with SMTP id i3mr10894260edx.173.1624109779469; Sat, 19 Jun 2021 06:36:19 -0700 (PDT) Received: from smtpclient.apple (p200300eb8f0dc7e7c9e5c8a858db0974.dip0.t-ipconnect.de. [2003:eb:8f0d:c7e7:c9e5:c8a8:58db:974]) by smtp.gmail.com with ESMTPSA id w2sm2344829ejn.118.2021.06.19.06.36.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 19 Jun 2021 06:36:19 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-AF254CED-874B-4718-B861-6B3123A3115D Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sat, 19 Jun 2021 15:36:18 +0200 Message-Id: References: Cc: oauth In-Reply-To: To: Brian Campbell X-Mailer: iPhone Mail (18F72) Archived-At: Subject: Re: [OAUTH-WG] RAR WGLC comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2021 13:36:28 -0000 --Apple-Mail-AF254CED-874B-4718-B861-6B3123A3115D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Brian, the idea was to use resource indicators as convenient short cut to support a= udience restricted access tokens. However, I agree this can be achieved by s= pecifying authorization details in the token request as well. So I=E2=80=98m fine with dropping resource indicators for RAR at all. This m= eans RAR on one hand and scopes + resource indicators on the other hand are c= learly decoupled and independent. best regards, Torsten. > Am 18.06.2021 um 20:13 schrieb Brian Campbell : >=20 > =EF=BB=BF > In my reading and understanding of the text and intent, the content and me= aning of a particular authorization details object are fully governed by its= "type". And while the draft provides a set of common data elements intended= to be usable across different types (locations, actions, datatypes, identif= ier, privileges) a specific type is free to define whatever suits its needs.= A type definition may or may not involve those common elements and could ev= en use the same name(s) with different meaning or structure.=20 >=20 > So, while I understand the motivation behind the RFC8707 resource paramete= r being usable in a token request to make the AS filter, the included author= ization details of the resultant token based on the "locations" element[1], I= 'm a bit concerned about a layering problem here. The authorization details o= bjects of the grant might not contain a "locations" element or might have on= e with a different meaning or structure. =20 >=20 > The draft also describes using the authorization_details token request par= ameter to specify the authorization details a client wants the AS to assign t= o a particular access token[2]. So the problematic resource parameter behavi= our is also kind of redundant. I think maybe it should be removed. >=20 > [*] described in https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.h= tml#section-6.2 and mentioned at https://www.ietf.org/archive/id/draft-ietf-= oauth-rar-05.html#section-1-8 and in https://www.ietf.org/archive/id/draft-i= etf-oauth-rar-05.html#section-7-1 >=20 > [2] https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-toke= n-request >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited. If you have rece= ived this communication in error, please notify the sender immediately by e-= mail and delete the message and any file attachments from your computer. Tha= nk you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oauth= &source=3Dgmail-imap&ust=3D1624644831000000&usg=3DAOvVaw1Ol8hiDotFufYe9jQCTi= 1m --Apple-Mail-AF254CED-874B-4718-B861-6B3123A3115D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

the idea was to use resource indicators as c= onvenient short cut to support audience restricted access tokens. However, I= agree this can be achieved by specifying authorization details in the token= request as well.

So I=E2=80= =98m fine with dropping resource indicators for RAR at all. This means RAR o= n one hand and scopes + resource indicators on the other hand are clearly de= coupled and independent.

be= st regards,
Torsten.

Am 18.06.2021 um 20:13 schrieb Brian Campbell <bcampbe= ll=3D40pingidentity.com@dmarc.ietf.org>:

=EF=BB=BF
In my reading= and understanding of the text and intent, the content and meaning of a part= icular authorization details object are fully governed by its "type". And wh= ile the draft provides a set of common data elements intended to be usable a= cross different types (locations, actions, datatypes, identifier, privileges= ) a specific type is free to define whatever suits its needs. A type definit= ion may or may not involve those common elements and could even use the same= name(s) with different meaning or structure.

So, wh= ile I understand the motivation behind the RFC8707 resource parameter being= usable in a token request to make the AS filter, the included authorization= details of the resultant token based on the "locations" element[1], I'm a b= it concerned about a layering problem here. The authorization details object= s of the grant might not contain a "locations" element or might have one wit= h a different meaning or structure.  

The dra= ft also describes using the authorization_details token request parameter to= specify the authorization details a client wants the AS to assign to a part= icular access token[2]. So the problematic resource parameter behaviour is= also kind of redundant. I think maybe it should be removed.
<= br>
CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited.  If y= ou have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your c= omputer. Thank you._________________________________= ______________
OAuth mailing list
OAuth@ietf= .org
https://www.google.com/url?q=3Dhttps://www.ietf.org/mai= lman/listinfo/oauth&source=3Dgmail-imap&ust=3D1624644831000000&u= sg=3DAOvVaw1Ol8hiDotFufYe9jQCTi1m
= --Apple-Mail-AF254CED-874B-4718-B861-6B3123A3115D-- From nobody Sat Jun 19 08:01:59 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136F53A133A for ; Sat, 19 Jun 2021 08:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0aaEsvchj2T for ; Sat, 19 Jun 2021 08:01:52 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721B33A1333 for ; Sat, 19 Jun 2021 08:01:52 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id i13so12640622edb.9 for ; Sat, 19 Jun 2021 08:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=As0HMn3PcQi6D87TfC3+UmhoP831/XlGaaK6VscehOc=; b=AuJoQvRhmaOXIzlPrWELuUdGThLsQfE4pZk9YjqT6+op/H2N1zLA+ffFczZ4hW/qvr sJlGgQP6FtzxiqlU1KJXNdK673sg88x+D9uCPfTaAMXcsvuZFgv86LyDh9HO2RjloZ2k c/2goq4rxz+jrJrPYTemT9KXhb7Wy+/mctYyl5oB/OEQxxmioF3iyUMWQ9T961vxAvM1 4cmRhxAd/vvsbLaVnYzu6pGemp1COcPIJSeKssn9D3/Rn2bxqvEKrINfM/FsalP0kslK CunjE7KDsTOZF4y/9y7rAg/vE8juY5iuPJ9o3SSIj24eo+FPbCI0MxWc2ttqFWI6KZG4 VPyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=As0HMn3PcQi6D87TfC3+UmhoP831/XlGaaK6VscehOc=; b=fXv1fppYftfqAaL9+hyk55mAhiTl1UEzamAjM0dZIEx5VIlb0Wr+kcSYgbJs7c7j1h c+RsNmEbKUCOlLFs2VshciGwUuYzt695B5uLfrSJsZf+BwxTrqV73WEutOgGDj80irFr Lw08y6+71bRtR0unQVSYybXtV5ZamLRjx/G+UYkuh3AEp+vpxoYpISmOZQ11kJCf7Stv oD2xpov9rmlImZw/We8EneUo1bYxgh34BLOETM0NLxWr7YyHbgZHoT9lTCXwc4Ch6bUI EPVDsQZ1Z0UD7G9m3KGEMvOSZONVoQ9kN0ZVdTEoQtLbmjUF+3X5HtD3+i9xyHzvAQ5k wzZQ== X-Gm-Message-State: AOAM5315RaFvzbyT/sxIO4mUSQSdwZObobfJqv64Ld1tiXWXvAn5kj3k CvGGSfmnkejEkML1cGiINOUEPUgt9l9X X-Google-Smtp-Source: ABdhPJxAVOgNFReqR5oPAbQi/hpjRN6P7/3hK/pnoWnCdMB/5Rh3x++u1kVwXiQbi959QcaBdb+GAw== X-Received: by 2002:a05:6402:1d17:: with SMTP id dg23mr11200142edb.128.1624114910205; Sat, 19 Jun 2021 08:01:50 -0700 (PDT) Received: from smtpclient.apple ([2a00:102a:5003:36e2:b8e5:dd52:ce2:2580]) by smtp.gmail.com with ESMTPSA id b14sm2409215ejk.120.2021.06.19.08.01.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 19 Jun 2021 08:01:49 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-6C3A7B29-DD98-4CA8-A5A1-E2C9846EAA4B Content-Transfer-Encoding: 7bit From: Filip Skokan Mime-Version: 1.0 (1.0) Date: Sat, 19 Jun 2021 17:01:47 +0200 Message-Id: References: Cc: Brian Campbell , oauth In-Reply-To: To: Torsten Lodderstedt X-Mailer: iPhone Mail (18F72) Archived-At: Subject: Re: [OAUTH-WG] RAR WGLC comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2021 15:01:57 -0000 --Apple-Mail-6C3A7B29-DD98-4CA8-A5A1-E2C9846EAA4B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I support such change. Odesl=C3=A1no z iPhonu > 19. 6. 2021 v 15:36, Torsten Lodderstedt : >=20 > =EF=BB=BF > Hi Brian, >=20 > the idea was to use resource indicators as convenient short cut to support= audience restricted access tokens. However, I agree this can be achieved by= specifying authorization details in the token request as well. >=20 > So I=E2=80=98m fine with dropping resource indicators for RAR at all. This= means RAR on one hand and scopes + resource indicators on the other hand ar= e clearly decoupled and independent. >=20 > best regards, > Torsten. >=20 >>> Am 18.06.2021 um 20:13 schrieb Brian Campbell : >>>=20 >> =EF=BB=BF >> In my reading and understanding of the text and intent, the content and m= eaning of a particular authorization details object are fully governed by it= s "type". And while the draft provides a set of common data elements intende= d to be usable across different types (locations, actions, datatypes, identi= fier, privileges) a specific type is free to define whatever suits its needs= . A type definition may or may not involve those common elements and could e= ven use the same name(s) with different meaning or structure.=20 >>=20 >> So, while I understand the motivation behind the RFC8707 resource paramet= er being usable in a token request to make the AS filter, the included autho= rization details of the resultant token based on the "locations" element[1],= I'm a bit concerned about a layering problem here. The authorization detail= s objects of the grant might not contain a "locations" element or might have= one with a different meaning or structure. =20 >>=20 >> The draft also describes using the authorization_details token request pa= rameter to specify the authorization details a client wants the AS to assign= to a particular access token[2]. So the problematic resource parameter beha= viour is also kind of redundant. I think maybe it should be removed. >>=20 >> [*] described in https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.= html#section-6.2 and mentioned at https://www.ietf.org/archive/id/draft-ietf= -oauth-rar-05.html#section-1-8 and in https://www.ietf.org/archive/id/draft-= ietf-oauth-rar-05.html#section-7-1 >>=20 >> [2] https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-tok= en-request >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you._______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oaut= h&source=3Dgmail-imap&ust=3D1624644831000000&usg=3DAOvVaw1Ol8hiDotFufYe9jQCT= i1m > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-6C3A7B29-DD98-4CA8-A5A1-E2C9846EAA4B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I support such change.

Odesl=C3=A1no z iPhonu

19. 6. 2021 v 15:36, Torsten Lodderstedt <torsten=3D40lodders= tedt.net@dmarc.ietf.org>:

=EF=BB=BF
Hi Brian,

the idea was to use resource indicators as conve= nient short cut to support audience restricted access tokens. However, I agr= ee this can be achieved by specifying authorization details in the token req= uest as well.

So I=E2=80=98= m fine with dropping resource indicators for RAR at all. This means RAR on o= ne hand and scopes + resource indicators on the other hand are clearly decou= pled and independent.

best r= egards,
Torsten.

Am 18.06.2021 um 20:13 schrieb Brian Campbell <bcampbell=3D= 40pingidentity.com@dmarc.ietf.org>:

=EF=BB=BF
In my reading and u= nderstanding of the text and intent, the content and meaning of a particular= authorization details object are fully governed by its "type". And while th= e draft provides a set of common data elements intended to be usable across d= ifferent types (locations, actions, datatypes, identifier, privileges) a spe= cific type is free to define whatever suits its needs. A type definition may= or may not involve those common elements and could even use the same name(s= ) with different meaning or structure.

So, while I u= nderstand the motivation behind the RFC8707 resource parameter being usable= in a token request to make the AS filter, the included authorization detail= s of the resultant token based on the "locations" element[1], I'm a bit con= cerned about a layering problem here. The authorization details objects of t= he grant might not contain a "locations" element or might have one with a di= fferent meaning or structure.  

The draft als= o describes using the authorization_details token request parameter to speci= fy the authorization details a client wants the AS to assign to a particular= access token[2]. So the problematic resource parameter behaviour is also k= ind of redundant. I think maybe it should be removed.

CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited.  If y= ou have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your c= omputer. Thank you._________________________________= ______________
OAuth mailing list
OAuth@ietf= .org
https://www.google.com/url?q=3Dhttps://www.ietf.org/mai= lman/listinfo/oauth&source=3Dgmail-imap&ust=3D1624644831000000&u= sg=3DAOvVaw1Ol8hiDotFufYe9jQCTi1m
_______= ________________________________________
OAuth mailing list<= /span>
OAuth@ietf.org
https://www.ietf.org/mailman/= listinfo/oauth
= --Apple-Mail-6C3A7B29-DD98-4CA8-A5A1-E2C9846EAA4B-- From nobody Sun Jun 20 02:44:11 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C35B3A0A4D for ; Sun, 20 Jun 2021 02:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.097 X-Spam-Level: X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qP_Ps6YIgZWJ for ; Sun, 20 Jun 2021 02:44:05 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4146E3A0A42 for ; Sun, 20 Jun 2021 02:44:05 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id c7so13800170edn.6 for ; Sun, 20 Jun 2021 02:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2uWOrtnEF838yU7rh3OFTih1hSU5sJI8qEfimrrRO+8=; b=fT7TwcCQohRmtpPjuYqESKP48WjBq/bcvogrImbuB9Wnit3wslKq5UZitKt3iSLD78 CAhDdfNtlo/MGXFDsOFZL9r4gmviOo85eFMGpJGCh4GkHbEnTx/rrPhjdlgtsQwQxDDN +xtf90pO3O5fTRWo1B/rwnISdQN8FHEvN1WtBeggujNQRgp15KjEufTOd6O1kE1BaCw/ DKdmKBiob0q97DzDf/594+W3CoAjYlMA9VZzyVUFUBQk9gtMP84QjS3i1K6BmxdBP/HX vTQHPWMrKSm+vk3iKFaK6ZIp21rgYmqsPKKZOzQVaJb0vurfuRlCRJjRETjzSGPn4rH1 SVAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2uWOrtnEF838yU7rh3OFTih1hSU5sJI8qEfimrrRO+8=; b=iB21P6THAydvQgmNjg4IbtJxYM2gN7mXaScbUyCqjaU5pYbQPDMaqVUW/crTOBkVGA 516h5AYHNfhbPtt+AWm2BTE2FM6WfVS3yr8Cl3yuh3BAJH+Csqk7mRrBDJ1NJyzh+u6Q FKmBpyHVPVNFxG6r3hCoaGFm+Y/zLaJYQwMfMO9MntYnJJPLTgu/Z1xTCKXRBDpU7PKK CUlOvkdV7k8j0yoEZ71uP+N7WZ1BuH6xm/PVmfOUOoEvQnTHBnn4vJ4o678pOyiWAZG+ AyyxrJbYF86ZxOg7YHYUY2sY60Mp6AWXzem1WgMy7jHUCOEfaVPPtZDEhoCxM577VUBV dx7A== X-Gm-Message-State: AOAM531atC19lZStCHcdLlWRWS0DSW33asqCOoAcP3AvMiIMTzSkJYj/ 9EUktNEwpsc6iwhn7EonwDr7s1QOKQQQFQ== X-Google-Smtp-Source: ABdhPJxWVQ+rzd6E78WsYmW67fAfDup4j9tquA5eVH2WOtZI4P2m6Km8jxh5i9NlXRPOy+H7Jn13nQ== X-Received: by 2002:aa7:c2d8:: with SMTP id m24mr7397531edp.65.1624182243009; Sun, 20 Jun 2021 02:44:03 -0700 (PDT) Received: from smtpclient.apple (p200300eb8f0dc7f0302c4efdd0b85c24.dip0.t-ipconnect.de. [2003:eb:8f0d:c7f0:302c:4efd:d0b8:5c24]) by smtp.gmail.com with ESMTPSA id r23sm4254949edy.13.2021.06.20.02.44.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Jun 2021 02:44:02 -0700 (PDT) From: Torsten Lodderstedt Message-Id: <30A1B062-4173-4FFF-BA33-43FBB61B2EF1@lodderstedt.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_089E81E8-7441-4970-8DD2-62EFAB77A617" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Sun, 20 Jun 2021 11:44:01 +0200 In-Reply-To: Cc: oauth To: Brian Campbell References: X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [OAUTH-WG] RAR WGLC editorial feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 09:44:10 -0000 --Apple-Mail=_089E81E8-7441-4970-8DD2-62EFAB77A617 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Brian. Review and approved. > Am 17.06.2021 um 21:27 schrieb Brian Campbell = : >=20 > In a PR to try and make it easy = https://github.com/oauthstuff/draft-oauth-rar/pull/74/files#diff-cbb16c673= 1a89f7daa2f8f1963f5c005633f4273846af12926d187292cb3a66b = =20 >=20 >=20 >=20 > 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._______________________________________________ > OAuth mailing list > OAuth@ietf.org > = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oauth= &source=3Dgmail-imap&ust=3D1624562884000000&usg=3DAOvVaw0FivdKy1B9S-6DJN8k= t1jJ --Apple-Mail=_089E81E8-7441-4970-8DD2-62EFAB77A617 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks Brian. Review and approved.

Am = 17.06.2021 um 21:27 schrieb Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>:
In a PR to try and make it easy https://github.com/oauthstuff/draft-oauth-rar/pull/74/files#dif= f-cbb16c6731a89f7daa2f8f1963f5c005633f4273846af12926d187292cb3a66b =



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._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/lis= tinfo/oauth&source=3Dgmail-imap&ust=3D1624562884000000&usg=3DA= OvVaw0FivdKy1B9S-6DJN8kt1jJ

= --Apple-Mail=_089E81E8-7441-4970-8DD2-62EFAB77A617-- From nobody Sun Jun 20 03:33:50 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864273A0D0B for ; Sun, 20 Jun 2021 03:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.088 X-Spam-Level: X-Spam-Status: No, score=-0.088 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iS24LMEtvdFL for ; Sun, 20 Jun 2021 03:33:43 -0700 (PDT) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8ABF3A0D07 for ; Sun, 20 Jun 2021 03:33:42 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id my49so23472449ejc.7 for ; Sun, 20 Jun 2021 03:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qNVwhcNoz+z1Z/nR6VpJk/f4ck4U7XYk4bS1cBDwpO4=; b=5fk0TLsPwQ2uQF5uMlogeK5Wlhqn+SKNft6d8TkTfP6wTOFM9rOIMszJex2X6XQbg+ zL7Wh4oXbFL2L68d+1ACS/zZV/rHubnZ57Sib/yro3sWQ+h3K84oiaS6y30rTKatTTL7 xvGLgEMTq2WrvltcevObxnTqMzTip0cuJjJh3W+Pwp6sm20J0UrCoslS3zTOg/y76mGj OZjbGzOOZ7u5aef5v6xRBdxNfe63xjYMVgjnc9oMA9FhWTB5g5nREqctN1H6obAq4mBK O8rLJ+K2hHghA6mtNMck9+GpIGfs6GD50vIA0veMCHaWn/ezkhOMeZ895patLbj1zJMz GwTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qNVwhcNoz+z1Z/nR6VpJk/f4ck4U7XYk4bS1cBDwpO4=; b=HZHHCSUFVUq8XICf0DQaki5YSS+OFH45okKS1SKdEvb2zBpKbsYu1LRwmf1AbCEKPV YYDjiOu4kgO0/azSDYk4jqHBHyviVjch1NCnwX30dhT+HNFkIS8HPH2JfD10OgoejwVh vJa69ULy6wCN4lEl42KbiO1DHsI+aT1NuIJsgcQp0OkC2gZh+51y7nUnsLiS/tZZei7D 1U9AQnnWz+630tthaPYqOkDZmQYnMJ/B5vYfpG+1HeL2ZiV1jbISc2BRLIXxj/+7z1y0 ioCFJNrA60r8wjyskajhtQyhwbYiy9yxLsKnQy/DSMqARq+aPOi7d7eYsCoGIPnH4TC7 UZiQ== X-Gm-Message-State: AOAM532FUVFAzTQDNH2GPuXwz7mrNozXhwczAH0jVXQZag5qbCaAMH2h xyTW2M5E3PjEP/hZOkqAemSB6A== X-Google-Smtp-Source: ABdhPJypxU6en7q6TVUUtBl51X0kxiauiIzfnSOc64dBLKIFQwX3j/GkZLjVBCO6hDg5qAY5FC1twQ== X-Received: by 2002:a17:906:b352:: with SMTP id cd18mr18905316ejb.222.1624185219922; Sun, 20 Jun 2021 03:33:39 -0700 (PDT) Received: from smtpclient.apple (p200300eb8f0dc7f0302c4efdd0b85c24.dip0.t-ipconnect.de. [2003:eb:8f0d:c7f0:302c:4efd:d0b8:5c24]) by smtp.gmail.com with ESMTPSA id ee47sm1838750edb.51.2021.06.20.03.33.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Jun 2021 03:33:39 -0700 (PDT) From: Torsten Lodderstedt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9E50AB98-9624-4840-A7D7-DFD9174A0927" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Sun, 20 Jun 2021 12:33:38 +0200 In-Reply-To: Cc: Rifaat Shekh-Yusef , oauth To: Dave Tonge References: X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [OAUTH-WG] WG Last Call on the RAR Document X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 10:33:49 -0000 --Apple-Mail=_9E50AB98-9624-4840-A7D7-DFD9174A0927 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Dave, thanks a lot for your review! I create a PR with the changes you proposed.=20 https://github.com/oauthstuff/draft-oauth-rar/pull/75 = Please review and comment/approve.=20 > Am 08.06.2021 um 12:33 schrieb Dave Tonge = : >=20 > Dear RAR authors >=20 > Thank you for your work on this draft - I believe it will be very = helpful to many ecosystems and am in favour of its progression. Thank you.=20 >=20 > A few nits: >=20 > Whole Document > - "payment initiation" is I think a PSD2 specific term, I'm not sure = about its use in the document, perhaps just "payment API" is sufficient? = If it is used, perhaps it needs a definition? I changed the wording and added a short explanation of the term. Please = have a look. > =20 > Introduction > - "enables the AS to mint RS-specific" - I wonder whether "mint" is a = well enough understood term? Changed it to =E2=80=9Eissue" >=20 > Section 2 > - final example in 2.1 - is the array of authorization details = supposed to be under the `resources` key? Good catch. I assume this is a remaining of the back port from GNAP. = Fixed it. >=20 > Section 3 > - Should PAR be added to 6747,8628 and CIBA in section 3? I know it = is referenced in 12.4, but I think that RAR and PAR fit very well = together and it would be better to call out earlier on in the spec ( it = is mentioned extensively in the security and privacy considerations and = so I think therefore should be mentioned earlier) I added a paragraph including references to the = security/privacy/implementation considerations. > - I suggest that mention is made in section 3 that the RO may grant a = subset of the request authorization details. This is mentioned in = section 7.1 but I feel it should be addressed in the authorization = section.=20 I added a note on that. >=20 > Section 7 > The title for section 7.1 could maybe adjusted to simply = "Authorization details in Token Response" as it deals with both = enrichment and a subset being returned. Can you please refer to text in 7.1 taking about subsets?=20 > In addition I don't think it is clear whether an AS is required to = enrich the authorization details. The statement is made >=20 > > In order to allow the client to determine the > accounts it is entitled to access, the authorization server will = add > this information to the respective authorization details object. >=20 > However a more standard approach currently is that the Client would = simply query an `/accounts` endpoint and would receive accounts to which = it has been given access to - without having to know their identifiers = up front. There could be a situation where a resource owner grants = access to all their accounts (including accounts opened in the future). = Having the AS be required to fill in the account identifiers in the = token response could be restrictive. I think this kind of enrichment is = nice, but I suggest that it be made clear that it is optional. Rephrased it to clearly point out this is _a_ design option. >=20 > Section 12 > - typo: "follwowing" -> "following" >=20 fixed.=20 best regards, Torsten.=20 > Dave >=20 >=20 >=20 >=20 > On Mon, 7 Jun 2021 at 22:19, Rifaat Shekh-Yusef = > wrote: > All, >=20 > This is to start a WG Last Call on the RAR document, that ends June = 22nd. > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-05 = >=20 > Please, review the document and provide your feedback on the mailing = list.=20 > A feedback that states that you have reviewed the document and have no = concerns would also be very helpful. >=20 > Regards, > Rifaat & Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > --=20 > Dave Tonge > CTO > = > t: +44 (0)117 280 5120 >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at fca.org.uk/register = . = Moneyhub Financial Technology is registered in England & Wales, company = registration number 06909772 . > Moneyhub Financial Technology Limited 2018 =C2=A9 >=20 > DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ = . = Moneyhub Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA.=20 >=20 > DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oauth= &source=3Dgmail-imap&ust=3D1623753262000000&usg=3DAOvVaw2EuCMd5rhjT2dwxeQn= ZXh7 --Apple-Mail=_9E50AB98-9624-4840-A7D7-DFD9174A0927 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = Dave,

thanks a lot = for your review!

I create a PR with the changes you proposed. 

https://github.com/oauthstuff/draft-oauth-rar/pull/75
=

Please review and = comment/approve. 

Am = 08.06.2021 um 12:33 schrieb Dave Tonge <dave.tonge@momentumft.co.uk>:

Dear RAR authors

Thank you for your work on = this draft - I believe it will be very helpful to many ecosystems and am = in favour of its = progression.

Thank you. 


A = few nits:

Whole = Document
 - "payment = initiation" is I think a PSD2 specific term, I'm not sure about its use = in the document, perhaps just "payment API" is sufficient? If it is = used, perhaps it needs a = definition?

I changed the wording and added a short = explanation of the term. Please have a look.

 
Introduction
- "enables the AS to mint RS-specific" - I wonder whether "mint" is a well = enough understood term?

Changed it to =E2=80=9Eissue"


Section = 2
 - final example in 2.1 - is the array of = authorization details supposed to be under the `resources` = key?

Good = catch. I assume this is a remaining of the back port from GNAP. Fixed = it.


Section = 3
 - Should PAR be added to 6747,8628 and CIBA in = section 3? I know it is referenced in 12.4, but I think that RAR and PAR = fit very well together and it would be better to call out earlier on in = the spec ( it is mentioned extensively in the security and = privacy considerations and so I think therefore should be mentioned = earlier)

I = added a paragraph including references to the = security/privacy/implementation considerations.

 - I suggest that mention is made in section 3 that = the RO may grant a subset of the request authorization details. This is = mentioned in section 7.1 but I feel it should be addressed in the = authorization = section. 

I added a note on that.


Section = 7
The title for section 7.1 could maybe adjusted to simply = "Authorization details in Token Response" as it deals with both = enrichment and a subset being = returned.

Can you please refer to text in 7.1 taking about = subsets? 

In addition I don't think it is clear whether an AS is = required to enrich the authorization details. The statement is = made

>  In = order to allow the client to determine the
  =  accounts it is entitled to access, the authorization server will = add
   this information to the respective = authorization details object.

However a more = standard approach currently is that the Client would simply query an = `/accounts` endpoint and would receive accounts to which it has been = given access to - without having to know their identifiers up = front. There could be a situation where a resource owner grants access = to all their accounts (including accounts opened in the future). Having = the AS be required to fill in the account identifiers in the token = response could be restrictive. I think this kind of enrichment is nice, = but I suggest that it be made clear that it is = optional.

Rephrased it to clearly point out this is _a_ design = option.

Section 12
 - typo: "follwowing" -> "following"


fixed. 

best = regards,
Torsten. 

Dave




On Mon, 7 = Jun 2021 at 22:19, Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:
All,

This is to start a WG Last Call = on the RAR document, that ends June = 22nd.
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-05

Please, review the document and provide = your feedback on the mailing list.
A feedback that states = that you have reviewed the document and have no concerns would also be = very helpful.

Regards,
 Rifaat & Hannes
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
Dave Tonge
CTO
3D"Moneyhub
t: +44 (0)117 280 = 5120

Moneyhub = Enterprise is a trading style of Moneyhub Financial Technology Limited = which is authorised and regulated by the Financial Conduct Authority = ("FCA"). Moneyhub Financial Technology is entered on the Financial = Services Register (FRN 809360) at fca.org.uk/register. = Moneyhub Financial Technology is registered in England & = Wales, company registration number  06909772 .
Moneyhub Financial Technology Limited 2018 =C2=A9

DISCLAIMER: This email (including any attachments) is = subject to copyright, and the information in it is confidential. Use of = this email or of any information in it other than by the addressee is = unauthorised and unlawful. Whilst reasonable efforts are made to ensure = that any attachments are virus-free, it is the recipient's sole = responsibility to scan all attachments for viruses. All calls and emails = to and from this company may be monitored and recorded for legitimate = purposes relating to this company's business. Any opinions expressed in = this email (or in any attachments) are those of the author and do not = necessarily represent the opinions of Moneyhub Financial Technology = Limited or of any other group = company.

Moneyhub = Enterprise is a trading style of Moneyhub Financial Technology Limited = which is authorised and regulated by the Financial Conduct Authority = ("FCA"). Moneyhub Financial Technology is entered on the Financial = Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial = Technology is registered in England & Wales, company registration = number 06909772. Moneyhub Financial Technology Limited 2020 =C2=A9 = Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 = 6EA. 

DISCLAIMER: This email (including = any attachments) is subject to copyright, and the information in it is = confidential. Use of this email or of any information in it other than = by the addressee is unauthorised and unlawful. Whilst reasonable efforts = are made to ensure that any attachments are virus-free, it is the = recipient's sole responsibility to scan all attachments for viruses. All = calls and emails to and from this company may be monitored and recorded = for legitimate purposes relating to this company's business. Any = opinions expressed in this email (or in any attachments) are those of = the author and do not necessarily represent the opinions of Moneyhub = Financial Technology Limited or of any other group = company.


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/lis= tinfo/oauth&source=3Dgmail-imap&ust=3D1623753262000000&usg=3DA= OvVaw2EuCMd5rhjT2dwxeQnZXh7

= --Apple-Mail=_9E50AB98-9624-4840-A7D7-DFD9174A0927-- From nobody Sun Jun 20 03:54:44 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679F83A0E1A for ; Sun, 20 Jun 2021 03:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BgmrSx5J1Y4 for ; Sun, 20 Jun 2021 03:54:37 -0700 (PDT) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91E953A0E19 for ; Sun, 20 Jun 2021 03:54:37 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id dm5so11205059ejc.9 for ; Sun, 20 Jun 2021 03:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=s75JBSREeEJnjIAaSyzJF/3YKJNN+4CaKmvMDj0JBEY=; b=wQXoE2mB8tjjA+lZ7ezrwKMZxT4/oWkUNEKlCP+KUDcOQtecr2MSV1+ByQ9QOAS+oF MGjQP1t2RT69Uba615dbQ6FWTAhf0LFSkMmByENVEPic30LaAkANKjgBiGS0nM1X8Eh7 XNjTBZxY7kC/9Iaqz1NnmCM1Av1F67gkI3/JtBD2elX+7uId1h5ugXELRADn6mA5VaLP V8M8gtADxYLBzP/TTP3wsByS51XZoogUpVWY1ml0+Q0ykxNCx3hOwFo+RdlQ4pQMsjaX /wqM9ckHF+jaycYDBmbO1oxo6FD9bJyKjgWaYP2ws05+zq4XC9HLWI1GSiAvtpWPcAn1 wOwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=s75JBSREeEJnjIAaSyzJF/3YKJNN+4CaKmvMDj0JBEY=; b=X1b+vbW0FYyBjs75wVMgK660JfPBZBgW3xJUE0NPucfcWnY4IEpy/t3XIlDw9b849u fytTmEaffOo5XhEVTYuu2BMHnhdUmw/AziTtT7w8GZSnmfL+m7TrPYmPIp+jtCnxt4jK je11VW9q/BW1fTx6xbLooSCL5+nWzwShQwlZRkH42e18FSLq61N+JBpjNKpONJkEfipw eBnUgY6EA7hxco+sMKS3vwysSDjTQ8e5bDAp6+I4ierQsrbX5356wu6+NlKnBn+P1cSG QSZgn1Io5AZ/VHwb7K4sLOde4HxSGLIzYCg8Ie/LeWU5768jWk4+lCTfAFKPZirRTw10 yTRA== X-Gm-Message-State: AOAM5336hAh6nn+87pA+jo9QGAvMHfhHHGQipSFqY0WxufTGNjiSZnPi vwZ9D25I2kX895U4EaxNUWK04g== X-Google-Smtp-Source: ABdhPJxNYtw4Vh/ALL2Ws11grE+zRb7YDMPmCL7vPDbSulfdkB19evLFc6d/e3EfohSy5P1ahj2zeA== X-Received: by 2002:a17:906:110b:: with SMTP id h11mr17454232eja.356.1624186475982; Sun, 20 Jun 2021 03:54:35 -0700 (PDT) Received: from smtpclient.apple (p200300eb8f0dc7f0302c4efdd0b85c24.dip0.t-ipconnect.de. [2003:eb:8f0d:c7f0:302c:4efd:d0b8:5c24]) by smtp.gmail.com with ESMTPSA id m18sm3443000ejx.56.2021.06.20.03.54.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Jun 2021 03:54:35 -0700 (PDT) From: Torsten Lodderstedt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_52E93BDC-D6BC-4263-87D4-91CA80A0B4C4" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Sun, 20 Jun 2021 12:54:34 +0200 In-Reply-To: Cc: Brian Campbell , oauth To: Filip Skokan References: X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [OAUTH-WG] RAR WGLC comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 10:54:42 -0000 --Apple-Mail=_52E93BDC-D6BC-4263-87D4-91CA80A0B4C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I created a PR for this change.=20 https://github.com/oauthstuff/draft-oauth-rar/pull/76 = Please review and comment/approve.=20 best regards, Torsten.=20 > Am 19.06.2021 um 17:01 schrieb Filip Skokan : >=20 > I support such change. >=20 > Odesl=C3=A1no z iPhonu >=20 >> 19. 6. 2021 v 15:36, Torsten Lodderstedt = : >>=20 >> =EF=BB=BF >> Hi Brian, >>=20 >> the idea was to use resource indicators as convenient short cut to = support audience restricted access tokens. However, I agree this can be = achieved by specifying authorization details in the token request as = well. >>=20 >> So I=E2=80=98m fine with dropping resource indicators for RAR at all. = This means RAR on one hand and scopes + resource indicators on the other = hand are clearly decoupled and independent. >>=20 >> best regards, >> Torsten. >>=20 >>> Am 18.06.2021 um 20:13 schrieb Brian Campbell = : >>>=20 >>> =EF=BB=BF >>> In my reading and understanding of the text and intent, the content = and meaning of a particular authorization details object are fully = governed by its "type". And while the draft provides a set of common = data elements intended to be usable across different types (locations, = actions, datatypes, identifier, privileges) a specific type is free to = define whatever suits its needs. A type definition may or may not = involve those common elements and could even use the same name(s) with = different meaning or structure.=20 >>>=20 >>> So, while I understand the motivation behind the RFC8707 resource = parameter being usable in a token request to make the AS filter, the = included authorization details of the resultant token based on the = "locations" element[1], I'm a bit concerned about a layering problem = here. The authorization details objects of the grant might not contain a = "locations" element or might have one with a different meaning or = structure. =20 >>>=20 >>> The draft also describes using the authorization_details token = request parameter to specify the authorization details a client wants = the AS to assign to a particular access token[2]. So the problematic = resource parameter behaviour is also kind of redundant. I think maybe it = should be removed. >>>=20 >>> [*] described in = https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-6.2 = and mentioned at = https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-1-8 = and in = https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-7-1 = >>>=20 >>> [2] = https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-token-re= quest = >>> 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._______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oauth= &source=3Dgmail-imap&ust=3D1624644831000000&usg=3DAOvVaw1Ol8hiDotFufYe9jQC= Ti1m >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_52E93BDC-D6BC-4263-87D4-91CA80A0B4C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all,

I created a PR = for this change. 

https://github.com/oauthstuff/draft-oauth-rar/pull/76
=

Please review and = comment/approve. 

best regards,
Torsten. 

Am 19.06.2021 um 17:01 schrieb Filip Skokan <panva.ip@gmail.com>:

I support such change.

Odesl=C3=A1no = z iPhonu

19. 6. 2021 v 15:36, Torsten Lodderstedt = <torsten=3D40lodderstedt.net@dmarc.ietf.org>:

=EF=BB=BF
Hi Brian,

the idea was = to use resource indicators as convenient short cut to support audience = restricted access tokens. However, I agree this can be achieved by = specifying authorization details in the token request as well.

So= I=E2=80=98m fine with dropping resource indicators for RAR at all. This = means RAR on one hand and scopes + resource indicators on the other hand = are clearly decoupled and independent.

best = regards,
Torsten.

Am = 18.06.2021 um 20:13 schrieb Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>:

=EF=BB=BF
In my reading and understanding of the text and intent, the = content and meaning of a particular authorization details object are = fully governed by its "type". And while the draft provides a set of = common data elements intended to be usable across different types = (locations, actions, datatypes, identifier, privileges) a specific type = is free to define whatever suits its needs. A type definition may or may = not involve those common elements and could even use the same name(s) = with different meaning or structure.

So, while I understand the motivation = behind the RFC8707 resource parameter being usable in a token request = to make the AS filter, the included authorization details of the = resultant token based on the "locations" element[1], I'm a bit = concerned about a layering problem here. The authorization details = objects of the grant might not contain a "locations" element or might = have one with a different meaning or structure.  

The draft also describes = using the authorization_details token request parameter to specify the = authorization details a client wants the AS to assign to a particular = access token[2]. So the problematic resource parameter behaviour is = also kind of redundant. I think maybe it should be removed.

[*] = described in https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#se= ction-6.2 and mentioned at https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#se= ction-1-8 and in https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#se= ction-7-1

[2] https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#na= me-token-request

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._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/lis= tinfo/oauth&source=3Dgmail-imap&ust=3D1624644831000000&usg=3DA= OvVaw1Ol8hiDotFufYe9jQCTi1m
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_52E93BDC-D6BC-4263-87D4-91CA80A0B4C4-- From nobody Sun Jun 20 07:58:23 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6ED23A1924; Sun, 20 Jun 2021 07:58:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <162420109776.21882.10257991600923382630@ietfa.amsl.com> Date: Sun, 20 Jun 2021 07:58:17 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 14:58:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : JWT Response for OAuth Token Introspection Authors : Torsten Lodderstedt Vladimir Dzhuvinov Filename : draft-ietf-oauth-jwt-introspection-response-11.txt Pages : 18 Date : 2021-06-20 Abstract: This specification proposes an additional JSON Web Token (JWT) secured response for OAuth 2.0 Token Introspection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 20 08:11:46 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9073A19A4; Sun, 20 Jun 2021 08:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BALPcn3QrBHk; Sun, 20 Jun 2021 08:11:40 -0700 (PDT) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55463A19A3; Sun, 20 Jun 2021 08:11:39 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id l1so24373722ejb.6; Sun, 20 Jun 2021 08:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=02J3xQyWkLIhfLdAq45Bla0OLEo1Yvd4aKBaFuX6+Ho=; b=g9ySpbJXnpHx9Q9TLcDtOuOTfqDt8qw7WmoVCWj5p7M19mrT2VvkK1IXiJwq9aPMiK D1eNjbvrdOmNixQCRomgXHAnsvF3ivUFafK33BrGoHrIp4FJAS5BIQatkr9UkxFufadW i+zEfwUW7yPvzgrX72bb6ffT4EzZC/iGd4iPv8r/MhB2fGxoJVbZiVfVcQIs6fT6xMwY m72CFVHIlojsq0pPlnXg52JOKERP39q3vfgY4BwvMNbQqPNx8bLtZeCyCrVrx/tA8C7k 1x8KAi6RDtAHms4eyniOOeGkTsKPNmZfO14b9CEJi+VkBRts6tzTaFe37JA7lLckNojd eMhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=02J3xQyWkLIhfLdAq45Bla0OLEo1Yvd4aKBaFuX6+Ho=; b=HOePwiXYzqamix/9FeywD62HDHcE8fChCUA9MOFbiVZZag9+WGQyzukMSLVYkKaTNa NbGea5a0tEwNX4s2h20uy266vLNQEZH2w8LQV79H02RCtFAIGzPnUf7LK7P+xOC3jBJt +qYMojNMxk50jZAXOm0hkdkJtSNOkINqsTER/b+uRIyNgJoRl9zc+efDT43Lxhxr2KHE dXDQhEA4DO7OLhvIMPTU60ApVy666SOfRwAZahfmBUDFHasFVZZ0pgDGojL01Wp77+mO XNlfG+GtYTZNz86Bt/c7he7fKCvO9O9OOqa8+chAMjcsTqDnXPRoIyx223G3AXXQyK0Y dGzg== X-Gm-Message-State: AOAM530U0J9Uc8op/5KmLsB8aF0mIOVtt85tRteXfxNi4lrtTO55/Z+j NRKFRNF+A/qCiJaS1HJw0SQI9QvfYiVjjwhMq4JiZai5 X-Google-Smtp-Source: ABdhPJxyU5wMaGOY8G4v+xfAYZ8a780ikezcsvxGJ4m3lj1nIVQoTErn5cxCjw7Zf1fmzXK+YBUZBHNtLhluk+hejxg= X-Received: by 2002:a17:906:dbf8:: with SMTP id yd24mr20094787ejb.160.1624201892559; Sun, 20 Jun 2021 08:11:32 -0700 (PDT) MIME-Version: 1.0 References: <162420109776.21882.10257991600923382630@ietfa.amsl.com> In-Reply-To: <162420109776.21882.10257991600923382630@ietfa.amsl.com> From: =?UTF-8?B?xJDEg25nIEjhuqNp?= Date: Sun, 20 Jun 2021 22:11:21 +0700 Message-ID: To: oauth@ietf.org Cc: i-d-announce@ietf.org Content-Type: multipart/alternative; boundary="000000000000d97dcd05c533f868" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 15:11:45 -0000 --000000000000d97dcd05c533f868 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable C=C3=A1i n=C3=A0y t=C3=B4i ko hi=E1=BB=83u mong ko g=E1=BB=ADi cho t=C3=B4i Xin c=E1=BA=A3m =C6=A1n b=E1=BA=A1n V=C3=A0o CN, 20 thg 6, 2021 l=C3=BAc 21:59 =C4= =91=C3=A3 vi=E1=BA=BFt: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IET= F. > > Title : JWT Response for OAuth Token Introspection > Authors : Torsten Lodderstedt > Vladimir Dzhuvinov > Filename : > draft-ietf-oauth-jwt-introspection-response-11.txt > Pages : 18 > Date : 2021-06-20 > > Abstract: > This specification proposes an additional JSON Web Token (JWT) > secured response for OAuth 2.0 Token Introspection. > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respo= nse/ > > There is also an htmlized version available at: > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-= response-11 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwt-introspection-re= sponse-11 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000d97dcd05c533f868 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
C=C3=A1i n=C3=A0y t=C3=B4i ko hi=E1=BB=83u mong ko g=E1= =BB=ADi cho t=C3=B4i=C2=A0
Xin c=E1=BA=A3m =C6=A1n b= =E1=BA=A1n=C2=A0

V=C3=A0o CN, 20 thg 6, 2021 l=C3=BAc 21:59 <internet-drafts@ietf.org> =C4= =91=C3=A3 vi=E1=BA=BFt:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= JWT Response for OAuth Token Introspection
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Tors= ten Lodderstedt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Vladimir Dzhuvinov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-jwt-introspection-response-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 18
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2021-06-20

Abstract:
=C2=A0 =C2=A0This specification proposes an additional JSON Web Token (JWT)=
=C2=A0 =C2=A0secured response for OAuth 2.0 Token Introspection.


The IETF datatracker status page for this draft is:
https://datatracker.iet= f.org/doc/draft-ietf-oauth-jwt-introspection-response/

There is also an htmlized version available at:
https://datatrac= ker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-11
A diff from the previous version is available at:
https://www.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-oauth-jwt-introspection-response-11


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000d97dcd05c533f868-- From nobody Mon Jun 21 03:53:59 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF7D3A2C45 for ; Mon, 21 Jun 2021 03:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.542 X-Spam-Level: ** X-Spam-Status: No, score=2.542 tagged_above=-999 required=5 tests=[DATE_IN_FUTURE_12_24=2.489, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYs_yfruWpYo for ; Mon, 21 Jun 2021 03:53:53 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28C03A2C49 for ; Mon, 21 Jun 2021 03:53:52 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id c84so10142384wme.5 for ; Mon, 21 Jun 2021 03:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=acpsc5OBotIdNY/11NnlqJKRT3bCaTfZPm8wRosAvW4=; b=VyqsUymRYNVFvfwwm1X7jeyLhuO0QMlSQZOvnKR7ZG3Lg0L/zvQ3E+ph+c/dr58gji jHSP98FDx4nHRkcYZGRKVd66mBIQPRtXdpdqkzTVZkVgilkhv+88N2JkkbYfepdhAOBt 9c8mK+FCtU0BO8ztBFh96NHCA/SoF25N8xsVLoTH3RsKB740TH6RF/IUc1lvVsUT1j1N ReQ40YaWj1ZirC6bnYAHKulkFtLFhHvJe9iZiwoqSD0NzC8CoUQQw9yQWmHiE5YS4iuM N2gcP8MmpHfWTqABLkgu5utG3aDkxcQbom0Xecfb9har36p7b+796su4zZZsggvjXQNg LgHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=acpsc5OBotIdNY/11NnlqJKRT3bCaTfZPm8wRosAvW4=; b=JGd9bknHTKumM3yA/IHckNcGJMWFA/AVrLTLq2hWRXkG+PYjaoCzGqDd8QRuj9RE4g QCfCA+imgEuzpECmW9J1Gc+3QYHjLVeglfvk3cq1g7ON9o8j3GNLjP2boBMxL66Zv3Mw vJ8tqyQ2fTg5Poo2twBtwc5IOyxUBjtkPDqlTGk8ds8nGexZv8rNkPuOJ9iMx7sQXjcu SyD3JUeIQkwga7dT7L8jfOM/dFWXmc8aeel1cXFeKBVkiCHXt/6SEndYfbhPgDrsW7xr Oobi1RCDBIA1HZDqi0aV4IM94UluRGsCOuD8mx853JIe2kKSY/sK2hcnxWDic6NbM4kN XrAw== X-Gm-Message-State: AOAM533WRqyf0et8UF2OvPmbWOBO7FAOK1+irFw+sEk4mbFwGm/xN2Is 2w3aGGdK1+FyVFaxWuyCKADwli7C8g6wgu0dGkRZ+DmW X-Google-Smtp-Source: ABdhPJyxjGIxggeanSjS4U0sLFPpsEmyve4GloBOQaajbKJ/NuEJv+Fcroj3Jce8DNdyw747yFFaFQFh8Hkzjxv04HM= X-Received: by 2002:a05:600c:3384:: with SMTP id o4mr26068138wmp.18.1624272830179; Mon, 21 Jun 2021 03:53:50 -0700 (PDT) MIME-Version: 1.0 From: thuan tran Date: Mon, 21 Jun 2021 17:53:01 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000000fad3d05c5447dd9" Archived-At: Subject: [OAUTH-WG] "Re" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 10:53:58 -0000 --0000000000000fad3d05c5447dd9 Content-Type: text/plain; charset="UTF-8" --0000000000000fad3d05c5447dd9 Content-Type: text/html; charset="UTF-8"

--0000000000000fad3d05c5447dd9-- From nobody Mon Jun 21 08:54:20 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6833A0C71 for ; Mon, 21 Jun 2021 08:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oD1XrXTiNUFG for ; Mon, 21 Jun 2021 08:54:14 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9EC43A0B8B for ; Mon, 21 Jun 2021 08:54:13 -0700 (PDT) Received: from [192.168.1.49] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 15LFsB86025116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 21 Jun 2021 11:54:11 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_30076882-BA5C-40BE-B689-EBCDBA1371F3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) Message-Id: References: <162429073469.28455.3912937829510210101@ietfa.amsl.com> To: IETF oauth WG Date: Mon, 21 Jun 2021 11:54:10 -0400 X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-httpsig-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 15:54:19 -0000 --Apple-Mail=_30076882-BA5C-40BE-B689-EBCDBA1371F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As promised at the last interim meeting, I=E2=80=99ve sat down and put = together a first strawman for PoP tokens using HTTP Message Signatures. = As you can see, it=E2=80=99s pretty short. I=E2=80=99ve intentionally = scoped it down to only pre-registered keys (unlike DPoP=E2=80=99s = dynamically presented keys), but this could change. I haven=E2=80=99t = put in the pieces for token key confirmation that would be required for = this work, which both the MTLS and DPoP drafts have. =E2=80=94 Justin > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-richer-oauth-httpsig-00.txt > Date: June 21, 2021 at 11:52:14 AM EDT > To: "Justin Richer" >=20 >=20 > A new version of I-D, draft-richer-oauth-httpsig-00.txt > has been successfully submitted by Justin Richer and posted to the > IETF repository. >=20 > Name: draft-richer-oauth-httpsig > Revision: 00 > Title: OAuth Proof of Possession Tokens with HTTP = Message Signatures > Document date: 2021-06-21 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-00.txt > Status: = https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/ > Html: = https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-00.html > Htmlized: = https://datatracker.ietf.org/doc/html/draft-richer-oauth-httpsig >=20 >=20 > Abstract: > This extension to the OAuth 2.0 authorization framework defines a > method for using HTTP Message Signatures to bind access tokens to > keys held by OAuth 2.0 clients. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_30076882-BA5C-40BE-B689-EBCDBA1371F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = promised at the last interim meeting, I=E2=80=99ve sat down and put = together a first strawman for PoP tokens using HTTP Message Signatures. = As you can see, it=E2=80=99s pretty short. I=E2=80=99ve intentionally = scoped it down to only pre-registered keys (unlike DPoP=E2=80=99s = dynamically presented keys), but this could change. I haven=E2=80=99t = put in the pieces for token key confirmation that would be required for = this work, which both the MTLS and DPoP drafts have.

 =E2=80=94 Justin

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-richer-oauth-httpsig-00.txt
Date: = June 21, 2021 at 11:52:14 AM = EDT
To: = "Justin Richer" <ietf@justin.richer.org>


A new version = of I-D, draft-richer-oauth-httpsig-00.txt
has been = successfully submitted by Justin Richer and posted to the
IETF repository.

Name: = draft-richer-oauth-httpsig
Revision: 00
Title:= = OAuth Proof of Possession Tokens with HTTP Message Signatures
Document date: 2021-06-21
Group:= = Individual Submission
Pages: 8
URL: =            https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-00.t= xt
Status: =         https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/
Html: =           https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-00.h= tml
Htmlized:       https://datatracker.ietf.org/doc/html/draft-richer-oauth-httpsi= g


Abstract:
=   This extension to the OAuth 2.0 authorization framework = defines a
  method for using HTTP Message = Signatures to bind access tokens to
  keys held = by OAuth 2.0 clients.




The IETF Secretariat



= --Apple-Mail=_30076882-BA5C-40BE-B689-EBCDBA1371F3-- From nobody Tue Jun 22 11:47:39 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3AA3A128B for ; Tue, 22 Jun 2021 11:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.998, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BprZeBQ3mdub for ; Tue, 22 Jun 2021 11:47:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324BB3A128C for ; Tue, 22 Jun 2021 11:47:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BFAFDF40817; Tue, 22 Jun 2021 11:47:26 -0700 (PDT) To: ietf@justin.richer.org, mbj@microsoft.com, ve7jtb@ve7jtb.com, maciej.machulak@gmail.com, phil.hunt@yahoo.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.s.ietf@gmail.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: disaacs@surveymonkey.com, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210622184726.BFAFDF40817@rfc-editor.org> Date: Tue, 22 Jun 2021 11:47:26 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Editorial Errata Reported] RFC7591 (6619) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 18:47:39 -0000 The following errata report has been submitted for RFC7591, "OAuth 2.0 Dynamic Client Registration Protocol". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6619 -------------------------------------- Type: Editorial Reported by: Dave Isaacs Section: 2 Original Text ------------- token_endpoint_auth_method String indicator of the requested authentication method for the token endpoint. Values defined by this specification are: * "none": The client is a public client as defined in OAuth 2.0, Section 2.1, and does not have a client secret. * "client_secret_post": The client uses the HTTP POST parameters as defined in OAuth 2.0, Section 2.3.1. * "client_secret_basic": The client uses HTTP Basic as defined in OAuth 2.0, Section 2.3.1. Corrected Text -------------- Text unchanged. It is the links that are incorrect. Notes ----- The links that are present in each bullet—to Section 2.1, and to Section 2.3.1 (twice)—link internally to the current RFC (RFC 7591) when they are supposed to link to the OAuth 2.0 RFC (RFC 6749). Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7591 (draft-ietf-oauth-dyn-reg-30) -------------------------------------- Title : OAuth 2.0 Dynamic Client Registration Protocol Publication Date : July 2015 Author(s) : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Jun 22 16:03:50 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027A73A1E1B for ; Tue, 22 Jun 2021 16:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKeiKnhRu8ff for ; Tue, 22 Jun 2021 16:03:42 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2BE3A1E18 for ; Tue, 22 Jun 2021 16:03:42 -0700 (PDT) Received: (qmail 46485 invoked from network); 22 Jun 2021 23:03:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=b593.60d26c4c.k2106; bh=AQXVc2oZFaIBJWt3y8UGkACBe7V7bk+YqVtVn17CQ0Q=; b=qwlPHXMYuHdJl6YT9xs1qhIGAMKRjDwkv1HkRmuZ/OdaQab6+5Qay6SM4uqiFXzhyR3MdKaWhd2z/TQjdlDqwk6bot27xchCv7dVxgZa5KDySFQA9hVxlH/HBqyAjyrASYEpQlWWgIGidO+by9wzF4WLoaE5GoV5ZfSt50g9mR4Ter1NhHrFVkRqq4wixQ5Ie5lAUMenTztI8D2oahnVge0Xj+2KY0e3WPwFvFilk/WNAuDirYyBrnfB6Q7ING29ip+r+XwHbQ4Iqa4705AXTpjGeZ8zWHOa4tr0FDPcBAboVhQjm8S1N28ZKsX4rH4WO1qHviQODFj5/TSJhf59cw== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 22 Jun 2021 23:03:40 -0000 Received: by ary.qy (Postfix, from userid 501) id A55A31626FC4; Tue, 22 Jun 2021 19:03:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 63CFE1626F9E; Tue, 22 Jun 2021 19:03:38 -0400 (EDT) Date: 22 Jun 2021 19:03:38 -0400 Message-ID: From: "John R. Levine" To: "RFC Errata System" , ietf@justin.richer.org, mbj@microsoft.com, ve7jtb@ve7jtb.com, maciej.machulak@gmail.com, phil.hunt@yahoo.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.s.ietf@gmail.com Cc: disaacs@surveymonkey.com, oauth@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: <20210622184726.BFAFDF40817@rfc-editor.org> References: <20210622184726.BFAFDF40817@rfc-editor.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1868618613-1624403018=:15964" Archived-At: Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC7591 (6619) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 23:03:48 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1868618613-1624403018=:15964 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Htmlized legacy RFCs are created by a script that uses heuristics to add formatting to the canonical text document. One of the limitations of the script is that it does not know when a section link is to another document. For RFCs published since we switched to XML v3 two years ago, the HTML is created directly from the XML and the links are correct. Since the underlying RFC is correct and currrent RFCs don't have the problem we're not planning to try to fix it. Regards, John Levine, temporary RFC series manager On Tue, 22 Jun 2021, RFC Errata System wrote: > The following errata report has been submitted for RFC7591, > "OAuth 2.0 Dynamic Client Registration Protocol". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6619 > > -------------------------------------- > Type: Editorial > Reported by: Dave Isaacs > > Section: 2 > > Original Text > ------------- > token_endpoint_auth_method > String indicator of the requested authentication method for the > token endpoint. Values defined by this specification are: > > * "none": The client is a public client as defined in OAuth 2.0, > Section 2.1, and does not have a client secret. > > * "client_secret_post": The client uses the HTTP POST parameters > as defined in OAuth 2.0, Section 2.3.1. > > * "client_secret_basic": The client uses HTTP Basic as defined in > OAuth 2.0, Section 2.3.1. > > Corrected Text > -------------- > Text unchanged. It is the links that are incorrect. > > Notes > ----- > The links that are present in each bullet—to Section 2.1, and to Section 2.3.1 (twice)—link internally to the current RFC (RFC 7591) when they are supposed to link to the OAuth 2.0 RFC (RFC 6749). > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7591 (draft-ietf-oauth-dyn-reg-30) > -------------------------------------- > Title : OAuth 2.0 Dynamic Client Registration Protocol > Publication Date : July 2015 > Author(s) : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG > > Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly --0-1868618613-1624403018=:15964-- From nobody Tue Jun 22 17:01:47 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CF93A2032 for ; Tue, 22 Jun 2021 17:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sb_oeCzWOrON for ; Tue, 22 Jun 2021 17:01:40 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E75D3A202D for ; Tue, 22 Jun 2021 17:01:40 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 15N01OcT003184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Jun 2021 20:01:30 -0400 Date: Tue, 22 Jun 2021 17:01:24 -0700 From: Benjamin Kaduk To: RFC Errata System Cc: dick.hardt@gmail.com, rdd@cert.org, Hannes.Tschofenig@gmx.net, rifaat.s.ietf@gmail.com, danielbarclay.oss@gmail.com, oauth@ietf.org Message-ID: <20210623000124.GJ11634@kduck.mit.edu> References: <20210617190437.C3E5AF40738@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210617190437.C3E5AF40738@rfc-editor.org> Archived-At: Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (6613) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 00:01:46 -0000 This looks correct to me; could the authors/WG please confirm? Thanks, Ben On Thu, Jun 17, 2021 at 12:04:37PM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC6749, > "The OAuth 2.0 Authorization Framework". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6613 > > -------------------------------------- > Type: Editorial > Reported by: Daniel Barclay > > Section: 3.3 > > Original Text > ------------- > The value of the scope parameter is expressed as a list of space-delimited, case-sensitive strings > > Corrected Text > -------------- > The value of the scope parameter is expressed as a space-delimited list of case-sensitive strings > > Notes > ----- > The original/current seems to be a bit confusing. > > The value is not a collection of space-delimited strings (whatever a "space-delimited string" would be), but it a space-delimited (representation of) a collection of strings. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6749 (draft-ietf-oauth-v2-31) > -------------------------------------- > Title : The OAuth 2.0 Authorization Framework > Publication Date : October 2012 > Author(s) : D. Hardt, Ed. > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG From nobody Tue Jun 22 21:48:34 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813C03A28E7; Tue, 22 Jun 2021 21:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.998, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYiRydy6WxmW; Tue, 22 Jun 2021 21:48:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1684F3A28E4; Tue, 22 Jun 2021 21:48:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 37AF0F407FE; Tue, 22 Jun 2021 21:48:19 -0700 (PDT) To: disaacs@surveymonkey.com, ietf@justin.richer.org, mbj@microsoft.com, ve7jtb@ve7jtb.com, maciej.machulak@gmail.com, phil.hunt@yahoo.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: kaduk@mit.edu, iesg@ietf.org, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210623044819.37AF0F407FE@rfc-editor.org> Date: Tue, 22 Jun 2021 21:48:19 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Errata Rejected] RFC7591 (6619) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 04:48:30 -0000 The following errata report has been rejected for RFC7591, "OAuth 2.0 Dynamic Client Registration Protocol". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6619 -------------------------------------- Status: Rejected Type: Editorial Reported by: Dave Isaacs Date Reported: 2021-06-22 Rejected by: Benjamin Kaduk (IESG) Section: 2 Original Text ------------- token_endpoint_auth_method String indicator of the requested authentication method for the token endpoint. Values defined by this specification are: * "none": The client is a public client as defined in OAuth 2.0, Section 2.1, and does not have a client secret. * "client_secret_post": The client uses the HTTP POST parameters as defined in OAuth 2.0, Section 2.3.1. * "client_secret_basic": The client uses HTTP Basic as defined in OAuth 2.0, Section 2.3.1. Corrected Text -------------- Text unchanged. It is the links that are incorrect. Notes ----- The links that are present in each bullet—to Section 2.1, and to Section 2.3.1 (twice)—link internally to the current RFC (RFC 7591) when they are supposed to link to the OAuth 2.0 RFC (RFC 6749). --VERIFIER NOTES-- Errata reports are for the official version(s) of the document as published by the RFC Editor. Prior to RFC 8650 the official version is the plain text copy; the html version with links is the result of running a script over the text copy, and so the "wrong link" here is more properly a bug in the script than an error in the RFC. -------------------------------------- RFC7591 (draft-ietf-oauth-dyn-reg-30) -------------------------------------- Title : OAuth 2.0 Dynamic Client Registration Protocol Publication Date : July 2015 Author(s) : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Jun 22 21:49:13 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2313A28EA for ; Tue, 22 Jun 2021 21:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDMdBDs6jijJ for ; Tue, 22 Jun 2021 21:49:07 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C313A28EB for ; Tue, 22 Jun 2021 21:49:07 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 15N4moHD009216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Jun 2021 00:48:54 -0400 Date: Tue, 22 Jun 2021 21:48:49 -0700 From: Benjamin Kaduk To: Dave Isaacs Cc: "John R. Levine" , RFC Errata System , "ietf@justin.richer.org" , "mbj@microsoft.com" , "ve7jtb@ve7jtb.com" , "maciej.machulak@gmail.com" , "phil.hunt@yahoo.com" , "rdd@cert.org" , "Hannes.Tschofenig@gmx.net" , "rifaat.s.ietf@gmail.com" , "oauth@ietf.org" Message-ID: <20210623044849.GQ11634@kduck.mit.edu> References: <20210622184726.BFAFDF40817@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC7591 (6619) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 04:49:12 -0000 On Wed, Jun 23, 2021 at 12:04:47AM +0000, Dave Isaacs wrote: > Fair enough, I guess. The HTML versions of the older RFCs must be peppered with bad links if this is the case. Yes, that is true, and we get some periodic errata reports of this nature as well. I marked this report as rejected per the policy that John described. > It is interesting to note that there is a correct link to RFC 6749 in the paragraph immediately before the one I quoted. Given what you have said, I am going to take a wild guess that replacing “OAuth 2.0, Section 2.1” with “Section 2.1 of OAuth 2.0 [RFC6749]” would fix the issue. IIRC it would have to be "Section 2.1 of [RFC6749]" (with no title of the referenced RFC). -Ben > > Dave I > > > From: John R. Levine > Date: Tuesday, June 22, 2021 at 7:03 PM > To: RFC Errata System , ietf@justin.richer.org , mbj@microsoft.com , ve7jtb@ve7jtb.com , maciej.machulak@gmail.com , phil.hunt@yahoo.com , rdd@cert.org , kaduk@mit.edu , Hannes.Tschofenig@gmx.net , rifaat.s.ietf@gmail.com > Cc: Dave Isaacs , oauth@ietf.org > Subject: Re: [Editorial Errata Reported] RFC7591 (6619) > Htmlized legacy RFCs are created by a script that uses heuristics to add > formatting to the canonical text document. One of the limitations of the > script is that it does not know when a section link is to another > document. > > For RFCs published since we switched to XML v3 two years ago, the HTML is > created directly from the XML and the links are correct. > > Since the underlying RFC is correct and currrent RFCs don't have the > problem we're not planning to try to fix it. > > Regards, > John Levine, temporary RFC series manager > > On Tue, 22 Jun 2021, RFC Errata System wrote: > > > The following errata report has been submitted for RFC7591, > > "OAuth 2.0 Dynamic Client Registration Protocol". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6619 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Dave Isaacs > > > > Section: 2 > > > > Original Text > > ------------- > > token_endpoint_auth_method > > String indicator of the requested authentication method for the > > token endpoint. Values defined by this specification are: > > > > * "none": The client is a public client as defined in OAuth 2.0, > > Section 2.1, and does not have a client secret. > > > > * "client_secret_post": The client uses the HTTP POST parameters > > as defined in OAuth 2.0, Section 2.3.1. > > > > * "client_secret_basic": The client uses HTTP Basic as defined in > > OAuth 2.0, Section 2.3.1. > > > > Corrected Text > > -------------- > > Text unchanged. It is the links that are incorrect. > > > > Notes > > ----- > > The links that are present in each bullet—to Section 2.1, and to Section 2.3.1 (twice)—link internally to the current RFC (RFC 7591) when they are supposed to link to the OAuth 2.0 RFC (RFC 6749). > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC7591 (draft-ietf-oauth-dyn-reg-30) > > -------------------------------------- > > Title : OAuth 2.0 Dynamic Client Registration Protocol > > Publication Date : July 2015 > > Author(s) : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt > > Category : PROPOSED STANDARD > > Source : Web Authorization Protocol > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > > > > Regards, > John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > Have you heard? SurveyMonkey (SVMK Inc.) is now Momentive. Learn more at momentive.ai From nobody Wed Jun 23 10:58:27 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EBB3A07CA for ; Wed, 23 Jun 2021 10:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icEyl29sRx3E for ; Wed, 23 Jun 2021 10:58:20 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E745C3A07CF for ; Wed, 23 Jun 2021 10:58:19 -0700 (PDT) Received: (qmail 34132 invoked from network); 23 Jun 2021 17:58:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=8551.60d3763a.k2106; bh=buYfV4fboXc5wpNZ4IXTzL+JgektupIlrh4hvjcd4+Y=; b=0PhbuPDvRQhqprMWMT4I3grc5YrcKttg9t2yMo8OS9rBJwgLUmjuPcd2SMeWMGGbvNTfGVNhN55yk20XHhqYxi9HVx6lGh/Mgid1s6ClBJW34815vTnxpZM+Oi5hfYELYz7w3wYmptG54i3ovcF7cZCLB3IgCX8cxx+lvk9ssJq2TmcdO4fecpJ7U/5F/uYo69pYuf754UBpGIdIMKaaXlkI2sf79HA+VxeKN18zPX8B4GIL572cGSHNtWk6BjRf8JLbvzfDdewDYDFcqqbLkUPQVtNad8LOb1oiuif7DRH5GGZ91/G8TUPlCe4p+v23AcZ6jtdT0wDELGgGgt71TA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 23 Jun 2021 17:58:18 -0000 Received: by ary.qy (Postfix, from userid 501) id B85D61680D56; Wed, 23 Jun 2021 13:58:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 787E31680D2A; Wed, 23 Jun 2021 13:58:16 -0400 (EDT) Date: 23 Jun 2021 13:58:16 -0400 Message-ID: <0ca4ba3-9115-11a6-125-50771b4bb90@iecc.com> From: "John R. Levine" To: "Dave Isaacs" , "RFC Errata System" , "ietf@justin.richer.org" , "mbj@microsoft.com" , "ve7jtb@ve7jtb.com" , "maciej.machulak@gmail.com" , "phil.hunt@yahoo.com" , "rdd@cert.org" , "kaduk@mit.edu" , "Hannes.Tschofenig@gmx.net" , "rifaat.s.ietf@gmail.com" Cc: "oauth@ietf.org" X-X-Sender: johnl@ary.qy In-Reply-To: References: <20210622184726.BFAFDF40817@rfc-editor.org>, MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1145561358-1624471096=:19998" Archived-At: Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC7591 (6619) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 17:58:26 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1145561358-1624471096=:19998 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > Fair enough, I guess. The HTML versions of the older RFCs must be peppered with bad links if this is the case. Yes, we've gotten a steady trickle of reports like this. The htmlizing script is available if someone wants to play with it but I think we're already in the region of diminishing returns, and I don't think there's any appetite to manually create exception lists for the links point in old RFCs. R's, John > > From: John R. Levine > Date: Tuesday, June 22, 2021 at 7:03 PM > To: RFC Errata System , ietf@justin.richer.org , mbj@microsoft.com , ve7jtb@ve7jtb.com , maciej.machulak@gmail.com , phil.hunt@yahoo.com , rdd@cert.org , kaduk@mit.edu , Hannes.Tschofenig@gmx.net , rifaat.s.ietf@gmail.com > Cc: Dave Isaacs , oauth@ietf.org > Subject: Re: [Editorial Errata Reported] RFC7591 (6619) > Htmlized legacy RFCs are created by a script that uses heuristics to add > formatting to the canonical text document. One of the limitations of the > script is that it does not know when a section link is to another > document. > > For RFCs published since we switched to XML v3 two years ago, the HTML is > created directly from the XML and the links are correct. > > Since the underlying RFC is correct and currrent RFCs don't have the > problem we're not planning to try to fix it. > > Regards, > John Levine, temporary RFC series manager > > On Tue, 22 Jun 2021, RFC Errata System wrote: > >> The following errata report has been submitted for RFC7591, >> "OAuth 2.0 Dynamic Client Registration Protocol". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid6619 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Dave Isaacs >> >> Section: 2 >> >> Original Text >> ------------- >> token_endpoint_auth_method >> String indicator of the requested authentication method for the >> token endpoint. Values defined by this specification are: >> >> * "none": The client is a public client as defined in OAuth 2.0, >> Section 2.1, and does not have a client secret. >> >> * "client_secret_post": The client uses the HTTP POST parameters >> as defined in OAuth 2.0, Section 2.3.1. >> >> * "client_secret_basic": The client uses HTTP Basic as defined in >> OAuth 2.0, Section 2.3.1. >> >> Corrected Text >> -------------- >> Text unchanged. It is the links that are incorrect. >> >> Notes >> ----- >> The links that are present in each bullet—to Section 2.1, and to Section 2.3.1 (twice)—link internally to the current RFC (RFC 7591) when they are supposed to link to the OAuth 2.0 RFC (RFC 6749). >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC7591 (draft-ietf-oauth-dyn-reg-30) >> -------------------------------------- >> Title : OAuth 2.0 Dynamic Client Registration Protocol >> Publication Date : July 2015 >> Author(s) : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt >> Category : PROPOSED STANDARD >> Source : Web Authorization Protocol >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> >> > > Regards, > John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > Have you heard? SurveyMonkey (SVMK Inc.) is now Momentive. Learn more at momentive.ai > Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly --0-1145561358-1624471096=:19998-- From nobody Wed Jun 23 11:14:49 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 697A73A0954; Wed, 23 Jun 2021 11:14:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwt-introspection-response@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Rifaat Shekh-Yusef , rifaat.s.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <162447208286.21677.10494308416979645858@ietfa.amsl.com> Date: Wed, 23 Jun 2021 11:14:43 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwt-introspection-response-11: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 18:14:44 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss (and Comment) points! Just a couple final notes on the -11: Section 4 Please double-check that describing the resource server as "authenticating with a private-key JWT" is compatible with using the urn:ietf;params:oauth:client-assertion-type:jwt-bearer assertion type. I am not up-to-date on the precise semantics of that assertion type, offhand. Section 5 Token introspection response parameter names intended to be used across domains SHOULD be registered in the OAuth Token Introspection Response registry [IANA.OAuth.Token.Introspection] defined by [RFC7662]. I'm a bit surprised to see any normative terminology used on the question of whether response parameter names are to be registered, since RFC 7662 already has a requirement ("MUST") for this scenario. If the intent truly is to weaken the requirement from RFC 7662, it seems that some additional clarification is in order that this is a change from the existing specification and why it is a desirable change. (The "MAY extend the token introspection response" in the preceding paragraph, not quoted, is also already present in RFC 7662.) From nobody Wed Jun 23 13:30:39 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536DA3A3F7E; Wed, 23 Jun 2021 13:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohtGXRi1yTnE; Wed, 23 Jun 2021 13:30:28 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0214C3A3F7B; Wed, 23 Jun 2021 13:30:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C6F8F389ED2; Wed, 23 Jun 2021 13:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sggMX15ABPJz; Wed, 23 Jun 2021 13:30:27 -0700 (PDT) Received: from [192.168.68.110] (pool-173-48-33-241.bstnma.fios.verizon.net [173.48.33.241]) by c8a.amsl.com (Postfix) with ESMTPSA id D9A86389ECC; Wed, 23 Jun 2021 13:30:26 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Megan Ferguson In-Reply-To: <20210623044819.37AF0F407FE@rfc-editor.org> Date: Wed, 23 Jun 2021 16:30:25 -0400 Cc: disaacs@surveymonkey.com, ietf@justin.richer.org, mbj@microsoft.com, ve7jtb@ve7jtb.com, maciej.machulak@gmail.com, phil.hunt@yahoo.com, oauth@ietf.org, kaduk@mit.edu, iesg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <976EB106-F26F-4EBB-9247-4F731A99C098@amsl.com> References: <20210623044819.37AF0F407FE@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [OAUTH-WG] [Errata Rejected] RFC7591 (6619) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 20:30:32 -0000 Greetings, FYI - this report has been deleted. A copy has been forwarded to = webmaster@tools.ietf.org. Thank you. RFC Editor/mf > On Jun 23, 2021, at 12:48 AM, RFC Errata System = wrote: >=20 > The following errata report has been rejected for RFC7591, > "OAuth 2.0 Dynamic Client Registration Protocol". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6619 >=20 > -------------------------------------- > Status: Rejected > Type: Editorial >=20 > Reported by: Dave Isaacs > Date Reported: 2021-06-22 > Rejected by: Benjamin Kaduk (IESG) >=20 > Section: 2 >=20 > Original Text > ------------- > token_endpoint_auth_method > String indicator of the requested authentication method for the > token endpoint. Values defined by this specification are: >=20 > * "none": The client is a public client as defined in OAuth 2.0, > Section 2.1, and does not have a client secret. >=20 > * "client_secret_post": The client uses the HTTP POST parameters > as defined in OAuth 2.0, Section 2.3.1. >=20 > * "client_secret_basic": The client uses HTTP Basic as defined = in > OAuth 2.0, Section 2.3.1. >=20 > Corrected Text > -------------- > Text unchanged. It is the links that are incorrect. >=20 > Notes > ----- > The links that are present in each bullet=E2=80=94to Section 2.1, and = to Section 2.3.1 (twice)=E2=80=94link internally to the current RFC (RFC = 7591) when they are supposed to link to the OAuth 2.0 RFC (RFC 6749). > --VERIFIER NOTES--=20 > Errata reports are for the official version(s) of the document as = published by the RFC Editor. Prior to RFC 8650 the official version is = the plain text copy; the html version with links is the result of = running a script over the text copy, and so the "wrong link" here is = more properly a bug in the script than an error in the RFC. >=20 > -------------------------------------- > RFC7591 (draft-ietf-oauth-dyn-reg-30) > -------------------------------------- > Title : OAuth 2.0 Dynamic Client Registration Protocol > Publication Date : July 2015 > Author(s) : J. Richer, Ed., M. Jones, J. Bradley, M. = Machulak, P. Hunt > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG >=20 From nobody Wed Jun 23 14:12:07 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7F83A409D; Wed, 23 Jun 2021 14:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9bLhmkaoDaC; Wed, 23 Jun 2021 14:12:00 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE39E3A409A; Wed, 23 Jun 2021 14:11:59 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id 17so3974939ill.6; Wed, 23 Jun 2021 14:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dl4PZqKYwt9jl0LXgyIc3oXvsidpcPdPBbregfneWhA=; b=aO937jFWpKtSn2SRsliisRZvkcNQ3oVpeLBQLPHCCwlKjGtDJEIP57/p0gNY6muKJL H0qIX1kghjNDUTdW/h8fqscq5wFWU6cZfWR5P5gJpiVFz15zgF42MGSZFDPOEAL27zFq 3+eyJMh0M1AKuF+aQLxahnRpsOzy4f6BKEvXG4onTjCJ32wpTHhV/kMWbjHwDZzGxuN8 w1Mp+Dwxagddk3ZKez9iW5k735hjXmvmZ4Mklgq/FTbHVWfGYi0QLo4x8r+OuofPWcFt U4SmOL9CrzXAVZ4TT26MDHz8qbDVKsQbzHqvuV1tec7o7ULbjOw9rgBBZAUaXlji8QkM VC1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dl4PZqKYwt9jl0LXgyIc3oXvsidpcPdPBbregfneWhA=; b=ANC8bxHqiyOMLzVDuMtVH6PuR/C5h+FmCyfgbEtp+w5VpNOWYH4VBPBHYOP+ItBSY0 H56UMVWQuv6ObNUbhfj/Z1hFGA1OejwZdCSP6fC1zmoj0UPSJe1DUW8Q8YveHnPO0Hvu 3b80as8ugO01Avy8AQU/VKX4GjcKSaTdTwfa0nfVPnAIVZrJ4TZUVKzVxoiWhHHGJEvI ABBmw8Z99WHHU+pDhjMMpDAxk+ngPqRmSArRVQFrvBokwDIbO7jvZeVS2EDHUaH4pr3/ P4BtudBIPDOnkCr9BxlggRKs0R7wwpC+paCXtlRkNiw2FG9itYSzMh7oyU073TDJ38Jb s3AA== X-Gm-Message-State: AOAM532e/aOFRW0SULLuSEDIxepJMcb0V8jJm2jBoRrOs57Am2142q7v ukAfpRy0a80hGtKBNGWyqUqYYKejdtJ1zIIGlKc= X-Google-Smtp-Source: ABdhPJx2eHwa1VU+zL0ohRvHMaDNsfobgC6ldz3mbmHD25GdplMFQyyCoJS73IyqZYiqJKExHQ6zKL6YezjmxgRXe6k= X-Received: by 2002:a05:6e02:1a0c:: with SMTP id s12mr1038488ild.52.1624482718298; Wed, 23 Jun 2021 14:11:58 -0700 (PDT) MIME-Version: 1.0 References: <20210623044819.37AF0F407FE@rfc-editor.org> In-Reply-To: <20210623044819.37AF0F407FE@rfc-editor.org> From: Hony Habesha Date: Thu, 24 Jun 2021 00:11:42 +0300 Message-ID: To: RFC Errata System Cc: disaacs@surveymonkey.com, ietf@justin.richer.org, mbj@microsoft.com, John Bradley , maciej.machulak@gmail.com, phil.hunt@yahoo.com, oauth@ietf.org, iesg@ietf.org Content-Type: multipart/alternative; boundary="0000000000005e39fd05c5755bda" Archived-At: Subject: Re: [OAUTH-WG] [Errata Rejected] RFC7591 (6619) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 21:12:05 -0000 --0000000000005e39fd05c5755bda Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What is this please tell me ? On Wed, 23 Jun 2021, 07:49 RFC Errata System, wrote: > The following errata report has been rejected for RFC7591, > "OAuth 2.0 Dynamic Client Registration Protocol". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6619 > > -------------------------------------- > Status: Rejected > Type: Editorial > > Reported by: Dave Isaacs > Date Reported: 2021-06-22 > Rejected by: Benjamin Kaduk (IESG) > > Section: 2 > > Original Text > ------------- > token_endpoint_auth_method > String indicator of the requested authentication method for the > token endpoint. Values defined by this specification are: > > * "none": The client is a public client as defined in OAuth 2.0, > Section 2.1, and does not have a client secret. > > * "client_secret_post": The client uses the HTTP POST parameters > as defined in OAuth 2.0, Section 2.3.1. > > * "client_secret_basic": The client uses HTTP Basic as defined in > OAuth 2.0, Section 2.3.1. > > Corrected Text > -------------- > Text unchanged. It is the links that are incorrect. > > Notes > ----- > The links that are present in each bullet=E2=80=94to Section 2.1, and to = Section > 2.3.1 (twice)=E2=80=94link internally to the current RFC (RFC 7591) when = they are > supposed to link to the OAuth 2.0 RFC (RFC 6749). > --VERIFIER NOTES-- > Errata reports are for the official version(s) of the document as > published by the RFC Editor. Prior to RFC 8650 the official version is t= he > plain text copy; the html version with links is the result of running a > script over the text copy, and so the "wrong link" here is more properly = a > bug in the script than an error in the RFC. > > -------------------------------------- > RFC7591 (draft-ietf-oauth-dyn-reg-30) > -------------------------------------- > Title : OAuth 2.0 Dynamic Client Registration Protocol > Publication Date : July 2015 > Author(s) : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, > P. Hunt > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000005e39fd05c5755bda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What is this please tell me ?

On Wed, 23 Jun 2021, 07:49 R= FC Errata System, <rfc-edit= or@rfc-editor.org> wrote:
Th= e following errata report has been rejected for RFC7591,
"OAuth 2.0 Dynamic Client Registration Protocol".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6619
--------------------------------------
Status: Rejected
Type: Editorial

Reported by: Dave Isaacs <disaacs@surveymonkey.com>
Date Reported: 2021-06-22
Rejected by: Benjamin Kaduk (IESG)

Section: 2

Original Text
-------------
token_endpoint_auth_method
=C2=A0 =C2=A0 =C2=A0 String indicator of the requested authentication metho= d for the
=C2=A0 =C2=A0 =C2=A0 token endpoint.=C2=A0 Values defined by this specifica= tion are:

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 "none": The client is a public clien= t as defined in OAuth 2.0,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 2.1, and does not have a client s= ecret.

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 "client_secret_post": The client use= s the HTTP POST parameters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as defined in OAuth 2.0, Section 2.3.1.
=C2=A0 =C2=A0 =C2=A0 *=C2=A0 "client_secret_basic": The client us= es HTTP Basic as defined in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth 2.0, Section 2.3.1.

Corrected Text
--------------
Text unchanged. It is the links that are incorrect.

Notes
-----
The links that are present in each bullet=E2=80=94to Section 2.1, and to Se= ction 2.3.1 (twice)=E2=80=94link internally to the current RFC (RFC 7591) w= hen they are supposed to link to the OAuth 2.0 RFC (RFC 6749).
=C2=A0--VERIFIER NOTES--
=C2=A0Errata reports are for the official version(s) of the document as pub= lished by the RFC Editor.=C2=A0 Prior to RFC 8650 the official version is t= he plain text copy; the html version with links is the result of running a = script over the text copy, and so the "wrong link" here is more p= roperly a bug in the script than an error in the RFC.

--------------------------------------
RFC7591 (draft-ietf-oauth-dyn-reg-30)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: OAuth 2.0 Dyn= amic Client Registration Protocol
Publication Date=C2=A0 =C2=A0 : July 2015
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: J. Richer, Ed., M. Jone= s, J. Bradley, M. Machulak, P. Hunt
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Web Authorization = Protocol
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000005e39fd05c5755bda-- From nobody Thu Jun 24 21:27:03 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172683A396F for ; Thu, 24 Jun 2021 21:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK8aioex6PCv for ; Thu, 24 Jun 2021 21:26:48 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03FB3A3978 for ; Thu, 24 Jun 2021 21:26:47 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id j4so14121923lfc.8 for ; Thu, 24 Jun 2021 21:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=cv5GJew4TxupFRLDdGHAtwlNA+/QAeQI7mLYsRcNj4w=; b=UMtzp2a+3xIDzNlzorRIuq0jEsPQUcSqYDHCm7veI+hudvql4BfuGbAfISZasvYyR/ VUf4sHhMLOK9RS253RGFfV1HBYkdvvxwxF13q3JhzpKUq8NmYQhYchgvPwaqGATMePGy tMqV3CKUPjrbCLftvQx07spyRlNWfpWI7//9Js0NkX6VbcM7WmsLxUYqA3Uq3Sungirz 2ZPB43TzVUpUb7Yz/MaqKJFClLokYsKXPREJCmo+QDAMx44Jv6i2ZYyJZBzgJQ5eX1ai yCaY7owebzBdON8qUKdIfU0FMP+kXXOwhBK5GU7wV4AqVDVeRRMHuJ1fUO/tFanO43R4 LmZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=cv5GJew4TxupFRLDdGHAtwlNA+/QAeQI7mLYsRcNj4w=; b=MK1UcxGlKhzHebpDRrYVjXtOnlUXff44mMBtjyFNIduHSHYbekQiRz/1wB65rQ75Wr hRBkjqntxqQME5k4c1I+p/O8kdnwL6CoFdt60T7Q70KLwzl4pgtkSnsTWPKxlnbDxlO0 BalIu+r3VJVcAc3qpEvD+1aiQeFmIfoGCo7tGLbYXJ77FAvb3zmETurJJGy3GyajdAGp OEKC98PKPMoVItDzfv33EdKRQaf2q+ybbAkDQyoYHFwOHeKPwtflKXn0ISth9nxSDgEG IBIuFARVHCwtnb4ZxakwHP/KQCFoBrNGIG5RzYU/OGKN+OFzkz41Vlc5uz4GOlh9Iu3k x/rA== X-Gm-Message-State: AOAM530iTI6GJ9gB5Yqa+/LWDt/NO6YRlokMOQCnX0bh4GG4pLHK84+e mLRK2VVNZFdS7ZETorbMEwPN/gYCKSC4FEYJgPsDfPNKMKI= X-Google-Smtp-Source: ABdhPJw5IF1znOdQxMrysTJg2ciJJa7Bj0hCiDzGpKTR4Z/ltTN41SXjZkAPmNIQyIwNdSzAM5zME4olAwgxhbNyhdg= X-Received: by 2002:ac2:4650:: with SMTP id s16mr6557512lfo.436.1624595204606; Thu, 24 Jun 2021 21:26:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:2d1a:0:0:0:0:0 with HTTP; Thu, 24 Jun 2021 21:26:43 -0700 (PDT) In-Reply-To: References: <22383e8e-97fc-48fd-92a3-577860662d0c@Spark> <714024cb-1672-41be-8f9e-9e784a733752@Spark> From: Rifaat Shekh-Yusef Date: Fri, 25 Jun 2021 00:26:43 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000130f9305c58f8c8f" Archived-At: Subject: [OAUTH-WG] Fwd: Request for Feedback and Interest: FedID CG charter review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 04:26:53 -0000 --000000000000130f9305c58f8c8f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable During the Federated Identity and Browser Workshop on May 25 & 26, we collectively decided to spin up a new community group focused on federated authentication. Several of us took the action to draft a charter for such a group, and we=E2=80=99d like your feedback. The draft charter is available here (we=E2=80=99ll have a proper repository once the group is actually formed) and issues against the draft are more than welcome. I=E2=80=99d like to have a call with anyone interested to make sure we=E2= =80=99ve captured the important bits for this iteration. If you are interested in participating on that call, please fill out the doodle poll by Monday, 28 June. I will respond to this message with information on whatever date/time is chosen at CoB (US Pacific time) on the 28th. Thanks for your interest! Heather Flanagan =E2=80=94 Translator of Geek to Human https://sphericalcowconsulting.com --000000000000130f9305c58f8c8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable During the=C2=A0Federated Identity and Browser Workshop=C2=A0on May 25 & 26, we collective= ly decided to spin up a new community group focused on federated authentica= tion. Several of us took the action to draft a charter for such a group, an= d we=E2=80=99d like your feedback.

The draft charter is available=C2=A0= here=C2=A0(we=E2=80=99ll have a proper repository once the group is actual= ly formed) and issues against the draft are more than welcome.

I=E2=80=99d like to have a call with= anyone interested to make sure we=E2=80=99ve captured the important bits f= or this iteration. If you are interested in participating on that call, ple= ase fill out the=C2=A0doodle poll=C2=A0by Monday, 28 June. I will respo= nd to this message with information on whatever date/time is chosen at CoB = (US Pacific time) on the 28th.

Thanks for your interest!

Heather Flanagan = =E2=80=94 Translator of Geek to Human
https://sphericalcowconsulting.com

--000000000000130f9305c58f8c8f-- From nobody Fri Jun 25 04:51:02 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF583A13AB for ; Fri, 25 Jun 2021 04:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6qV266Bm2YY for ; Fri, 25 Jun 2021 04:50:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594023A13A8 for ; Fri, 25 Jun 2021 04:50:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 58680F40715; Fri, 25 Jun 2021 04:50:46 -0700 (PDT) To: mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.jp, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.s.ietf@gmail.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: srp.naren@gmail.com, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210625115046.58680F40715@rfc-editor.org> Date: Fri, 25 Jun 2021 04:50:46 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Editorial Errata Reported] RFC7519 (6622) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 11:51:01 -0000 The following errata report has been submitted for RFC7519, "JSON Web Token (JWT)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6622 -------------------------------------- Type: Editorial Reported by: Padmanarayanan SR Section: 11 Original Text ------------- All the security considerations in the JWS specification also apply to JWT, as do the JWE security considerations when encryption is employed. In particular, Sections 10.12 Corrected Text -------------- All the security considerations in the JWS specification also apply to JWT, as do the JWE security considerations when encryption is employed. In particular, Sections 10.12 Notes ----- The link appears to be broken. It is intended to point to rfc7515#section-10.12 whereas it is pointing to the non-existent section of the same document. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7519 (draft-ietf-oauth-json-web-token-32) -------------------------------------- Title : JSON Web Token (JWT) Publication Date : May 2015 Author(s) : M. Jones, J. Bradley, N. Sakimura Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Jun 25 08:39:09 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083E03A1C76 for ; Fri, 25 Jun 2021 08:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZ2ud7GmLYZs for ; Fri, 25 Jun 2021 08:39:03 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BEC23A1C75 for ; Fri, 25 Jun 2021 08:39:03 -0700 (PDT) Received: from [192.168.1.49] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 15PFcxrB006901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Jun 2021 11:38:59 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Justin Richer In-Reply-To: <20210623000124.GJ11634@kduck.mit.edu> Date: Fri, 25 Jun 2021 11:38:58 -0400 Cc: RFC Errata System , danielbarclay.oss@gmail.com, oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210617190437.C3E5AF40738@rfc-editor.org> <20210623000124.GJ11634@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (6613) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 15:39:08 -0000 I personally agree with this report, the new proposed wording is better. OAuth 2.1 editors, please take note! =E2=80=94 Justin > On Jun 22, 2021, at 8:01 PM, Benjamin Kaduk wrote: >=20 > This looks correct to me; could the authors/WG please confirm? >=20 > Thanks, >=20 > Ben >=20 > On Thu, Jun 17, 2021 at 12:04:37PM -0700, RFC Errata System wrote: >> The following errata report has been submitted for RFC6749, >> "The OAuth 2.0 Authorization Framework". >>=20 >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid6613 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: Daniel Barclay >>=20 >> Section: 3.3 >>=20 >> Original Text >> ------------- >> The value of the scope parameter is expressed as a list of = space-delimited, case-sensitive strings >>=20 >> Corrected Text >> -------------- >> The value of the scope parameter is expressed as a space-delimited = list of case-sensitive strings >>=20 >> Notes >> ----- >> The original/current seems to be a bit confusing. >>=20 >> The value is not a collection of space-delimited strings (whatever a = "space-delimited string" would be), but it a space-delimited = (representation of) a collection of strings. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party =20 >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC6749 (draft-ietf-oauth-v2-31) >> -------------------------------------- >> Title : The OAuth 2.0 Authorization Framework >> Publication Date : October 2012 >> Author(s) : D. Hardt, Ed. >> Category : PROPOSED STANDARD >> Source : Web Authorization Protocol >> Area : Security >> Stream : IETF >> Verifying Party : IESG >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Jun 25 08:40:38 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373A53A0AB0 for ; Fri, 25 Jun 2021 08:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, KHOP_HELO_FCRDNS=0.398, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-wR5hapKjnR for ; Fri, 25 Jun 2021 08:40:34 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA2443A1C7C for ; Fri, 25 Jun 2021 08:40:33 -0700 (PDT) Received: from [192.168.1.49] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 15PFeUCW007611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Jun 2021 11:40:31 -0400 From: Justin Richer Message-Id: <4BAF6CE6-5BC2-4156-A0A2-81BFCC035E6E@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_A3462E67-AA6B-4213-B715-559601D9E881" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Fri, 25 Jun 2021 11:40:30 -0400 In-Reply-To: Cc: Filip Skokan , oauth To: Torsten Lodderstedt References: X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [OAUTH-WG] RAR WGLC comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 15:40:36 -0000 --Apple-Mail=_A3462E67-AA6B-4213-B715-559601D9E881 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with this change, but with one caveat (already expressed in the = PR) that an AS should be aware that clients can now send scope, = resource, and authorization_details parameters together on a single = request. It=E2=80=99s not up to RAR to define how all of those fit = together, but an AS implementing RAR is going to need to know that = it=E2=80=99s going to have to deal with this potentially unwieldy mix.=20= =E2=80=94 Justin > On Jun 20, 2021, at 6:54 AM, Torsten Lodderstedt = wrote: >=20 > Hi all, >=20 > I created a PR for this change.=20 >=20 > https://github.com/oauthstuff/draft-oauth-rar/pull/76 = >=20 > Please review and comment/approve.=20 >=20 > best regards, > Torsten.=20 >=20 >> Am 19.06.2021 um 17:01 schrieb Filip Skokan >: >>=20 >> I support such change. >>=20 >> Odesl=C3=A1no z iPhonu >>=20 >>> 19. 6. 2021 v 15:36, Torsten Lodderstedt = >: >>>=20 >>> =EF=BB=BF >>> Hi Brian, >>>=20 >>> the idea was to use resource indicators as convenient short cut to = support audience restricted access tokens. However, I agree this can be = achieved by specifying authorization details in the token request as = well. >>>=20 >>> So I=E2=80=98m fine with dropping resource indicators for RAR at = all. This means RAR on one hand and scopes + resource indicators on the = other hand are clearly decoupled and independent. >>>=20 >>> best regards, >>> Torsten. >>>=20 >>>> Am 18.06.2021 um 20:13 schrieb Brian Campbell = >: >>>>=20 >>>> =EF=BB=BF >>>> In my reading and understanding of the text and intent, the content = and meaning of a particular authorization details object are fully = governed by its "type". And while the draft provides a set of common = data elements intended to be usable across different types (locations, = actions, datatypes, identifier, privileges) a specific type is free to = define whatever suits its needs. A type definition may or may not = involve those common elements and could even use the same name(s) with = different meaning or structure.=20 >>>>=20 >>>> So, while I understand the motivation behind the RFC8707 resource = parameter being usable in a token request to make the AS filter, the = included authorization details of the resultant token based on the = "locations" element[1], I'm a bit concerned about a layering problem = here. The authorization details objects of the grant might not contain a = "locations" element or might have one with a different meaning or = structure. =20 >>>>=20 >>>> The draft also describes using the authorization_details token = request parameter to specify the authorization details a client wants = the AS to assign to a particular access token[2]. So the problematic = resource parameter behaviour is also kind of redundant. I think maybe it = should be removed. >>>>=20 >>>> [*] described in = https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-6.2 = and mentioned at = https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-1-8 = and in = https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-7-1 = >>>>=20 >>>> [2] = https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-token-re= quest = >>>> 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._______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oauth= &source=3Dgmail-imap&ust=3D1624644831000000&usg=3DAOvVaw1Ol8hiDotFufYe9jQC= Ti1m = >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A3462E67-AA6B-4213-B715-559601D9E881 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree with this change, but with one caveat (already expressed in the = PR) that an AS should be aware that clients can now send scope, = resource, and authorization_details parameters together on a single = request. It=E2=80=99s not up to RAR to define how all of those fit = together, but an AS implementing RAR is going to need to know that = it=E2=80=99s going to have to deal with this potentially unwieldy = mix. 

 =E2=80= =94 Justin

On Jun 20, 2021, at 6:54 AM, Torsten = Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> = wrote:

Hi all,

I created a PR for this = change. 

https://github.com/oauthstuff/draft-oauth-rar/pull/76
=

Please review and = comment/approve. 

best regards,
Torsten. 

Am 19.06.2021 um 17:01 schrieb Filip Skokan = <panva.ip@gmail.com>:

I support such change.

Odesl=C3=A1no z iPhonu

19. 6. = 2021 v 15:36, Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>:

=EF=BB=BF
Hi Brian,

the idea was to use = resource indicators as convenient short cut to support audience = restricted access tokens. However, I agree this can be achieved by = specifying authorization details in the token request as well.

So= I=E2=80=98m fine with dropping resource indicators for RAR at all. This = means RAR on one hand and scopes + resource indicators on the other hand = are clearly decoupled and independent.

best = regards,
Torsten.

Am = 18.06.2021 um 20:13 schrieb Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>:

=EF=BB=BF
In my reading and understanding of the text and intent, the = content and meaning of a particular authorization details object are = fully governed by its "type". And while the draft provides a set of = common data elements intended to be usable across different types = (locations, actions, datatypes, identifier, privileges) a specific type = is free to define whatever suits its needs. A type definition may or may = not involve those common elements and could even use the same name(s) = with different meaning or structure.

So, while I understand the motivation = behind the RFC8707 resource parameter being usable in a token request = to make the AS filter, the included authorization details of the = resultant token based on the "locations" element[1], I'm a bit = concerned about a layering problem here. The authorization details = objects of the grant might not contain a "locations" element or might = have one with a different meaning or structure.  

The draft also describes = using the authorization_details token request parameter to specify the = authorization details a client wants the AS to assign to a particular = access token[2]. So the problematic resource parameter behaviour is = also kind of redundant. I think maybe it should be removed.

[*] = described in https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#se= ction-6.2 and mentioned at https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#se= ction-1-8 and in https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#se= ction-7-1

[2] https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#na= me-token-request

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._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/lis= tinfo/oauth&source=3Dgmail-imap&ust=3D1624644831000000&usg=3DA= OvVaw1Ol8hiDotFufYe9jQCTi1m
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_A3462E67-AA6B-4213-B715-559601D9E881-- From nobody Fri Jun 25 10:20:15 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2443A0C50 for ; Fri, 25 Jun 2021 10:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvIyw8VCZsuz for ; Fri, 25 Jun 2021 10:20:07 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2603A0C56 for ; Fri, 25 Jun 2021 10:20:07 -0700 (PDT) Received: (qmail 71378 invoked from network); 25 Jun 2021 17:20:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=116cf.60d61044.k2106; bh=zj3OT0fGSVA5T5gm5xtzs5GSOOdrZYOXHDAJYhTph/o=; b=K/C/GOmBHqjmZ/hbG6r33dj00n+Zlj8pomFxXJNuzHaKXgXaPQAc5GgYfn/b0QNXCJvh3mXzJtNdHdpTPp/1KhUEVxvQ9pkLZpn6ChRLKSfmii1LtDzFonZEyLYQ0W1//9sHFh+FAAmwelIYmCCKE8vrYQhF1F+IhVKg+t5gkazcdca5U1xRzj7b6N51AjH85jmVE+u9rn63WrqssDCzIT13CfNm0U1SP+rv8mGwIeYT4OH8Tyv9Lq1dOfq67UyIk1PEr+3FDsCZ8n4Ki2fe/VUPVfGvckmIqaSVWpSosnn8FXhcSTrgkFylHpj0d67zNbksAyA8wBM+te5+nYDqAg== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 25 Jun 2021 17:20:04 -0000 Received: by ary.qy (Postfix, from userid 501) id B15D117959B5; Fri, 25 Jun 2021 13:20:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 747DC1795995; Fri, 25 Jun 2021 13:20:03 -0400 (EDT) Date: 25 Jun 2021 13:20:03 -0400 Message-ID: From: "John R. Levine" To: "RFC Errata System" , mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.jp, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.s.ietf@gmail.com Cc: srp.naren@gmail.com, oauth@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: <20210625115046.58680F40715@rfc-editor.org> References: <20210625115046.58680F40715@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC7519 (6622) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 17:20:13 -0000 Htmlized legacy RFCs are created by a script that uses heuristics to add formatting to the canonical text document. One of the limitations of the script is that it does not know when a section link is to another document. For RFCs published since we switched to XML v3 two years ago, the HTML is created directly from the XML and the links are correct. Since the underlying RFC is correct and currrent RFCs don't have the problem we're not planning to try to fix it. Regards, John Levine, temporary RFC series manager On Fri, 25 Jun 2021, RFC Errata System wrote: > The following errata report has been submitted for RFC7519, > "JSON Web Token (JWT)". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6622 > > -------------------------------------- > Type: Editorial > Reported by: Padmanarayanan SR > > Section: 11 > > Original Text > ------------- > All the security considerations in the JWS specification also apply > to JWT, as do the JWE security considerations when encryption is > employed. In particular, Sections 10.12 > > Corrected Text > -------------- > All the security considerations in the JWS specification also apply > to JWT, as do the JWE security considerations when encryption is > employed. In particular, Sections 10.12 > > Notes > ----- > The link appears to be broken. It is intended to point to rfc7515#section-10.12 whereas it is pointing to the non-existent section of the same document. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7519 (draft-ietf-oauth-json-web-token-32) > -------------------------------------- > Title : JSON Web Token (JWT) > Publication Date : May 2015 > Author(s) : M. Jones, J. Bradley, N. Sakimura > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG > > Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Jun 28 02:47:50 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B71FC3A3337; Mon, 28 Jun 2021 02:47:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-oauth-par@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, hannes.tschofenig@arm.com, hannes.tschofenig@arm.com X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <162487366465.24063.6175742745396190118@ietfa.amsl.com> Date: Mon, 28 Jun 2021 02:47:44 -0700 Archived-At: Subject: [OAUTH-WG] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-oauth-par-08=3A_=28with_COMMENT=29?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 09:47:45 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-oauth-par-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. I can only regret that the document shepherd write-up does not include anything about the WG consensus. Please find below one non-blocking COMMENT points (no need to reply), and some nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 1 -- "traditional web applications but is prohibitively difficult to use with mobile apps", I find the adverb "prohibitively" possibly slightly exagerated ;-) == NITS == Is this "user-agent" or "user agent" ? As it is not about the HTTP header. The PAR acronym for "pushed authorization requests" is defined but nearly never used in the text. -- Section 1 -- The first § is a single very long sentence. Consider splitting this long sentence in shorter ones ? Same applies in other places in the document (e.g., 1st sentence in section 2.4) From nobody Mon Jun 28 07:14:09 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 793243A095C; Mon, 28 Jun 2021 07:14:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwt-introspection-response@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Rifaat Shekh-Yusef , rifaat.s.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <162488964340.9518.9707742774515945903@ietfa.amsl.com> Date: Mon, 28 Jun 2021 07:14:03 -0700 Archived-At: Subject: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-jwt-introspection-response-11: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 14:14:04 -0000 Robert Wilton has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I still believe that using non 2119 language (i.e., "must" rather than "MUST") would be better for the privacy section, but won't block the document on this minor point. From nobody Mon Jun 28 12:45:52 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6FE3A0C63; Mon, 28 Jun 2021 12:45:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-oauth-par@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, hannes.tschofenig@arm.com, hannes.tschofenig@arm.com X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <162490954694.18608.7401442671159157596@ietfa.amsl.com> Date: Mon, 28 Jun 2021 12:45:46 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-par-08: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 19:45:47 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-par-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I made a github PR with some editorial suggestions, at https://github.com/oauthstuff/draft-oauth-par/pull/70 . Section 1 Those apps typically invoke a custom tab with an URL that is translated into a GET request. Using "POST" would require the app to first open a web page under its control in the custom tab that in turn would initiate the form "POST" towards the authorization server. PAR is simpler to use and has additional security benefits as described above. This description leaves me with a feeling that I only have an incomplete picture of why POST is "prohibitively difficult" to use with mobile apps. It seems like the setup is describing a scenario where the authorization logic is operating inside a framework or environment provided by some other entity that is unwilling or unable to change the framework to accomodate new OAuth behavior. Is this other entity the author of the mobile app, or an app framework, or somethint else? Having a bit more description of the multiple entities involved and which one is trying to control the specific mechanics of the authorization request would make this depiction a more compelling argument that POST is unusable. Section 1.1 POST /as/par HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 My personal preference would be to have examples that just want a generic HTTP authentication mechanism to use something stronger than Basic, though I don't think this is something that I can insist on, at present. (Applies throughout.) HTTP/1.1 201 Created Cache-Control: no-cache, no-store Content-Type: application/json { "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2", "expires_in": 90 } The "request_uri" element's semantics feels like a very natural fit for the native HTTP "Location" response header field (vs requiring a specific element in the JSON body of the response). I am less sure that there's a native HTTP element for the expiration time, as the HTTP timeouts tend to be associated with HTTP caching vs the actual lifetime of the resource. Section 2 It feels a little unfortunate that we have to reuse the metadata parameters relating to the token_endpoint_auth_method for PAR, but creating new metadata parameters that are basically always going to hold the same values is probably worse... Section 2.1 Any token endpoint parameters that are not related to client authentication have no defined meaning for a pushed authorization request. [...] I suppose that in most cases, whether or not a token endpoint parameter is related to client authentication should be fairly unambiguous ... but the registry at https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters has a dedicated column for "parameter usage location". It seems like it would be fairly straightforward to add "pushed authorization request" as an additional possible value there and remove the ambiguity. We could enumerate the existing parameters that are applicable and update the references for the registry to include this document. Section 2.1 The authorization server MUST process the request as follows: We often see descriptions along the lines of "this is not intended to constrain implementation techniques; any procedure that results in an equivalent outcome is permissible". This procedure is simple enough that we may not need to have concerns of that nature, though. Section 2.2 * "request_uri" : The request URI corresponding to the authorization request posted. This URI is used as reference to the respective request data in the subsequent authorization request only. [...] Would it be appropriate to use the phrase "single-use" in this description? Section 2.4 It is at the discretion of the authorization server to apply restrictions on supplied "redirect_uri" values, e.g. the authorization server MAY require a certain URI prefix or allow only a query parameter to vary at runtime. Is this expected to be discoverable by the client? Would there be a particular error code used, for example? Section 3 When the "application/x-www-form- urlencoded" HTTP entity-body "request" parameter is used, the request object MUST contain all the authorization request parameters as claims of the JWT. Additional request parameters as required by the given client authentication method are to be included as 'application/x-www-form-urlencoded' parameters in the HTTP request entity-body [...] I might flip this around and start off with "authentication request parameters required by a given client authentication method are included in the application/x-www-form-urlencoded request directly, and are the only parameters other than 'request' in the form body. All other request parameters, i.e., those pertaining to the authorization request itself, MUST appear as claims of the JWT representing the authorization request". The current formulation kind of hides the specifics of how to determine which parameter goes where -- the spec for the client authentication method in use is the authoritative one, IIUC. 1. If applicable, decrypt the request object as specified in JAR [I-D.ietf-oauth-jwsreq], section 6.1. 2. Validate the request object signature as specified in JAR [I-D.ietf-oauth-jwsreq], section 6.2. Do we want to say anything more about error handling if decryption or signature validation fails? Section 4 I think we should explicitly state that expired "request_uri"s are rejected as invalid. Section 5 Note that the presence of "pushed_authorization_request_endpoint" is sufficient for a client to determine that it may use the pushed authorization request flow. A "request_uri" value obtained from the PAR endpoint is usable at the authorization endpoint regardless of other authorization server metadata such as "request_uri_parameter_supported" or "require_request_uri_registration". Since this is the only mention of it in this document, and it's an OIDC parameter, maybe we should provide a reference for "require_request_uri_registration"? Section 7.1 An attacker could attempt to guess and replay a valid request URI value and try to impersonate the respective client. [...] Just to confirm my analysis here: an attacker that does guess a valid request URI value would probably also need to guess the corresponding "client_id", and if the request used PKCE, would also need to guess the PKCE value in order to successfully obtain a token response? I'm not sure whether any of that is worth mentioning or not here, though. Section 10.3 Section 12 Why is RFC 6749 not a normative reference? NITS Section 2 The pushed authorization request endpoint is an HTTP API at the authorization server that accepts HTTP "POST" requests with parameters in the HTTP request entity-body using the "application/x- www-form-urlencoded" format with a character encoding of UTF-8 as I'm not sure where "entity-body" is defined as the name for the request body in this case; draft-ietf-httpbis-semantics would seem to just have us refer to this as the "message body". Section 2.1 The client adds the parameters in "x-www-form-urlencoded" format with I'd suggest a different word than "adds"; these paratmers are the entire body, not appended to some earlier structure. Some parameters of the example request (e.g., "state") are duplicated across the multiple examples in the document. For those which are typically single-use in practice, we might consider using different values in the different examples (including in the JWT payload of the example request in Section 3). Section 7.4 The section heading is "Client Policy Change", which to me indicates a change in the policy of the client, that is, what the client requires. The text of the section indicates that this is discussing the AS's per-client policy, though, so I wonder if there is a better phrasing that could be used. From nobody Tue Jun 29 01:54:53 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 272003A2BBB; Tue, 29 Jun 2021 01:54:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-oauth-par@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, hannes.tschofenig@arm.com, hannes.tschofenig@arm.com X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <162495689162.17201.16673826726221874767@ietfa.amsl.com> Date: Tue, 29 Jun 2021 01:54:52 -0700 Archived-At: Subject: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-par-08: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 08:54:52 -0000 Robert Wilton has entered the following ballot position for draft-ietf-oauth-par-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for this document. Outside my area of expertise, but I have a couple of questions/comments: Section 2: Due to historical reasons there is potential ambiguity regarding the appropriate audience value to use when employing JWT client assertion based authentication (defined in Section 2.2 of [RFC7523] with "private_key_jwt" or "client_secret_jwt" authentication method names per Section 9 of [OIDC]). To address that ambiguity the issuer identifier URL of the authorization server according to [RFC8414] SHOULD be used as the value of the audience. In order to facilitate interoperability the authorization server MUST accept its issuer identifier, token endpoint URL, or pushed authorization request endpoint URL as values that identify it as an intended audience. I may be misunderstanding this text, but I note that by giving flexibility to the client (i.e., the SHOULD) and being strict on the receiver (MUST support x, y, z), this seems to encourage a proliferation. Hence, I was wondering whether this might be better the other way round. I.e., be strict with what is sent, and less strict with what is received: MUST send 'issuer identifier', MUST receive 'issuer identifier', SHOULD receive 'token endpoint URL' and 'pushed authorization request endpoint URL'? 2. * "expires_in" : A JSON number that represents the lifetime of the request URI in seconds as a positive integer. The request URI lifetime is at the discretion of the authorization server but will typically be relatively short (e.g., between 5 and 600 seconds). JSON numbers are doubles, but the value is a positive integer. Does it make sense to put in a hard limit of 2^53, or given that these are expected to be small numbers, 2^31 - 1? 3. The success and error examples both define: Content-Type: application/json Cache-Control: no-cache, no-store The document states that the response should be JSON, but should it more specifically specify the content type as "application/json"? Similarly, the cache control makes sense, but should the document mandate that the response must include "Cache-Control: no-cache, no-store"? Regards, Rob From nobody Tue Jun 29 07:44:40 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA893A366A; Tue, 29 Jun 2021 07:44:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Zaheduzzaman Sarker via Datatracker To: "The IESG" Cc: draft-ietf-oauth-par@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, hannes.tschofenig@arm.com, hannes.tschofenig@arm.com X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Zaheduzzaman Sarker Message-ID: <162497787750.11887.8041988401958112136@ietfa.amsl.com> Date: Tue, 29 Jun 2021 07:44:37 -0700 Archived-At: Subject: [OAUTH-WG] Zaheduzzaman Sarker's No Objection on draft-ietf-oauth-par-08: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 14:44:38 -0000 Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-oauth-par-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the efforts on this document. I think RFC6749 should be in the normative reference. To understand, implement and use this document one has to understand RFC6749 first. From nobody Tue Jun 29 09:52:47 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFE73A3A7B for ; Tue, 29 Jun 2021 09:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG7BwCxqMSQb for ; Tue, 29 Jun 2021 09:52:41 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F7D3A3A77 for ; Tue, 29 Jun 2021 09:52:41 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id x20so25190241ljc.5 for ; Tue, 29 Jun 2021 09:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ncJOqU3zhDw0w2hLK/KM0Kt0c4u0VlVCSYdQa7URolc=; b=kATgI9AbAsn9G8o/BTTnjbOwYXfTad4rgIpudS9FVOK+K2lH4BXRfY5PEcDCosaSDH nWDte92mrXLU7wETdTEbd9UJSsIoK1kYHNMaaJZM4EnC5x596TBGP+iBLf6BvZC1AuNu 4TcAPUz+wesd+wUM84UY3D2MdMB4lwgtv8nz6eZim88ntJ2XMC94Ic814Mg+qqSAW3UK mMBHvurnA7YzCG3lvlZO+oTGAGXekJQVGx3GV2H+nFxMAnyx+OVl/50Kl/iNKAYF20EH byau42Ex8Q8PsFp06YDIjCfYErz40tBroVm03wkW0S1Aj63ZktAWbvVipPrT4Ipi4/sA 3jsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ncJOqU3zhDw0w2hLK/KM0Kt0c4u0VlVCSYdQa7URolc=; b=ZaZdzGHe/H6kZlaACeLOcbYaGtQ1ybWkuSANcFIe5iZJTfEef9JLInUy8GD2q2oKIU oJ1VWxMZYxTZlNpZVWk2B+lqnIOOVtqQmj4Lo8h1O8fe9NQHl1QeKjtjO4F9FoGdWdF3 ji+1SdTjbEH1xiBYMEXAHgPKscdCmURzKZp85alGHVN/84C7JicreybR7RM0sGasAY4m BnQANsvWh5e256nyQyHUjPMNv7paz3dShyJQJ9kvNfWLEc1r6S3iaFv+V1410MPCetLA apHBw3dKf6Ggva/7L9wMBFGSKgG9UPdnVIwZDrXGahm3/YuB/r3MbcKDi4hYIydzRHoV jMug== X-Gm-Message-State: AOAM530bdMrwYokIbjgRkNuATK7B3v+OpbNpEwsAxQL7dQwHrUoU3bba qXvNgqKHPts5Jd3laEMU4kEgH7qXQA9lXX7IULkMm3r/IwY= X-Google-Smtp-Source: ABdhPJzhSYJ/tn31t0/zb7phK8PrHKLfuwcg7BuLdVueeJivsKb07WqZbpq6enNop+ZP5StRG27PkXrgKqNLmYxSbvE= X-Received: by 2002:a2e:8210:: with SMTP id w16mr4654688ljg.278.1624985559053; Tue, 29 Jun 2021 09:52:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac2:47f7:0:0:0:0:0 with HTTP; Tue, 29 Jun 2021 09:52:38 -0700 (PDT) In-Reply-To: References: <22383e8e-97fc-48fd-92a3-577860662d0c@Spark> <714024cb-1672-41be-8f9e-9e784a733752@Spark> From: Rifaat Shekh-Yusef Date: Tue, 29 Jun 2021 19:52:38 +0300 Message-ID: To: oauth Content-Type: multipart/mixed; boundary="0000000000000354db05c5ea6fbf" Archived-At: Subject: [OAUTH-WG] Fwd: Request for Feedback and Interest: FedID CG charter review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 16:52:47 -0000 --0000000000000354db05c5ea6fbf Content-Type: multipart/alternative; boundary="0000000000000354d905c5ea6fbd" --0000000000000354d905c5ea6fbd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---------- Forwarded message ---------- From: *Rifaat Shekh-Yusef* Date: Tuesday, June 29, 2021 Subject: Fwd: Request for Feedback and Interest: FedID CG charter review To: "rifaat.s.ietf@gmail.com" ---------- Forwarded message --------- From: Heather Flanagan Date: Tue, Jun 29, 2021 at 5:57 PM Subject: Re: Request for Feedback and Interest: FedID CG charter review To: Rifaat Shekh-Yusef And here=E2=80=99s the follow up: The Doodle poll has spoken! The call to discuss the draft charter is scheduled for Tuesday, 6 July 2021 @ 13:00 UTC (06:00 PDT, 09:00 EDT, 15:00 CEST). An .ics file is attached, but in case the mailing list software does not support attachments, details are below: Topic: FedID CG Charter Review Time: Jul 6, 2021 06:00 AM Pacific Time (US and Canada) Join Zoom Meeting https://us02web.zoom.us/j/81033154512?pwd=3DTU9tMW9jMUkzMXB2bEFQK3dJazJxdz0= 9 Meeting ID: 810 3315 4512 Passcode: 942941 One tap mobile +12532158782,,81033154512#,,,,*942941# US (Tacoma) +13462487799,,81033154512#,,,,*942941# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 6833 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 929 205 6099 US (New York) Meeting ID: 810 3315 4512 Passcode: 942941 Find your local number: https://us02web.zoom.us/u/kC1t7VQq9 Join by Skype for Business https://us02web.zoom.us/skype/81033154512 Heather Flanagan =E2=80=94 Translator of Geek to Human https://sphericalcowconsulting.com On Jun 24, 2021, 9:23 PM -0700, Rifaat Shekh-Yusef < rifaat.shekh-yusef@auth0.com>, wrote: Thanks Heather! Will do. Regards, Rifaat On Thu, Jun 24, 2021 at 5:34 PM Heather Flanagan < hlf@sphericalcowconsulting.com> wrote: > Hi Rifaat - > > Would you be so kind as to forward this to the OAuth2.0 working group, > please? > > ------ > > (Apologies for the cross-posting.) > > During the Federated Identity and Browser Workshop > on May 25 & 26, > we collectively decided to spin up a new community group focused on > federated authentication. Several of us took the action to draft a charte= r > for such a group, and we=E2=80=99d like your feedback. > > The draft charter is available here > (we=E2=80=99ll have a proper repo= sitory > once the group is actually formed) and issues against the draft are more > than welcome. > > I=E2=80=99d like to have a call with anyone interested to make sure we=E2= =80=99ve captured > the important bits for this iteration. If you are interested in > participating on that call, please fill out the doodle poll > by Monday, 28 June. I will > respond to this message with information on whatever date/time is chosen = at > CoB (US Pacific time) on the 28th. > > Thanks for your interest! > > Heather Flanagan =E2=80=94 Translator of Geek to Human > https://sphericalcowconsulting.com > --0000000000000354d905c5ea6fbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------
From: Rifaat Shekh-Yu= sef <rifaat.shekh-yu= sef@auth0.com>
Date: Tuesday, June 29, 2021
Subject: Fwd: Requ= est for Feedback and Interest: FedID CG charter review
To: "rifaat.s.ietf@gmail.com" <<= a href=3D"mailto:rifaat.s.ietf@gmail.com">rifaat.s.ietf@gmail.com>



---------- Forwarded message ---------
From: Heather Flanagan <hlf@sphericalcowconsulting.com>
Date: Tue= , Jun 29, 2021 at 5:57 PM
Subject: Re: Request for Feedback and Interest= : FedID CG charter review
To: Rifaat Shekh-Yusef <rifaat.shekh-yusef@auth0.com= >


And here=E2=80=99s= the follow up:

The Doodle poll has spoken! The call= to discuss the draft charter is scheduled for Tuesday, 6 July 2021 @ 13:00= UTC (06:00 PDT, 09:00 EDT, 15:00 CEST). An .ics file is attached, but in c= ase the mailing list software does not support attachments, details are bel= ow:

Topic: FedID CG Charter Review
Time: Jul 6, 2021 06:00 AM Pacific Time (US and Canada)

Join Zoom Meeting
https://us02web.zoom.us/j/81033154512?= pwd=3DTU9tMW9jMUkzMXB2bEFQK3dJazJxdz09

Meeting ID: 810 3315 4512
Passcode: 942941
One tap mobile
+12532158782,,81033154512#,,,,*= 942941# US (Tacoma)
+13462487799,,81033154512#,,,,*= 942941# US (Houston)

Dial by your location
=C2=A0+1 253 215 8782 US (Tacoma)
=C2=A0+1 346 248 7799 US (Houston)
=C2=A0+1 669 900 6833 US (San Jose)<= /span>
=C2=A0+1 301 715 8592 US (Washington= DC)
=C2=A0+1 312 626 6799 US (Chicago)
=C2=A0+1 929 205 6099 US (New York)<= /span>
Meeting ID: 810 3315 4512
Passcode: 942941
Find your local number:=C2=A0= https://u= s02web.zoom.us/u/kC1t7VQq9

Join by Skype for Business htt= ps://us02web.zoom.us/skype/81033154512
=C2=A0

Heather Flanagan = =E2=80=94 Translator of Geek to Human
https://sphericalcowconsulting.com
On Jun 24, 2021, 9:23 PM -0700, Rifaat Sh= ekh-Yusef <rifaat.shekh-yusef@auth0.com>, wrote:
Thanks=C2=A0Heather! Will do.=C2=A0

Regards,
=C2=A0Rifaat

On Thu, Jun 24, 2021 at 5:34 PM Heath= er Flanagan <hlf@sphericalcowconsulting.com> wrote:
Hi Rifaat -=C2=A0<= /span>

Would you be so kind as to forward t= his to the OAuth2.0 working group, please?

------

(Apologies for the cross-posting.)

During the=C2=A0Federated Identity and Browser Workshop=C2=A0on May 25 & 26, we collective= ly decided to spin up a new community group focused on federated authentica= tion. Several of us took the action to draft a charter for such a group, an= d we=E2=80=99d like your feedback.

The draft charter is available=C2=A0= here=C2=A0(we=E2=80=99ll have a proper repository once the group is actual= ly formed) and issues against the draft are more than welcome.

I=E2=80=99d like to have a call with= anyone interested to make sure we=E2=80=99ve captured the important bits f= or this iteration. If you are interested in participating on that call, ple= ase fill out the=C2=A0doodle poll=C2=A0by Monday, 28 June. I will respo= nd to this message with information on whatever date/time is chosen at CoB = (US Pacific time) on the 28th.

Thanks for your interest!

Heather Flanagan = =E2=80=94 Translator of Geek to Human
https://sphericalcowconsulting.com

--0000000000000354d905c5ea6fbd Content-Type: text/calendar; charset="UTF-8" Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Apple Inc.//macOS 11.4//EN CALSCALE:GREGORIAN BEGIN:VTIMEZONE TZID:America/Los_Angeles BEGIN:DAYLIGHT TZOFFSETFROM:-0800 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU DTSTART:20070311T020000 TZNAME:PDT TZOFFSETTO:-0700 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0700 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU DTSTART:20071104T020000 TZNAME:PST TZOFFSETTO:-0800 END:STANDARD END:VTIMEZONE BEGIN:VEVENT TRANSP:OPAQUE DTEND;TZID=America/Los_Angeles:20210706T070000 UID:96FC8F73-4112-41E8-9BF8-AE94D9A8E6A5+ZOOMMEETINGNUMBER:81033154512 DTSTAMP:20210629T145326Z LOCATION:https://us02web.zoom.us/j/81033154512?pwd=TU9tMW9jMUkzMXB2bEFQK 3dJazJxdz09 DESCRIPTION:Heather Flanagan (she/hers) is inviting you to a scheduled Z oom meeting.\n\nTopic: FedID CG Charter Review\nTime: Jul 6\, 2021 06:00 AM Pacific Time (US and Canada)\n\nJoin Zoom Meeting\nhttps://us02web.z oom.us/j/81033154512?pwd=TU9tMW9jMUkzMXB2bEFQK3dJazJxdz09\n\nMeeting ID: 810 3315 4512\nPasscode: 942941\nOne tap mobile\n+12532158782\,\,810331 54512#\,\,\,\,*942941# US (Tacoma)\n+13462487799\,\,81033154512#\,\,\,\, *942941# US (Houston)\n\nDial by your location\n +1 253 215 8782 US (Tacoma)\n +1 346 248 7799 US (Houston)\n +1 669 900 68 33 US (San Jose)\n +1 301 715 8592 US (Washington DC)\n +1 312 626 6799 US (Chicago)\n +1 929 205 6099 US (New York)\nMeeti ng ID: 810 3315 4512\nPasscode: 942941\nFind your local number: https:// us02web.zoom.us/u/kC1t7VQq9\n\nJoin by Skype for Business\nhttps://us02w eb.zoom.us/skype/81033154512\n\n STATUS:CONFIRMED SEQUENCE:0 SUMMARY:FedID CG Charter Review LAST-MODIFIED:20210629T145326Z DTSTART;TZID=America/Los_Angeles:20210706T060000 CREATED:20210629T145326Z X-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC BEGIN:VALARM X-WR-ALARMUID:B1DAC124-B544-4C29-B8D7-D174AC3DA921 UID:B1DAC124-B544-4C29-B8D7-D174AC3DA921 TRIGGER:-PT10M DESCRIPTION:This is an event reminder ACTION:DISPLAY END:VALARM END:VEVENT END:VCALENDAR --0000000000000354d905c5ea6fbd-- --0000000000000354db05c5ea6fbf Content-Type: application/ics; name="FedID CG Charter Review.ics" Content-Disposition: attachment; filename="FedID CG Charter Review.ics" Content-Transfer-Encoding: base64 Content-ID: <17a58ae42f3fac7f5491> X-Attachment-Id: 17a58ae42f3fac7f5491 QkVHSU46VkNBTEVOREFSDQpWRVJTSU9OOjIuMA0KUFJPRElEOi0vL0FwcGxlIEluYy4vL21hY09T IDExLjQvL0VODQpDQUxTQ0FMRTpHUkVHT1JJQU4NCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpBbWVy aWNhL0xvc19BbmdlbGVzDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wODAwDQpSUlVM RTpGUkVRPVlFQVJMWTtCWU1PTlRIPTM7QllEQVk9MlNVDQpEVFNUQVJUOjIwMDcwMzExVDAyMDAw MA0KVFpOQU1FOlBEVA0KVFpPRkZTRVRUTzotMDcwMA0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFO REFSRA0KVFpPRkZTRVRGUk9NOi0wNzAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTExO0JZ REFZPTFTVQ0KRFRTVEFSVDoyMDA3MTEwNFQwMjAwMDANClRaTkFNRTpQU1QNClRaT0ZGU0VUVE86 LTA4MDANCkVORDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpUUkFOU1A6 T1BBUVVFDQpEVEVORDtUWklEPUFtZXJpY2EvTG9zX0FuZ2VsZXM6MjAyMTA3MDZUMDcwMDAwDQpV SUQ6OTZGQzhGNzMtNDExMi00MUU4LTlCRjgtQUU5NEQ5QThFNkE1K1pPT01NRUVUSU5HTlVNQkVS OjgxMDMzMTU0NTEyDQpEVFNUQU1QOjIwMjEwNjI5VDE0NTMyNloNCkxPQ0FUSU9OOmh0dHBzOi8v dXMwMndlYi56b29tLnVzL2ovODEwMzMxNTQ1MTI/cHdkPVRVOXRNVzlqTVVrek1YQjJiRUZRSw0K IDNkSmF6SnhkejA5DQpERVNDUklQVElPTjpIZWF0aGVyIEZsYW5hZ2FuIChzaGUvaGVycykgaXMg aW52aXRpbmcgeW91IHRvIGEgc2NoZWR1bGVkIFoNCiBvb20gbWVldGluZy5cblxuVG9waWM6IEZl ZElEIENHIENoYXJ0ZXIgUmV2aWV3XG5UaW1lOiBKdWwgNlwsIDIwMjEgMDY6MDANCiAgQU0gUGFj aWZpYyBUaW1lIChVUyBhbmQgQ2FuYWRhKVxuXG5Kb2luIFpvb20gTWVldGluZ1xuaHR0cHM6Ly91 czAyd2ViLnoNCiBvb20udXMvai84MTAzMzE1NDUxMj9wd2Q9VFU5dE1XOWpNVWt6TVhCMmJFRlFL M2RKYXpKeGR6MDlcblxuTWVldGluZyBJRDoNCiAgODEwIDMzMTUgNDUxMlxuUGFzc2NvZGU6IDk0 Mjk0MVxuT25lIHRhcCBtb2JpbGVcbisxMjUzMjE1ODc4MlwsXCw4MTAzMzENCiA1NDUxMiNcLFws XCxcLCo5NDI5NDEjIFVTIChUYWNvbWEpXG4rMTM0NjI0ODc3OTlcLFwsODEwMzMxNTQ1MTIjXCxc LFwsXCwNCiAqOTQyOTQxIyBVUyAoSG91c3RvbilcblxuRGlhbCBieSB5b3VyIGxvY2F0aW9uXG4g ICAgICAgICsxIDI1MyAyMTUgODc4MiANCiBVUyAoVGFjb21hKVxuICAgICAgICArMSAzNDYgMjQ4 IDc3OTkgVVMgKEhvdXN0b24pXG4gICAgICAgICsxIDY2OSA5MDAgNjgNCiAzMyBVUyAoU2FuIEpv c2UpXG4gICAgICAgICsxIDMwMSA3MTUgODU5MiBVUyAoV2FzaGluZ3RvbiBEQylcbiAgICAgICAg KzENCiAgMzEyIDYyNiA2Nzk5IFVTIChDaGljYWdvKVxuICAgICAgICArMSA5MjkgMjA1IDYwOTkg VVMgKE5ldyBZb3JrKVxuTWVldGkNCiBuZyBJRDogODEwIDMzMTUgNDUxMlxuUGFzc2NvZGU6IDk0 Mjk0MVxuRmluZCB5b3VyIGxvY2FsIG51bWJlcjogaHR0cHM6Ly8NCiB1czAyd2ViLnpvb20udXMv dS9rQzF0N1ZRcTlcblxuSm9pbiBieSBTa3lwZSBmb3IgQnVzaW5lc3Ncbmh0dHBzOi8vdXMwMncN CiBlYi56b29tLnVzL3NreXBlLzgxMDMzMTU0NTEyXG5cbg0KU1RBVFVTOkNPTkZJUk1FRA0KU0VR VUVOQ0U6MA0KU1VNTUFSWTpGZWRJRCBDRyBDaGFydGVyIFJldmlldw0KTEFTVC1NT0RJRklFRDoy MDIxMDYyOVQxNDUzMjZaDQpEVFNUQVJUO1RaSUQ9QW1lcmljYS9Mb3NfQW5nZWxlczoyMDIxMDcw NlQwNjAwMDANCkNSRUFURUQ6MjAyMTA2MjlUMTQ1MzI2Wg0KWC1BUFBMRS1UUkFWRUwtQURWSVNP UlktQkVIQVZJT1I6QVVUT01BVElDDQpCRUdJTjpWQUxBUk0NClgtV1ItQUxBUk1VSUQ6QjFEQUMx MjQtQjU0NC00QzI5LUI4RDctRDE3NEFDM0RBOTIxDQpVSUQ6QjFEQUMxMjQtQjU0NC00QzI5LUI4 RDctRDE3NEFDM0RBOTIxDQpUUklHR0VSOi1QVDEwTQ0KREVTQ1JJUFRJT046VGhpcyBpcyBhbiBl dmVudCByZW1pbmRlcg0KQUNUSU9OOkRJU1BMQVkNCkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVO RDpWQ0FMRU5EQVINCg== --0000000000000354db05c5ea6fbf-- From nobody Tue Jun 29 10:57:44 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA573A3C37 for ; Tue, 29 Jun 2021 10:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaKKO-pVuavK for ; Tue, 29 Jun 2021 10:57:38 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0FB3A3C34 for ; Tue, 29 Jun 2021 10:57:37 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id q4so23789459ljp.13 for ; Tue, 29 Jun 2021 10:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W4Z9IjUiF3HM2+BSB167q78jZ38ndEm9OnleHG1D0Xc=; b=bwiB9mzbqx+NCT0kvudhqiPjRScfPH7a0H/QPFZB0jfBzpsFguEkeHrrpav6llQnNw 5TK+z1SMzyVPHglcYDagAUNaCdGQjvhKJWjn4VcexFuNUzd16/ksNM8aETblgdH5bePQ 98FXLN4MwlHB3SSn7iKX9sFHnALcBhxtmOfifMk3tmC02lsLH11W7Yn1jkHteFLaTr6O 7j4gIGExrkd8LncF3vlHKIjhottoTTmR90QHJSduKK1sThd9ceus/LJxGnnix1aVx+Zb Wj5dNFo7h1QkydCEIifA+ll2lWym7shaVcmJkz5AhhfVnLaoHr9NVieklTXLPoDznhkS Je1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W4Z9IjUiF3HM2+BSB167q78jZ38ndEm9OnleHG1D0Xc=; b=oAUwkvJai/65dnUu01IiNOwsluvuQx9GXEffuc4O1V1EDvmMUNDhKzsKW0jqMnoBAQ Mu1uAIZgrZwoMPr7riih7y1++uxDeSrGHkU/FkZTL5NbJqt+JVKKG3qTgOnUJNOpUNFn 5PSnGv4uf86o5VmP72S+AImrrWe9hzjHfm9eGCSzeiP0g0SxkEoF+heIEg6OGjNjRuOZ /XhxemodMHWd298m1uLJ0b27oafWZEomsqJ1YSZvd8BIqsLAQFg45cpblhYvyFjYNIoN dhqQ0xSzBjhwouCbHej05i0eGw+Omvac4kw1MFihHlkYRCvcx8Qj5zHI0PF4IhkcKG1X ASUg== X-Gm-Message-State: AOAM531XIgvi0ZYo78W5XtHHSvhYujok9OLKXe7cVb5kQwU+ntGBaSuq FR3goxkaBIpomOEqHESdwUOUu3A/5t5d+UUwkDIccp9Npm4LqHXmJ/fc8j6xVqYvny5xKmtqQlw nLd3Wjgon7xtWpQ== X-Google-Smtp-Source: ABdhPJxT/J7JWWZOLtlP+g5aqyr+lC3JqG2KGcxcIcEiAvTQzFjnqjrZtEfMJyNv4+y38VDh0MyvSprk1XkGxb0kT88= X-Received: by 2002:a2e:80ca:: with SMTP id r10mr4862168ljg.485.1624989455124; Tue, 29 Jun 2021 10:57:35 -0700 (PDT) MIME-Version: 1.0 References: <162497787750.11887.8041988401958112136@ietfa.amsl.com> In-Reply-To: <162497787750.11887.8041988401958112136@ietfa.amsl.com> From: Brian Campbell Date: Tue, 29 Jun 2021 11:57:08 -0600 Message-ID: To: Zaheduzzaman Sarker Cc: The IESG , draft-ietf-oauth-par@ietf.org, oauth-chairs@ietf.org, oauth , Hannes Tschofenig Content-Type: multipart/alternative; boundary="0000000000003cab2905c5eb57b3" Archived-At: Subject: Re: [OAUTH-WG] Zaheduzzaman Sarker's No Objection on draft-ietf-oauth-par-08: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 17:57:42 -0000 --0000000000003cab2905c5eb57b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Zaheduzzaman, Indeed it was intended that RFC6749 be a normative reference. But we had a little oversight/mixup with the tooling (mmark), which should be corrected with https://github.com/oauthstuff/draft-oauth-par/commit/2c78427a9 (all but one of the RFC6749 citations were marked with the normative modifier but it picked up the one that wasn't). On Tue, Jun 29, 2021 at 8:44 AM Zaheduzzaman Sarker via Datatracker < noreply@ietf.org> wrote: > Zaheduzzaman Sarker has entered the following ballot position for > draft-ietf-oauth-par-08: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the efforts on this document. > > I think RFC6749 should be in the normative reference. To understand, > implement > and use this document one has to understand RFC6749 first. > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000003cab2905c5eb57b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks Zaheduzzaman, =

Indeed it was intended that RFC6749 be a no= rmative=20 reference. But we had a little oversight/mixup with the tooling (mmark), w= hich=20 should be corrected with=20 = https://github.com/oauthstuff/draft-oauth-par/commit/2c78427a9 (all but= one of the RFC6749 citations were marked with the normative modifier but = it picked up the one that wasn't).

On Tue, Jun 29, 2021 at 8:= 44 AM Zaheduzzaman Sarker via Datatracker <noreply@ietf.org> wrote:
Zaheduzzaman Sarker has entered the following ballot= position for
draft-ietf-oauth-par-08: No Objection

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the efforts on this document.

I think RFC6749 should be in the normative reference. To understand, implem= ent
and use this document one has to understand RFC6749 first.
=






=C2=A0

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000003cab2905c5eb57b3-- From nobody Tue Jun 29 11:20:50 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54903A3CCD; Tue, 29 Jun 2021 11:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNmRHd2gaxVT; Tue, 29 Jun 2021 11:20:40 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50068.outbound.protection.outlook.com [40.107.5.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F923A3CCA; Tue, 29 Jun 2021 11:20:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YdS2ZvR0zN51Of6KwElIrDET2CyBfUr5SrpnERcZXwV6VNgb+S+/XqlHmVGnToKwup3Rp2QheLOu5NYhj8xwfDjMuV7OeusSLJl4PQ8o9mwBzh+wTSEs/AloFGcNCw/+tvyEnMbp7qnbQRnQdYtgBBxIE1p+xVFpI/wFQXo8muhWtkxqsXdubAb2ITQfSoeuOaipKBrgZ7St6gokwqyQLA8PnKPH0xwJz+QBnkdRHkBp5Jlu3LH85RuzKTldYBdh8bcA0LWfaoxYGDP2+o415YoRWDtDrmxzvGi+Ik9fEQAHnmCEvwW5tbPq279v+g/CHY67aMJRcfWZmC+kBI9pgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eDaXknfXRJYBvEdS/KnKMpvF5E/DxQiSndgspclKezg=; b=ih9C1HUH51cM9IIChLIf0TdalmL95fNQU5iY4Vp9Tlc7RNUzhU5C4Uu3zpnmyMzLU1wnAJP277+8mSI1aL5AgXIkscHxOT1pTC8hVJFWG/pAB9yZiEC8YHyEiEYMhtq527LUIr2czFzBn2KlYCkf+jN4pXVcSbJqygDjo1vdHl2n+21QTyJdVAMn4aNezASUndo7LMCVep+L4TF6TgW7bH5pGtsOg0StOoM+i6zdbrzMt9NoGaWgJz1l3Xit9TZOFYAcvDMaabqfEACj3UhtiiqVXLg+wfQtcHU/+f5NmKfhv54EUElZYNkSaxRApM2he/wM3w5z/w0kre/00Prg1A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eDaXknfXRJYBvEdS/KnKMpvF5E/DxQiSndgspclKezg=; b=TdH6tTRl55GDD+BiuW6Gcl7kbl1hUtT0F2a03alMiCtW13ECuVBGk1OcHzylbtRHpmJ2+FQ22P54ifUrXQkDF1Afg0R6ze1Jl8PZH/vALjl1nmnlbti0153GSGL5PUNBs63n1opfk9hCnSctm+h/0leDmfHHE6qraM57rbGmlUo= Received: from HE1PR07MB4187.eurprd07.prod.outlook.com (2603:10a6:7:98::23) by HE1PR07MB4315.eurprd07.prod.outlook.com (2603:10a6:7:a3::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.14; Tue, 29 Jun 2021 18:20:36 +0000 Received: from HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::d03:727f:e4c0:cd79]) by HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::d03:727f:e4c0:cd79%7]) with mapi id 15.20.4287.021; Tue, 29 Jun 2021 18:20:36 +0000 From: Zaheduzzaman Sarker To: Brian Campbell CC: The IESG , "draft-ietf-oauth-par@ietf.org" , "oauth-chairs@ietf.org" , oauth , Hannes Tschofenig Thread-Topic: Zaheduzzaman Sarker's No Objection on draft-ietf-oauth-par-08: (with COMMENT) Thread-Index: AQHXbPVXe8cGGZ+MqEaIjrYhSMyZFKsrRnAAgAAoFQA= Date: Tue, 29 Jun 2021 18:20:36 +0000 Message-ID: <4A670B55-5477-41FD-8876-7AD2EED0691B@ericsson.com> References: <162497787750.11887.8041988401958112136@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050901 authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4c4bf2e8-e82b-4a3f-c29e-08d93b2a978b x-ms-traffictypediagnostic: HE1PR07MB4315: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6qAPlOVj9ptG3t8pNDv3sXGYApF8aswO0FcnF0WWYwYDkaMSGivz7XZsKHod83QP1wTsChvrJcukubOHRuGvW8oxqHzOk4e+bowOS8RAVPRQVi+v850NismI/Gou57bzCnxbvwrGio62wyP/nGcOLEE1lsB66U56EQonAzp1XsDS6Lu5UIjAHxUBVCRXUDF/BFSyIZWbC2dqO9q/nDDijyZXBhA13ZS5IfqDr9URvguOFixGm+EkJjiFLwkd/ByNFDQVxCuUr4FEDO7JonmLRxH18QapddBTSrWDx3UNYL8wF5ssDY1LUONj2+nfnQ5zJaO4yPGINTwMXiwSzEIu8p9sR+vJuZyNlXtZL5cmhfdtYzL+iPPXxjoRYhGzaZ1iCrkSTfYAkzmn03BRbxN13fquCzMowA81o/3bothiUeN4315r9jWFbMkR17dpKc9KTqcRoSgOZKaRbt59eVq4AkP4FIY6/ChC6H/MujmSDKK4/+xZ3yCAHTpnaBQRiFQPNAyigpSFCW9OsECgg4dq3KRKx8jQie4QNaW+wjwoNKqk2329vp8WQhLcoaF9Xt/14clYqi9d2wShQlkguyqlzj9QrnCFmUp6hXGS3Pnd6kObVtMlTfkwsSpKb8tTiyvbsKls9uODLMXNrS6ro+cU/kdhXrdVkIQq15ektuKHxLXT9IyW2FZZEW0Ax/IrPrcnWJgpIPzKyqQqWIfeIyJb0LC9wLVg5qfuOYE1lsCv8nICdPP0ii8vrpYYkLUDhdOXbuRz44rcgrSvgpvao5GBDRpNoszeyyIeAJFpcb94V1jjeb6TjGH7M+wPufk0+jhruQS99Qiw7oGLK197HXvv3Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4187.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(396003)(366004)(346002)(39860400002)(54906003)(4326008)(2906002)(2616005)(76116006)(478600001)(86362001)(6512007)(66556008)(66476007)(64756008)(66946007)(186003)(66446008)(316002)(122000001)(6916009)(36756003)(53546011)(44832011)(5660300002)(33656002)(38100700002)(966005)(8676002)(71200400001)(6486002)(6506007)(166002)(26005)(83380400001)(8936002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Vm03VVl3S0JPUlAwbXYwUUNZazB5TUppYVdHYS9MQVdISHJtc0tSYVdiU2Yx?= =?utf-8?B?by9ZdlNhc2xQSGY1N3oyQk1pSHNQdk01YVpQTWJqVnVQVDJqOGYzUVZXWldi?= =?utf-8?B?S3ovOGlPTXM3RDJVcWVScC8waDNyeEdNYWszaEw5TG5zM3I2U1h4Ulg0MGhJ?= =?utf-8?B?L2pXcy9kWjlFMDBTYTVxaVJkRkViRGRiQjlxZ1dkbmdOdlpCYjJqMWpIdFVN?= =?utf-8?B?Uk9TVzUwSDhGeDdmK203Vkg1aCtHaTNsQy9IKzM3NVZkQnM1SDZENjlQQis3?= =?utf-8?B?aWM3UmhheTZpVWtQNzgyVG92T3AyWCtRM3pNdzluWUpIQjY3aG9XRVJaK1BU?= =?utf-8?B?VjY0L3ozZVp0OG90NHVSdGxaVlBkeFlmQWZnWDBZSVByazYxVDd4WENrYm9I?= =?utf-8?B?ZDJVclFyazE3RURlOGFLWEVsVXl3TGpyWEN6eW5FbzRyYlVOYzZ6NTZjSWho?= =?utf-8?B?QTEvWUliMVBpMVUySnZ3Tk1LMUhDTnBUbk9ueCtuN1NGSWdtTERTU1lNK21I?= =?utf-8?B?eCtHcGtPUzZaek8wTlZsbWlKVUJ1Rm9NdmFZZ1JoTVBxWmdtL2J5RC9uZEo3?= =?utf-8?B?M01TMnVxTE1USlFmUXQzUGpJMDg1aEhDUmpERFplRytkdnVISW9Pb252a2FS?= =?utf-8?B?RE8xSE9scXdKRFFHT05kT0Vyc0RPTUVaUXIrTDhDT1QxSHVNQ2FROWxkdURZ?= =?utf-8?B?Tm1acUw1SWl6V3ZjTFFFZllqTTcyUm1nZXJMRDdLdVQvYmJXV0U5UEJabmJI?= =?utf-8?B?L0padkNIb2dTN3dUMkxXOEh1ajBDQUNOSjJYMkQ2MW9LTTZRZzFkMXZSS0tw?= =?utf-8?B?aGtsbmdBOThVeTZQcStPODhhWEpwcFA5dXFmSGoxU0tkSDdoRzFHR1B6ZWlM?= =?utf-8?B?VmlmSlRmZ01BV042NU5rN3EwR1U2OGREZk5tVThwSllldDlZMXVnbWRXVS9S?= =?utf-8?B?cVYrN2ZzT0JKTHpXR29Zeisyb3Fmd2xRT2RoOFRVbjlJYkZia2ZWQWdacWhE?= =?utf-8?B?MlhNNTltYmZ4aGdPMFdYSEtNM3NHb2d3U3c3RncwVUIxUXJNMDVhVVJJK0RC?= =?utf-8?B?ckMrbVhjdnlqcTJ5M0pTaExrSEZWS3Y2dm1ZeE55djF1VDRhbnpURk5Hd2VK?= =?utf-8?B?bTJWZE1pblNiTU0xTmFXdzdWQi9HZkJIWk1BVU5mRGtrUXVYci9CNFQ1c0py?= =?utf-8?B?Y0lucVA3eWUwMzFxeDAwSldxaEpPcnY3UlNHNWpmT0tsOWNCR2d5QVYrdytq?= =?utf-8?B?UWJpY2ZrQ0QrRVBWSjl3WVdmVjNkd3pMR3IvT1JwUWZrbUxkRFNXUGtYZTdl?= =?utf-8?B?cU5TZVNWczAweGF3dmZoVUNhdDdnejdYRTQvVWtMSHhnbndETlhJNUlQTlNj?= =?utf-8?B?Qndsa1RBZzBuWTkrQjdleGxEK1BQKzhsVnVYUDZBMnkxeVpuTlZmQzcyY2xz?= =?utf-8?B?V3ZGTTRqOS9LMHk1Z2RPeWp4eHloaUtlY3Z2YkRSQ2VhbHB4d0c2SzRiR0Nz?= =?utf-8?B?bXRjcVdQWGowQVBSRXE5dmVSMHVndG9HN0NhdEhrY0x4azNxWEMweVJRMlQz?= =?utf-8?B?ODZpeTVKWXJHSUI1bElxeTFkMmhiOEFqL3lQUzdvNFFNK204NVB6cDZ5cU05?= =?utf-8?B?SmZnT1R2R0Y4MHdybVZ4cWR1VURCTUcvK3NxRS9qV21hQmVIVzM1dmNGeXJ6?= =?utf-8?B?V2s1cGJDOU1hZjl0NE1FRnZ4Wi9QTk9ZYU9TWlN0YXNZZ2VXaEtiL2F3RXFO?= =?utf-8?B?QVJ1RkpiQndscHE5VDZYazEvSWNjOTdJczA0U0hsczBLRSthYlBMZllsUk83?= =?utf-8?B?bUN4bk9YZEF1UkgyQVgrUT09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_4A670B55547741FD88767AD2EED0691Bericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4187.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4c4bf2e8-e82b-4a3f-c29e-08d93b2a978b X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2021 18:20:36.4761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +P5WXACsbJipC/GkyopdD0glRmZVrX7V+3uzOWew0qPIqcGqSxrTfbnxtbO+F9JnNj1M1MDEdoyVhqeNPF1eU5jaXUSzgnlFRUTQz3+b+yMA57JgQyrwfcVtlXvQ9kDs X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4315 Archived-At: Subject: Re: [OAUTH-WG] Zaheduzzaman Sarker's No Objection on draft-ietf-oauth-par-08: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 18:20:45 -0000 --_000_4A670B55547741FD88767AD2EED0691Bericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgaW5mb3JtYXRpb24uIEhvcGVmdWxseSBpdCB3aWxsIGdldCBmaXhlZCBp biB0aGUgbmV4dCB2ZXJzaW9uLg0KDQpCUg0KWmFoZWQNCg0KT24gMjAyMS0wNi0yOSwgMTk6NTcs ICJCcmlhbiBDYW1wYmVsbCIgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KDQoNClRoYW5rcyBaYWhlZHV6emFtYW4s DQoNCkluZGVlZCBpdCB3YXMgaW50ZW5kZWQgdGhhdCBSRkM2NzQ5IGJlIGEgbm9ybWF0aXZlIHJl ZmVyZW5jZS4gQnV0IHdlIGhhZCBhIGxpdHRsZSBvdmVyc2lnaHQvbWl4dXAgd2l0aCB0aGUgdG9v bGluZyAobW1hcmspLCB3aGljaCBzaG91bGQgYmUgY29ycmVjdGVkIHdpdGggaHR0cHM6Ly9naXRo dWIuY29tL29hdXRoc3R1ZmYvZHJhZnQtb2F1dGgtcGFyL2NvbW1pdC8yYzc4NDI3YTk8aHR0cHM6 Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/az0xMjZkMGRiMi00ZGY2MzdmNy0xMjZkNGQy OS04NjdiMzZkMTYzNGMtNmQ4MjA4N2I2ODc3MTk3NCZxPTEmZT0wODgzZGY2ZC1iZDNmLTQ3YWQt ODg5Ny01M2YyNjk3ZWY3ZjQmdT1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZvYXV0aHN0dWZm JTJGZHJhZnQtb2F1dGgtcGFyJTJGY29tbWl0JTJGMmM3ODQyN2E5PiAoYWxsIGJ1dCBvbmUgb2Yg dGhlIFJGQzY3NDkgY2l0YXRpb25zIHdlcmUgbWFya2VkIHdpdGggdGhlIG5vcm1hdGl2ZSBtb2Rp ZmllciBidXQgaXQgcGlja2VkIHVwIHRoZSBvbmUgdGhhdCB3YXNuJ3QpLg0KDQpPbiBUdWUsIEp1 biAyOSwgMjAyMSBhdCA4OjQ0IEFNIFphaGVkdXp6YW1hbiBTYXJrZXIgdmlhIERhdGF0cmFja2Vy IDxub3JlcGx5QGlldGYub3JnPG1haWx0bzpub3JlcGx5QGlldGYub3JnPj4gd3JvdGU6DQpaYWhl ZHV6emFtYW4gU2Fya2VyIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9u IGZvcg0KZHJhZnQtaWV0Zi1vYXV0aC1wYXItMDg6IE5vIE9iamVjdGlvbg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGFua3MgZm9yIHRoZSBlZmZvcnRzIG9u IHRoaXMgZG9jdW1lbnQuDQoNCkkgdGhpbmsgUkZDNjc0OSBzaG91bGQgYmUgaW4gdGhlIG5vcm1h dGl2ZSByZWZlcmVuY2UuIFRvIHVuZGVyc3RhbmQsIGltcGxlbWVudA0KYW5kIHVzZSB0aGlzIGRv Y3VtZW50IG9uZSBoYXMgdG8gdW5kZXJzdGFuZCBSRkM2NzQ5IGZpcnN0Lg0KDQoNCg0KDQoNCg0K DQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGlu dGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlz Y2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkg ZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg== --_000_4A670B55547741FD88767AD2EED0691Bericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <0E5FC59B10700D4796084052FE609202@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIjsNCglwYW5vc2UtMToyIDExIDYg NCAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMwMDcwQzA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJlbi1TRSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9 IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzA7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyBmb3IgdGhlIGluZm9ybWF0aW9uLiBI b3BlZnVsbHkgaXQgd2lsbCBnZXQgZml4ZWQgaW4gdGhlIG5leHQgdmVyc2lvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOiMwMDcwQzA7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzAwNzBDMDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QlI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiMwMDcwQzA7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlphaGVk PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDcwQzA7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMjAyMS0wNi0yOSwgMTk6NTcsICZxdW90O0JyaWFuIENh bXBiZWxsJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j b20iPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoYW5rcyBaYWhlZHV6emFtYW4sIDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JbmRlZWQg aXQgd2FzIGludGVuZGVkIHRoYXQgUkZDNjc0OSBiZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UuIEJ1 dCB3ZSBoYWQgYSBsaXR0bGUgb3ZlcnNpZ2h0L21peHVwIHdpdGggdGhlIHRvb2xpbmcgKG1tYXJr KSwgd2hpY2ggc2hvdWxkIGJlIGNvcnJlY3RlZCB3aXRoDQo8YSBocmVmPSJodHRwczovL3Byb3Rl Y3QyLmZpcmVleWUuY29tL3YxL3VybD9rPTEyNmQwZGIyLTRkZjYzN2Y3LTEyNmQ0ZDI5LTg2N2Iz NmQxNjM0Yy02ZDgyMDg3YjY4NzcxOTc0JmFtcDtxPTEmYW1wO2U9MDg4M2RmNmQtYmQzZi00N2Fk LTg4OTctNTNmMjY5N2VmN2Y0JmFtcDt1PWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRm9hdXRo c3R1ZmYlMkZkcmFmdC1vYXV0aC1wYXIlMkZjb21taXQlMkYyYzc4NDI3YTkiPg0KaHR0cHM6Ly9n aXRodWIuY29tL29hdXRoc3R1ZmYvZHJhZnQtb2F1dGgtcGFyL2NvbW1pdC8yYzc4NDI3YTk8L2E+ IChhbGwgYnV0IG9uZSBvZiB0aGUgUkZDNjc0OSBjaXRhdGlvbnMgd2VyZSBtYXJrZWQgd2l0aCB0 aGUgbm9ybWF0aXZlIG1vZGlmaWVyIGJ1dCBpdCBwaWNrZWQgdXAgdGhlIG9uZSB0aGF0IHdhc24n dCkuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ T24gVHVlLCBKdW4gMjksIDIwMjEgYXQgODo0NCBBTSBaYWhlZHV6emFtYW4gU2Fya2VyIHZpYSBE YXRhdHJhY2tlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmciPm5vcmVwbHlA aWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlphaGVk dXp6YW1hbiBTYXJrZXIgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24g Zm9yPGJyPg0KZHJhZnQtaWV0Zi1vYXV0aC1wYXItMDg6IE5vIE9iamVjdGlvbjxicj4NCjxicj4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+DQpDT01NRU5UOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+ DQpUaGFua3MgZm9yIHRoZSBlZmZvcnRzIG9uIHRoaXMgZG9jdW1lbnQuPGJyPg0KPGJyPg0KSSB0 aGluayBSRkM2NzQ5IHNob3VsZCBiZSBpbiB0aGUgbm9ybWF0aXZlIHJlZmVyZW5jZS4gVG8gdW5k ZXJzdGFuZCwgaW1wbGVtZW50PGJyPg0KYW5kIHVzZSB0aGlzIGRvY3VtZW50IG9uZSBoYXMgdG8g dW5kZXJzdGFuZCBSRkM2NzQ5IGZpcnN0LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20iPkNPTkZJ REVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFu ZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJl Y2lwaWVudChzKS4NCiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJl IGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZp bGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48 L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4A670B55547741FD88767AD2EED0691Bericssoncom_-- From nobody Wed Jun 30 12:11:18 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B353A272F for ; Wed, 30 Jun 2021 12:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpFFr3396bHw for ; Wed, 30 Jun 2021 12:11:07 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462813A2730 for ; Wed, 30 Jun 2021 12:11:07 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id q16so7101524lfr.4 for ; Wed, 30 Jun 2021 12:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5hDnKZls+Ezv6F7qLvXAfwhJm0ySSXcZlGHJ3nWTB+w=; b=CiBLY6WPjvhtzQ8fj2uRTlz2/2PwLWkjB5Tu5ZQRaz4LD1oDcRjaUCRt+ExscJ144x sHWH3BdCULyc+NRFP6Eahnl1VkQHro4/glhbcGTnzF6DfH6xfogClcRo2nxQxj/BiZNu vBAM+68JGnSHnAjaogO6dW834RxUoBPUopgUOVMSY8EO1G/f7W1YkVeypfxYZIo7MZLt r+otE/hyp/nUwTPEFyPlJfIKHtKuLWxvvN6Vg0xaMRqtMTg55K1neh0lEcn3kihziQFR 342sihJuA5Vx8cI2paA4gNkr9ZGqlmirCU868ck+UeE7idfja/N7yVfRqvPiEkXPz0B/ vb0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5hDnKZls+Ezv6F7qLvXAfwhJm0ySSXcZlGHJ3nWTB+w=; b=Dqnahmj6bD41XpnAg++yOLrLz99hynuWWYa1tvVqGQtgjwPrC0V4xGkg704VGH7YY2 HMIds+uVMo8qUdB2bobQAByPZbZheKAapISvIQ73xQQMp09lIXemdf0NObYTp3pb2l7P cw5205MiwlrstTHb8QuEA5TaGxn59x7d120P4tUlagL55Iic9qbRQHi50xRtfumlY0vj y35HpRmd108QLdJHjB5ZIsgOpIllelLU5gD3n0JljugBiiy9mbZpcGDqLBM/lvvF042E fHVHebzKi92Fi5Hw4SdYuiWkmVM5lToGf2TEdBdpT15HjI4/VUnWHlWonf0R2B1zSIeJ uT9w== X-Gm-Message-State: AOAM532u+MStNFbJknnXOAwE0fvi8hvoEEpKgK/Wcps8LzLncpkP3oL8 P9J0tHWy+Zq8R7VyrDbkQoImewny+DuDqUtSME+WNba5hnedVyceUrlVeoBLTg007oFE7gwgckB r+UdFfttoyzOUig== X-Google-Smtp-Source: ABdhPJye4piYBiL99ATFVdJo2TlnOebnPhPy4hSx6fSV2KbrEGB0bKsI4gOeCiepF01McYiq9+wHd0sKrDr+WKEZ/50= X-Received: by 2002:ac2:4187:: with SMTP id z7mr11294251lfh.574.1625080263738; Wed, 30 Jun 2021 12:11:03 -0700 (PDT) MIME-Version: 1.0 References: <162490954694.18608.7401442671159157596@ietfa.amsl.com> In-Reply-To: <162490954694.18608.7401442671159157596@ietfa.amsl.com> From: Brian Campbell Date: Wed, 30 Jun 2021 13:10:37 -0600 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-oauth-par@ietf.org, oauth-chairs@ietf.org, oauth , Hannes Tschofenig Content-Type: multipart/alternative; boundary="000000000000da31f605c6007b91" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-par-08: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2021 19:11:13 -0000 --000000000000da31f605c6007b91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ben, I've endeavored to respond to your comments inline below. And I will/am working on related document updates but have some time off planned around the 4th of July so likely won't have a new revision out until next week sometime. On Mon, Jun 28, 2021 at 1:45 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-oauth-par-08: Yes > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I made a github PR with some editorial suggestions, at > https://github.com/oauthstuff/draft-oauth-par/pull/70 . > Merged on Monday. Thank you. Section 1 > > Those apps typically invoke a > custom tab with an URL that is translated into a GET request. Using > "POST" would require the app to first open a web page under its > control in the custom tab that in turn would initiate the form "POST" > towards the authorization server. PAR is simpler to use and has > additional security benefits as described above. > > This description leaves me with a feeling that I only have an incomplete > picture of why POST is "prohibitively difficult" to use with mobile > apps. It seems like the setup is describing a scenario where the > authorization logic is operating inside a framework or environment > provided by some other entity that is unwilling or unable to change the > framework to accomodate new OAuth behavior. Is this other entity the > author of the mobile app, or an app framework, or somethint else? > Having a bit more description of the multiple entities involved and > which one is trying to control the specific mechanics of the > authorization request would make this depiction a more compelling > argument that POST is unusable. > I think perhaps myself and co-authors are so familiar with it that it seems almost self-evident. This is the second ballot comment on this paragraph, however, so it seems some more work on the text is warranted. I'll try to elaborate and better explain why it isn't particularly viable for a native mobile app to cause the user's browser on the device to make a POST request (with sizable body content). > Section 1.1 > > POST /as/par HTTP/1.1 > Host: as.example.com > Content-Type: application/x-www-form-urlencoded > Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 > > My personal preference would be to have examples that just want a > generic HTTP authentication mechanism to use something stronger than > Basic, though I don't think this is something that I can insist on, at > present. (Applies throughout.) > I wavered on this very point when putting together the examples but eventually took the easy route and went with Basic (aka client_secret_basic). The three such examples just want to show some form of OAuth client authentication happening. I think JWT based client assertion authentication using asymmetric keys https://datatracker.ietf.org/doc/html/rfc7523#section-2.2 (aka private_key_jwt) is the only stronger mechanism that would show well in examples (MTLS/RFC8705 is hard to show in a meaningful way in an HTTP example). I could update the examples to use RFC7523 client_assertion/client_assertion_type parameter auth? > HTTP/1.1 201 Created > Cache-Control: no-cache, no-store > Content-Type: application/json > > { > "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2", > "expires_in": 90 > } > > The "request_uri" element's semantics feels like a very natural fit for > the native HTTP "Location" response header field (vs requiring a > specific element in the JSON body of the response). I am less sure that > there's a native HTTP element for the expiration time, as the HTTP > timeouts tend to be associated with HTTP caching vs the actual lifetime > of the resource. > The semantics feel subtly different in that the "request_uri" value is not used as-is by the client but rather as a query string parameter in the construction of the full authorization request URI to which it will direct the user's browser. I was also unsure whether the "Location" response header field had to have a resolvable URI value (I didn't find text saying so explicitly but it seems somewhat logical). Also, to me anyway, it made sense and was more consistent to keep the OAuth parameters at the same layer they show up in other OAuth exchanges. And, as you note, there isn't an obvious HTTP field to convey the expiration time and putting some protocol data in the headers and some in the JSON content payload seemed awkward. That's some of the reasoning behind not using the "Location" header. Avoiding a breaking change at this stage is another reason. > Section 2 > > It feels a little unfortunate that we have to reuse the metadata > parameters relating to the token_endpoint_auth_method for PAR, but > creating new metadata parameters that are basically always going to hold > the same values is probably worse... > I believe the reuse is exactly what's wanted here. The unfortunate part is in the naming that, in retrospect, is overly specific. Section 2.1 > > Any token endpoint parameters that are not related > to client authentication have no defined meaning for a pushed > authorization request. [...] > > I suppose that in most cases, whether or not a token endpoint parameter > is related to client authentication should be fairly unambiguous ... but > the registry at > > https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#= parameters > has a dedicated column for "parameter usage location". It seems like it > would be fairly straightforward to add "pushed authorization request" as > an additional possible value there and remove the ambiguity. We could > enumerate the existing parameters that are applicable and update the > references for the registry to include this document. > I believe the text describes the situation pretty well and resolves the ambiguities sufficient for interoperable implementations/deployments in practice. A registry update is possible but would be a significant change with ongoing maintenance needs that aren't readily apparent while not providing practical value. > Section 2.1 > > The authorization server MUST process the request as follows: > > We often see descriptions along the lines of "this is not intended to > constrain implementation techniques; any procedure that results in an > equivalent outcome is permissible". This procedure is simple enough > that we may not need to have concerns of that nature, though. > > Section 2.2 > > * "request_uri" : The request URI corresponding to the authorization > request posted. This URI is used as reference to the respective > request data in the subsequent authorization request only. [...] > > Would it be appropriate to use the phrase "single-use" in this > description? > Yes, I think so. I'll add it. > Section 2.4 > > It is at the discretion of the authorization server to apply > restrictions on supplied "redirect_uri" values, e.g. the > authorization server MAY require a certain URI prefix or allow only a > query parameter to vary at runtime. > > Is this expected to be discoverable by the client? Would there be a > particular error code used, for example? > It's not so much intended to be discoverable but more to just note the possible exception to the tightening restrictions on redirect_uri values in the security BCP and OAuth 2.1. It's allowance/utilization will likely be determined for a whole deployment or ecosystem, which will also dictate the specific URI allowances and how clients are configured or registered with such info. Section 3 > > When the "application/x-www-form- > urlencoded" HTTP entity-body "request" parameter is used, the request > object MUST contain all the authorization request parameters as > claims of the JWT. Additional request parameters as required by the > given client authentication method are to be included as > 'application/x-www-form-urlencoded' parameters in the HTTP request > entity-body [...] > > I might flip this around and start off with "authentication request > parameters required by a given client authentication method are included > in the application/x-www-form-urlencoded request directly, and are the > only parameters other than 'request' in the form body. All other > request parameters, i.e., those pertaining to the authorization request > itself, MUST appear as claims of the JWT representing the authorization > request". The current formulation kind of hides the specifics of how to > determine which parameter goes where -- the spec for the client > authentication method in use is the authoritative one, IIUC. > That makes sense, I'll flip it around like you suggest (modulo a few wording tweaks). > 1. If applicable, decrypt the request object as specified in JAR > [I-D.ietf-oauth-jwsreq], section 6.1. > > 2. Validate the request object signature as specified in JAR > [I-D.ietf-oauth-jwsreq], section 6.2. > > Do we want to say anything more about error handling if decryption or > signature validation fails? > The referenced sections in JAR indicate "invalid_request_object" as the error code, which seems sufficient and doesn't warrant repeating here. Section 4 > > I think we should explicitly state that expired "request_uri"s are > rejected as invalid. > Sure, I can add that. Section 5 > > Note that the presence of "pushed_authorization_request_endpoint" is > sufficient for a client to determine that it may use the pushed > authorization request flow. A "request_uri" value obtained from the > PAR endpoint is usable at the authorization endpoint regardless of > other authorization server metadata such as > "request_uri_parameter_supported" or > "require_request_uri_registration". > > Since this is the only mention of it in this document, and it's an OIDC > parameter, maybe we should provide a reference for > "require_request_uri_registration"? > Sure, I'll add an informational reference to https://openid.net/specs/openid-connect-discovery-1_0.html > Section 7.1 > > An attacker could attempt to guess and replay a valid request URI > value and try to impersonate the respective client. [...] > > Just to confirm my analysis here: an attacker that does guess a valid > request URI value would probably also need to guess the corresponding > "client_id", and if the request used PKCE, would also need to guess the > PKCE value in order to successfully obtain a token response? I'm not > sure whether any of that is worth mentioning or not here, though. > While true, it's immaterial when the URI value itself is not guessable. So I don't think it needs mentioning. > Section 10.3 > > Section 12 > > Why is RFC 6749 not a normative reference? > Just a mistake due to a tooling misunderstanding - see the reply to the same issue raised by Zaheduzzaman Sarker https://mailarchive.ietf.org/arch/msg/oauth/Mx_6jDnlE4vjn4UvywNJ5QV4Y_M/ NITS > > Section 2 > > The pushed authorization request endpoint is an HTTP API at the > authorization server that accepts HTTP "POST" requests with > parameters in the HTTP request entity-body using the "application/x- > www-form-urlencoded" format with a character encoding of UTF-8 as > > I'm not sure where "entity-body" is defined as the name for the request > body in this case; draft-ietf-httpbis-semantics would seem to just have > us refer to this as the "message body". > Sure, I'll change it and the few other occurrences to "message body" (FWIW I think "entity-body" came from text borrowed from RFC 6749, which in turn used the term from RFC 2616). Section 2.1 > > The client adds the parameters in "x-www-form-urlencoded" format with > > I'd suggest a different word than "adds"; these paratmers are the entire > body, not appended to some earlier structure. > Okay. Maybe "constructs the request with parameters" or similar ... Some parameters of the example request (e.g., "state") are duplicated > across the multiple examples in the document. For those which are > typically single-use in practice, we might consider using different > values in the different examples (including in the JWT payload of the > example request in Section 3). > The JWT payload of the example request in Section 3 was kinda sorta meant to show what the same request from an earlier example in 2.1 would look like in JWT request form. So I might keep that. But in general the suggestion makes sense and I'll take a pass through the examples to try and ensure things that should be unique are unique. Section 7.4 > > The section heading is "Client Policy Change", which to me indicates a > change in the policy of the client, that is, what the client requires. > The text of the section indicates that this is discussing the AS's > per-client policy, though, so I wonder if there is a better phrasing > that could be used. > Maybe configuration rather than policy? I dunno. I'm tempted to just remove 7.4 --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000da31f605c6007b91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ben, I've endeavored to r= espond to your comments inline below. And I will/am working on related docu= ment updates but have some time off planned around the 4th of July so likel= y won't have a new revision out until next week sometime.=C2=A0

On Mon, Jun 28, 2021 at 1:45 PM Benjamin Kaduk via Datatracker <noreply@ietf.org> w= rote:
Benjamin K= aduk has entered the following ballot position for
draft-ietf-oauth-par-08: Yes

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oa= uth-par/


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I made a github PR with some editorial suggestions, at
https://github.com/oauthstuff/draft-oauth-par/p= ull/70 .

Merged on Monday. Thank yo= u.
=C2=A0

Section 1

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Those app= s typically invoke a
=C2=A0 =C2=A0custom tab with an URL that is translated into a GET request.= =C2=A0 Using
=C2=A0 =C2=A0"POST" would require the app to first open a web pag= e under its
=C2=A0 =C2=A0control in the custom tab that in turn would initiate the form= "POST"
=C2=A0 =C2=A0towards the authorization server.=C2=A0 PAR is simpler to use = and has
=C2=A0 =C2=A0additional security benefits as described above.

This description leaves me with a feeling that I only have an incomplete picture of why POST is "prohibitively difficult" to use with mobi= le
apps.=C2=A0 It seems like the setup is describing a scenario where the
authorization logic is operating inside a framework or environment
provided by some other entity that is unwilling or unable to change the
framework to accomodate new OAuth behavior.=C2=A0 Is this other entity the<= br> author of the mobile app, or an app framework, or somethint else?
Having a bit more description of the multiple entities involved and
which one is trying to control the specific mechanics of the
authorization request would make this depiction a more compelling
argument that POST is unusable.

I think= perhaps myself and co-authors are so familiar with it that it seems almost= self-evident. This is the second ballot comment on this paragraph, however= , so it seems some more work on the text is warranted. I'll try to elab= orate and better explain why it isn't particularly viable for a native = mobile app to cause the user's browser on the device to make a POST req= uest (with sizable body content).


=C2=A0
Section 1.1

=C2=A0 =C2=A0 =C2=A0POST /as/par HTTP/1.1
=C2=A0 =C2=A0 =C2=A0Host: as.example.com
=C2=A0 =C2=A0 =C2=A0Content-Type: application/x-www-form-urlencoded
=C2=A0 =C2=A0 =C2=A0Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUm= JuZlZkbUl3

My personal preference would be to have examples that just want a
generic HTTP authentication mechanism to use something stronger than
Basic, though I don't think this is something that I can insist on, at<= br> present.=C2=A0 (Applies throughout.)

I = wavered on this very point when putting together the examples but eventuall= y took the easy route and went with Basic (aka client_secret_basic). The th= ree such examples just want to show some form of OAuth client authenticatio= n happening. I think JWT based client assertion authentication using asymme= tric keys https://datatracker.ietf.org/doc/html/rfc7523#sectio= n-2.2 (aka private_key_jwt) is the only stronger mechanism that would s= how well in examples (MTLS/RFC8705 is hard to show in a meaningful way in a= n HTTP example). I could update the examples to use RFC7523 client_assertio= n/client_assertion_type parameter auth?


=
=C2=A0
=C2=A0 =C2=A0 =C2=A0HTTP/1.1 201 Created
=C2=A0 =C2=A0 =C2=A0Cache-Control: no-cache, no-store
=C2=A0 =C2=A0 =C2=A0Content-Type: application/json

=C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0"request_uri": "urn:example:bwc4J= K-ESC0w8acc191e-Y1LTC2",
=C2=A0 =C2=A0 =C2=A0 =C2=A0"expires_in": 90
=C2=A0 =C2=A0 =C2=A0}

The "request_uri" element's semantics feels like a very natur= al fit for
the native HTTP "Location" response header field (vs requiring a<= br> specific element in the JSON body of the response).=C2=A0 I am less sure th= at
there's a native HTTP element for the expiration time, as the HTTP
timeouts tend to be associated with HTTP caching vs the actual lifetime
of the resource.

The semantics feel sub= tly different in that the "request_uri" value is not used as-is b= y the client but rather as a query string parameter in the construction of = the full authorization request URI to which it will direct the user's b= rowser. I was also unsure whether the "Location" response header = field had to have a resolvable URI value (I didn't find text saying so = explicitly but it seems somewhat logical). Also, to me anyway, it made sens= e and was more consistent to keep the OAuth parameters at the same layer th= ey show up in other OAuth exchanges. And, as you note, there isn't an o= bvious HTTP field to convey the expiration time and putting some protocol d= ata in the headers and some in the JSON content payload seemed awkward.

That's some of the reasoning behind not usin= g the "Location" header.=C2=A0 Avoiding a breaking change at this= stage is another reason.

=C2=A0
Section 2

It feels a little unfortunate that we have to reuse the metadata
parameters relating to the token_endpoint_auth_method for PAR, but
creating new metadata parameters that are basically always going to hold the same values is probably worse...

I = believe the reuse is exactly what's wanted here. The unfortunate part i= s in the naming that, in retrospect, is overly specific. =C2=A0
= =C2=A0

https://www.iana.= org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters
has a dedicated column for "parameter usage location".=C2=A0 It s= eems like it
would be fairly straightforward to add "pushed authorization request&q= uot; as
an additional possible value there and remove the ambiguity.=C2=A0 We could=
enumerate the existing parameters that are applicable and update the
references for the registry to include this document.
=
I believe the text describes the situation pretty well and r= esolves the ambiguities sufficient for interoperable implementations/deploy= ments in practice. A registry update is possible but would be a significant= change with ongoing maintenance needs that aren't readily apparent whi= le not providing practical value.

=C2=A0
Section 2.1

=C2=A0 =C2=A0The authorization server MUST process the request as follows:<= br>
We often see descriptions along the lines of "this is not intended to<= br> constrain implementation techniques; any procedure that results in an
equivalent outcome is permissible".=C2=A0 This procedure is simple eno= ugh
that we may not need to have concerns of that nature, though.

Section 2.2

=C2=A0 =C2=A0*=C2=A0 "request_uri" : The request URI correspondin= g to the authorization
=C2=A0 =C2=A0 =C2=A0 request posted.=C2=A0 This URI is used as reference to= the respective
=C2=A0 =C2=A0 =C2=A0 request data in the subsequent authorization request o= nly.=C2=A0 [...]

Would it be appropriate to use the phrase "single-use" in this description?

Yes, I think so. I'll = add it.

=C2=A0
Section 2.4

=C2=A0 =C2=A0It is at the discretion of the authorization server to apply =C2=A0 =C2=A0restrictions on supplied "redirect_uri" values, e.g.= the
=C2=A0 =C2=A0authorization server MAY require a certain URI prefix or allow= only a
=C2=A0 =C2=A0query parameter to vary at runtime.

Is this expected to be discoverable by the client?=C2=A0 Would there be a particular error code used, for example?

It's not so much intended to be discoverable but more to just note th= e possible exception to the tightening restrictions on redirect_uri values = in the security BCP and OAuth 2.1. It's allowance/utilization will like= ly be determined for a whole deployment or ecosystem, which will also dicta= te the specific URI allowances and how clients are configured or registered= with such info.


Section 3

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When the "applicat= ion/x-www-form-
=C2=A0 =C2=A0urlencoded" HTTP entity-body "request" paramete= r is used, the request
=C2=A0 =C2=A0object MUST contain all the authorization request parameters a= s
=C2=A0 =C2=A0claims of the JWT.=C2=A0 Additional request parameters as requ= ired by the
=C2=A0 =C2=A0given client authentication method are to be included as
=C2=A0 =C2=A0'application/x-www-form-urlencoded' parameters in the = HTTP request
=C2=A0 =C2=A0entity-body [...]

I might flip this around and start off with "authentication request parameters required by a given client authentication method are included in the application/x-www-form-urlencoded request directly, and are the
only parameters other than 'request' in the form body.=C2=A0 All ot= her
request parameters, i.e., those pertaining to the authorization request
itself, MUST appear as claims of the JWT representing the authorization
request".=C2=A0 The current formulation kind of hides the specifics of= how to
determine which parameter goes where -- the spec for the client
authentication method in use is the authoritative one, IIUC.

That makes sense, I'll flip it around like you su= ggest (modulo a few wording tweaks).
=C2=A0
= =C2=A0
=C2=A0=C2=A0 1.=C2=A0 If applicable, decrypt the request object as specifie= d in JAR
=C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-oauth-jwsreq], section 6.1.

=C2=A0 =C2=A02.=C2=A0 Validate the request object signature as specified in= JAR
=C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-oauth-jwsreq], section 6.2.

Do we want to say anything more about error handling if decryption or
signature validation fails?

The referen= ced sections in JAR indicate "invalid_request_object" as the erro= r code, which seems sufficient and doesn't warrant repeating here.
=
=C2=A0

Section 4

I think we should explicitly state that expired "request_uri"s ar= e
rejected as invalid.

Sure, I can add th= at.


Section 5

=C2=A0 =C2=A0Note that the presence of "pushed_authorization_request_e= ndpoint" is
=C2=A0 =C2=A0sufficient for a client to determine that it may use the pushe= d
=C2=A0 =C2=A0authorization request flow.=C2=A0 A "request_uri" va= lue obtained from the
=C2=A0 =C2=A0PAR endpoint is usable at the authorization endpoint regardles= s of
=C2=A0 =C2=A0other authorization server metadata such as
=C2=A0 =C2=A0"request_uri_parameter_supported" or
=C2=A0 =C2=A0"require_request_uri_registration".

Since this is the only mention of it in this document, and it's an OIDC=
parameter, maybe we should provide a reference for
"require_request_uri_registration"?

Sure, I'll add an informational reference to https= ://openid.net/specs/openid-connect-discovery-1_0.html
= =C2=A0
=C2=A0
Section 7.1

=C2=A0 =C2=A0An attacker could attempt to guess and replay a valid request = URI
=C2=A0 =C2=A0value and try to impersonate the respective client.=C2=A0 [...= ]

Just to confirm my analysis here: an attacker that does guess a valid
request URI value would probably also need to guess the corresponding
"client_id", and if the request used PKCE, would also need to gue= ss the
PKCE value in order to successfully obtain a token response?=C2=A0 I'm = not
sure whether any of that is worth mentioning or not here, though.

=C2=A0While true, it's immaterial when the U= RI value itself is not guessable. So I don't think it needs mentioning.=

=C2=A0
Section 10.3

Section 12

Why is RFC 6749 not a normative reference?

<= div>Just a mistake due to a tooling misunderstanding - see the reply to the= same issue raised by Zaheduzzaman Sarker https= ://mailarchive.ietf.org/arch/msg/oauth/Mx_6jDnlE4vjn4UvywNJ5QV4Y_M/
=C2=A0

NITS

Section 2

=C2=A0 =C2=A0The pushed authorization request endpoint is an HTTP API at th= e
=C2=A0 =C2=A0authorization server that accepts HTTP "POST" reques= ts with
=C2=A0 =C2=A0parameters in the HTTP request entity-body using the "app= lication/x-
=C2=A0 =C2=A0www-form-urlencoded" format with a character encoding of = UTF-8 as

I'm not sure where "entity-body" is defined as the name for t= he request
body in this case; draft-ietf-httpbis-semantics would seem to just have
us refer to this as the "message body".

=
Sure, I'll change it and the few other occurrences to "= message body" (FWIW I think "entity-body" came from text bor= rowed from RFC 6749, which in turn used the term from RFC 2616).
<= div>=C2=A0

Section 2.1

=C2=A0 =C2=A0The client adds the parameters in "x-www-form-urlencoded&= quot; format with

I'd suggest a different word than "adds"; these paratmers are= the entire
body, not appended to some earlier structure.

=C2=A0Okay. Maybe "constructs the request with parameters"= or similar ...

Some parameters of the example request (e.g., "state") are duplic= ated
across the multiple examples in the document.=C2=A0 For those which are
typically single-use in practice, we might consider using different
values in the different examples (including in the JWT payload of the
example request in Section 3).
=C2=A0
The JW= T payload of the example request in Section 3 was kinda sorta meant to show= what the same request from an earlier example in 2.1 would look like in JW= T request form. So I might keep that. But in general the suggestion makes s= ense and I'll take a pass through the examples to try and ensure things= that should be unique are unique.


=
Section 7.4

The section heading is "Client Policy Change", which to me indica= tes a
change in the policy of the client, that is, what the client requires.
The text of the section indicates that this is discussing the AS's
per-client policy, though, so I wonder if there is a better phrasing
that could be used.

=C2=A0Maybe configu= ration rather than policy? I dunno. I'm tempted to just remove 7.4
=

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000da31f605c6007b91-- From nobody Wed Jun 30 14:12:35 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58443A2B23 for ; Wed, 30 Jun 2021 14:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyBYRgVJQbay for ; Wed, 30 Jun 2021 14:12:29 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16A193A2B22 for ; Wed, 30 Jun 2021 14:12:28 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id q18so7667483lfc.7 for ; Wed, 30 Jun 2021 14:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RcfgycE3jjaDiRBXeDEhor62y3wHbwDR0P+zCQiP47o=; b=T1WROlKmXWBN4SJQ7zDfthiAacaO+AqOrDEO/NWcSBsByQGVAwMYUz7UiDhq8Qi6ym 75m7WCPqhHoxdMjhY/hp/eeDRy0hUYZ6nx43Bgdt/F73+NiFNzdWjxh37MSyZ10api2V NFnDBwMpzou7vO/V4YDwSIUWUOQWjEyMIhAWGPzRSNFcaK5QexdD78V3PeMAXKKc1SZ9 bwMPud7NVIXBikNC1zY2aSP8CxKU7HuLK65k0lTrGluJ65qeANdMBhi+Co5MatanrcZE IsbJ8pvLEfs2HsMhs9a6yMAj2TAWx+R4+5bC6wn+f/I9wvl/4uo/5fzYs0n+7JUk9Wtg qLnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RcfgycE3jjaDiRBXeDEhor62y3wHbwDR0P+zCQiP47o=; b=U53fI5/Oy206fOa07vYO+iiBO5zFNH75iAKB5hlfcbkwiJIKmvRyULlr3245OY5Eh7 ThSiVzBjchiRkjsfTakD6xLg758jugSl2JiFLW1m5fES36hC28f2QTY3sIMzHoG+oeeS 9UMGRxne8Uov/A1muejccXryjqpqF+nGQIYzUggJXoZDr/eBfVAo6pV4OSwBrEgomXXt erd+iOWMOqdlTqjNPlt/td38AzlZewX1t0djSdcFlulIPAxwpFJu5wjVkp+wIEHe7+uN LBix2G6+amMhzW4kSaYxlPrP44CeSeDs82nPJkt6hstcmP965JDERMIPqoJbuLI479j/ 9fcw== X-Gm-Message-State: AOAM531WHv3JpQL9AtWt+PevaaeF2W41hch+q0/kesbQNpXXk8fr41/v f87pZVuu+m5MJLfLO4FgOuUnH3zIXGi1if/N/AACK5oImIowiiJ1VuhcP2hJyjStUtpRRJ8J6yA MhNiB2YTQR1hwkw== X-Google-Smtp-Source: ABdhPJxyxfpMpY07sp9u/rYJywTXGoP4sdAjjiSrhYsnF8K8C3TxeAL1IByHT6rSLFuH6PtxXhwS/whM+xBLZrHeoCk= X-Received: by 2002:ac2:4187:: with SMTP id z7mr11602911lfh.574.1625087546173; Wed, 30 Jun 2021 14:12:26 -0700 (PDT) MIME-Version: 1.0 References: <162495689162.17201.16673826726221874767@ietfa.amsl.com> In-Reply-To: <162495689162.17201.16673826726221874767@ietfa.amsl.com> From: Brian Campbell Date: Wed, 30 Jun 2021 15:11:59 -0600 Message-ID: To: Robert Wilton Cc: The IESG , draft-ietf-oauth-par@ietf.org, oauth-chairs@ietf.org, oauth , Hannes Tschofenig Content-Type: multipart/alternative; boundary="000000000000eb55df05c6022dcb" Archived-At: Subject: Re: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-par-08: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2021 21:12:35 -0000 --000000000000eb55df05c6022dcb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review Rob. I've endeavored to reply to your comments inline below. On Tue, Jun 29, 2021 at 2:54 AM Robert Wilton via Datatracker wrote: > Robert Wilton has entered the following ballot position for > draft-ietf-oauth-par-08: No Objection > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > Thanks for this document. Outside my area of expertise, but I have a > couple of > questions/comments: > > Section 2: > Due to historical reasons there is potential ambiguity regarding the > appropriate audience value to use when employing JWT client assertion > based authentication (defined in Section 2.2 of [RFC7523] with > "private_key_jwt" or "client_secret_jwt" authentication method names > per Section 9 of [OIDC]). To address that ambiguity the issuer > identifier URL of the authorization server according to [RFC8414] > SHOULD be used as the value of the audience. In order to facilitate > interoperability the authorization server MUST accept its issuer > identifier, token endpoint URL, or pushed authorization request > endpoint URL as values that identify it as an intended audience. > > I may be misunderstanding this text, but I note that by giving flexibilit= y > to > the client (i.e., the SHOULD) and being strict on the receiver (MUST > support x, > y, z), this seems to encourage a proliferation. Hence, I was wondering > whether > this might be better the other way round. I.e., be strict with what is > sent, > and less strict with what is received: MUST send 'issuer identifier', MUS= T > receive 'issuer identifier', SHOULD receive 'token endpoint URL' and > 'pushed > authorization request endpoint URL'? > While definitely not trying to encourage proliferation, the text is aiming to help interoperability while also accounting for the treatment in other documents (RFC7523/21) and existing implementations while also allowing for consistent processing to be implemented across the different endpoints where JWT client assertion based authentication can be employed. It's kinda tricky and I don't know for sure that the current text is exactly right but it's made it through the WG process and seen a number of implementations. > 2. > * "expires_in" : A JSON number that represents the lifetime of the > request URI in seconds as a positive integer. The request URI > lifetime is at the discretion of the authorization server but will > typically be relatively short (e.g., between 5 and 600 seconds). > > JSON numbers are doubles, but the value is a positive integer. Does it > make > sense to put in a hard limit of 2^53, or given that these are expected to > be > small numbers, 2^31 - 1? > I think the soft general guidance is enough and don't believe a hard upper limit is needed. 3. The success and error examples both define: > Content-Type: application/json > Cache-Control: no-cache, no-store > > The document states that the response should be JSON, but should it more > specifically specify the content type as "application/json"? Yeah, it probably should be that specific. I'll add the content type specificity to the document. > Similarly, the > cache control makes sense, but should the document mandate that the > response > must include "Cache-Control: no-cache, no-store"? > Although it makes sense not to cache I'm less comfortable mandating cache control stuff - particularly for a response to a POST (that I'm not sure is ever cacheable anyway) and for a client that is most likely not doing any caching at all and would immediately encounter failures if it were. Regards, > Rob > > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000eb55df05c6022dcb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review Rob. I've endeavored to re= ply to your comments inline below.
On Tu= e, Jun 29, 2021 at 2:54 AM Robert Wilton via D= atatracker <noreply@i= etf.org> wrote:
Robert Wilton has entered the following ballot position for draft-ietf-oauth-par-08: No Objection

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oa= uth-par/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for this document.=C2=A0 Outside my area of expertise, but I have a = couple of
questions/comments:

Section 2:
=C2=A0 =C2=A0Due to historical reasons there is potential ambiguity regardi= ng the
=C2=A0 =C2=A0appropriate audience value to use when employing JWT client as= sertion
=C2=A0 =C2=A0based authentication (defined in Section 2.2 of [RFC7523] with=
=C2=A0 =C2=A0"private_key_jwt" or "client_secret_jwt" a= uthentication method names
=C2=A0 =C2=A0per Section 9 of [OIDC]).=C2=A0 To address that ambiguity the = issuer
=C2=A0 =C2=A0identifier URL of the authorization server according to [RFC84= 14]
=C2=A0 =C2=A0SHOULD be used as the value of the audience.=C2=A0 In order to= facilitate
=C2=A0 =C2=A0interoperability the authorization server MUST accept its issu= er
=C2=A0 =C2=A0identifier, token endpoint URL, or pushed authorization reques= t
=C2=A0 =C2=A0endpoint URL as values that identify it as an intended audienc= e.

I may be misunderstanding this text, but I note that by giving flexibility = to
the client (i.e., the SHOULD) and being strict on the receiver (MUST suppor= t x,
y, z), this seems to encourage a proliferation.=C2=A0 Hence, I was wonderin= g whether
this might be better the other way round.=C2=A0 I.e., be strict with what i= s sent,
and less strict with what is received: MUST send 'issuer identifier'= ;, MUST
receive 'issuer identifier', SHOULD receive 'token endpoint URL= ' and 'pushed
authorization request endpoint URL'?

While definitely not trying to encourage proliferation, the text is aimin= g to help interoperability while also accounting for the treatment in other= documents (RFC7523/21)=C2=A0and existing implementations while also allowi= ng for consistent processing to be implemented across the different endpoin= ts where JWT client assertion based authentication can be employed. It'= s kinda tricky and I don't know for sure that the current text is exact= ly right but it's made it through the WG process and seen a number of i= mplementations.

=C2=A0
2.
=C2=A0 =C2=A0*=C2=A0 "expires_in" : A JSON number that represents= the lifetime of the
=C2=A0 =C2=A0 =C2=A0 request URI in seconds as a positive integer.=C2=A0 Th= e request URI
=C2=A0 =C2=A0 =C2=A0 lifetime is at the discretion of the authorization ser= ver but will
=C2=A0 =C2=A0 =C2=A0 typically be relatively short (e.g., between 5 and 600= seconds).

JSON numbers are doubles, but the value is a positive integer.=C2=A0 Does i= t make
sense to put in a hard limit of 2^53, or given that these are expected to b= e
small numbers, 2^31 - 1?

=C2=A0I think = the soft general guidance is enough and don't believe a hard upper limi= t is needed.


3. The success and error examples both define:
=C2=A0 =C2=A0 Content-Type: application/json
=C2=A0 =C2=A0 Cache-Control: no-cache, no-store

The document states that the response should be JSON, but should it more specifically specify the content type as "application/json"?

Yeah, it probably should be that specific. I&#= 39;ll add the content type specificity to the document.

=C2=A0
Similar= ly, the
cache control makes sense, but should the document mandate that the respons= e
must include "Cache-Control: no-cache, no-store"?
=C2=A0
Although it makes sense not to cache I'm les= s comfortable mandating cache control stuff - particularly for a response t= o a POST (that I'm not sure is ever cacheable anyway) and for a client = that is most likely not doing any caching at all and would immediately enco= unter failures if it were.
=C2=A0

Regards,
Rob




<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000eb55df05c6022dcb-- From nobody Wed Jun 30 18:48:20 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060833A0BD6; Wed, 30 Jun 2021 18:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxXu2fVnqMAJ; Wed, 30 Jun 2021 18:48:08 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B123A0BD4; Wed, 30 Jun 2021 18:48:07 -0700 (PDT) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1611lwh9013165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Jun 2021 21:48:02 -0400 Date: Wed, 30 Jun 2021 18:47:57 -0700 From: Benjamin Kaduk To: Brian Campbell Cc: The IESG , draft-ietf-oauth-par@ietf.org, oauth-chairs@ietf.org, oauth , Hannes Tschofenig Message-ID: <20210701014757.GM17170@mit.edu> References: <162490954694.18608.7401442671159157596@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-par-08: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2021 01:48:14 -0000 Hi Brian, On Wed, Jun 30, 2021 at 01:10:37PM -0600, Brian Campbell wrote: > Thanks Ben, I've endeavored to respond to your comments inline below. And I > will/am working on related document updates but have some time off planned > around the 4th of July so likely won't have a new revision out until next > week sometime. Understandable! > On Mon, Jun 28, 2021 at 1:45 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-oauth-par-08: Yes > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I made a github PR with some editorial suggestions, at > > https://github.com/oauthstuff/draft-oauth-par/pull/70 . > > > > Merged on Monday. Thank you. > > > Section 1 > > > > Those apps typically invoke a > > custom tab with an URL that is translated into a GET request. Using > > "POST" would require the app to first open a web page under its > > control in the custom tab that in turn would initiate the form "POST" > > towards the authorization server. PAR is simpler to use and has > > additional security benefits as described above. > > > > This description leaves me with a feeling that I only have an incomplete > > picture of why POST is "prohibitively difficult" to use with mobile > > apps. It seems like the setup is describing a scenario where the > > authorization logic is operating inside a framework or environment > > provided by some other entity that is unwilling or unable to change the > > framework to accomodate new OAuth behavior. Is this other entity the > > author of the mobile app, or an app framework, or somethint else? > > Having a bit more description of the multiple entities involved and > > which one is trying to control the specific mechanics of the > > authorization request would make this depiction a more compelling > > argument that POST is unusable. > > > > I think perhaps myself and co-authors are so familiar with it that it seems > almost self-evident. This is the second ballot comment on this paragraph, > however, so it seems some more work on the text is warranted. I'll try to > elaborate and better explain why it isn't particularly viable for a native > mobile app to cause the user's browser on the device to make a POST request > (with sizable body content). I think that even mentioning that there are ecosystem pressures to use the native (OS?) browser for an otherwise independent app (that acts as OAuth client) would be helpful. The fact that the interface between native apps and the system browser has limitations should be fairly easy to accept as a fact of life, whereas the current text invites the reader to ask "but can't you just make a POST request yourself? Why is that so hard?". > > > > > Section 1.1 > > > > POST /as/par HTTP/1.1 > > Host: as.example.com > > Content-Type: application/x-www-form-urlencoded > > Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 > > > > My personal preference would be to have examples that just want a > > generic HTTP authentication mechanism to use something stronger than > > Basic, though I don't think this is something that I can insist on, at > > present. (Applies throughout.) > > > > I wavered on this very point when putting together the examples but > eventually took the easy route and went with Basic (aka > client_secret_basic). The three such examples just want to show some form > of OAuth client authentication happening. I think JWT based client > assertion authentication using asymmetric keys > https://datatracker.ietf.org/doc/html/rfc7523#section-2.2 (aka > private_key_jwt) is the only stronger mechanism that would show well in > examples (MTLS/RFC8705 is hard to show in a meaningful way in an HTTP > example). I could update the examples to use RFC7523 > client_assertion/client_assertion_type parameter auth? That would address my concern, but I understand that it's a nontrivial amount of work and definitely am not insisting on it. > > > > > HTTP/1.1 201 Created > > Cache-Control: no-cache, no-store > > Content-Type: application/json > > > > { > > "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2", > > "expires_in": 90 > > } > > > > The "request_uri" element's semantics feels like a very natural fit for > > the native HTTP "Location" response header field (vs requiring a > > specific element in the JSON body of the response). I am less sure that > > there's a native HTTP element for the expiration time, as the HTTP > > timeouts tend to be associated with HTTP caching vs the actual lifetime > > of the resource. > > > > The semantics feel subtly different in that the "request_uri" value is not > used as-is by the client but rather as a query string parameter in the > construction of the full authorization request URI to which it will direct > the user's browser. I was also unsure whether the "Location" response > header field had to have a resolvable URI value (I didn't find text saying > so explicitly but it seems somewhat logical). Also, to me anyway, it made > sense and was more consistent to keep the OAuth parameters at the same > layer they show up in other OAuth exchanges. And, as you note, there isn't > an obvious HTTP field to convey the expiration time and putting some > protocol data in the headers and some in the JSON content payload seemed > awkward. > > That's some of the reasoning behind not using the "Location" header. > Avoiding a breaking change at this stage is another reason. Indeed. And to be honest, the last one is pretty compelling. (I am not an HTTP expert and should not opine on whether the Location response value has to be resolvable or not. I do think that "the location of the resource that was created" is a good fit even if the resource itself is not accessed directly by the entity that receives the HTTP response with the location header field -- a URI is a way to identify a resource, after all, and that identifier can be passed around to other entities.) > > > > Section 2 > > > > It feels a little unfortunate that we have to reuse the metadata > > parameters relating to the token_endpoint_auth_method for PAR, but > > creating new metadata parameters that are basically always going to hold > > the same values is probably worse... > > > > I believe the reuse is exactly what's wanted here. The unfortunate part is > in the naming that, in retrospect, is overly specific. Er, yes, exactly that. > Section 2.1 > > > > Any token endpoint parameters that are not related > > to client authentication have no defined meaning for a pushed > > authorization request. [...] > > > > I suppose that in most cases, whether or not a token endpoint parameter > > is related to client authentication should be fairly unambiguous ... but > > the registry at > > > > https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters > > has a dedicated column for "parameter usage location". It seems like it > > would be fairly straightforward to add "pushed authorization request" as > > an additional possible value there and remove the ambiguity. We could > > enumerate the existing parameters that are applicable and update the > > references for the registry to include this document. > > > > I believe the text describes the situation pretty well and resolves the > ambiguities sufficient for interoperable implementations/deployments in > practice. A registry update is possible but would be a significant change > with ongoing maintenance needs that aren't readily apparent while not > providing practical value. I won't insist on anything; the benefit would mostly be "ideological cleanliness" which is not very tangible. > > > > Section 2.1 > > > > The authorization server MUST process the request as follows: > > > > We often see descriptions along the lines of "this is not intended to > > constrain implementation techniques; any procedure that results in an > > equivalent outcome is permissible". This procedure is simple enough > > that we may not need to have concerns of that nature, though. > > > > Section 2.2 > > > > * "request_uri" : The request URI corresponding to the authorization > > request posted. This URI is used as reference to the respective > > request data in the subsequent authorization request only. [...] > > > > Would it be appropriate to use the phrase "single-use" in this > > description? > > > > Yes, I think so. I'll add it. > > > > > Section 2.4 > > > > It is at the discretion of the authorization server to apply > > restrictions on supplied "redirect_uri" values, e.g. the > > authorization server MAY require a certain URI prefix or allow only a > > query parameter to vary at runtime. > > > > Is this expected to be discoverable by the client? Would there be a > > particular error code used, for example? > > > > It's not so much intended to be discoverable but more to just note the > possible exception to the tightening restrictions on redirect_uri values in > the security BCP and OAuth 2.1. It's allowance/utilization will likely be > determined for a whole deployment or ecosystem, which will also dictate the > specific URI allowances and how clients are configured or registered with > such info. Okay. > > Section 3 > > > > When the "application/x-www-form- > > urlencoded" HTTP entity-body "request" parameter is used, the request > > object MUST contain all the authorization request parameters as > > claims of the JWT. Additional request parameters as required by the > > given client authentication method are to be included as > > 'application/x-www-form-urlencoded' parameters in the HTTP request > > entity-body [...] > > > > I might flip this around and start off with "authentication request > > parameters required by a given client authentication method are included > > in the application/x-www-form-urlencoded request directly, and are the > > only parameters other than 'request' in the form body. All other > > request parameters, i.e., those pertaining to the authorization request > > itself, MUST appear as claims of the JWT representing the authorization > > request". The current formulation kind of hides the specifics of how to > > determine which parameter goes where -- the spec for the client > > authentication method in use is the authoritative one, IIUC. > > > > That makes sense, I'll flip it around like you suggest (modulo a few > wording tweaks). > > > > > 1. If applicable, decrypt the request object as specified in JAR > > [I-D.ietf-oauth-jwsreq], section 6.1. > > > > 2. Validate the request object signature as specified in JAR > > [I-D.ietf-oauth-jwsreq], section 6.2. > > > > Do we want to say anything more about error handling if decryption or > > signature validation fails? > > > > The referenced sections in JAR indicate "invalid_request_object" as the > error code, which seems sufficient and doesn't warrant repeating here. Okay, makes sense. > > Section 4 > > > > I think we should explicitly state that expired "request_uri"s are > > rejected as invalid. > > > > Sure, I can add that. > > > Section 5 > > > > Note that the presence of "pushed_authorization_request_endpoint" is > > sufficient for a client to determine that it may use the pushed > > authorization request flow. A "request_uri" value obtained from the > > PAR endpoint is usable at the authorization endpoint regardless of > > other authorization server metadata such as > > "request_uri_parameter_supported" or > > "require_request_uri_registration". > > > > Since this is the only mention of it in this document, and it's an OIDC > > parameter, maybe we should provide a reference for > > "require_request_uri_registration"? > > > > Sure, I'll add an informational reference to > https://openid.net/specs/openid-connect-discovery-1_0.html > > > > > Section 7.1 > > > > An attacker could attempt to guess and replay a valid request URI > > value and try to impersonate the respective client. [...] > > > > Just to confirm my analysis here: an attacker that does guess a valid > > request URI value would probably also need to guess the corresponding > > "client_id", and if the request used PKCE, would also need to guess the > > PKCE value in order to successfully obtain a token response? I'm not > > sure whether any of that is worth mentioning or not here, though. > > > > While true, it's immaterial when the URI value itself is not guessable. So > I don't think it needs mentioning. Okay. > > > > Section 10.3 > > > > Section 12 > > > > Why is RFC 6749 not a normative reference? > > > > Just a mistake due to a tooling misunderstanding - see the reply to the > same issue raised by Zaheduzzaman Sarker > https://mailarchive.ietf.org/arch/msg/oauth/Mx_6jDnlE4vjn4UvywNJ5QV4Y_M/ > > > NITS > > > > Section 2 > > > > The pushed authorization request endpoint is an HTTP API at the > > authorization server that accepts HTTP "POST" requests with > > parameters in the HTTP request entity-body using the "application/x- > > www-form-urlencoded" format with a character encoding of UTF-8 as > > > > I'm not sure where "entity-body" is defined as the name for the request > > body in this case; draft-ietf-httpbis-semantics would seem to just have > > us refer to this as the "message body". > > > > Sure, I'll change it and the few other occurrences to "message body" (FWIW > I think "entity-body" came from text borrowed from RFC 6749, which in turn > used the term from RFC 2616). > > > Section 2.1 > > > > The client adds the parameters in "x-www-form-urlencoded" format with > > > > I'd suggest a different word than "adds"; these paratmers are the entire > > body, not appended to some earlier structure. > > > > Okay. Maybe "constructs the request with parameters" or similar ... > > > Some parameters of the example request (e.g., "state") are duplicated > > across the multiple examples in the document. For those which are > > typically single-use in practice, we might consider using different > > values in the different examples (including in the JWT payload of the > > example request in Section 3). > > > > The JWT payload of the example request in Section 3 was kinda sorta meant > to show what the same request from an earlier example in 2.1 would look > like in JWT request form. So I might keep that. But in general the If you do, please note that it's intended to match up! > suggestion makes sense and I'll take a pass through the examples to try and > ensure things that should be unique are unique. Thanks! > Section 7.4 > > > > The section heading is "Client Policy Change", which to me indicates a > > change in the policy of the client, that is, what the client requires. > > The text of the section indicates that this is discussing the AS's > > per-client policy, though, so I wonder if there is a better phrasing > > that could be used. > > > > Maybe configuration rather than policy? I dunno. I'm tempted to just > remove 7.4 I'd prefer leaving it alone over removing it, if we can't find any wordings that we like better than what's there. Thanks for all the responses and updates! -Ben From nobody Wed Jun 30 22:48:10 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F5D3A13AA; Wed, 30 Jun 2021 22:47:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-oauth-par@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, hannes.tschofenig@arm.com X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <162511847243.31399.17160212703912299773@ietfa.amsl.com> Date: Wed, 30 Jun 2021 22:47:53 -0700 Archived-At: Subject: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-par-08: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2021 05:47:53 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-oauth-par-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I concur with Ben and Zahed that RFC 6749 should be listed as a normative reference. Section 1: * "The impact of which can be ..." -- s/which/this/ * "personal identifiable information" -- s/personal/personally/ * In the final paragraph, since you quote "POST", you should quote "GET" as well. Section 7.2: * "An attacker could try register ..." -- s/try/try to/ In Section 7.3, I think that SHOULD ought to be a MUST. Is there a good reason not to do what it says? The field names in Section 10.2 don't match the field names in the registry.