From nobody Sat Aug 1 07:44:56 2020 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 29DDC3A0B32 for ; Sat, 1 Aug 2020 07:44: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, 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 (1024-bit key) header.d=adorsys.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 IJXqDD2AyK5u for ; Sat, 1 Aug 2020 07:44:53 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 E899F3A0B2C for ; Sat, 1 Aug 2020 07:44:52 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id c80so10749342wme.0 for ; Sat, 01 Aug 2020 07:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:from:date:message-id:subject:to; bh=FNKMYGRUk74YAwWQYXghnFRyuSa4NzFF3d350XFZlfI=; b=hr1ZC4M4PE92yZ5VVgtQAk9UY5XtPtenQk0bWBFp4x5iG/L7mn8WBn4YuX2JKCor6h 7gqRDQAqe/NMU53/q2WFTfuhyMyICFU7HzLy86G2mYkeDwknogYt/622db4qdbFyuXFO kb3qOt0yTk83vF20OSlFFFFgJUhkMltKyVodA= 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=FNKMYGRUk74YAwWQYXghnFRyuSa4NzFF3d350XFZlfI=; b=FQQaiJDJCggWbAUghy16LTVZfYJqFLSwztIb+vawqwKK9990YHbqHpzeC7hicl/2Fh 4jb9O0Km4/pM7ykOQJ0PASgRlJHkom8Awk2p97jx7SOWtgXJXou3BLZEiWiuSNdhu2NJ ot3micjwmYOf9SdEA9akXdVRdwMsBcvwPFBzMxBZ26YhH0E7+yynm0IXNLO3p9ac+5vZ AoB1ueUxkTMSRfbJjXNFZzuUBEK0Q9IHzAXI2TVawKN4yGa5gDlzAi6xA8Wm+kphaj54 InUZkAiRD8wFLFCE5PnBe3wxsYaUCrtGdTljtBq1++9otWfZrHAXRYb2o6OeGtOjXQIP YlZg== X-Gm-Message-State: AOAM5311rvPuxChqA67mt4ZjRDhcsUJzxWrdZGwNqn8pS55DYWDr4uww wxWIUY3mMM1cWoUFLFB12CalP4KUgfMqe2gpdNryd4eR/Fs= X-Google-Smtp-Source: ABdhPJz8jxLdDV93ThA/1jJ87nakkClEUKRqvfNaT4imHkHz4gp5YkEPEFOyWHkzbnTXtf65zw+RRM76JjsURYK7RpQ= X-Received: by 2002:a7b:c3d4:: with SMTP id t20mr8221488wmj.8.1596293090890; Sat, 01 Aug 2020 07:44:50 -0700 (PDT) MIME-Version: 1.0 From: Francis Pouatcha Date: Sat, 1 Aug 2020 10:44:40 -0400 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="000000000000a3eadb05abd1f238" Archived-At: Subject: [OAUTH-WG] Review of draft-ietf-oauth-jwsreq-26.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: Sat, 01 Aug 2020 14:44:55 -0000 --000000000000a3eadb05abd1f238 Content-Type: text/plain; charset="UTF-8" Below is my review of the draft-ietf-oauth-jwsreq-26.txt: Section: 1. Introduction : Signed JWT also provides for non repudiation. Under the section: Using JWT [RFC7519] as the request encoding instead of query parameters has several advantages: Therefore I suggest adding this: ... (e) (non repudiation) the signed JWT request can be archived by the AS as is and used later in investigation and auditing processes. Section: 10.5 Text block repeated twice" <> Section: 12.1 Must a TFP validate every single authorization request to be sent by Client to AS? I thought: - Certificate issued by TFP is proof that the client abides by trust framework principles. Certificate can also contain details on resources accessible to client (e.g. AIS, PIS) - AS understands the content of the certificate and can use it to validate adherence of client to TF. Removing the need to have to send each authz request to the TFP for validation. Best regards, -- Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --000000000000a3eadb05abd1f238 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Below is my review of the=C2=A0draft-ietf-oauth-jwsreq-26.= txt:

Section: 1. Introduction :=C2=A0Signed JWT also provides for no= n repudiation.

Under the section:=C2=A0
Using JWT [RFC7519] = as the request encoding instead of query parameters has several advantages:=

Therefore I suggest adding this:=C2=A0
...
(e) (no= n repudiation) the signed JWT request can be archived by the AS as is and u= sed later in investigation and auditing processes.


Section: 10.5=
Text block repeated twice"
<<When the value of it as a s= erver metadata is "true", then the server
=C2=A0 =C2=A0MUST re= ject the authorization request from any client that does not
=C2=A0 =C2= =A0conform to this specification.=C2=A0 It MUST also reject the request if<= br>=C2=A0 =C2=A0the request object uses "alg":"none".= =C2=A0 If omitted, the default value
=C2=A0 =C2=A0is "false".&= gt;>

Section: 12.1
Must a TFP validate every single authoriza= tion request to be sent by Client to AS?

I thought:
- Certificate= issued by TFP is proof that the client abides by trust framework principle= s. Certificate can also contain details on resources accessible to client (= e.g. AIS, PIS)
- AS understands the content of the certificate and can u= se it to validate adherence of client to TF. Removing the need to have to s= end each authz request to the TFP for validation.

=

Best regards,

--
<= div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature= ">
Francis Pouatcha
Co-Founder and Technical Lea= d
adorsys GmbH & Co. KG
--000000000000a3eadb05abd1f238-- From nobody Mon Aug 3 07:42:18 2020 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 EE97A3A0B79 for ; Mon, 3 Aug 2020 07:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 FVBpZk22js9F for ; Mon, 3 Aug 2020 07:42:10 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106B83A0B51 for ; Mon, 3 Aug 2020 07:42:09 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BL0w00bqhz17qv; Mon, 3 Aug 2020 16:42:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAF0C2A@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Mon, 3 Aug 2020 16:42:06 +0200 Cc: Stephen Farrell , "oauth@ietf.org" X-Mao-Original-Outgoing-Id: 618158526.810256-afc169bc568f7e8545bf4e589f6ebb9f Content-Transfer-Encoding: quoted-printable Message-Id: <6A795E47-860D-4A1C-89B6-565937BEEFC7@tzi.org> References: <20141002120308.9386.79961.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C2A@TK5EX14MBXC286.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and 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: Mon, 03 Aug 2020 14:42:17 -0000 On 2014-10-06, at 09:54, Mike Jones wrote: >> - 4.1.7: maybe worth adding that jti+iss being unique enough is not = sufficient and >> jti alone has to meet that need. In >> X.509 the issuer/serial has the equivalent property so someone might = assume >> sequential jti values starting at 0 are ok. >=20 > Makes sense to add a warning of some kind along these lines. I think = I know the reasons you say that, but can you expand on that thought a = bit before I take a stab on writing this up? For instance, while = normally true, I don't think your observation is true if a relying party = will only accept tokens from a single issuer. So can someone remind me why jti needs to be unique globally, and not = just per issuer? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 3 11:48:24 2020 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 C46E93A09B9 for ; Mon, 3 Aug 2020 11:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 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_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 3ScUMAGyLDeW for ; Mon, 3 Aug 2020 11:48:21 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 5115C3A0A36 for ; Mon, 3 Aug 2020 11:48:21 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id f7so35188165wrw.1 for ; Mon, 03 Aug 2020 11:48:21 -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=HI590DgDtZXDw/q0WqizYaMnTmjL00+Oy2elL9yEq94=; b=Ix8TjpdG16ImOyJl+wD6iy6oXczlUyM3guJK9R2tsqSySDisucg6hGo5pUj/pFAk8u 7nv7evgZwpF5JtPt+BfqRUs6CmuIe079AYCb1A97hg/rlaaeRmNuYo/46NlRRbH06V3G m5RTLaB+3Ah9nE+MCbSjKf6JFQEGb+tzTKTIEkOhTI0bk7d1s6Q0fEjQakRc09VIXmgz 7jS0lswXKQSvSFA0ZKhhC9arrovzCEjKbEUaMOlnW+MTmi7TL3Kb7cXBt4MWdG4EZ9g5 FWyxeegxV28B5TkLXnbxYESTHANUoNhCCcjz1OuCTWt4Ds8MFoGODxxZh2y97F1VTT3K Wnng== 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=HI590DgDtZXDw/q0WqizYaMnTmjL00+Oy2elL9yEq94=; b=mx9y6DkEC1GsU3sx4mPtWia68cLW+vLtNFjsPvfKFwifZvc+JB7UcYlLUDra57Qjuc PcoBPiyvbfenUQD0hfoSKmdMpWc/W9ns7utm/fsW13sAhs5y2K+DR89fXvU63BEwoFQh VVi219guJq3/pJyNaWTOWxiDIWVxPq7fjAUcJ6TZaFgY6CVsvrHUNiCr5dcG63nE4921 698PqfbhnyC5Qb/v7KpDrhdux+9bSTwGzQQBurrXh+x+OtEpJ14lYK6RKqNG3EfGjH5X fJGzs4z/Teh9wNMVr1IzaKrEX8FMerApt6xIrfOgsNoenv2/8nBD2Q/kINEDEPmx63Uw 1XJw== X-Gm-Message-State: AOAM533g420dwzEbwqB/m5eXzpw498y4bDfOUXecn0oNrAU/6Z4Z+TPH PgoQlAt+M1IrEObybSsucCXtfahtf5qh7j4pp9E+H36J X-Google-Smtp-Source: ABdhPJwbvXvoDmIVLsBuNq6od2HuEntDXzzGVtWA3u/nyGFoyKJtia+hpetf04N6Xr39wHF3CmSKWYrsBo31uHI5cwc= X-Received: by 2002:adf:f151:: with SMTP id y17mr17321969wro.179.1596480499695; Mon, 03 Aug 2020 11:48:19 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Mon, 3 Aug 2020 14:48:08 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000013429d05abfd958c" Archived-At: Subject: [OAUTH-WG] OAuth Interim Aug 3rd Minutes 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, 03 Aug 2020 18:48:23 -0000 --00000000000013429d05abfd958c Content-Type: text/plain; charset="UTF-8" All, You can find the meeting minutes and meeting recording here: https://www.ietf.org/proceedings/interim-2020-oauth-10/minutes/minutes-interim-2020-oauth-10-202008031200-00 Thanks to Dick Hardt for taking notes. Regards, Rifaat --00000000000013429d05abfd958c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

You can find the meeting=C2=A0minu= tes and meeting recording=C2=A0here:

<= /div>
Thanks to Dick Hardt for taking notes.

R= egards,
=C2=A0Rifaat

--00000000000013429d05abfd958c-- From nobody Wed Aug 5 01:47:12 2020 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 7C35E3A0FB3; Wed, 5 Aug 2020 01:47:07 -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-jwsreq@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Hannes.Tschofenig@gmx.net X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <159661722741.30500.10022053097818080667@ietfa.amsl.com> Date: Wed, 05 Aug 2020 01:47:07 -0700 Archived-At: Subject: [OAUTH-WG] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-oauth-jwsreq-26=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: Wed, 05 Aug 2020 08:47:08 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-oauth-jwsreq-26: 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below a couple of non-blocking COMMENTs. I hope that this helps to improve the document, Regards, -éric == COMMENTS == Should the document shepherd's write-up be updated ? It is dated October 2016... about 4 years ago. -- Section 5.2 -- Based on the long history of this document, is the following statement "Many phones in the market as of this writing still" still valid ? -- Section 5.2.1 -- Suggest to give a hint about the use of tfp.example.org (TFP is expanded only in section 10.2). == NITS == Please check the ID-NITS at https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-oauth-jwsreq-26.txt From nobody Wed Aug 5 01:56:25 2020 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 266053A0FBE for ; Wed, 5 Aug 2020 01:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.447 X-Spam-Level: X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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, TVD_SPACE_RATIO=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 RQUaoleQBOuA for ; Wed, 5 Aug 2020 01:56:22 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 07D0E3A0FB7 for ; Wed, 5 Aug 2020 01:56:22 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id kq25so32581263ejb.3 for ; Wed, 05 Aug 2020 01:56:21 -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=+dfIAyZGBugXl85JdZUPurUlXJNrHqOX9Zu5kxQhKWs=; b=XDKMqt+FvVJKxeVvWk9/ZSA4Ixf0RE5xlhaSaMPZVjNtK7WFvFZOEgMYbO7G9q3V7S a+fLL9jI0M1bUrU82vYrY/fJMbIsjfXyTDO/hzPJddl2NgTsf1Rk5woA/+58TN+gP74O YE7r95OieiVtHLT03+8acrdkDwbkYKxN0VyYY4M4hPqPUb2JQsEyAELcofLvO87cirTl HlhrMkNZnhpwDlk9ditEVmRUcFTKnTTmYOYR1hstVKXk719EU5+5ifYd74caxYIEqLKu sVgOC/csaDlZh1qRCSKGfXg3o3RHeKZx1Q7nG82ATP49668ntfu/HaRE7U8krgAu2Klt 5Mxg== 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=+dfIAyZGBugXl85JdZUPurUlXJNrHqOX9Zu5kxQhKWs=; b=Fna47zkO22V0nABKNFj2eYjf72ap1IR8+Ijwp8IZCdB+XXjZL50afe7q3tpnjGnK5D 6IEXooJkZanZBy7gUcQkQGVWvyPF+6S0Ew1j8wPIUzh77F32yCYiGWGk6WMCCOuIXbZx OHyi1bFYDmqmEs/aRvrSPtWPYwedaX2MtdHrQ8aHxDDs6nNYOUxNS3HDtgPz7KOz6W2d TJT0dlu2csDgxLB7KE7174BJsfsnpmPQr4bTGkNiUD8n+osjH6EEe6FmLS2xsibsiNAG gZ+nIihfhduLnUN+mJ8+P/EONpehPV/kkmuWr5vV0SUlqMI4d192L8VIOJ0m4bkHzCCT ERxg== X-Gm-Message-State: AOAM5337Tsjkx47UFTyWXFlsgxcsfrGbZkk5CnNhEGw7GZ9kJ55vBuQd 5FDPUVF6aBeejIGSyfK2MMlkX6514GTtk3HUpvBZv8XT X-Google-Smtp-Source: ABdhPJxfGALk+UxoiRXcezyVABjIK+BJWAxjjKTdV9JaATm1RciMJ9RtJBUqpoGE8nvxS7hAgAAPIHe14pH/HnTz7fk= X-Received: by 2002:a17:906:3616:: with SMTP id q22mr2297354ejb.79.1596617780209; Wed, 05 Aug 2020 01:56:20 -0700 (PDT) MIME-Version: 1.0 From: Umair Aziz Date: Wed, 5 Aug 2020 13:56:08 +0500 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000a1aabc05ac1d8be9" Archived-At: Subject: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq 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, 05 Aug 2020 08:56:23 -0000 --000000000000a1aabc05ac1d8be9 Content-Type: text/plain; charset="UTF-8" --000000000000a1aabc05ac1d8be9 Content-Type: text/html; charset="UTF-8"
--000000000000a1aabc05ac1d8be9-- From nobody Wed Aug 5 03:02:03 2020 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 A82B63A1410 for ; Wed, 5 Aug 2020 03:02:01 -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 (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 Vb7IwptK972A for ; Wed, 5 Aug 2020 03:01:59 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 0B39F3A13EC for ; Wed, 5 Aug 2020 03:01:58 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id f7so40131801wrw.1 for ; Wed, 05 Aug 2020 03:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=2SLqYBWWpu/U8p2lq/osB4IV9AP7Y4VPpki9+fFrUkk=; b=ipbTAGCo9Ffrz/mETXY0hjLNSZAeJqQSDn3Ec7O2WBBlxXEPrWM/tpv66jwkECbx1+ DB+XIeaNGDjYKWBkB1x40xf+vROd3M2UIfhwYs8tVP6rNWRAJmJVebYq8VP4d8FyRhSX hjDkTTxYJJo4kU0CSocpXQv7EzdVbMIdhzqUc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=2SLqYBWWpu/U8p2lq/osB4IV9AP7Y4VPpki9+fFrUkk=; b=tA27yQxsonF9uYbM5NnH7SBq+Rt38s8t7K3FBZSF88s57Fv1p0V6/IRKAAaDVkjQNp ZOvuC8f5rtBvRlO/ENsUqlZBkPQfxNNubnaCwe44ORPhvJfw6A0OpUjVFIOahFL1B+u/ CGgYrqJydenhdDFvWHmeg61jPDEvk90nipCh1pOOv1DxvbFd7QoJoHlUUlkUb1OEcQdA zH4sfRF3wm674SBLIE7OoVC5UWJrEz8t1wZfMLhzms8DrhAklsQrLPZXvgCIDoQjo9Ce W+Dd+YhmHzbeOf3WlQHjKBLPKyDJ8wR2AGNB+rXUJ6MhWSXFTZDKbvjnn+/4gLNbfrs+ sIpg== X-Gm-Message-State: AOAM533qYDmq7BbQgEfo5r4eV5Sg9bTL1lsbqgVKaB7AI4HaqztXCE1x 1Vk3ACE3j8XlKJNX2MOD/9EU1AxIAEZkB4g7yn4GIl5NrnF7iV/X4JF/sZQOrw1Nx2OamYhXMh3 16StHSxwJEISgX1USx32OCgNGTaoYI8tp2x+CpHrY7Z0OklVF7KvyZ/kG+N/Tpuc= X-Google-Smtp-Source: ABdhPJxqJSzia+xi0zd5NyzCGFX6C2LT7IGQYULEbxCdFzrGV8s1m1kFnGxcrEZ0VTx/CpAZJtzItg== X-Received: by 2002:a5d:6910:: with SMTP id t16mr2229580wru.178.1596621716644; Wed, 05 Aug 2020 03:01:56 -0700 (PDT) Received: from [10.0.0.6] (38.227.143.150.dyn.plus.net. [150.143.227.38]) by smtp.gmail.com with ESMTPSA id y142sm2229301wmd.3.2020.08.05.03.01.55 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2020 03:01:56 -0700 (PDT) From: Neil Madden Content-Type: multipart/alternative; boundary="Apple-Mail=_655AD172-4341-42B1-8EE1-8D816722FF95" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <0DEE1AC7-2EA7-420F-B0B5-6F96A3D04D1C@forgerock.com> Date: Wed, 5 Aug 2020 11:01:55 +0100 To: oauth X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [OAUTH-WG] ECDH-1PU encryption algorithm 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, 05 Aug 2020 10:02:02 -0000 --Apple-Mail=_655AD172-4341-42B1-8EE1-8D816722FF95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, You may remember me from such I-Ds as = https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03 = , which = proposes adding a new encryption algorithm to JOSE. I=E2=80=99d like to = reserve a bit of time to discuss it at one of the upcoming interim = meetings. The basic idea is that in many cases in OAuth and OIDC you want to = ensure both confidentiality and authenticity of some token - for example = when transferring an ID token containing PII to the client through the = front channel, or for access tokens intended to be handled by a specific = RS without online token introspection (such as the JWT access token = draft). If you have a shared secret key between the AS and the client/RS = then you can use symmetric authenticated encryption (alg=3Ddir or = alg=3DA128KW etc). But if you need to use public key cryptography then = currently you are limited to a nested signed-then-encrypted JOSE = structure, which produces much larger token sizes. The draft adds a new =E2=80=9Cpublic key authenticated encryption=E2=80=9D= mode based on ECDH in the NIST standard =E2=80=9Cone-pass unified=E2=80=9D= model. The primary advantage for OAuth usage is that the tokens = produced are more compact compared to signing+encryption (~30% smaller = for typical access/ID token sizes in compact serialization). = Performance-wise, it=E2=80=99s roughly equivalent. I know that size = concerns are often a limiting factor in choosing whether to encrypt = tokens, so this should help. In terms of implementation, it=E2=80=99s essentially just a few extra = lines of code compared to an ECDH-ES implementation. (Some JOSE library = APIs might need an adjustment to accommodate the extra private key = needed for encryption/public key for decryption). I=E2=80=99ve received a few emails off-list from people interested in = using it for non-OAuth use-cases such as secure messaging applications. = I think these use-cases can be accommodated without significant changes, = so I think the OAuth WG would be a good venue for advancing this. I=E2=80=99d be interested to hear thoughts and discussion on the list = prior to any discussion at an interim meeting. =E2=80=94 Neil= --Apple-Mail=_655AD172-4341-42B1-8EE1-8D816722FF95 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all,

You may = remember me from such I-Ds as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, = which proposes adding a new encryption algorithm to JOSE. I=E2=80=99d = like to reserve a bit of time to discuss it at one of the upcoming = interim meetings.

The basic idea is that in many cases in OAuth and OIDC you = want to ensure both confidentiality and authenticity of some token - for = example when transferring an ID token containing PII to the client = through the front channel, or for access tokens intended to be handled = by a specific RS without online token introspection (such as the JWT = access token draft). If you have a shared secret key between the AS and = the client/RS then you can use symmetric authenticated encryption = (alg=3Ddir or alg=3DA128KW etc). But if you need to use public key = cryptography then currently you are limited to a nested = signed-then-encrypted JOSE structure, which produces much larger token = sizes.

The = draft adds a new =E2=80=9Cpublic key authenticated encryption=E2=80=9D = mode based on ECDH in the NIST standard =E2=80=9Cone-pass unified=E2=80=9D= model. The primary advantage for OAuth usage is that the tokens = produced are more compact compared to signing+encryption (~30% smaller = for typical access/ID token sizes in compact serialization). = Performance-wise, it=E2=80=99s roughly equivalent. I know that size = concerns are often a limiting factor in choosing whether to encrypt = tokens, so this should help.

In terms of implementation, it=E2=80=99s = essentially just a few extra lines of code compared to an ECDH-ES = implementation. (Some JOSE library APIs might need an adjustment to = accommodate the extra private key needed for encryption/public key for = decryption).

I=E2=80=99ve received a few emails off-list from people = interested in using it for non-OAuth use-cases such as secure messaging = applications. I think these use-cases can be accommodated without = significant changes, so I think the OAuth WG would be a good venue for = advancing this.

I=E2=80=99d be interested to hear thoughts and discussion on = the list prior to any discussion at an interim meeting.

=E2=80=94 = Neil
= --Apple-Mail=_655AD172-4341-42B1-8EE1-8D816722FF95-- From nobody Thu Aug 6 03:48:43 2020 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 8038E3A101E for ; Thu, 6 Aug 2020 03:48:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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=hackmanit-de.20150623.gappssmtp.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 Y12cc-9WNglM for ; Thu, 6 Aug 2020 03:48:39 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 CB6693A101B for ; Thu, 6 Aug 2020 03:48:36 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id v22so24015314edy.0 for ; Thu, 06 Aug 2020 03:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackmanit-de.20150623.gappssmtp.com; s=20150623; h=cc:from:subject:autocrypt:to:message-id:date:user-agent :mime-version:content-language; bh=Cz11XR0sdbBgSgtPiYn4AvTL+aCJEPfhBDp7/E9gqIA=; b=VkJctib3fZoyyWy67YB/AKOD4BBdSHbNg0rev62xT6TIuL9c3CFnwHfRT2dKgM/fqZ yDvwt/VLrOAiNlV9a8j55vl5QBuIGxraiwH096peRE5g+Vxr0u+QtSQvjY7xlsVvGUb0 MZpRBDFaBuv74iOoKyddWDbpuvItb6+ocS6cY7k0fQSeRvwRVlyMvRhRgoggl9BIYGSy zo96xWBYkQMl5OV2SBNCZ9RaA4wxF1wlyH6Cusy01dQxirnE7maIuGC2U/QdX8/N5E/b cMXTNtsx3Y+pRJBheLGckwHloWjLDGOIVV3k7A7u6LX0Oni7HE9bmS7Z2kuWXKHbUBDk YzrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:cc:from:subject:autocrypt:to:message-id:date :user-agent:mime-version:content-language; bh=Cz11XR0sdbBgSgtPiYn4AvTL+aCJEPfhBDp7/E9gqIA=; b=py4nN7Goqzf32QGK4lYh/xgjgLLlY26Y53WtgyJ6xIw0zrrEkTzycITGskxDqfkU6k 53S+z+Hkqt8ziDmmcT92fHlREdoKGMzDTXqFUGlhx8kf3oEdg/2FpfnoCx2WCaAiEzYX u2qC5tK1B6gagoCUBNrAycTZCgJTlmUeJX6u6LPQdntOH+5d0Alerh5shcCq+yKtNnVZ Oi7eD3sptlEbDqexk43sZZCtJfjcDdmNene0HEWhc23SbhaHhS60HJlC0VOLiOiq0l7Z f4t7PzeLuQDMTGozfFdY0ETI1NYTopUO6LndAedgd7gjBD9lb++wLUY5na9D2kkpQsKw IIDw== X-Gm-Message-State: AOAM531iBHBeuE6N9DRT3QAj7gsTRR0DJTS11fAUZgXzcUIz4zFKeuGq Fu7sqAjO8oxqjWEq6OWxcsn6EPOHZm0= X-Google-Smtp-Source: ABdhPJxeheUKNCQbWlibV+bpuuegUs2vKx8BeH2gfY1E7PYSyoOIutTduTbiEgK0d5RorGoN1vKm7Q== X-Received: by 2002:aa7:d9d7:: with SMTP id v23mr3628770eds.112.1596710914731; Thu, 06 Aug 2020 03:48:34 -0700 (PDT) Received: from [192.168.178.22] (b2b-37-24-87-133.unitymedia.biz. [37.24.87.133]) by smtp.gmail.com with ESMTPSA id e8sm3138925edy.68.2020.08.06.03.48.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Aug 2020 03:48:33 -0700 (PDT) Cc: Christian Mainka From: Karsten Meyer zu Selhausen Autocrypt: addr=karsten.meyerzuselhausen@hackmanit.de; keydata= mQINBFh1IBMBEADV73c10lB7zeFy6/ezLFzOBp8z6Zy1zUyIrf6RoBk1GQWREcGEGeaL90Pj F5plZeASVJdsEYnYXdgcIPE0tlBq6al6OYoWtH/VbFPWEPLVhA3rL1iXVJveD3J40OzSYP8N G7bla3zQ2+TXOB3iDPPsHZUdHCLASkIIWQK6+fE1C2epAdPtnsLsb++1d080jfXXwgyUUh4y bimcy9Jg5oZ4QMwnSq3Y+x38PNb+nTgjDi1X/89/WsNd7Bdh4Zvw3CAuc/W58CFaDjb7liUD YRoAp6ysnjPKEUSnAnMpgaiXJc1gFoL+ahdKJ3D9XTn28NTjUrvOkVidsuKbyxnXP9I6BO6i 2jzjrH6TEAfIYMjZlYTyPZTt271SW5iAHYwvPZWlqQTBT2P/d4gHl0To5b4e+UXxjQgxqUyi QIcxh3Ris21Kx4lKQKDXYWiwNTZzx8AdqrcxCWfK+MRpFyk0B+4uDMm7Apm5ZWwDKN/JnVsJ yokkkrrHs/elRCUGtN9NyhJQf3VnE87862Pej8PVvQJr3uVnoNX2yieTvJZftIOBG1b9ta6Z BcYyn3un1rSn7lBPg+RSnPemposVorQpjGwT+Dhg13Bpv5q0JfSc//js/nB6A4iq5YssdtQ7 35QBWLLaF1oCxalvrQVDD4Sh06eAUQsga9xeE0yv7sxqdsozdwARAQABtEJLYXJzdGVuIE1l eWVyIHp1IFNlbGhhdXNlbiA8a2Fyc3Rlbi5tZXllcnp1c2VsaGF1c2VuQGhhY2ttYW5pdC5k ZT6JAj8EEwEIACkFAlh1IBMCGyMFCQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAK CRBFNcDn2xbxSK7sEAC5hk0VQHo2+fMV3b4TgSt4qSPLz6EnWwoqcEzUGYHErQXy7tCENpqS rsZsFphpgvWo1tcQdpyQTFm0dry4ASJD78lEiYC/8Hedp0fIaJTGwxrSLpRxV/Wb+iqkbgz8 /Qydl3QyupSqznSHQMd0uhvzHLxoYvHAIKy52gCK0T9gmxcCIh7UEjDfm+kqHp+oU4sbNe+2 ZEtJLuCKW+amNyqnHXr7ehAIaYmTdKOEcUb2UM7Yzp9g4kSkg1GbPlAn6yjyAqJ96sobKFXX S3rkXksRTxkGKW278Nrs4UBO+OIu32kIXCM2m3fKaUK777jAQu1e8sdj2nL0sPWQvMikZRx6 0dy+wVuH8gGHZsd7rW201Sv5pAhSAK4l58GS3xSLId6smXCend9Vu+tcYA+Bb+45943LmoPA PrdIUeI+zC9pjGwm+x+jFiCxbChqAiJF7RyYv9crziEYnTQ70gHGNOTOTIS5t0ufc9D4wD4O IkkrPQYg3KcAqP2Kyj1uHcqdk7XEhV1fdTXdeEt1e7auWPh0d3Fo+BTtiGXfNMuORArE0El6 ky8eUOqZEJ8rYpEGDLt0JFkJM5AhX4PrQWekjaMhQ5yl/+M+Ss0V0JkImagSgWdvUn1+eAs0 zEuVxTc6ON69mIyMalQ5d4ofvPnKr3GNVmEiXAVDMGUZHoeabfgSBbkCDQRYdSATARAAsp2V mr3N7iNND8+M/OyA/OwcDQ6utZh+m4TnKsOVdiNLGpu2U3/2Qg3yrbjic2dWx1CsS6VH2/oO 1e/a4FlxA93wFv/OZjiUjHtEvdIJeHWlCvWOUlMsqyGDc3Q75fNjFw6DGKkiOu9lZaBs6naS BmkvAMGjV5bNKLyIL5j7Im1pCdZ2lCjD7eVwR3RQQKobTmu916htX8g1cB9yFmquu37X+ZBl A4GLJi63Kw0L2r8i8iO1NqDLOfT8IeNkOroEm3SDAuEApGAubKLSPBJ1khQ7kDhpdfzSYKUF tiIHpGWVOImDjqf4JIcF7OIdRPQfFPlwoPnsyBAS8znQJvmqbbMowgFZe3UMLAN78CETZHGM OLBPB873oWyZ07Ar4v/SL5/aD+FRj2VnYEcGwt0HMmMyaN6ed8Udj4OTNZ7ceZA1Tw8/lZuI KCamj0XfJIK6376RCGnqjsEfS65P1KWZXfWphCKWp2c7uWKtau1q8pgiVRoBSAmjvfXRrIvK LhhQyNOiCUDKrvEWpoeq9y5GTrY27ncLov8nSR/SUPOw5HwJmzdFjhOF9XAOtiND/QRH886O IohdlnUu668mwLCmL2ROe7XWcTkFQWLDg+5b0bC9dgfL+HHpWGUdQPG3CCyPG5LfDmnmuXkE eU1kSD27kFe1kM6pfqpCydJW66DuwoMAEQEAAYkCJQQYAQgADwUCWHUgEwIbDAUJCWYBgAAK CRBFNcDn2xbxSAAbEACeIsfrsq2tlyigZv+bwkiVP1oKtWfXN1e3K3lDOBqPJaPXWFOopq/1 9osk58PFtVEaDlYPlN/NP6Jq5nTTC8QyLG3swAdo4ZJXWEg1NTRu8ddYUvZWuRHWRghaq7qh eW5lVPqilCndSG7bkDPU/Vyd93nPKnKTKKs/Nd7ePneWA0JQohEg5gO/GU0v5SN3YfTxG1LV Cxu3HHHFodDLK4KITSYmt1+g0WCADeclwm5+L5lIvgKQvcIpjpMGNK1wj2E3exsLlgo/ZEyS AslOPXyQw2yfYLrcfGpvWa3e+AvU7eLVBgihskpibJg53yw31B0CXAJBbjg7AsxR8UE5pl6h 2gTjN2t++GvqefGtw/bPvx2RzFsorh1/RYaFgcaFyefghmpi55iiIhgEOiSIct0LoYl3cmH8 DGYKhSskpSDgfE41Esk/P2odeax9SmJuv4mnqkiGFPpTwCfUka2k0mCpBDpfTdECWUFhreGS qFbrvJDZRBiyaVyCjOvOc0v6Z0/iIRgHWTjITpqaQh69kqAtt9GQWV6i3THnpHFlIC2ecvdc YCagneZdoLEHCS8Nois/uDbp5qZwZcF5zKMI+T7u6Qf8EGdvxCB1fp0Sdlmeto0c6/gnFUix 4J/tozBwSXSg7JCxTrUdnJtcQAJzosOUZTVO/ZZR/n0+904kud6o3w== To: oauth@ietf.org Message-ID: Date: Thu, 6 Aug 2020 12:48:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------C632C9223B4FCCE2A57344C0" Content-Language: en-US Archived-At: Subject: [OAUTH-WG] Comments on draft-ietf-oauth-v2-1-00 (The OAuth 2.1 Authorization Framework) 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, 06 Aug 2020 10:48:43 -0000 This is a multi-part message in MIME format. --------------C632C9223B4FCCE2A57344C0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, great to see that the OAuth 2.1 draft was adopted by the WG. We appreciate the efforts to create a single document which contains the current state of the art in terms of OAuth and all security best practices very much. It will make it a lot easier for developers and others to get started with OAuth. Christian and I reviewed the current draft (https://www.ietf.org/id/draft-ietf-oauth-v2-1-00.html) and would like give some feedback. You can find our comments below; they are sorted based on the section they affect. I divided the comments into two parts: The first one consists of suggestions and improvements to generally clarify the draft and increase the security of deployments implementing OAuth 2.1. The second part contains typos and other minor mistakes. There should be no need for further discussion on the list regarding these comments. We are happy to hear your thoughts on our suggestions. Best regards, Karsten Comments: Part 1: Suggestions and Improvements Section 1. Introduction - 1.4: "The string is opaque to the client, but depending on the authorization server, may be parseable by the resource server." =C2=A0=C2=A0 =C2=A0- What does opaque mean in this context? The client is= technically able to decode an AT if it is, for example, a JWT. =C2=A0=C2=A0 =C2=A0- For refresh tokens the wording is not as strong: "Th= e string is **usually** opaque to the client." (see section 1.5) - 1.5: In step 2 and 8 the AS "authenticates the client" but in step 7 the client provides "client authentication if it has been issued credentials". Should the possibility of public clients and credentialed clients (which cannot be authenticated) not be taken into account in step 2 and 8, as well? - 1.7 (and in general): HTTP status code 303 shoudl be used instead of 302 in this section and generally in all examples due to the recommendation to use 303 in section 9.7.2. Section 2. Client Registration - 2.3 (and in general): Is "client authentication" the right term for credentialed clients? We think the term "authentication" is confusing because their credentials should be considered to be public. Therefore, the AS can not be sure about their identity when they present their client credentials. - 2.3.1: An AS MUST NOT accept requests with ambiguous client information (both HTTP Basic Authentication and client_id/client_secret body parameters). =C2=A0=C2=A0 =C2=A0- Different application logics could extract and use a= different client_id from the request otherwise. For example, the HTTP header is validated to pass client authentication but the client_id parameter is used to check if code/RT was issued for this client. =C2=A0=C2=A0 =C2=A0- Should also be considered in 4.1.3. =C2=A0=C2=A0 =C2=A0- Implicitly included in 5.2 Error Response: ""invalid= _request": The request ... includes multiple credentials, utilizes more than one mechanism for authenticating the client =E2=80=A6" Section 3. Protocol Endpoints - 3.1.2: "The authorization server MUST compare the two URIs using simple string comparison as defined in [RFC3986], Section 6.2.1." We think the term "two URIs" is ambiguous and suggest to name the parameters here directly. - 3.1.2.4: "If an authorization request fails validation due to a missing, invalid, or mismatching redirect URI, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirect URI." We think the term "missing" is inaccurate because it might indicate that a redirect URI should always be present. Maybe the paragraph could be changed to something like "If an authorization request fails validation due to **an invalid, a mismatching, or a missing (if it was required**) redirect URI, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirect URI.". Section 4. Obtaining Authorization - 4.1.2.1: ""invalid_request": The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once" Is this only relevant for the parameters defined in this RFC or also for extensions? For example, RFC8707 (Resource Indicators) allows to use multiple "resource" parameters in the authorization request ("Multiple resource parameters MAY be used to indicate that the requested token is intended to be used at multiple resources.", https://www.rfc-editor.org/rfc/rfc8707.html#section-2-2.2). - 4.2.2: Combine "The client MUST authenticate with the authorization server as described in Section 3.2.1." and "The authorization server MUST authenticate the client." below the example. The second sentence looks oddly placed below the example. Section 6. Refreshing an Access Token - 6.1: Is token binding supported by any major browser? AFAIK it has been removed recently, so it could be removed here as well. Section 7. Accessing Protected Resources - 7.2.1: The RS MUST NOT accept resource requests which use more than one method to transmit the access token. This should be stated more clearly here and not be included only in 7.2.3 Error Codes "invalid_request". - 7.4.2: =C2=A0=C2=A0 =C2=A0- "As a further defense against token disclosure, the = client MUST validate the TLS certificate chain when making requests to protected resources, including checking the Certificate Revocation List (CRL) [RFC5280]." The paragraph should also mention OCSP [RFC 6960] as an alternative to CRLs. =C2=A0=C2=A0 =C2=A0- "Bearer tokens MUST NOT be stored in cookies that ca= n be sent in the clear". Maybe state explicitly that only cookies with secure flag are allowed? - 7.4.3.4: Maybe add recommended cookie flags (secure, httpOnly, sameSite) with note "or equivalent measures" (to ensure that future cookie flags / alternatives are allowed). This is also discussed in this thread: https://mailarchive.ietf.org/arch/msg/oauth/f18vynrMXC4dj4tqck7SZIl4xp4/ Section 9. Security Considerations - 9.2: "Authorization servers MUST require clients to register" should be clarified to "Authorization servers MUST require **native app** clients to register" although this is already present in the headline of the section. - 9.7: Explicitly state that code_challenge / nonce must be bound to user agent, as well? - 9.15: Adjust text according to CSRF part in 9.7. - 9.21: Remove the section as the only present recommendation is redundant and already covered in 9.6. Appendix: - Appendix C: =C2=A0=C2=A0 =C2=A0- Sort Extensions either alphabetically or depending o= n the RFC number (drafts below the RFCs). =C2=A0=C2=A0 =C2=A0- Should RFC7592 (Dynamic Client Management) really be= included as an "well-established extension"? It is only categorized as "experimental" RFC. General Comments: - Unify the order of client types: In 2.1 and 9 it is web application, browser-based application, native application, but the main section about native applications (10) is in front of the main section about browser-based applications (11). This should also be taken into account when sections are added to 9, 9.1, or 9.3. Currently 9.1.1, 9.2, and 9.3.1 are about native applications and sections about browser-based applications should be added in front of them (if there will be sections specifically about browser-based applications). - Is there any statement that it is allowed to add additional parameters in the authorization/token request/response? Part 2: Minor Mistakes (typos etc.) Section 1. Introduction - 1.5: "If the authorization server issues a refresh token, it is included when issuing an access token (i.e., step (4) in Figure 2)." -> "If the authorization server issues a refresh token, it is included when issuing an access token (i.e., step (**2**) in Figure 2)." Section 4. Obtaining Authorization - 4.1.2: Note "(with extra line breaks for display purposes only)" is missing in front of example. - 4.2.2: Note "(with extra line breaks for display purposes only)" present but there are no extra line breaks. The note is not present in 4.1.2.1, 4.1.4, and 4.2.3, for example. Section 5. Issuing an Access Token - 5.2: "The provided authorization grant (e.g., authorization code, resource owner credentials)" -> "The provided authorization grant (e.g., authorization code, **client** credentials)" Section 6. Refreshing an Access Token - 6: Note "(with extra line breaks for display purposes only)" present but there are no extra line breaks. Section 7. Accessing Protected Resources - 7.2.2: Note "(with extra line breaks for display purposes only)" is missing in front of last example. Section 9. Security Considerations - 9.1.1: "public native app**s** clients" -> "public native app clients" - 9.4.2: Missing reference to "(#pop_tokens)". - 9.5: Missing reference to "(#refresh_token_protection)". - 9.7: =C2=A0=C2=A0 =C2=A0- Missing references to "(#insufficient_uri_validation= )", "(#open_redirector_on_client)", "(#csrf_countermeasures)", and "(#mix_up)" (twice). =C2=A0=C2=A0 =C2=A0- "Clients MUST store the authorization server they se= nt an authorization request to and bind this information to the user agent and check that the authorization request was received from the correct authorization server." -> "Clients MUST store the authorization server they sent an authorization request to and bind this information to the user agent and check that the authorization **response** was received from the correct authorization server." - 9.7.2 (and in general): Replace "user agent" (used 18 times) with "user-agent" (used 64 times). - 9.8: Missing reference to "(#secmodel)". - 9.18.1: Missing reference to "(#redir_uri_open_redir)". - 9.21: Missing reference to "(#client_impersonating)". --=20 Karsten Meyer zu Selhausen IT Security Consultant Phone: +49 (0)234 / 54456499 Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, = Security Training Unsere n=C3=A4chste Live Online-Schulung zur Sicherheit von OAuth und Ope= nID Connect am 24.09 + 25.09: https://hackmanit.de/de/schulungen/109-live-online-schulung-single-sign-o= n-sicherheit-oauth-openid-connect-am-24-und-25-09-2020 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 --------------C632C9223B4FCCE2A57344C0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi all,

great to see that the OAuth 2.1 draft was adopted by the WG.
We appreciate the efforts to create a single document which contains the current state of the art in terms of OAuth and all security best practices very much. It will make it a lot easier for developers and others to get started with OAuth.

Christian and I reviewed the current draft (https://www.ietf.org/id/draft-ietf-oauth-v2-1-00.html) and would like give some feedback.

You can find our comments below; they are sorted based on the section they affect. I divided the comments into two parts: The first one consists of suggestions and improvements to generally clarify the draft and increase the security of deployments implementing OAuth 2.1. The second part contains typos and other minor mistakes. There should be no need for further discussion on the list regarding these comments.

We are happy to hear your thoughts on our suggestions.

Best regards,
Karsten

Comments:
Part 1: Suggestions and Improvements

Section 1. Introduction
- 1.4: "The string is opaque to the client, but depending on the authorization server, may be parseable by the resource server."
    - What does opaque mean in this context? The client is technically able to decode an AT if it is, for example, a JWT.
    - For refresh tokens the wording is not as strong: "The string is **usually** opaque to the client." (see section 1.5)
- 1.5: In step 2 and 8 the AS "authenticates the client" but in step 7 the client provides "client authentication if it has been issued credentials". Should the possibility of public clients and credentialed clients (which cannot be authenticated) not be taken into account in step 2 and 8, as well?
- 1.7 (and in general): HTTP status code 303 shoudl be used instead of 302 in this section and generally in all examples due to the recommendation to use 303 in section 9.7.2.

Section 2. Client Registration
- 2.3 (and in general): Is "client authentication" the right term for credentialed clients? We think the term "authentication" is confusing because their credentials should be considered to be public. Therefore, the AS can not be sure about their identity when they present their client credentials.
- 2.3.1: An AS MUST NOT accept requests with ambiguous client information (both HTTP Basic Authentication and client_id/client_secret body parameters).
    - Different application logics could extract and use a different client_id from the request otherwise. For example, the HTTP header is validated to pass client authentication but the client_id parameter is used to check if code/RT was issued for this client.
    - Should also be considered in 4.1.3.
    - Implicitly included in 5.2 Error Response: ""invalid_request": The request ... includes multiple credentials, utilizes more than one mechanism for authenticating the client …"

Section 3. Protocol Endpoints
- 3.1.2: "The authorization server MUST compare the two URIs using simple string comparison as defined in [RFC3986], Section 6.2.1." We think the term "two URIs" is ambiguous and suggest to name the parameters here directly.
- 3.1.2.4: "If an authorization request fails validation due to a missing, invalid, or mismatching redirect URI, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirect URI." We think the term "missing" is inaccurate because it might indicate that a redirect URI should always be present. Maybe the paragraph could be changed to something like "If an authorization request fails validation due to **an invalid, a mismatching, or a missing (if it was required**) redirect URI, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirect URI.".

Section 4. Obtaining Authorization
- 4.1.2.1: ""invalid_request": The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once" Is this only relevant for the parameters defined in this RFC or also for extensions? For example, RFC8707 (Resource Indicators) allows to use multiple "resource" parameters in the authorization request ("Multiple resource parameters MAY be used to indicate that the requested token is intended to be used at multiple resources.", https://www.rfc-editor.org/rfc/rfc8707.html#section-2-2.2).
- 4.2.2: Combine "The client MUST authenticate with the authorization server as described in Section 3.2.1." and "The authorization server MUST authenticate the client." below the example. The second sentence looks oddly placed below the example.

Section 6. Refreshing an Access Token
- 6.1: Is token binding supported by any major browser? AFAIK it has been removed recently, so it could be removed here as well.

Section 7. Accessing Protected Resources
- 7.2.1: The RS MUST NOT accept resource requests which use more than one method to transmit the access token. This should be stated more clearly here and not be included only in 7.2.3 Error Codes "invalid_request".
- 7.4.2:
    - "As a further defense against token disclosure, the client MUST validate the TLS certificate chain when making requests to protected resources, including checking the Certificate Revocation List (CRL) [RFC5280]." The paragraph should also mention OCSP [RFC 6960] as an alternative to CRLs.
    - "Bearer tokens MUST NOT be stored in cookies that can be sent in the clear". Maybe state explicitly that only cookies with secure flag are allowed?
- 7.4.3.4: Maybe add recommended cookie flags (secure, httpOnly, sameSite) with note "or equivalent measures" (to ensure that future cookie flags / alternatives are allowed). This is also discussed in this thread: https://mailarchive.ietf.org/arch/msg/oauth/f18vynrMXC4dj4tqck7SZIl4xp4/

Section 9. Security Considerations
- 9.2: "Authorization servers MUST require clients to register" should be clarified to "Authorization servers MUST require **native app** clients to register" although this is already present in the headline of the section.
- 9.7: Explicitly state that code_challenge / nonce must be bound to user agent, as well?
- 9.15: Adjust text according to CSRF part in 9.7.
- 9.21: Remove the section as the only present recommendation is redundant and already covered in 9.6.

Appendix:
- Appendix C:
    - Sort Extensions either alphabetically or depending on the RFC number (drafts below the RFCs).
    - Should RFC7592 (Dynamic Client Management) really be included as an "well-established extension"? It is only categorized as "experimental" RFC.

General Comments:
- Unify the order of client types: In 2.1 and 9 it is web application, browser-based application, native application, but the main section about native applications (10) is in front of the main section about browser-based applications (11). This should also be taken into account when sections are added to 9, 9.1, or 9.3. Currently 9.1.1, 9.2, and 9.3.1 are about native applications and sections about browser-based applications should be added in front of them (if there will be sections specifically about browser-based applications).
- Is there any statement that it is allowed to add additional parameters in the authorization/token request/response?


Part 2: Minor Mistakes (typos etc.)

Section 1. Introduction
- 1.5: "If the authorization server issues a refresh token, it is included when issuing an access token (i.e., step (4) in Figure 2)." -> "If the authorization server issues a refresh token, it is included when issuing an access token (i.e., step (**2**) in Figure 2)."

Section 4. Obtaining Authorization
- 4.1.2: Note "(with extra line breaks for display purposes only)" is missing in front of example.
- 4.2.2: Note "(with extra line breaks for display purposes only)" present but there are no extra line breaks. The note is not present in 4.1.2.1, 4.1.4, and 4.2.3, for example.

Section 5. Issuing an Access Token
- 5.2: "The provided authorization grant (e.g., authorization code, resource owner credentials)" -> "The provided authorization grant (e.g., authorization code, **client** credentials)"

Section 6. Refreshing an Access Token
- 6: Note "(with extra line breaks for display purposes only)" present but there are no extra line breaks.

Section 7. Accessing Protected Resources
- 7.2.2: Note "(with extra line breaks for display purposes only)" is missing in front of last example.

Section 9. Security Considerations
- 9.1.1: "public native app**s** clients" -> "public native app clients"
- 9.4.2: Missing reference to "(#pop_tokens)".
- 9.5: Missing reference to "(#refresh_token_protection)".
- 9.7:
    - Missing references to "(#insufficient_uri_validation)", "(#open_redirector_on_client)", "(#csrf_countermeasures)", and "(#mix_up)" (twice).
    - "Clients MUST store the authorization server they sent an authorization request to and bind this information to the user agent and check that the authorization request was received from the correct authorization server." -> "Clients MUST store the authorization server they sent an authorization request to and bind this information to the user agent and check that the authorization **response** was received from the correct authorization server."
- 9.7.2 (and in general): Replace "user agent" (used 18 times) with "user-agent" (used 64 times).
- 9.8: Missing reference to "(#secmodel)".
- 9.18.1: Missing reference to "(#redir_uri_open_redir)".
- 9.21: Missing reference to "(#client_impersonating)". 

-- 
Karsten Meyer zu Selhausen
IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training

Unsere nächste Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 24.09 + 25.09:
https://hackmanit.de/de/schulungen/109-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-24-und-25-09-2020

Hackmanit GmbH
Universitätsstraße 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
--------------C632C9223B4FCCE2A57344C0-- From nobody Thu Aug 6 14:23:22 2020 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 66BFB3A0F2A for ; Thu, 6 Aug 2020 14:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, 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 kPleBHEM1VKW for ; Thu, 6 Aug 2020 14:23:19 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 BFE2C3A0F26 for ; Thu, 6 Aug 2020 14:23:18 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id w25so17944890ljo.12 for ; Thu, 06 Aug 2020 14:23:18 -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=TY/yrcvdv6mQkuqP9INU8r2GFGaGhDvKWNeMQvnsuk0=; b=ozoA59TjdiOsLsVo/R3Tfc6ymYIrS05Bp41a9PoYOvXRsuIjXV7iVAPP/AHm4CbGyq 6urcxGkxTviJtLbjmIDscSG8kdAnFTBeVOyEDYw5JUJgdgp0Ms1R+uNLqOmpWeoY1QF8 PgxL5beVgrccGrslqC2L+ocg4NNvhZeYpsLeyu9wTLPwMnNmvGESMT9fwUb5IIZTfSQg mVWt5tlNbO+xdmcrBsd5B6lsOoUMzr1GLLJc6jLkbvbo1hdve6EbPrBhhnQ8G03Paopi diZ2sfejOr/wKF7365R7TKBKU6y4nMJWhyG0lvG15oagoFWTN7O3qLBRZjBiRa1Bc+XY ++zg== 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=TY/yrcvdv6mQkuqP9INU8r2GFGaGhDvKWNeMQvnsuk0=; b=d9J9t5YwTcoH4O6Rv+PBDNSQwNohsGXhbig9PNBXwC/Mtp3bQD2Rw0leKbCiG/WY3o h6nQojypICabDaBYJ0Y7LQADLxNZfDJgrn8bgfINQydaI0sf+r9/Kb8P/Fqr9xINwGWU pJ66DNeHjW2hgoaQtIDdhlj1KYSb7T/FU95zQaNCjWDxUEH8V8yQZirk94I+vtfPM1v8 I7hV0Yhjn3RUxkH4p6492/a2Zfg2IdUplg/yz9uuEkzPiLF1d+WDhDpgWwVxrTAHV7c7 5Qh/+KHKQyPhMQzh39pmDLc4RUsH+BSmLYNeT5vvP1oO6xvgYHlO8VH5CGVZcte7eyDR k8iA== X-Gm-Message-State: AOAM531SugU7iYRs1ZMAlNo3ZOPdhAsN4KfMW6eKBiiYX5RuyjZRMhQw vSl4npuOskOvXT4RmT+eW0W9Hma2FIGXn068XTnV2QQLkgA= X-Google-Smtp-Source: ABdhPJyxTfsa5Sf4X5eXdjshGFsFYCLoi8JtqBVrje0qMnM0Tjed0Yvmj5qommXQrJbiL0pK57vWPArdMcUK2LDEtZM= X-Received: by 2002:a2e:2283:: with SMTP id i125mr4539512lji.142.1596748996594; Thu, 06 Aug 2020 14:23:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 6 Aug 2020 14:22:40 -0700 Message-ID: To: Karsten Meyer zu Selhausen Cc: oauth@ietf.org, Christian Mainka Content-Type: multipart/alternative; boundary="000000000000bcfafb05ac3c1803" Archived-At: Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-1-00 (The OAuth 2.1 Authorization Framework) 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, 06 Aug 2020 21:23:21 -0000 --000000000000bcfafb05ac3c1803 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Karsten / Christian: thank you for reviewing the draft and all of your feedback. Greatly appreciated! Responses inline ... if no comment, I (or another author) will have to review to respond. On Thu, Aug 6, 2020 at 3:48 AM Karsten Meyer zu Selhausen < karsten.meyerzuselhausen@hackmanit.de> wrote: > Hi all, > > great to see that the OAuth 2.1 draft was adopted by the WG. > We appreciate the efforts to create a single document which contains the > current state of the art in terms of OAuth and all security best practice= s > very much. It will make it a lot easier for developers and others to get > started with OAuth. > > Christian and I reviewed the current draft ( > https://www.ietf.org/id/draft-ietf-oauth-v2-1-00.html) and would like > give some feedback. > > You can find our comments below; they are sorted based on the section the= y > affect. I divided the comments into two parts: The first one consists of > suggestions and improvements to generally clarify the draft and increase > the security of deployments implementing OAuth 2.1. The second part > contains typos and other minor mistakes. There should be no need for > further discussion on the list regarding these comments. > > We are happy to hear your thoughts on our suggestions. > > Best regards, > Karsten > > Comments: > Part 1: Suggestions and Improvements > > Section 1. Introduction > - 1.4: "The string is opaque to the client, but depending on the > authorization server, may be parseable by the resource server." > - What does opaque mean in this context? The client is technically > able to decode an AT if it is, for example, a JWT. > More clarity on what opaque means is a good suggestion. To answer your question, the Client should treat the AT as a string. The token format could be anything the AS and RS want, and could change at any time. This does not mean the Client cannot discern information from the token, and an AS should ensure that a Client cannot violate any privacy objectives by gleaning information from the AT. > - For refresh tokens the wording is not as strong: "The string is > **usually** opaque to the client." (see section 1.5) > I'm not sure why "usually" is in there. > - 1.5: In step 2 and 8 the AS "authenticates the client" but in step 7 th= e > client provides "client authentication if it has been issued credentials"= . > Should the possibility of public clients and credentialed clients (which > cannot be authenticated) not be taken into account in step 2 and 8, as we= ll? > - 1.7 (and in general): HTTP status code 303 shoudl be used instead of 302 > in this section and generally in all examples due to the recommendation t= o > use 303 in section 9.7.2. > > Section 2. Client Registration > - 2.3 (and in general): Is "client authentication" the right term for > credentialed clients? We think the term "authentication" is confusing > because their credentials should be considered to be public. Therefore, t= he > AS can not be sure about their identity when they present their client > credentials. > It is unfortunate that credentials can be interpreted a couple of ways. One way is how I think you are intending, which is a public statement about an entity. In this case, we are thinking of credentials as a mechanism to authenticate such as a password or private key. > - 2.3.1: An AS MUST NOT accept requests with ambiguous client information > (both HTTP Basic Authentication and client_id/client_secret body > parameters). > - Different application logics could extract and use a different > client_id from the request otherwise. For example, the HTTP header is > validated to pass client authentication but the client_id parameter is us= ed > to check if code/RT was issued for this client. > - Should also be considered in 4.1.3. > - Implicitly included in 5.2 Error Response: ""invalid_request": The > request ... includes multiple credentials, utilizes more than one mechani= sm > for authenticating the client =E2=80=A6" > > Section 3. Protocol Endpoints > - 3.1.2: "The authorization server MUST compare the two URIs using simple > string comparison as defined in [RFC3986], Section 6.2.1." We think the > term "two URIs" is ambiguous and suggest to name the parameters here > directly. > - 3.1.2.4: "If an authorization request fails validation due to a > missing, invalid, or mismatching redirect URI, the authorization server > SHOULD inform the resource owner of the error and MUST NOT automatically > redirect the user-agent to the invalid redirect URI." We think the term > "missing" is inaccurate because it might indicate that a redirect URI > should always be present. Maybe the paragraph could be changed to somethi= ng > like "If an authorization request fails validation due to **an invalid, a > mismatching, or a missing (if it was required**) redirect URI, the > authorization server SHOULD inform the resource owner of the error and MU= ST > NOT automatically redirect the user-agent to the invalid redirect URI.". > > Section 4. Obtaining Authorization > - 4.1.2.1: ""invalid_request": The request is missing a required > parameter, includes an invalid parameter value, includes a parameter more > than once" Is this only relevant for the parameters defined in this RFC o= r > also for extensions? For example, RFC8707 (Resource Indicators) allows to > use multiple "resource" parameters in the authorization request ("Multipl= e > resource parameters MAY be used to indicate that the requested token is > intended to be used at multiple resources.", > https://www.rfc-editor.org/rfc/rfc8707.html#section-2-2.2). > - 4.2.2: Combine "The client MUST authenticate with the authorization > server as described in Section 3.2.1." and "The authorization server MUST > authenticate the client." below the example. The second sentence looks > oddly placed below the example. > > Section 6. Refreshing an Access Token > - 6.1: Is token binding supported by any major browser? AFAIK it has been > removed recently, so it could be removed here as well. > Edge still supports token binding AFAIK. > > Section 7. Accessing Protected Resources > - 7.2.1: The RS MUST NOT accept resource requests which use more than one > method to transmit the access token. This should be stated more clearly > here and not be included only in 7.2.3 Error Codes "invalid_request". > - 7.4.2: > - "As a further defense against token disclosure, the client MUST > validate the TLS certificate chain when making requests to protected > resources, including checking the Certificate Revocation List (CRL) > [RFC5280]." The paragraph should also mention OCSP [RFC 6960] as an > alternative to CRLs. > - "Bearer tokens MUST NOT be stored in cookies that can be sent in th= e > clear". Maybe state explicitly that only cookies with secure flag are > allowed? > - 7.4.3.4: Maybe add recommended cookie flags (secure, httpOnly, > sameSite) with note "or equivalent measures" (to ensure that future cooki= e > flags / alternatives are allowed). This is also discussed in this thread: > https://mailarchive.ietf.org/arch/msg/oauth/f18vynrMXC4dj4tqck7SZIl4xp4/ > > Section 9. Security Considerations > - 9.2: "Authorization servers MUST require clients to register" should be > clarified to "Authorization servers MUST require **native app** clients t= o > register" although this is already present in the headline of the section= . > - 9.7: Explicitly state that code_challenge / nonce must be bound to user > agent, as well? > - 9.15: Adjust text according to CSRF part in 9.7. > - 9.21: Remove the section as the only present recommendation is redundan= t > and already covered in 9.6. > > Appendix: > - Appendix C: > - Sort Extensions either alphabetically or depending on the RFC numbe= r > (drafts below the RFCs). > - Should RFC7592 (Dynamic Client Management) really be included as an > "well-established extension"? It is only categorized as "experimental" RF= C. > > General Comments: > - Unify the order of client types: In 2.1 and 9 it is web application, > browser-based application, native application, but the main section about > native applications (10) is in front of the main section about > browser-based applications (11). This should also be taken into account > when sections are added to 9, 9.1, or 9.3. Currently 9.1.1, 9.2, and 9.3.= 1 > are about native applications and sections about browser-based applicatio= ns > should be added in front of them (if there will be sections specifically > about browser-based applications). > - Is there any statement that it is allowed to add additional parameters > in the authorization/token request/response? > > > Part 2: Minor Mistakes (typos etc.) > > Section 1. Introduction > - 1.5: "If the authorization server issues a refresh token, it is include= d > when issuing an access token (i.e., step (4) in Figure 2)." -> "If the > authorization server issues a refresh token, it is included when issuing = an > access token (i.e., step (**2**) in Figure 2)." > > Section 4. Obtaining Authorization > - 4.1.2: Note "(with extra line breaks for display purposes only)" is > missing in front of example. > - 4.2.2: Note "(with extra line breaks for display purposes only)" presen= t > but there are no extra line breaks. The note is not present in 4.1.2.1, > 4.1.4, and 4.2.3, for example. > > Section 5. Issuing an Access Token > - 5.2: "The provided authorization grant (e.g., authorization code, > resource owner credentials)" -> "The provided authorization grant (e.g., > authorization code, **client** credentials)" > > Section 6. Refreshing an Access Token > - 6: Note "(with extra line breaks for display purposes only)" present bu= t > there are no extra line breaks. > > Section 7. Accessing Protected Resources > - 7.2.2: Note "(with extra line breaks for display purposes only)" is > missing in front of last example. > > Section 9. Security Considerations > - 9.1.1: "public native app**s** clients" -> "public native app clients" > - 9.4.2: Missing reference to "(#pop_tokens)". > - 9.5: Missing reference to "(#refresh_token_protection)". > - 9.7: > - Missing references to "(#insufficient_uri_validation)", > "(#open_redirector_on_client)", "(#csrf_countermeasures)", and "(#mix_up)= " > (twice). > - "Clients MUST store the authorization server they sent an > authorization request to and bind this information to the user agent and > check that the authorization request was received from the correct > authorization server." -> "Clients MUST store the authorization server th= ey > sent an authorization request to and bind this information to the user > agent and check that the authorization **response** was received from the > correct authorization server." > - 9.7.2 (and in general): Replace "user agent" (used 18 times) with > "user-agent" (used 64 times). > - 9.8: Missing reference to "(#secmodel)". > - 9.18.1: Missing reference to "(#redir_uri_open_redir)". > - 9.21: Missing reference to "(#client_impersonating)". > > -- > Karsten Meyer zu Selhausen > IT Security Consultant > Phone: +49 (0)234 / 54456499 > Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, = Security Training > > Unsere n=C3=A4chste Live Online-Schulung zur Sicherheit von OAuth und Ope= nID Connect am 24.09 + 25.09:https://hackmanit.de/de/schulungen/109-live-on= line-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-24-und-25-0= 9-2020 > > 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =E1=90=A7 --000000000000bcfafb05ac3c1803 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Karsten / Christian: thank you for reviewing=C2=A0the= draft and all of your feedback. Greatly=C2=A0appreciated!

Responses inline ... if no comment, I (or another author) will hav= e to review to respond.

On Thu, Aug 6, 2020 at 3:48 AM Karsten Meyer zu Selh= ausen <karsten.= meyerzuselhausen@hackmanit.de> wrote:
=20 =20 =20
Hi all,

great to see that the OAuth 2.1 draft was adopted by the WG.
We appreciate the efforts to create a single document which contains the current state of the art in terms of OAuth and all security best practices very much. It will make it a lot easier for developers and others to get started with OAuth.

Christian and I reviewed the current draft (https://www.ietf.o= rg/id/draft-ietf-oauth-v2-1-00.html) and would like give some feedback.

You can find our comments below; they are sorted based on the section they affect. I divided the comments into two parts: The first one consists of suggestions and improvements to generally clarify the draft and increase the security of deployments implementing OAuth 2.1. The second part contains typos and other minor mistakes. There should be no need for further discussion on the list regarding these comments.

We are happy to hear your thoughts on our suggestions.

Best regards,
Karsten

Comments:
Part 1: Suggestions and Improvements

Section 1. Introduction
- 1.4: "The string is opaque to the client, but depending on the authorization server, may be parseable by the resource server." =C2=A0=C2=A0 =C2=A0- What does opaque mean in this context? The client = is technically able to decode an AT if it is, for example, a JWT.

More clarity on what opaque means is a go= od suggestion. To answer your question, the Client should treat the AT as a= string. The token format could be anything the AS and RS want, and could c= hange at any time. This does not mean the Client cannot discern information= from the token, and an AS should ensure that a Client cannot violate any p= rivacy objectives by gleaning=C2=A0information from the AT.
=C2= =A0
=C2=A0=C2=A0 =C2=A0- For refresh tokens the wording is not as strong: &= quot;The string is **usually** opaque to the client." (see section 1.5)
<= /blockquote>

I'm not sure why "usually" is= in there.
=C2=A0
- 1.5: In step 2 and 8 the AS "authenticates the client" but = in step 7 the client provides "client authentication if it has been issued credentials". Should the possibility of public clients and credentialed clients (which cannot be authenticated) not be taken into account in step 2 and 8, as well?
- 1.7 (and in general): HTTP status code 303 shoudl be used instead of 302 in this section and generally in all examples due to the recommendation to use 303 in section 9.7.2.

Section 2. Client Registration
- 2.3 (and in general): Is "client authentication" the right = term for credentialed clients? We think the term "authentication" = is confusing because their credentials should be considered to be public. Therefore, the AS can not be sure about their identity when they present their client credentials.

<= /div>

It is unfortunate that credentials can be interpre= ted a couple of ways. One way is how I think you are intending, which is a = public statement about an entity.

In this case, we= are thinking of credentials as a mechanism to authenticate=C2=A0such as a = password or private key.
=C2=A0
- 2.3.1: An AS MUST NOT accept requests with ambiguous client information (both HTTP Basic Authentication and client_id/client_secret body parameters).
=C2=A0=C2=A0 =C2=A0- Different application logics could extract and use= a different client_id from the request otherwise. For example, the HTTP header is validated to pass client authentication but the client_id parameter is used to check if code/RT was issued for this client.
=C2=A0=C2=A0 =C2=A0- Should also be considered in 4.1.3.
=C2=A0=C2=A0 =C2=A0- Implicitly included in 5.2 Error Response: "&= quot;invalid_request": The request ... includes multiple credentials, utilizes more than one mechanism for authenticating the client =E2=80=A6"

Section 3. Protocol Endpoints
- 3.1.2: "The authorization server MUST compare the two URIs using simple string comparison as defined in [RFC3986], Section 6.2.1." = We think the term "two URIs" is ambiguous and suggest to name th= e parameters here directly.
- 3.1.2.4: "If an= authorization request fails validation due to a missing, invalid, or mismatching redirect URI, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirect URI."= ; We think the term "missing" is inaccurate because it might in= dicate that a redirect URI should always be present. Maybe the paragraph could be changed to something like "If an authorization request fails validation due to **an invalid, a mismatching, or a missing (if it was required**) redirect URI, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirect URI.".

Section 4. Obtaining Authorization
- 4.1.2.1: ""= ;invalid_request": The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once" Is this only relevant for the parameters defined i= n this RFC or also for extensions? For example, RFC8707 (Resource Indicators) allows to use multiple "resource" parameters in t= he authorization request ("Multiple resource parameters MAY be used t= o indicate that the requested token is intended to be used at multiple resources.", https://www.rfc-editor.org/rfc/rfc8707.html#section-2-2.2<= /a>).
- 4.2.2: Combine "The client MUST authenticate with the authorization server as described in Section 3.2.1." and "The authorization server MUST authenticate the client." below the example. The second sentence looks oddly placed below the example.

Section 6. Refreshing an Access Token
- 6.1: Is token binding supported by any major browser? AFAIK it has been removed recently, so it could be removed here as well.


Section 7. Accessing Protected Resources
- 7.2.1: The RS MUST NOT accept resource requests which use more than one method to transmit the access token. This should be stated more clearly here and not be included only in 7.2.3 Error Codes "invalid_request".
- 7.4.2:
=C2=A0=C2=A0 =C2=A0- "As a further defense against token disclosur= e, the client MUST validate the TLS certificate chain when making requests to protected resources, including checking the Certificate Revocation List (CRL) [RFC5280]." The paragraph should also mention OCSP [RFC 6960] as an alternative to CRLs.
=C2=A0=C2=A0 =C2=A0- "Bearer tokens MUST NOT be stored in cookies = that can be sent in the clear". Maybe state explicitly that only cookies with secur= e flag are allowed?
- 7.4.3.4: Maybe add r= ecommended cookie flags (secure, httpOnly, sameSite) with note "or equivalent measures" (to ensure that = future cookie flags / alternatives are allowed). This is also discussed in this thread: https://mailarchive.ietf.org/arch/msg/oauth= /f18vynrMXC4dj4tqck7SZIl4xp4/

Section 9. Security Considerations
- 9.2: "Authorization servers MUST require clients to register&quo= t; should be clarified to "Authorization servers MUST require **nativ= e app** clients to register" although this is already present in the headline of the section.
- 9.7: Explicitly state that code_challenge / nonce must be bound to user agent, as well?
- 9.15: Adjust text according to CSRF part in 9.7.
- 9.21: Remove the section as the only present recommendation is redundant and already covered in 9.6.

Appendix:
- Appendix C:
=C2=A0=C2=A0 =C2=A0- Sort Extensions either alphabetically or depending= on the RFC number (drafts below the RFCs).
=C2=A0=C2=A0 =C2=A0- Should RFC7592 (Dynamic Client Management) really = be included as an "well-established extension"? It is only categorized as "experimental" RFC.

General Comments:
- Unify the order of client types: In 2.1 and 9 it is web application, browser-based application, native application, but the main section about native applications (10) is in front of the main section about browser-based applications (11). This should also be taken into account when sections are added to 9, 9.1, or 9.3. Currently 9.1.1, 9.2, and 9.3.1 are about native applications and sections about browser-based applications should be added in front of them (if there will be sections specifically about browser-based applications).
- Is there any statement that it is allowed to add additional parameters in the authorization/token request/response?


Part 2: Minor Mistakes (typos etc.)

Section 1. Introduction
- 1.5: "If the authorization server issues a refresh token, it is included when issuing an access token (i.e., step (4) in Figure 2).&quo= t; -> "If the authorization server issues a refresh token, it is included when issuing an access token (i.e., step (**2**) in Figure 2)."

Section 4. Obtaining Authorization
- 4.1.2: Note "(with extra line breaks for display purposes only)&= quot; is missing in front of example.
- 4.2.2: Note "(with extra line breaks for display purposes only)&= quot; present but there are no extra line breaks. The note is not present in 4.1.2.1, 4.1.4, and 4.2.3, for example.

Section 5. Issuing an Access Token
- 5.2: "The provided authorization grant (e.g., authorization code= , resource owner credentials)" -> "The provided authorizatio= n grant (e.g., authorization code, **client** credentials)"

Section 6. Refreshing an Access Token
- 6: Note "(with extra line breaks for display purposes only)"= ; present but there are no extra line breaks.

Section 7. Accessing Protected Resources
- 7.2.2: Note "(with extra line breaks for display purposes only)&= quot; is missing in front of last example.

Section 9. Security Considerations
- 9.1.1: "public native app**s** clients" -> "public = native app clients"
- 9.4.2: Missing reference to "(#pop_tokens)".
- 9.5: Missing reference to "(#refresh_token_protection)". - 9.7:
=C2=A0=C2=A0 =C2=A0- Missing references to "(#insufficient_uri_val= idation)", "(#open_redirector_on_client)", "(#csrf_countermeasures)= ", and "(#mix_up)" (twice).
=C2=A0=C2=A0 =C2=A0- "Clients MUST store the authorization server = they sent an authorization request to and bind this information to the user agent and check that the authorization request was received from the correct authorization server." -> "Clients MUST store the authorization server they sent an authorization request to and bind this information to the user agent and check that the authorization **response** was received from the correct authorization server."<= br> - 9.7.2 (and in general): Replace "user agent" (used 18 times= ) with "user-agent" (used 64 times).
- 9.8: Missing reference to "(#secmodel)".
- 9.18.1: Missing reference to "(#redir_uri_open_redir)".
- 9.21: Missing reference to "(#client_impersonating)".

= 

--=20
Karsten Meyer zu Selhausen
IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	https://hackmanit.d=
e | IT Security Consulting, Penetration Testing, Security Training

Unsere n=C3=A4chste Live Online-Schulung zur Sicherheit von OAuth und OpenI=
D Connect am 24.09 + 25.09:
https://hackmanit.de/de/schulungen/109-live-online-schulung-single-=
sign-on-sicherheit-oauth-openid-connect-am-24-und-25-09-2020

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 Som=
orovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
3D""= =E1=90=A7
--000000000000bcfafb05ac3c1803-- From nobody Sat Aug 8 02:40:00 2020 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 DD1FA3A09E4 for ; Sat, 8 Aug 2020 02:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=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 BGTZwBYcTbaY for ; Sat, 8 Aug 2020 02:39:57 -0700 (PDT) Received: from p3plsmtpa09-10.prod.phx3.secureserver.net (p3plsmtpa09-10.prod.phx3.secureserver.net [173.201.193.239]) (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 9E4EA3A09D9 for ; Sat, 8 Aug 2020 02:39:57 -0700 (PDT) Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id 4LKVk8iORAJJp4LKWkIeQ6; Sat, 08 Aug 2020 02:39:57 -0700 X-CMAE-Analysis: v=2.3 cv=Sd6JicZu c=1 sm=1 tr=0 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=48vgC7mUAAAA:8 a=fxrcP2pIblrs7K5vFycA:9 a=QEXdDO2ut3YA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: oauth@ietf.org References: <0DEE1AC7-2EA7-420F-B0B5-6F96A3D04D1C@forgerock.com> From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd Organization: Connect2id Ltd. Message-ID: <51424c05-3199-0caf-65ea-6d7a4433c9b9@connect2id.com> Date: Sat, 8 Aug 2020 12:39:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <0DEE1AC7-2EA7-420F-B0B5-6F96A3D04D1C@forgerock.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080700070207000501000009" X-CMAE-Envelope: MS4wfFfkoTQWvrpzuTm9KBzxG8du3umnnH//eOYFUeHfbixKgwPXxENYw4g5Fx+mv6bncKGn45XPsmzpVUQTZsl/Ur4eDPgvp2mCF/9xq1KAPIih4lCSuPZg /y6luAT1fXN1eiKMs7BdA7zBrrw/x2wouh6wuuwsi9oDkPdule8T3LGs Archived-At: Subject: Re: [OAUTH-WG] ECDH-1PU encryption algorithm 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, 08 Aug 2020 09:39:59 -0000 This is a cryptographically signed message in MIME format. --------------ms080700070207000501000009 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Neil, I definitely like the elegance of the proposed alg for JOSE, it provides something that isn't currently available in the various classes of algs made standard in JOSE. I also wanted to ask what's happening with AES SIV for JOSE, if there's traction / feedback / support there as well? https://tools.ietf.org/html/draft-madden-jose-siv-mode-02 Vladimir On 05/08/2020 13:01, Neil Madden wrote: > Hi all, > > You may remember me from such I-Ds > as=C2=A0https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, whic= h > proposes adding a new encryption algorithm to JOSE. I=E2=80=99d like to= > reserve a bit of time to discuss it at one of the upcoming interim > meetings. > > The basic idea is that in many cases in OAuth and OIDC you want to > ensure both confidentiality and authenticity of some token - for > example when transferring an ID token containing PII to the client > through the front channel, or for access tokens intended to be handled > by a specific RS without online token introspection (such as the JWT > access token draft). If you have a shared secret key between the AS > and the client/RS then you can use symmetric authenticated encryption > (alg=3Ddir or alg=3DA128KW etc). But if you need to use public key > cryptography then currently you are limited to a nested > signed-then-encrypted JOSE structure, which produces much larger token > sizes. > > The draft adds a new =E2=80=9Cpublic key authenticated encryption=E2=80= =9D mode based > on ECDH in the NIST standard =E2=80=9Cone-pass unified=E2=80=9D model. = The primary > advantage for OAuth usage is that the tokens produced are more compact > compared to signing+encryption (~30% smaller for typical access/ID > token sizes in compact serialization). Performance-wise, it=E2=80=99s r= oughly > equivalent. I know that size concerns are often a limiting factor in > choosing whether to encrypt tokens, so this should help. > > In terms of implementation, it=E2=80=99s essentially just a few extra l= ines of > code compared to an ECDH-ES implementation. (Some JOSE library APIs > might need an adjustment to accommodate the extra private key needed > for encryption/public key for decryption). > > I=E2=80=99ve received a few emails off-list from people interested in u= sing it > for non-OAuth use-cases such as secure messaging applications. I think > these use-cases can be accommodated without significant changes, so I > think the OAuth WG would be a good venue for advancing this. > > I=E2=80=99d be interested to hear thoughts and discussion on the list p= rior to > any discussion at an interim meeting. > > =E2=80=94 Neil --------------ms080700070207000501000009 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA4MDgwOTM5NTVaMC8G CSqGSIb3DQEJBDEiBCDbkJ4ajf/6MNI9kGOCuKl/nQa3y1egyKOleCkAlSfcIzBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAD8LVYZc0T2/lez+rQzh8Ep2m0bzQtts/tDOAZq5Xk34oc+y LSD/Nn9IjGLKgScKDhIl9GSRuLJ7mTLCX68KcIFpbsvvlwEojrKqagUtVSjX6B1f89gHK4PD sITqcQUzOOGrVHf2eMzAP2A4ded6nvd2GDy9eu+2cL3zbUlGzVKFgU1QaFyRNBTE7WUZa3OO YG7E1pcu9HoyPLxQ4TUJZd/GwQ35VPzxmPCcrDKY3fiV37UfoAU4jOiC7Rmhiu4wAcY7gd5A 2I8zJOl+bofJyHUKwVbG/VKrwLx7zoSgSWqAmcdiWM0KEK2h2rM3bwvrfHBKd21Ii1yXpkg3 x/aA3ZMAAAAAAAA= --------------ms080700070207000501000009-- From nobody Sun Aug 9 23:18:02 2020 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 6C37B3A13FF for ; Sun, 9 Aug 2020 23:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 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.001, HTML_MESSAGE=0.001, 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 (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 RgOH-RefByXa for ; Sun, 9 Aug 2020 23:17:59 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 5C3A23A0433 for ; Sun, 9 Aug 2020 23:17:59 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id x6so4265969pgx.12 for ; Sun, 09 Aug 2020 23:17:59 -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=2CRrRMGAliyaneg0T9FkHraZuJpx1WtKGq6YOshDLN8=; b=X1o1axOROX9bEa2baZ3fDSuqcBvbmfC0k5+au92RqJJNLStT3iNiV9EbxZu/Pr+a// zNyF40hwxv4sNnNfP3YI6GuVSeqaIyGM1qFL7xy2IJh024cmHwldankuDNg5rndoakK7 bMn0jOZJ9eEJQuAhcqKP0n667Ep9mEaH7Nooo= 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=2CRrRMGAliyaneg0T9FkHraZuJpx1WtKGq6YOshDLN8=; b=k/2kzyiZK6asvW/rB0oZMsGTchWNaeNR4KLUvDsn6Ovy7O5kxr40HHBWvUDqeJraK/ AmoTe+jpjs/r2GXpPkb/HEXEkRSX6Al0f/kphCXNVn55BMeYy9LtQO9f19RNooXzkLGk YfZcpq2Zxhydz1TmouPmmJVj/FM88JvTPce8924FqaYMFz9zTdxV8h+DUXJu4IGR7mwe im+J+GJG3RZt9jXyYKwDNdrIm5DHdgZJR7Wo+IviaAoaQ1RN53N8/HhxAKrN8mp2mQ5T tbUT1nZsE2q9A2yyLukyRBEluIYlPn0AxyeAhawrAjFiUtIJRyutyURqaDeO+WV43GB0 di6A== X-Gm-Message-State: AOAM530/pfMthTbQKtU8CayCcP6L8xH+9x6TlhrMzvc0SCT21X0bHWHg bMd7MGT7TYsVv+TRrVxj29iwi7y+buNeYn2K3Ll5Cn3PUYhj3o24XDm5Ww6Js6cbOj0g/1LPQgZ mqD8C8N60blIzLnyThi9eSw== X-Google-Smtp-Source: ABdhPJwget8VThC+e9gyFqHA2JLujHmltQVqmQ8GfmPYWQgQ+i233k0SgVzYJhemdr1KmsOeGu5EC81V1trrRo4JDdY= X-Received: by 2002:a63:4c48:: with SMTP id m8mr21027943pgl.290.1597040278637; Sun, 09 Aug 2020 23:17:58 -0700 (PDT) MIME-Version: 1.0 References: <0DEE1AC7-2EA7-420F-B0B5-6F96A3D04D1C@forgerock.com> In-Reply-To: <0DEE1AC7-2EA7-420F-B0B5-6F96A3D04D1C@forgerock.com> From: Dave Tonge Date: Mon, 10 Aug 2020 08:17:47 +0200 Message-ID: To: Neil Madden Cc: oauth Content-Type: multipart/alternative; boundary="00000000000080317205ac7fea44" Archived-At: Subject: Re: [OAUTH-WG] ECDH-1PU encryption algorithm 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, 10 Aug 2020 06:18:01 -0000 --00000000000080317205ac7fea44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Neil I'd be interested in seeing this draft discussed. Dave On Wed, 5 Aug 2020 at 12:02, Neil Madden wrote: > Hi all, > > You may remember me from such I-Ds as > https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which proposes > adding a new encryption algorithm to JOSE. I=E2=80=99d like to reserve a = bit of > time to discuss it at one of the upcoming interim meetings. > > The basic idea is that in many cases in OAuth and OIDC you want to ensure > both confidentiality and authenticity of some token - for example when > transferring an ID token containing PII to the client through the front > channel, or for access tokens intended to be handled by a specific RS > without online token introspection (such as the JWT access token draft). = If > you have a shared secret key between the AS and the client/RS then you ca= n > use symmetric authenticated encryption (alg=3Ddir or alg=3DA128KW etc). B= ut if > you need to use public key cryptography then currently you are limited to= a > nested signed-then-encrypted JOSE structure, which produces much larger > token sizes. > > The draft adds a new =E2=80=9Cpublic key authenticated encryption=E2=80= =9D mode based on > ECDH in the NIST standard =E2=80=9Cone-pass unified=E2=80=9D model. The p= rimary advantage > for OAuth usage is that the tokens produced are more compact compared to > signing+encryption (~30% smaller for typical access/ID token sizes in > compact serialization). Performance-wise, it=E2=80=99s roughly equivalent= . I know > that size concerns are often a limiting factor in choosing whether to > encrypt tokens, so this should help. > > In terms of implementation, it=E2=80=99s essentially just a few extra lin= es of > code compared to an ECDH-ES implementation. (Some JOSE library APIs might > need an adjustment to accommodate the extra private key needed for > encryption/public key for decryption). > > I=E2=80=99ve received a few emails off-list from people interested in usi= ng it for > non-OAuth use-cases such as secure messaging applications. I think these > use-cases can be accommodated without significant changes, so I think the > OAuth WG would be a good venue for advancing this. > > I=E2=80=99d be interested to hear thoughts and discussion on the list pri= or to any > discussion at an interim meeting. > > =E2=80=94 Neil > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Dave Tonge CTO [image: Moneyhub Enterprise] Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL 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. --00000000000080317205ac7fea44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Neil

I'd be interested=C2=A0in seei= ng this draft discussed.

Dave

On Wed, 5 Aug 2020 at 12= :02, Neil Madden <neil.madd= en@forgerock.com> wrote:
Hi all,

<= /div>
You may remember me from such I-Ds as=C2=A0https://t= ools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which proposes adding= a new encryption algorithm to JOSE. I=E2=80=99d like to reserve a bit of t= ime to discuss it at one of the upcoming interim meetings.

The basic idea is that in many cases in OAuth and OIDC you want to= ensure both confidentiality and authenticity of some token - for example w= hen transferring an ID token containing PII to the client through the front= channel, or for access tokens intended to be handled by a specific RS with= out online token introspection (such as the JWT access token draft). If you= have a shared secret key between the AS and the client/RS then you can use= symmetric authenticated encryption (alg=3Ddir or alg=3DA128KW etc). But if= you need to use public key cryptography then currently you are limited to = a nested signed-then-encrypted JOSE structure, which produces much larger t= oken sizes.

The draft adds a new =E2=80=9Cpublic k= ey authenticated encryption=E2=80=9D mode based on ECDH in the NIST standar= d =E2=80=9Cone-pass unified=E2=80=9D model. The primary advantage for OAuth= usage is that the tokens produced are more compact compared to signing+enc= ryption (~30% smaller for typical access/ID token sizes in compact serializ= ation). Performance-wise, it=E2=80=99s roughly equivalent. I know that size= concerns are often a limiting factor in choosing whether to encrypt tokens= , so this should help.

In terms of implementation,= it=E2=80=99s essentially just a few extra lines of code compared to an ECD= H-ES implementation. (Some JOSE library APIs might need an adjustment to ac= commodate the extra private key needed for encryption/public key for decryp= tion).

I=E2=80=99ve received a few emails off-list= from people interested in using it for non-OAuth use-cases such as secure = messaging applications. I think these use-cases can be accommodated without= significant changes, so I think the OAuth WG would be a good venue for adv= ancing this.

I=E2=80=99d be interested to hear tho= ughts and discussion on the list prior to any discussion at an interim meet= ing.

=E2=80=94 Neil
___________________= ____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
Da= ve Tonge
CTO
3D"Moneyhub
Moneyhub Financial Technology, 5th Fl= oor, 10 Temple Back, Bristol, BS1 6FL
t:=C2=A0+44 (0)117 280 512= 0

Moneyhub = Enterprise is a trading style of Moneyhub Financial Technology Limited whic= h is authorised and regulated by the Financial Conduct Authority ("FCA= ").=C2=A0Moneyhub Financial Technology is entered on the Financial Ser= vices Register=C2=A0(FRN=C2=A0809360) at fca.= org.uk/register. Moneyhub=C2=A0Financial Technology is registered in England &= ; Wales, company registration number=C2=A0=C2=A006909772=C2=A0.<= /span>
Moneyhub=C2=A0Financial Technology L= imited 2018=C2=A0=C2=A9<= /div>

DISCLAIMER: This email (including any attachments) is subject to co= pyright, 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 unla= wful. Whilst reasonable efforts are made to ensure that any attachments are= virus-free, it is the recipient's sole responsibility to scan all atta= chments for viruses. All calls and emails to and from this company may be m= onitored and recorded for legitimate purposes relating to this company'= s business. Any opinions expressed in this email (or in any attachments) ar= e those of the author and do not necessarily represent the opinions of Mone= yhub Financial Technology Limited or of any other group company.
<= /div>

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.


--00000000000080317205ac7fea44-- From nobody Mon Aug 10 01:29:02 2020 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 3C78C3A0DDC for ; Mon, 10 Aug 2020 01:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=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 g5hY_CilVWJp for ; Mon, 10 Aug 2020 01:28:59 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 D2DBA3A1426 for ; Mon, 10 Aug 2020 01:28:58 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id d190so6879584wmd.4 for ; Mon, 10 Aug 2020 01:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:mime-version:subject:from:in-reply-to:cc :date:message-id:references:to; bh=R2veiZ4WZO4syfyOxtLkJl6Ivh0Hy3WfGZZ93RPJPyo=; b=WUGF+iA1UNDihxD+hscN6Q2GcmUaZptvdPRQXfmsJWLhgTtPvomyJC5T5HPuDib6Ad OLw8cKaH3su3eizSLL5ue1R1mvwCWAvmLBFnmfV/sc7Fy2hL6acxRNNXepDSRyQmXw4E hqpJ0nES5gbpVGJaiINpKGFpeKKhzxAsnA2Mc= 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:mime-version:subject :from:in-reply-to:cc:date:message-id:references:to; bh=R2veiZ4WZO4syfyOxtLkJl6Ivh0Hy3WfGZZ93RPJPyo=; b=CGh3JNAKY9/vSbwwwKlD29hh7pOlEcVFvcvp9qzAljvIFDhKGKQVyVhH7qEUNOrig0 Ciqm7geFIQwV0+NmxcADRrIYC7F9RQn10XF3baXg3/Wv/YnkgMPHDRkA3WKRbaX60qPJ QibZ4WMb1S4v0Hseec1nYppxjoTubC8kuZWXP7p06s1khR1XWi+VBhOpewR3K32psgJo zXtOfETAG4maJ4obIAvfqgYmC6on8rpkZrNodkYOXhMf0WGEUvkuBDnQYloA5I3OT0oM bsIRUAMDyCTdH7HPig67dTFZXeTJuzZQRZRfEcz+x2bLqsw3Iz86TsrjITWRw3fbHp1V efmg== X-Gm-Message-State: AOAM531dMirbhrvw/fm7AXrFF0Cux/ZlfwUfpY1AB6V1RELI2wPIOXdc XmGoMgMXiAWWM1SYPLnmiMPi5gHCV5E= X-Google-Smtp-Source: ABdhPJwqUQtsUiSmXStwDAOJa6nNn7eGP8nmtWrICKHAZz0ik6mvU3Rx+wCzZrFuXPEZFhVkNHfBRQ== X-Received: by 2002:a7b:c3d4:: with SMTP id t20mr23903620wmj.8.1597048136956; Mon, 10 Aug 2020 01:28:56 -0700 (PDT) Received: from [10.0.0.3] (38.227.143.150.dyn.plus.net. [150.143.227.38]) by smtp.gmail.com with ESMTPSA id s20sm19597568wmh.21.2020.08.10.01.28.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Aug 2020 01:28:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Neil Madden In-Reply-To: <51424c05-3199-0caf-65ea-6d7a4433c9b9@connect2id.com> Cc: oauth@ietf.org Date: Mon, 10 Aug 2020 09:28:55 +0100 Message-Id: References: <51424c05-3199-0caf-65ea-6d7a4433c9b9@connect2id.com> To: Vladimir Dzhuvinov X-Mailer: iPhone Mail (17F80) Archived-At: Subject: Re: [OAUTH-WG] ECDH-1PU encryption algorithm 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, 10 Aug 2020 08:29:01 -0000 Thanks Vladimir, Responses below > On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov wrot= e: >=20 > =EF=BB=BFHi Neil, >=20 > I definitely like the elegance of the proposed alg for JOSE, it provides > something that isn't currently available in the various classes of algs > made standard in JOSE. >=20 > I also wanted to ask what's happening with AES SIV for JOSE, if there's > traction / feedback / support there as well? >=20 > https://tools.ietf.org/html/draft-madden-jose-siv-mode-02 Thanks for bringing this up. I=E2=80=99ve not received much feedback about t= his one, and I haven=E2=80=99t been very good at pushing it. If there is int= erest then I=E2=80=99d certainly be interested in bringing this forward too.= =20 That draft might be a better fit for eg the COSE WG though, which could then= also register identifiers for JOSE. What do you think? >=20 > Vladimir >=20 >=20 >>> On 05/08/2020 13:01, Neil Madden wrote: >> Hi all, >> You may remember me from such I-Ds >> as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which >> proposes adding a new encryption algorithm to JOSE. I=E2=80=99d like to >> reserve a bit of time to discuss it at one of the upcoming interim >> meetings. >> The basic idea is that in many cases in OAuth and OIDC you want to >> ensure both confidentiality and authenticity of some token - for >> example when transferring an ID token containing PII to the client >> through the front channel, or for access tokens intended to be handled >> by a specific RS without online token introspection (such as the JWT >> access token draft). If you have a shared secret key between the AS >> and the client/RS then you can use symmetric authenticated encryption >> (alg=3Ddir or alg=3DA128KW etc). But if you need to use public key >> cryptography then currently you are limited to a nested >> signed-then-encrypted JOSE structure, which produces much larger token >> sizes. >> The draft adds a new =E2=80=9Cpublic key authenticated encryption=E2=80=9D= mode based >> on ECDH in the NIST standard =E2=80=9Cone-pass unified=E2=80=9D model. Th= e primary >> advantage for OAuth usage is that the tokens produced are more compact >> compared to signing+encryption (~30% smaller for typical access/ID >> token sizes in compact serialization). Performance-wise, it=E2=80=99s rou= ghly >> equivalent. I know that size concerns are often a limiting factor in >> choosing whether to encrypt tokens, so this should help. >> In terms of implementation, it=E2=80=99s essentially just a few extra lin= es of >> code compared to an ECDH-ES implementation. (Some JOSE library APIs >> might need an adjustment to accommodate the extra private key needed >> for encryption/public key for decryption). >> I=E2=80=99ve received a few emails off-list from people interested in usi= ng it >> for non-OAuth use-cases such as secure messaging applications. I think >> these use-cases can be accommodated without significant changes, so I >> think the OAuth WG would be a good venue for advancing this. >> I=E2=80=99d be interested to hear thoughts and discussion on the list pri= or to >> any discussion at an interim meeting. >> =E2=80=94 Neil From nobody Mon Aug 10 06:11:56 2020 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 EF9883A1546 for ; Mon, 10 Aug 2020 06:11:54 -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 o6ym5HoW07xb for ; Mon, 10 Aug 2020 06:11:53 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 5C3443A1543 for ; Mon, 10 Aug 2020 06:11:53 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id k20so8291508wmi.5 for ; Mon, 10 Aug 2020 06:11:53 -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=5Ur2s4uvYnamaYq9lT3r8M1pwFl9pJH7MPfoN0UoSN8=; b=uucuQxLVq53tvUCwn0ymEF8hL7OgWLFDqakvQhbkPtnOQRwCXc8WGAd9PdZTCAVnO5 M/bVBuTNhGeFMvjthl5yZhNO8RIfOi0qUgAkBvF9I8c4qG8qoEH5Nrhiw1dAc0Uej9JV +NodOflMyQaU1EGG4YADsujH49XNSXalwvyHAAVR2fl1BM5ad0TYXhtlE+zAdrKBB20a LMNaAi6H6MAMXxw2zL1nZDeaqJ5QjH7S93IXxChfxCBunaeWNVQHtorqduvnpaiOn+nc OAyiR2CVkSg7eOakDCQ1CBp4PRkY/zsWVfO7wZMSuLOaAvw5fbRB4rCKRYGfojPjLcMa iw1w== 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=5Ur2s4uvYnamaYq9lT3r8M1pwFl9pJH7MPfoN0UoSN8=; b=KKZxn1FVVeSVKk5JcNxTjipQ2D1YPMHaWVfQqjM1xboWAk4nfCAAVUtjVAElt2yy6h qdjHk0S/XOrmTH2kiVP5AJUNwNGgWFXQkAuNQb23ETbhd9YwH/SKwIsLPVSG1TKamJvN hX9mBEvWZcLGFNeaScOQAZLHfGxWMdNr5bCD3ir+WPeJY4f5IFs9vmXnJ3iTZbPSuhjA yOSBYa4km5Qfa5ms3Hrmc8zaovreoBRLio60+2cAZtoiPHIvhzmuKNP6Mz40tatf+jtv 02dk+kaU29p10sI2gzjN53hvdbibL/IGq92HuZZj7L7ZrfPoAbDQcL5/cisbGlooU4kq /cQw== X-Gm-Message-State: AOAM531H1xtQfuFf8brqPOYHt8F7D1O0fHRgBzhOt2Ssv7T0XaX0lfQr Fae4bolKE8MQzCGGD9ENMaZC1btFiApW7BxoEWb99Icl X-Google-Smtp-Source: ABdhPJynZB4FftXYtbiEcdReOY84nuPkH/mGL7OrkoYGubTsHO8iALYevr69Jrsdq/Va+DKbB8B2yx0VKmeigFxc6BA= X-Received: by 2002:a1c:b4c1:: with SMTP id d184mr2371716wmf.26.1597065111704; Mon, 10 Aug 2020 06:11:51 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Mon, 10 Aug 2020 09:11:41 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000aa979005ac85b2cf" Archived-At: Subject: [OAUTH-WG] August 10th Interim slides 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, 10 Aug 2020 13:11:55 -0000 --000000000000aa979005ac85b2cf Content-Type: text/plain; charset="UTF-8" You can find the slides for today's interim here: https://datatracker.ietf.org/meeting/interim-2020-oauth-11/session/oauth Regards, Rifaat --000000000000aa979005ac85b2cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You can find the slides for today's interim here:

Regards,
=C2=A0Rifaat
--000000000000aa979005ac85b2cf-- From nobody Mon Aug 10 09:01:03 2020 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 9FB7C3A07C8 for ; Mon, 10 Aug 2020 09:01:01 -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 wqalNFQTZYAe for ; Mon, 10 Aug 2020 09:00:59 -0700 (PDT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 CFAC03A07C7 for ; Mon, 10 Aug 2020 09:00:59 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id g3so2397908ybc.3 for ; Mon, 10 Aug 2020 09:00: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=bEOAnj1YkifZr1wvs1BKS9rsP8e19n7ATtedpWCL0tk=; b=TLn698IXOD/wt3GxUkB/Jcvk+mFOiW3i+RGwMxLe71xc9g90yJCwJZMcpc93CovDNV zvotx5bE8hvT2hR7AlzsC0CnSaIf7fkKCOM32yaMMnEvKbKCLCHdfRhYJ2pJCkXXhn3Q +ofyGzKiPJowcE+m9wth+FZca3v3fM7suQ/ulTaJIPYV+2cLQKiKoljeZpgrLjCVrwZR n5zkDYyZx9HtlJy0HmJjIFpuOQizN9z0w3nOy8pkNU9rSQYo0PRqbeY0sDvnkeVBVHrA AgC++6OdPAj9gnlDNThr0AChiNk9gf6yXK6LrxKnhUO8funMBVQvo3jqFTEb2SUWd+cB ub/g== 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=bEOAnj1YkifZr1wvs1BKS9rsP8e19n7ATtedpWCL0tk=; b=HR++IpAITsTsoPVMAcfk9Dzsr/Fsc/OExOcGL6ZDyGEzgGMP+tlOOGP6iFvoSEuJ2b OC4qdigJEWTzhZf1hk+/V9D1JxkGpOV6SfbZN23lqOfYGXWKDsrGBHSq3aYJGozg+/BR OO7EajhbqcLr1otxlITME34luqezF62bsYKsBO6EkCdbxdFnga6cWsbURaTemANH4qNR l/AnhTMMvMt2lV8kiFaOB1hl6Q9NMOa/g5Q4ktcj+15GMz3aJuAEXhuPWHO1Ced/vpFD cktWVbfx0XaqALFZhdvGU++94TXAbztjcf9gqoxJJrCc7nz8Fp1D4hLrnDXcOu33Nm7h qJ+g== X-Gm-Message-State: AOAM531uDEDuWfo7h/P6NNiDqJrTVr3BKlxVodI1avKoW42Nmi0ks6uC bH5uMDWdROmoHUH6o7Y8enuSCXNUjq3Fk+dBPQ== X-Google-Smtp-Source: ABdhPJynopxpHNaVYmDg1S4TRbTGctFqBEyXpyl59YJNNF5lp4Fcx5rOMVYRQNB0OxD8a/uHw3dZdd1ztUD/W0ElzqM= X-Received: by 2002:a25:c743:: with SMTP id w64mr38285669ybe.127.1597075258876; Mon, 10 Aug 2020 09:00:58 -0700 (PDT) MIME-Version: 1.0 References: <51424c05-3199-0caf-65ea-6d7a4433c9b9@connect2id.com> In-Reply-To: From: Filip Skokan Date: Mon, 10 Aug 2020 18:00:22 +0200 Message-ID: To: Neil Madden Cc: Vladimir Dzhuvinov , oauth Content-Type: multipart/alternative; boundary="0000000000007c25a105ac880f53" Archived-At: Subject: Re: [OAUTH-WG] ECDH-1PU encryption algorithm 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, 10 Aug 2020 16:01:02 -0000 --0000000000007c25a105ac880f53 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Neil, I'm interested in seeing both AES SIV and ECDH-1PU for JOSE. Not sure how to go about it tho since JOSE is a concluded WG. Out of curiosity, why is it a concluded WG? Did IETF/JOSE WG not consider the need to further maintain/expand the JOSE algorithms as time goes on? S pozdravem, *Filip Skokan* On Mon, 10 Aug 2020 at 10:29, Neil Madden wrote= : > Thanks Vladimir, > > Responses below > > > On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov > wrote: > > > > =EF=BB=BFHi Neil, > > > > I definitely like the elegance of the proposed alg for JOSE, it provide= s > > something that isn't currently available in the various classes of algs > > made standard in JOSE. > > > > I also wanted to ask what's happening with AES SIV for JOSE, if there's > > traction / feedback / support there as well? > > > > https://tools.ietf.org/html/draft-madden-jose-siv-mode-02 > > Thanks for bringing this up. I=E2=80=99ve not received much feedback abou= t this > one, and I haven=E2=80=99t been very good at pushing it. If there is inte= rest then > I=E2=80=99d certainly be interested in bringing this forward too. > > That draft might be a better fit for eg the COSE WG though, which could > then also register identifiers for JOSE. What do you think? > > > > > Vladimir > > > > > >>> On 05/08/2020 13:01, Neil Madden wrote: > >> Hi all, > >> You may remember me from such I-Ds > >> as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which > >> proposes adding a new encryption algorithm to JOSE. I=E2=80=99d like t= o > >> reserve a bit of time to discuss it at one of the upcoming interim > >> meetings. > >> The basic idea is that in many cases in OAuth and OIDC you want to > >> ensure both confidentiality and authenticity of some token - for > >> example when transferring an ID token containing PII to the client > >> through the front channel, or for access tokens intended to be handled > >> by a specific RS without online token introspection (such as the JWT > >> access token draft). If you have a shared secret key between the AS > >> and the client/RS then you can use symmetric authenticated encryption > >> (alg=3Ddir or alg=3DA128KW etc). But if you need to use public key > >> cryptography then currently you are limited to a nested > >> signed-then-encrypted JOSE structure, which produces much larger token > >> sizes. > >> The draft adds a new =E2=80=9Cpublic key authenticated encryption=E2= =80=9D mode based > >> on ECDH in the NIST standard =E2=80=9Cone-pass unified=E2=80=9D model.= The primary > >> advantage for OAuth usage is that the tokens produced are more compact > >> compared to signing+encryption (~30% smaller for typical access/ID > >> token sizes in compact serialization). Performance-wise, it=E2=80=99s = roughly > >> equivalent. I know that size concerns are often a limiting factor in > >> choosing whether to encrypt tokens, so this should help. > >> In terms of implementation, it=E2=80=99s essentially just a few extra = lines of > >> code compared to an ECDH-ES implementation. (Some JOSE library APIs > >> might need an adjustment to accommodate the extra private key needed > >> for encryption/public key for decryption). > >> I=E2=80=99ve received a few emails off-list from people interested in = using it > >> for non-OAuth use-cases such as secure messaging applications. I think > >> these use-cases can be accommodated without significant changes, so I > >> think the OAuth WG would be a good venue for advancing this. > >> I=E2=80=99d be interested to hear thoughts and discussion on the list = prior to > >> any discussion at an interim meeting. > >> =E2=80=94 Neil > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000007c25a105ac880f53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Neil,

I'm interested in seeing b= oth AES SIV and=C2=A0ECDH-1PU for JOSE. Not sure how to go about it tho sin= ce JOSE is a concluded WG.=C2=A0

Out of curiosity,= why is it a concluded WG? Did IETF/JOSE WG not consider the need to furthe= r maintain/expand the JOSE algorithms as time goes on?

S pozdravem,
Filip Skokan

<= /div>
O= n Mon, 10 Aug 2020 at 10:29, Neil Madden <neil.madden@forgerock.com> wrote:
Thanks Vladimir,

Responses below

> On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov <vladimir@connect2id.com> wrot= e:
>
> =EF=BB=BFHi Neil,
>
> I definitely like the elegance of the proposed alg for JOSE, it provid= es
> something that isn't currently available in the various classes of= algs
> made standard in JOSE.
>
> I also wanted to ask what's happening with AES SIV for JOSE, if th= ere's
> traction / feedback / support there as well?
>
> https://tools.ietf.org/html/draft-madd= en-jose-siv-mode-02

Thanks for bringing this up. I=E2=80=99ve not received much feedback about = this one, and I haven=E2=80=99t been very good at pushing it. If there is i= nterest then I=E2=80=99d certainly be interested in bringing this forward t= oo.

That draft might be a better fit for eg the COSE WG though, which could the= n also register identifiers for JOSE. What do you think?

>
> Vladimir
>
>
>>> On 05/08/2020 13:01, Neil Madden wrote:
>> Hi all,
>> You may remember me from such I-Ds
>> as https://tools.ietf.org/html/dra= ft-madden-jose-ecdh-1pu-03, which
>> proposes adding a new encryption algorithm to JOSE. I=E2=80=99d li= ke to
>> reserve a bit of time to discuss it at one of the upcoming interim=
>> meetings.
>> The basic idea is that in many cases in OAuth and OIDC you want to=
>> ensure both confidentiality and authenticity of some token - for >> example when transferring an ID token containing PII to the client=
>> through the front channel, or for access tokens intended to be han= dled
>> by a specific RS without online token introspection (such as the J= WT
>> access token draft). If you have a shared secret key between the A= S
>> and the client/RS then you can use symmetric authenticated encrypt= ion
>> (alg=3Ddir or alg=3DA128KW etc). But if you need to use public key=
>> cryptography then currently you are limited to a nested
>> signed-then-encrypted JOSE structure, which produces much larger t= oken
>> sizes.
>> The draft adds a new =E2=80=9Cpublic key authenticated encryption= =E2=80=9D mode based
>> on ECDH in the NIST standard =E2=80=9Cone-pass unified=E2=80=9D mo= del. The primary
>> advantage for OAuth usage is that the tokens produced are more com= pact
>> compared to signing+encryption (~30% smaller for typical access/ID=
>> token sizes in compact serialization). Performance-wise, it=E2=80= =99s roughly
>> equivalent. I know that size concerns are often a limiting factor = in
>> choosing whether to encrypt tokens, so this should help.
>> In terms of implementation, it=E2=80=99s essentially just a few ex= tra lines of
>> code compared to an ECDH-ES implementation. (Some JOSE library API= s
>> might need an adjustment to accommodate the extra private key need= ed
>> for encryption/public key for decryption).
>> I=E2=80=99ve received a few emails off-list from people interested= in using it
>> for non-OAuth use-cases such as secure messaging applications. I t= hink
>> these use-cases can be accommodated without significant changes, s= o I
>> think the OAuth WG would be a good venue for advancing this.
>> I=E2=80=99d be interested to hear thoughts and discussion on the l= ist prior to
>> any discussion at an interim meeting.
>> =E2=80=94 Neil

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000007c25a105ac880f53-- From nobody Mon Aug 10 09:42:37 2020 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 8074C3A0A06 for ; Mon, 10 Aug 2020 09:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.435 X-Spam-Level: X-Spam-Status: No, score=-0.435 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_08=1.651, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 9kNPrEKxVwUC for ; Mon, 10 Aug 2020 09:42:34 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 E2E803A0A3A for ; Mon, 10 Aug 2020 09:42:33 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id i80so5051901lfi.13 for ; Mon, 10 Aug 2020 09:42:33 -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:cc; bh=Eow0WXVUW/yUCSTWwf5W8aFgbZL3R0D3152d/Ncoglc=; b=DfVBx7fSSY0ZYI+oY3xCpLWls40jKa30vLZA4lPYr563tgh75zn1WYi2TYhdWFSxBq bd4YeJqSUE50/aTk6J72LsEJrPmAMoCE531tSSVWQAqBMxwNyPP8+Jnu4PTk2aeX2jAV vpnSwoub+TGrY9YV6TQlwKNWa9PcW9toZRn19d8K5rOwboeim5qpas2N14S/xoWJ65jE xDip6cKL2bKgo1JEd+u8e4ijYY8Lx+fgbGFao2vpRDNVx3KJn79TtkvVA3ExnLRUCHXj kECUFUglPnnkA+CKVv4jA+HsH1WOuioodmH6Yc+XnVycDqh7V77I3rAwd8xzVDo7n33J XyFg== 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:cc; bh=Eow0WXVUW/yUCSTWwf5W8aFgbZL3R0D3152d/Ncoglc=; b=rEDetx5JQkK+Ynoboxc+z9OpkU686UcUG6xZ1FtlSZVoAjMlnHjTbuLYknCcZOSmKj +tcHl0pHy+ZEJiy4NS51Y4hpUi+El/HYqp+0kzYw1AZs3yHXkE33Qs4SBaNF8KzVI6tk ZVdT9Jn7r8iOA5SZfZED71KGQs0d6iWt8jrfUBBWzdaKSU+ppq3ujXEpb+lxWtHDMl5J 1jF8FCLsBAXdp2Mym3Yg7rL89dwL6AOfmGPhkM+O+1aUkDOspQFcZhF6XdMSHVbKso6B 2HQR2F1fv8tpUq8jkDYtOVT7OdOnkhpt30KIFATrnnAH7rTAKeJ9jWmQNfBPNiE3je2M FK1A== X-Gm-Message-State: AOAM531aLao6pNgiTr+j30SbotYNiU4ULSh8xC5/KBe7/TBKboYnOe9A MFQj9xlR8h4GU5dW+PFxw948RWUVprD3PfgKi/sT+qWM X-Google-Smtp-Source: ABdhPJxl63Khf57ppvT2J+nhb9jb1RJgtsEcsJRDqKpTJtHcsK2AFHeeR9djRjc/5M5/5jOZwvCNdOBufrq3uYTH2nk= X-Received: by 2002:a19:8044:: with SMTP id b65mr975228lfd.91.1597077751606; Mon, 10 Aug 2020 09:42:31 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Mon, 10 Aug 2020 09:41:55 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000010311205ac88a421" Archived-At: Subject: [OAUTH-WG] Privacy Considerations section in OAuth 2.1? 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, 10 Aug 2020 16:42:36 -0000 --00000000000010311205ac88a421 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In the PAR meeting today, Denis requested there be a privacy considerations section in PAR. I don't think there is anything specific in PAR that would change the privacy considerations of OAuth, and am checking if there is WG interest, and consensus, on including a Privacy Considerations section in the OAuth 2.1 draft. /Dick =E1=90=A7 --00000000000010311205ac88a421 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the PAR meeting today, Denis requested there be a priva= cy considerations section in PAR. I don't think there is anything speci= fic in PAR that would change the privacy considerations of OAuth, and am ch= ecking if there is WG interest, and consensus, on including a Privacy Consi= derations section in the OAuth 2.1 draft.

/Dick
3D""=E1=90=A7
--00000000000010311205ac88a421-- From nobody Mon Aug 10 10:04:15 2020 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 8DED83A089F for ; Mon, 10 Aug 2020 10:04:14 -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_FONT_LOW_CONTRAST=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=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 8oN-aye3fQAp for ; Mon, 10 Aug 2020 10:04:12 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 A30B33A084D for ; Mon, 10 Aug 2020 10:04:12 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id w14so10401448ljj.4 for ; Mon, 10 Aug 2020 10:04:12 -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=eFZY5X7ryD2+KO8CAB8/LVB100mWZNQyodZLu0nX3qI=; b=UVoreLoRyJ/UZmawhkTx4pkEeiTuS2+gRNQuJ3s5lqBLEyvKCpcXLgBAdKfcn6irtG 1DmPhWhkD23q7YgAtQUt63xi3Kivv2LfgcI8ghqpQFong0tAmIT7BWazyNWZXogneESQ N83FQ981aXOb7XjdJOKpEgq7eImt0cSqSbsIBMfJ8GM6jdfex8E9snZr4sl2bnx+d6mk gnhO8nUlu4RiJYyRsxMWH0Rmwre76/ID7M+VHCEgZgIk9DqUySySbOPmMYOYYe0/Qdg0 rOuH4SHfCbxIfy08LdEen3bLqCw5DmA1nrE5nrrV6qG+BSY4bVyc9rKUEQHodyDPIixf LVpQ== 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=eFZY5X7ryD2+KO8CAB8/LVB100mWZNQyodZLu0nX3qI=; b=qtApMgN4bawpkRemvzqBZBuSjZuVLPi8oZ0lZ8pxAXWK3RT3ai5ll6SFaz0xVYf7+l ok9aUEiDaN2fRWyTN4v+d20yh29miJLPs8TRTfnCZRUFVtIXbxDE5HfbN6gksDtXSJbR 3T1+L8uv9j0r+RDn6y22hX9o0tf/2ZOStxiMKm1u9NXRhU/aLyZlyQtqlsvpLRBGQlyC tlX2LCbjSvzAY21CqCjXNxBpsxes7UEMuypK/CGsQVwjPmQyIndGIX3Wp+qelsGsKxwT 58+cDgGHssxMsfp+geaq4irUsDSiLqT+G97s+KOsN6Md59H/DuA2rsf+nsXKM+lJGJeI toxw== X-Gm-Message-State: AOAM530HmAu/Hdo/Dr+goIAi8M0iNNb46N4PRUidcnEVlfupYpmq/cCv Jw1mm+3uxzPLPNQp9JFO5IDloHM+WsNtVzZUoUTrZGWw+ZMoIhB+mU/Gv3AhtEeqKrKjSux7T4u 4pQ1fvGvwZ27BTg== X-Google-Smtp-Source: ABdhPJyYnmi66InnM4iA3dPjkAnA+fCJg8Gzkd59xZm4xPs+nosNmmzukEmNg1M5voPpX3qbMPzw7uUPGgMOjKidbx0= X-Received: by 2002:a2e:d1a:: with SMTP id 26mr997066ljn.422.1597079050569; Mon, 10 Aug 2020 10:04:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Mon, 10 Aug 2020 11:03:44 -0600 Message-ID: To: Dick Hardt Cc: oauth Content-Type: multipart/alternative; boundary="0000000000007ce9cf05ac88f1c9" Archived-At: Subject: Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1? 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, 10 Aug 2020 17:04:15 -0000 --0000000000007ce9cf05ac88f1c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I didn't have the reference offhand during the meeting today but https://tools.ietf.org/html/rfc6973 looks to be a good source of considerations for writing privacy considerations. As I mentioned, I've written a number of such sections. Though these probably shouldn't be considered exemplary they were published: https://tools.ietf.org/html/rfc8707#section-4, https://tools.ietf.org/html/rfc8705#section-8https://tools.ietf.org/html/rf= c8693#section-6 , https://tools.ietf.org/html/rfc7523#section-7, https://tools.ietf.org/html/rfc7522#section-7, and https://tools.ietf.org/html/rfc7521#section-8.4. I think including a pragmatic Privacy Considerations section in the OAuth 2.1 draft could be worthwhile. On Mon, Aug 10, 2020 at 10:42 AM Dick Hardt wrote: > In the PAR meeting today, Denis requested there be a privacy > considerations section in PAR. I don't think there is anything specific i= n > PAR that would change the privacy considerations of OAuth, and am checkin= g > if there is WG interest, and consensus, on including a Privacy > Considerations section in the OAuth 2.1 draft. > > /Dick > =E1=90=A7 > _______________________________________________ > 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._ --0000000000007ce9cf05ac88f1c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I didn't have the reference offhand during the me= eting today but https://tools.ietf.org/html/rfc6973 looks to be a good source of= considerations for writing privacy considerations. As I mentioned, I'v= e written a number of such sections. Though these probably shouldn't be= considered exemplary they were published: https://tools.ietf.org/html/rfc= 8707#section-4, https://tools.ietf.org/html/rfc8705#section-8https://t= ools.ietf.org/html/rfc8693#section-6, https://tools.ietf.org/html/rfc7= 523#section-7, https://tools.ietf.org/html/rfc7522#section-7, and = https://tools.ietf.org/html/rfc7521#section-8.4.

=
I think including a pragmatic Privacy Considerations section in the O= Auth 2.1 draft could be worthwhile.=C2=A0

On Mon, Aug 10, 2020 at 10:42= AM Dick Hardt <dick.hardt@gmail.com> wrote:
In the PAR meeting today, Denis requ= ested there be a privacy considerations section in PAR. I don't think t= here is anything specific in PAR that would change the privacy consideratio= ns of OAuth, and am checking if there is WG interest, and consensus, on inc= luding a Privacy Considerations section in the OAuth 2.1 draft.

/Dick
3D""=E1=90=A7
_______________________________________________
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. --0000000000007ce9cf05ac88f1c9-- From nobody Mon Aug 10 10:16:11 2020 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 EFA053A0B21 for ; Mon, 10 Aug 2020 10:16:09 -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 3EnKNS5-6aUv for ; Mon, 10 Aug 2020 10:16:08 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 A09843A0B20 for ; Mon, 10 Aug 2020 10:16:08 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id t14so273903wmi.3 for ; Mon, 10 Aug 2020 10:16:08 -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=PoA8HY/3puEpSrSgmoJPdJBjCq1T/QPBS+jWz+Kvyh4=; b=olIXQrGLaOoOpEit+m1bikWAUbiD/3sMayNyOCPJJ9ydKQMsUoVtBKDkjhcw3SAi0j PceChKUZJaH0e8P12hEBPGRhjVVKFx6s1mjPyucNhlFAyEj3uGRQhmacxegVjU4CU6wX QHN15ekLfEUPyMLxYWboXNLnZPNVV4l0XO9zjuxXSgUvfOKYLUM+Bjrw6W2nZKtB7kDy uOlicmppZ1Hkjx1FTEN1Gh6kHM6RokFD26js+kRy7c8nJqbtA7jQ9wE5WqPRkl4PDmV3 sUgPpNGAcM/heWXWApSLSEn9RaJvclh3NRpJwjSbLg6qnmvrfPfee1AAhcOCZ6fLoEZS DE+w== 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=PoA8HY/3puEpSrSgmoJPdJBjCq1T/QPBS+jWz+Kvyh4=; b=lVtXMmxJM51PwI1CcDk8XmMK5md0qxSG36e/Oc1StnFXCSW0f6Cfa8YDFXD+CvCaj7 pZ83krH6RxOzDniXkQgzh1fhMZm63Cvezs3GqsfIf/ToEo48gMRQRuX1QiqyskndeJln bNYDz8r5vsEcNq9QsgW0iHSfCS958ivVuBZQ6Xa858ME4hDP2i9UGbnhHBgUg5ZNx2s8 MMTxZ0kCxEVZktIKFWAp+DcQH8Lt4frvuSMhlJIiGZAxUPL9J5AKbzuLUNd9wDqN6z0P 0igP6xc6NTdSdTYK+jVkDk8WZRRXQQr5ENQu2rEahQWBMKp3fy4c62cjOzX7+KjlT+uF BINQ== X-Gm-Message-State: AOAM5307+qvo8DCZc9OZb9X9/di95Pvq6mJzfJ/qf473HUJtiFgsz+RK jfJMRTVPEmcLENMHtwdad4DY19+RZmXSrOEs3jk7M/ur X-Google-Smtp-Source: ABdhPJyQUzGPQaR5riOuQZtpiP1DEDI3QkDy5neNARU7giEXpJQSaCfHG/0x/WDr4hvfUt3YF1c5KTSL/kKCxZT1HlA= X-Received: by 2002:a7b:c084:: with SMTP id r4mr291940wmh.20.1597079767045; Mon, 10 Aug 2020 10:16:07 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Mon, 10 Aug 2020 13:15:56 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000315b6d05ac891c76" Archived-At: Subject: [OAUTH-WG] OAuth Interim Aug 10th Minutes 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, 10 Aug 2020 17:16:10 -0000 --000000000000315b6d05ac891c76 Content-Type: text/plain; charset="UTF-8" All, You can find the minutes and recording of this interim meeting in the following link: https://www.ietf.org/proceedings/interim-2020-oauth-11/minutes/minutes-interim-2020-oauth-11-202008101200-00 Thanks to *Dick Hardt *for taking these notes. Regards, Rifaat --000000000000315b6d05ac891c76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000315b6d05ac891c76-- From nobody Mon Aug 10 10:20:44 2020 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 EDF663A0B21 for ; Mon, 10 Aug 2020 10:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.995 X-Spam-Level: X-Spam-Status: No, score=-0.995 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.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 Tn-uSZbek7rq for ; Mon, 10 Aug 2020 10:20:41 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 B58193A0B4F for ; Mon, 10 Aug 2020 10:20:41 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id k23so9703903iom.10 for ; Mon, 10 Aug 2020 10:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B4Elje0uXPXKSmbCK8AyL1qaJx4mVd7OzJmRi/MekXo=; b=YTEB3TMKxnimbzvVWONg/GFG8gmamGqYJAo0Fy2bK1HuBL6ZOjXdJLjGYI1WTlfam7 ugwFAuINQlLHBKfQXo4jtw4/doxYrRKcNF9KryWu2iVyKnWYtCdCQJNCWlPaaNiMFkSX lX+unBbaR0RtgTXUDIz9MEeRUgMW0o+ulAKAaMHSGk6rSKfL8EzvrP3sI4w/QYxONbpt Y8AmAI8TQ1kK4fhbYSCQ/dkVjfAyaTXzRyDkEj2QIBvsFKaJGq8iKKD9Ey69b0X/KN2x 60SIvLq1yjnOB7LcHCaMus3E3tQ0/2XZVFqLICaCt3hHwh8/P9jCG0uRqpKLX44ZEBDZ 3zJw== 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=B4Elje0uXPXKSmbCK8AyL1qaJx4mVd7OzJmRi/MekXo=; b=WeIs3K3dBdPJgTt2Xj8Wx/jsidpyFI68Lu7NtgilAKXHZYqdL/R9X7xWCX3DeuWu6+ QsBc7yhsxSTea0hArhHus3pjYRgK8KFojfPmmetS/ujEwfkFbEO24UdO7FZrs3Z305Q7 eCBjgaN5huyj/ososCekgqy2D7obqBFGVZZOaOLb+JzA1NY2SFKgJo0ndboL9DnpbPJa D6jPkNt12FKKpZCSPqwGzK9DWoaeKBUUev8nQ0mGKmNF37Qh6tqdfmfwjZHe03PCIAi4 oTCuE/cQV2V3L8E5IFEWtbU2jZ2SjdG3m9mPA9M9QSwrqXRZWm+CuR4YWQ7NecxRKBq2 sRRw== X-Gm-Message-State: AOAM531wk3uTHr3C80l91GEArSi+WGZNYB5tvlpSkBRzXn/8iUBfPl3r srhEQTY5I7M5D6RGZMj9zVw/XAbdo14= X-Google-Smtp-Source: ABdhPJxHaZVqvSiB5rp2GX/PTFO4aYwLqbDSVV84+Pm0FLBwq8DyFR/zsqfocQ2EcuHnx31LQyw5kA== X-Received: by 2002:a05:6638:2164:: with SMTP id p4mr20688786jak.57.1597080040077; Mon, 10 Aug 2020 10:20:40 -0700 (PDT) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com. [209.85.166.169]) by smtp.gmail.com with ESMTPSA id l16sm6244318ilg.5.2020.08.10.10.20.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Aug 2020 10:20:39 -0700 (PDT) Received: by mail-il1-f169.google.com with SMTP id 77so8225284ilc.5 for ; Mon, 10 Aug 2020 10:20:38 -0700 (PDT) X-Received: by 2002:a92:5bd5:: with SMTP id c82mr19185913ilg.166.1597080038736; Mon, 10 Aug 2020 10:20:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Mon, 10 Aug 2020 10:20:27 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Dick Hardt Cc: OAuth WG , Denis , Torsten Lodderstedt Content-Type: multipart/alternative; boundary="0000000000006308ba05ac892ca9" Archived-At: Subject: Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1? 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, 10 Aug 2020 17:20:43 -0000 --0000000000006308ba05ac892ca9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree that there is nothing unique to PAR that would justify adding the privacy considerations mentioned to that draft. I wouldn't oppose adding a privacy considerations section to OAuth 2.1 though. Aaron On Mon, Aug 10, 2020 at 9:42 AM Dick Hardt wrote: > In the PAR meeting today, Denis requested there be a privacy > considerations section in PAR. I don't think there is anything specific i= n > PAR that would change the privacy considerations of OAuth, and am checkin= g > if there is WG interest, and consensus, on including a Privacy > Considerations section in the OAuth 2.1 draft. > > /Dick > =E1=90=A7 > --0000000000006308ba05ac892ca9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that there is nothing unique to PAR that would jus= tify adding the privacy considerations mentioned to that draft. I wouldn= 9;t oppose adding a privacy considerations section to OAuth 2.1 though.
Aaron


On Mon, Aug 10, 2020 at 9:42 AM D= ick Hardt <dick.hardt@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">In the PAR meeting today, Denis requested there be a privac= y considerations section in PAR. I don't think there is anything specif= ic in PAR that would change the privacy considerations of OAuth, and am che= cking if there is WG interest, and consensus, on including a Privacy Consid= erations section in the OAuth 2.1 draft.

/Dick
3D""=E1=90=A7
--0000000000006308ba05ac892ca9-- From nobody Mon Aug 10 10:28:05 2020 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 92A363A0BCD for ; Mon, 10 Aug 2020 10:28:03 -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 mP3pnFBZ4teY for ; Mon, 10 Aug 2020 10:28:02 -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 8630B3A0BC2 for ; Mon, 10 Aug 2020 10:28:01 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id v12so10463434ljc.10 for ; Mon, 10 Aug 2020 10:28:01 -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=S6LfJw/twivNZ4TTTXqzHCFNPlLDE/zKI5XKtt0aAYs=; b=svSrI/c6bttqp5DZKMk2ofiMnnCptFKxvqCqXZge2JsepQdsn/2TWEJBDfxyl7U/P2 ICj8+XQ4r60TmjgrcARiOzYcZk2FpuMSUyx6OAsvyM+9//PkwtKjUpJDCYBdF4BbqtIR ZGYg01kaDdC57ibfzEJpT8rmU70HZR9ftNB3O1bA1JnGfUdDv3Ww7NtihQajL2P9/wWK gRElnca0K4J7ByjoHWTOkKSxEJHd/Ip2gSozoCw0aCGgRgG/aClbszFaFxVxd8GDYPMw NZQJ0TDUTUw0dPXeS5+yZhY/c++TWWf76A0zgQ7mf1RHodyxdXYGIejz+K7lmZhb/TV0 oeIg== 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=S6LfJw/twivNZ4TTTXqzHCFNPlLDE/zKI5XKtt0aAYs=; b=R8vmbj7zB4qej6aZWDZV56tmVWcsTVEHwCNayzJvUd8QpOJ9axdpnQNmIpUOSjIoMV Im/nOQOVXniLweg3RMOU0htc+R4eBJ+hZSxJWPPnpQqjTfJIdo5W829VkmLwvhAIPq7U hKeNgieyBMdqqd2eZJNWFb3XyTgAswZXiGqseB5iRdMPdZTBzPu7rrZz7qwd0eK1/bhw j3SE6V294Gdx60LOg3gAxbjfTE01D7UWNoXPWTriDW9QwT2BPuGmisDp9A7rzh/buiE5 hgAjzE4Akl3Ez3Tbx6uRsVJvEibJzkf3dlwe1w5HhHwYb4McVul0CZI9LMvLX6JzKjZh vLGg== X-Gm-Message-State: AOAM530YjM4bqS2OryDQTGExfT3RyjHtKxrCEEfyU8+s7fNsM5mzmYrO nuhTJKor4r0TRjYC/zTPcq2u9CN6JGbzcLPWlHjCRs+z X-Google-Smtp-Source: ABdhPJw0pfWg3Hqba2x0vPUWzHFSC5aTxbCiSEmOS/9SDo757anK699SrZbKVoKrQX185a2NIt7SE+mzLSoOE2Ba8ps= X-Received: by 2002:a2e:9695:: with SMTP id q21mr1001728lji.437.1597080479591; Mon, 10 Aug 2020 10:27:59 -0700 (PDT) MIME-Version: 1.0 References: <51424c05-3199-0caf-65ea-6d7a4433c9b9@connect2id.com> In-Reply-To: From: Dick Hardt Date: Mon, 10 Aug 2020 10:27:23 -0700 Message-ID: To: Filip Skokan Cc: Neil Madden , oauth Content-Type: multipart/alternative; boundary="000000000000a9f2b805ac894692" Archived-At: Subject: Re: [OAUTH-WG] ECDH-1PU encryption algorithm 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, 10 Aug 2020 17:28:04 -0000 --000000000000a9f2b805ac894692 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm supportive of this work. It is not clear that it is in the charter of the OAuth WG. On Mon, Aug 10, 2020 at 9:01 AM Filip Skokan wrote: > Hi Neil, > > I'm interested in seeing both AES SIV and ECDH-1PU for JOSE. Not sure how > to go about it tho since JOSE is a concluded WG. > > Out of curiosity, why is it a concluded WG? Did IETF/JOSE WG not consider > the need to further maintain/expand the JOSE algorithms as time goes on? > > S pozdravem, > *Filip Skokan* > > > On Mon, 10 Aug 2020 at 10:29, Neil Madden > wrote: > >> Thanks Vladimir, >> >> Responses below >> >> > On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov >> wrote: >> > >> > =EF=BB=BFHi Neil, >> > >> > I definitely like the elegance of the proposed alg for JOSE, it provid= es >> > something that isn't currently available in the various classes of alg= s >> > made standard in JOSE. >> > >> > I also wanted to ask what's happening with AES SIV for JOSE, if there'= s >> > traction / feedback / support there as well? >> > >> > https://tools.ietf.org/html/draft-madden-jose-siv-mode-02 >> >> Thanks for bringing this up. I=E2=80=99ve not received much feedback abo= ut this >> one, and I haven=E2=80=99t been very good at pushing it. If there is int= erest then >> I=E2=80=99d certainly be interested in bringing this forward too. >> >> That draft might be a better fit for eg the COSE WG though, which could >> then also register identifiers for JOSE. What do you think? >> >> > >> > Vladimir >> > >> > >> >>> On 05/08/2020 13:01, Neil Madden wrote: >> >> Hi all, >> >> You may remember me from such I-Ds >> >> as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which >> >> proposes adding a new encryption algorithm to JOSE. I=E2=80=99d like = to >> >> reserve a bit of time to discuss it at one of the upcoming interim >> >> meetings. >> >> The basic idea is that in many cases in OAuth and OIDC you want to >> >> ensure both confidentiality and authenticity of some token - for >> >> example when transferring an ID token containing PII to the client >> >> through the front channel, or for access tokens intended to be handle= d >> >> by a specific RS without online token introspection (such as the JWT >> >> access token draft). If you have a shared secret key between the AS >> >> and the client/RS then you can use symmetric authenticated encryption >> >> (alg=3Ddir or alg=3DA128KW etc). But if you need to use public key >> >> cryptography then currently you are limited to a nested >> >> signed-then-encrypted JOSE structure, which produces much larger toke= n >> >> sizes. >> >> The draft adds a new =E2=80=9Cpublic key authenticated encryption=E2= =80=9D mode based >> >> on ECDH in the NIST standard =E2=80=9Cone-pass unified=E2=80=9D model= . The primary >> >> advantage for OAuth usage is that the tokens produced are more compac= t >> >> compared to signing+encryption (~30% smaller for typical access/ID >> >> token sizes in compact serialization). Performance-wise, it=E2=80=99s= roughly >> >> equivalent. I know that size concerns are often a limiting factor in >> >> choosing whether to encrypt tokens, so this should help. >> >> In terms of implementation, it=E2=80=99s essentially just a few extra= lines of >> >> code compared to an ECDH-ES implementation. (Some JOSE library APIs >> >> might need an adjustment to accommodate the extra private key needed >> >> for encryption/public key for decryption). >> >> I=E2=80=99ve received a few emails off-list from people interested in= using it >> >> for non-OAuth use-cases such as secure messaging applications. I thin= k >> >> these use-cases can be accommodated without significant changes, so I >> >> think the OAuth WG would be a good venue for advancing this. >> >> I=E2=80=99d be interested to hear thoughts and discussion on the list= prior to >> >> any discussion at an interim meeting. >> >> =E2=80=94 Neil >> >> _______________________________________________ >> 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 > --000000000000a9f2b805ac894692 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm supportive of this work.

It is = not clear that it is in the charter of the OAuth WG.


On= Mon, Aug 10, 2020 at 9:01 AM Filip Skokan <panva.ip@gmail.com> wrote:
Hi Neil,

I&= #39;m interested in seeing both AES SIV and=C2=A0ECDH-1PU for JOSE. Not sur= e how to go about it tho since JOSE is a concluded WG.=C2=A0

=
Out of curiosity, why is it a concluded WG? Did IETF/JOSE WG not= consider the need to further maintain/expand the JOSE algorithms as time g= oes on?

S pozdravem,
<= b>Filip Skokan


On Mon, 10 Aug 2020 at 10:29, Neil = Madden <n= eil.madden@forgerock.com> wrote:
Thanks Vladimir,

Responses below

> On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov <vladimir@connect2id.com> wrot= e:
>
> =EF=BB=BFHi Neil,
>
> I definitely like the elegance of the proposed alg for JOSE, it provid= es
> something that isn't currently available in the various classes of= algs
> made standard in JOSE.
>
> I also wanted to ask what's happening with AES SIV for JOSE, if th= ere's
> traction / feedback / support there as well?
>
> https://tools.ietf.org/html/draft-madd= en-jose-siv-mode-02

Thanks for bringing this up. I=E2=80=99ve not received much feedback about = this one, and I haven=E2=80=99t been very good at pushing it. If there is i= nterest then I=E2=80=99d certainly be interested in bringing this forward t= oo.

That draft might be a better fit for eg the COSE WG though, which could the= n also register identifiers for JOSE. What do you think?

>
> Vladimir
>
>
>>> On 05/08/2020 13:01, Neil Madden wrote:
>> Hi all,
>> You may remember me from such I-Ds
>> as https://tools.ietf.org/html/dra= ft-madden-jose-ecdh-1pu-03, which
>> proposes adding a new encryption algorithm to JOSE. I=E2=80=99d li= ke to
>> reserve a bit of time to discuss it at one of the upcoming interim=
>> meetings.
>> The basic idea is that in many cases in OAuth and OIDC you want to=
>> ensure both confidentiality and authenticity of some token - for >> example when transferring an ID token containing PII to the client=
>> through the front channel, or for access tokens intended to be han= dled
>> by a specific RS without online token introspection (such as the J= WT
>> access token draft). If you have a shared secret key between the A= S
>> and the client/RS then you can use symmetric authenticated encrypt= ion
>> (alg=3Ddir or alg=3DA128KW etc). But if you need to use public key=
>> cryptography then currently you are limited to a nested
>> signed-then-encrypted JOSE structure, which produces much larger t= oken
>> sizes.
>> The draft adds a new =E2=80=9Cpublic key authenticated encryption= =E2=80=9D mode based
>> on ECDH in the NIST standard =E2=80=9Cone-pass unified=E2=80=9D mo= del. The primary
>> advantage for OAuth usage is that the tokens produced are more com= pact
>> compared to signing+encryption (~30% smaller for typical access/ID=
>> token sizes in compact serialization). Performance-wise, it=E2=80= =99s roughly
>> equivalent. I know that size concerns are often a limiting factor = in
>> choosing whether to encrypt tokens, so this should help.
>> In terms of implementation, it=E2=80=99s essentially just a few ex= tra lines of
>> code compared to an ECDH-ES implementation. (Some JOSE library API= s
>> might need an adjustment to accommodate the extra private key need= ed
>> for encryption/public key for decryption).
>> I=E2=80=99ve received a few emails off-list from people interested= in using it
>> for non-OAuth use-cases such as secure messaging applications. I t= hink
>> these use-cases can be accommodated without significant changes, s= o I
>> think the OAuth WG would be a good venue for advancing this.
>> I=E2=80=99d be interested to hear thoughts and discussion on the l= ist prior to
>> any discussion at an interim meeting.
>> =E2=80=94 Neil

_______________________________________________
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
--000000000000a9f2b805ac894692-- From nobody Mon Aug 10 10:33:50 2020 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 59D963A0B3F for ; Mon, 10 Aug 2020 10:33:49 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=microsoft.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 a1kKlHdtcOWN for ; Mon, 10 Aug 2020 10:33:47 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640107.outbound.protection.outlook.com [40.107.64.107]) (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 18EB03A0B81 for ; Mon, 10 Aug 2020 10:33:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CzWayAuMVTy6MuR1YIT1ZN++WYZONLnQsgnUJa/iK1YOZuyBruLiABhcq85q/7mxhrOfFsFv6kFAjdzs4g3H7ibPL2YI/Ssayomy0M5rw78H3PbcYRMzuUTZw0D23yOpUCEqmMiEyg0nLon8o8h6w/5mj3xicAKK3oBX9JXqaeGsdWLTrEyq+09+xiP5S748cGIDrfKRvXXdH6GSmQuO6PXocfeqqa0tWuJWdNjC+SgWxXBjIWYtS1IoFy59UZTHFTNji6CzaGz+E4FdRoXZiFXqvQeLq54fHhnTEMJWuyymdnoVcxavP0L8D6VfAc8xSlTv62v5JfJJHS97pYTQ6Q== 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=QKbZ5nO4QMpGqRMu4Zs5pwFVumReb9nGv5StDttZ6tA=; b=SZrGVDbBuLxeu9I60hxWhWMYRvSZqPh4KZE5DKDqgf1BMVXzRAFmCcdmaqZBtM0487djqaCyr0nd09m1HjuuQ6Q2LJNHoLznGT01SXoeQ1qLcr8nT2vEBGwl/wCzZEONMA79XdtEjKSzxo6RsJOOkmIU9iKS5Q05VsULCsXMnYaw78L0FJ64lo4SOU9a4mH/HH0aEAEtVI1iw0/Y4Vg6138HfgXQhL5W72BTMcztJiBEhuRNKSkItNpwMHqpdvMMjbJUtSUwXj2K4+MAd63+dGDID0PnZ/O7EUr1Kw3xdCjQIbGtsea7q1sPSmqOIY8U6LkwcaQsdStxmiARz6ENog== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QKbZ5nO4QMpGqRMu4Zs5pwFVumReb9nGv5StDttZ6tA=; b=WjD9er7sG5spBg3d2QbvelOPL2XtW33/I/tiftNcN0ZElLnzvSKJSSdVeyHkIFQVD/XnBcLuQwAm3MXW/BqLE/0SMFOdyRIn4B49RbokGuLPjUvo7CgXpNopb+xEeQJpuhWPDzTG5P0hit+jbb95dlHHo+1O2DWeyQrBIFfQNBk= Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0307.namprd00.prod.outlook.com (2603:10b6:207:1e::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3312.0; Mon, 10 Aug 2020 17:33:45 +0000 Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::21a7:c5f5:46ed:7417]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::21a7:c5f5:46ed:7417%5]) with mapi id 15.20.3318.000; Mon, 10 Aug 2020 17:33:45 +0000 From: Mike Jones To: Dick Hardt , Filip Skokan CC: oauth Thread-Topic: [OAUTH-WG] ECDH-1PU encryption algorithm Thread-Index: AdZvPGNrmaieZepATZmREah+emUFTg== Date: Mon, 10 Aug 2020 17:33:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=6c9f99f0-4b85-49b6-aff4-ed5275ccca96; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-10T17:29:38Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.88.234] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ef8d1b67-e60e-4589-280b-08d83d53885d x-ms-traffictypediagnostic: BL0PR00MB0307: 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: Ox2N3uK/HJS0na9oBoBHS5HJzBJjefNvq8gGh+pkCfzfXni2zuKMReeSucS8NjXiqgPf9cV3RMqy1td5N7dTqIdCD+KHo5tlv/imsl5gVYtejp/Fl/pnoG4llWxq3WquvJyoyePJR9/SonvxzgnkyzIekClFvWWdA6DI7Wk9HFXEXjZvgXCwsAhbh5GPHDbpfQueIXlCE1spsGSKe4wksAGdzvJ/fz/ns6P4X+Nn3qZjlWqIsNzZdxDZImsKprPP1JYnVsIjXiwLHC1CkNBlWRBdtTQHrURs1To1GMkZcxbpeRBuzGRx2hsQTc7KFm4x/mBeFiPuLMriGcUK382IeTQLX/gUbLxqaVv7LTQ1bIiW7cA7wmT3Y4R7qVvjzKGvzr2O8WL9hBS/6pZ8zZIVJA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(39860400002)(136003)(396003)(376002)(33656002)(5660300002)(2906002)(71200400001)(83380400001)(166002)(53546011)(6506007)(52536014)(82960400001)(82950400001)(478600001)(26005)(66946007)(86362001)(10290500003)(316002)(66556008)(66476007)(8990500004)(110136005)(186003)(8676002)(9686003)(64756008)(66446008)(4326008)(8936002)(55016002)(966005)(7696005)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: m+x/rNdNpZVXu6es7UerRFrwveVWZm9+J23K1H2O+qShfp1AjGhqYLuj64Z5GLF9J2YZrNMCg26kQZFUMuY6xXscf8iiISUJMY5+bJojCpATU2VcKg5ioSljFG5rAzkvdTHmp6O84l95JLQEM3S3ws7v/zpCtFoj87+oyaMECVjpodCrzYslrQsAK683L7cdadCnpjJKTENjJQIvvP06i/cr4oxUCzh3nzSWRncd+ib2Hk80cNHp41A4WegZSqKpXPkWGU4UwF6nhH6SeNlAwZwKG/5BRRKxBs31T0PMMnR4YSIsnbTtRQvIegoAoL/kUApDYciHyYUhMYD0001zq4TpDl91w5vYS/6ZhFgarA/YLxZlnh67FUIbhNJqOursSvQ+/MnmNFL4Fy+BjcbXscthQS5CKJy45UyuoPkDa8sZd7alXEnT86j/Og3OMggw4J5aBQGzEYEfIV/emEUAuqDjM6nSYOfzx9+iRWXAKeLJx2WwlTQSvJn0BrauPmPbZmiUNeyu3LMgrcSzxMk+07dg9KUHsreBxsrCSjUj8wT6HOM1bZv53E8r8zBHjfmygeUkCV6glq8rbw/N+zr+2izZa+L53KP8Fg0jqjWgjwYtXOyGsh2fZLf9QYQ2ZTAwOLTpaTC09nauAU/dfyfVvQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB068857CCC85EB4D127F633E6F5441MN2PR00MB0688namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0688.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ef8d1b67-e60e-4589-280b-08d83d53885d X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2020 17:33:45.1634 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: G6aw1PzMlB0OdhdsdP8UTNRvzELvfKKpRI+LblTX5sge+K/lqRiAjnvzABcY0LYbs4AfXKVUkDxN4o1hO3HEiA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0307 Archived-At: Subject: Re: [OAUTH-WG] ECDH-1PU encryption algorithm 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, 10 Aug 2020 17:33:49 -0000 --_000_MN2PR00MB068857CCC85EB4D127F633E6F5441MN2PR00MB0688namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbGlrZXdpc2Ugc3VwcG9ydGl2ZSBvZiB0aGUgd29yay4gIE5vdGUgdGhhdCBDT1NFIHdv cmtpbmcgZ3JvdXAgaXMgY3VycmVudGx5IG9wZW4gd2hlcmVhcyBKT1NFIGlzIGNsb3NlZCwgc28g aWYgeW91IHdhbnQgd29ya2luZyBncm91cCByZXZpZXcsIEnigJlkIHN1Ym1pdCBzcGVjcyB0byBD T1NFIHNvb24uDQoNCkFzIGJhY2tncm91bmQsIEkgd29ya2VkIHRoZSBzcGVjIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvc2Utd2ViYXV0aG4tYWxnb3JpdGhtcy0wOCBp biBDT1NFIHdoaWNoIGFsc28gcGVyZm9ybXMgSk9TRSByZWdpc3RyYXRpb25zLiAgU28gdGhhdOKA mXMgZGVmaW5pdGVseSBhIHZpYWJsZSBwYXRoIGZvcndhcmQuICAoVGhpcyBkb2N1bWVudCBpcyBj dXJyZW50bHkgaW4gQVVUSDQ4IHN0YXR1cywgYW5kIHNvIGlzIGFib3V0IHRvIGJlY29tZSBhbiBS RkMuKQ0KDQpGaWxpcCwgdGhlIEpPU0Ugd29ya2luZyBncm91cCBjbG9zZWQgYWZ0ZXIgUkZDcyA3 NTE1LTc1MTggYW5kIDc1MjAgd2VyZSBjb21wbGV0ZWQuICBOb3RlIHRoYXQgaXTigJlzIHBvc3Np YmxlIHRvIHJlZ2lzdGVyIGFsZ29yaXRobXMsIGV0Yy4gaW4gdGhlIElBTkEgSk9TRSByZWdpc3Ry aWVzIGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2pvc2Uvam9zZS54aHRtbCB3aXRo b3V0IHRoZSBzcGVjIGNvbWluZyBmcm9tIGEgd29ya2luZyBncm91cCDigJMgYW5kIGluZGVlZCwg d2l0aG91dCBjb21pbmcgZnJvbSBhIHdvcmtpbmcgZ3JvdXAgYXQgYWxsLg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K DQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIERpY2sg SGFyZHQNClNlbnQ6IE1vbmRheSwgQXVndXN0IDEwLCAyMDIwIDEwOjI3IEFNDQpUbzogRmlsaXAg U2tva2FuIDxwYW52YS5pcEBnbWFpbC5jb20+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtPQVVUSC1XR10gRUNESC0xUFUgZW5jcnlwdGlvbiBhbGdvcml0aG0NCg0K SSdtIHN1cHBvcnRpdmUgb2YgdGhpcyB3b3JrLg0KDQpJdCBpcyBub3QgY2xlYXIgdGhhdCBpdCBp cyBpbiB0aGUgY2hhcnRlciBvZiB0aGUgT0F1dGggV0cuDQoNCg0KT24gTW9uLCBBdWcgMTAsIDIw MjAgYXQgOTowMSBBTSBGaWxpcCBTa29rYW4gPHBhbnZhLmlwQGdtYWlsLmNvbTxtYWlsdG86cGFu dmEuaXBAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBOZWlsLA0KDQpJJ20gaW50ZXJlc3RlZCBpbiBz ZWVpbmcgYm90aCBBRVMgU0lWIGFuZCBFQ0RILTFQVSBmb3IgSk9TRS4gTm90IHN1cmUgaG93IHRv IGdvIGFib3V0IGl0IHRobyBzaW5jZSBKT1NFIGlzIGEgY29uY2x1ZGVkIFdHLg0KDQpPdXQgb2Yg Y3VyaW9zaXR5LCB3aHkgaXMgaXQgYSBjb25jbHVkZWQgV0c/IERpZCBJRVRGL0pPU0UgV0cgbm90 IGNvbnNpZGVyIHRoZSBuZWVkIHRvIGZ1cnRoZXIgbWFpbnRhaW4vZXhwYW5kIHRoZSBKT1NFIGFs Z29yaXRobXMgYXMgdGltZSBnb2VzIG9uPw0KDQpTIHBvemRyYXZlbSwNCkZpbGlwIFNrb2thbg0K DQoNCk9uIE1vbiwgMTAgQXVnIDIwMjAgYXQgMTA6MjksIE5laWwgTWFkZGVuIDxuZWlsLm1hZGRl bkBmb3JnZXJvY2suY29tPG1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPj4gd3JvdGU6 DQpUaGFua3MgVmxhZGltaXIsDQoNClJlc3BvbnNlcyBiZWxvdw0KDQo+IE9uIDggQXVnIDIwMjAs IGF0IDEwOjQwLCBWbGFkaW1pciBEemh1dmlub3YgPHZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPG1h aWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4+IHdyb3RlOg0KPg0KPiDvu79IaSBOZWlsLA0K Pg0KPiBJIGRlZmluaXRlbHkgbGlrZSB0aGUgZWxlZ2FuY2Ugb2YgdGhlIHByb3Bvc2VkIGFsZyBm b3IgSk9TRSwgaXQgcHJvdmlkZXMNCj4gc29tZXRoaW5nIHRoYXQgaXNuJ3QgY3VycmVudGx5IGF2 YWlsYWJsZSBpbiB0aGUgdmFyaW91cyBjbGFzc2VzIG9mIGFsZ3MNCj4gbWFkZSBzdGFuZGFyZCBp biBKT1NFLg0KPg0KPiBJIGFsc28gd2FudGVkIHRvIGFzayB3aGF0J3MgaGFwcGVuaW5nIHdpdGgg QUVTIFNJViBmb3IgSk9TRSwgaWYgdGhlcmUncw0KPiB0cmFjdGlvbiAvIGZlZWRiYWNrIC8gc3Vw cG9ydCB0aGVyZSBhcyB3ZWxsPw0KPg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtbWFkZGVuLWpvc2Utc2l2LW1vZGUtMDINCg0KVGhhbmtzIGZvciBicmluZ2luZyB0aGlzIHVw LiBJ4oCZdmUgbm90IHJlY2VpdmVkIG11Y2ggZmVlZGJhY2sgYWJvdXQgdGhpcyBvbmUsIGFuZCBJ IGhhdmVu4oCZdCBiZWVuIHZlcnkgZ29vZCBhdCBwdXNoaW5nIGl0LiBJZiB0aGVyZSBpcyBpbnRl cmVzdCB0aGVuIEnigJlkIGNlcnRhaW5seSBiZSBpbnRlcmVzdGVkIGluIGJyaW5naW5nIHRoaXMg Zm9yd2FyZCB0b28uDQoNClRoYXQgZHJhZnQgbWlnaHQgYmUgYSBiZXR0ZXIgZml0IGZvciBlZyB0 aGUgQ09TRSBXRyB0aG91Z2gsIHdoaWNoIGNvdWxkIHRoZW4gYWxzbyByZWdpc3RlciBpZGVudGlm aWVycyBmb3IgSk9TRS4gV2hhdCBkbyB5b3UgdGhpbms/DQoNCj4NCj4gVmxhZGltaXINCj4NCj4N Cj4+PiBPbiAwNS8wOC8yMDIwIDEzOjAxLCBOZWlsIE1hZGRlbiB3cm90ZToNCj4+IEhpIGFsbCwN Cj4+IFlvdSBtYXkgcmVtZW1iZXIgbWUgZnJvbSBzdWNoIEktRHMNCj4+IGFzIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYWRkZW4tam9zZS1lY2RoLTFwdS0wMywgd2hpY2gNCj4+ IHByb3Bvc2VzIGFkZGluZyBhIG5ldyBlbmNyeXB0aW9uIGFsZ29yaXRobSB0byBKT1NFLiBJ4oCZ ZCBsaWtlIHRvDQo+PiByZXNlcnZlIGEgYml0IG9mIHRpbWUgdG8gZGlzY3VzcyBpdCBhdCBvbmUg b2YgdGhlIHVwY29taW5nIGludGVyaW0NCj4+IG1lZXRpbmdzLg0KPj4gVGhlIGJhc2ljIGlkZWEg aXMgdGhhdCBpbiBtYW55IGNhc2VzIGluIE9BdXRoIGFuZCBPSURDIHlvdSB3YW50IHRvDQo+PiBl bnN1cmUgYm90aCBjb25maWRlbnRpYWxpdHkgYW5kIGF1dGhlbnRpY2l0eSBvZiBzb21lIHRva2Vu IC0gZm9yDQo+PiBleGFtcGxlIHdoZW4gdHJhbnNmZXJyaW5nIGFuIElEIHRva2VuIGNvbnRhaW5p bmcgUElJIHRvIHRoZSBjbGllbnQNCj4+IHRocm91Z2ggdGhlIGZyb250IGNoYW5uZWwsIG9yIGZv ciBhY2Nlc3MgdG9rZW5zIGludGVuZGVkIHRvIGJlIGhhbmRsZWQNCj4+IGJ5IGEgc3BlY2lmaWMg UlMgd2l0aG91dCBvbmxpbmUgdG9rZW4gaW50cm9zcGVjdGlvbiAoc3VjaCBhcyB0aGUgSldUDQo+ PiBhY2Nlc3MgdG9rZW4gZHJhZnQpLiBJZiB5b3UgaGF2ZSBhIHNoYXJlZCBzZWNyZXQga2V5IGJl dHdlZW4gdGhlIEFTDQo+PiBhbmQgdGhlIGNsaWVudC9SUyB0aGVuIHlvdSBjYW4gdXNlIHN5bW1l dHJpYyBhdXRoZW50aWNhdGVkIGVuY3J5cHRpb24NCj4+IChhbGc9ZGlyIG9yIGFsZz1BMTI4S1cg ZXRjKS4gQnV0IGlmIHlvdSBuZWVkIHRvIHVzZSBwdWJsaWMga2V5DQo+PiBjcnlwdG9ncmFwaHkg dGhlbiBjdXJyZW50bHkgeW91IGFyZSBsaW1pdGVkIHRvIGEgbmVzdGVkDQo+PiBzaWduZWQtdGhl bi1lbmNyeXB0ZWQgSk9TRSBzdHJ1Y3R1cmUsIHdoaWNoIHByb2R1Y2VzIG11Y2ggbGFyZ2VyIHRv a2VuDQo+PiBzaXplcy4NCj4+IFRoZSBkcmFmdCBhZGRzIGEgbmV3IOKAnHB1YmxpYyBrZXkgYXV0 aGVudGljYXRlZCBlbmNyeXB0aW9u4oCdIG1vZGUgYmFzZWQNCj4+IG9uIEVDREggaW4gdGhlIE5J U1Qgc3RhbmRhcmQg4oCcb25lLXBhc3MgdW5pZmllZOKAnSBtb2RlbC4gVGhlIHByaW1hcnkNCj4+ IGFkdmFudGFnZSBmb3IgT0F1dGggdXNhZ2UgaXMgdGhhdCB0aGUgdG9rZW5zIHByb2R1Y2VkIGFy ZSBtb3JlIGNvbXBhY3QNCj4+IGNvbXBhcmVkIHRvIHNpZ25pbmcrZW5jcnlwdGlvbiAofjMwJSBz bWFsbGVyIGZvciB0eXBpY2FsIGFjY2Vzcy9JRA0KPj4gdG9rZW4gc2l6ZXMgaW4gY29tcGFjdCBz ZXJpYWxpemF0aW9uKS4gUGVyZm9ybWFuY2Utd2lzZSwgaXTigJlzIHJvdWdobHkNCj4+IGVxdWl2 YWxlbnQuIEkga25vdyB0aGF0IHNpemUgY29uY2VybnMgYXJlIG9mdGVuIGEgbGltaXRpbmcgZmFj dG9yIGluDQo+PiBjaG9vc2luZyB3aGV0aGVyIHRvIGVuY3J5cHQgdG9rZW5zLCBzbyB0aGlzIHNo b3VsZCBoZWxwLg0KPj4gSW4gdGVybXMgb2YgaW1wbGVtZW50YXRpb24sIGl04oCZcyBlc3NlbnRp YWxseSBqdXN0IGEgZmV3IGV4dHJhIGxpbmVzIG9mDQo+PiBjb2RlIGNvbXBhcmVkIHRvIGFuIEVD REgtRVMgaW1wbGVtZW50YXRpb24uIChTb21lIEpPU0UgbGlicmFyeSBBUElzDQo+PiBtaWdodCBu ZWVkIGFuIGFkanVzdG1lbnQgdG8gYWNjb21tb2RhdGUgdGhlIGV4dHJhIHByaXZhdGUga2V5IG5l ZWRlZA0KPj4gZm9yIGVuY3J5cHRpb24vcHVibGljIGtleSBmb3IgZGVjcnlwdGlvbikuDQo+PiBJ 4oCZdmUgcmVjZWl2ZWQgYSBmZXcgZW1haWxzIG9mZi1saXN0IGZyb20gcGVvcGxlIGludGVyZXN0 ZWQgaW4gdXNpbmcgaXQNCj4+IGZvciBub24tT0F1dGggdXNlLWNhc2VzIHN1Y2ggYXMgc2VjdXJl IG1lc3NhZ2luZyBhcHBsaWNhdGlvbnMuIEkgdGhpbmsNCj4+IHRoZXNlIHVzZS1jYXNlcyBjYW4g YmUgYWNjb21tb2RhdGVkIHdpdGhvdXQgc2lnbmlmaWNhbnQgY2hhbmdlcywgc28gSQ0KPj4gdGhp bmsgdGhlIE9BdXRoIFdHIHdvdWxkIGJlIGEgZ29vZCB2ZW51ZSBmb3IgYWR2YW5jaW5nIHRoaXMu DQo+PiBJ4oCZZCBiZSBpbnRlcmVzdGVkIHRvIGhlYXIgdGhvdWdodHMgYW5kIGRpc2N1c3Npb24g b24gdGhlIGxpc3QgcHJpb3IgdG8NCj4+IGFueSBkaXNjdXNzaW9uIGF0IGFuIGludGVyaW0gbWVl dGluZy4NCj4+IOKAlCBOZWlsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_MN2PR00MB068857CCC85EB4D127F633E6F5441MN2PR00MB0688namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAy MDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpi cmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SeKAmW0gbGlrZXdpc2Ugc3VwcG9ydGl2 ZSBvZiB0aGUgd29yay4mbmJzcDsgTm90ZSB0aGF0IENPU0Ugd29ya2luZyBncm91cCBpcyBjdXJy ZW50bHkgb3BlbiB3aGVyZWFzIEpPU0UgaXMgY2xvc2VkLCBzbyBpZiB5b3Ugd2FudCB3b3JraW5n IGdyb3VwIHJldmlldywgSeKAmWQgc3VibWl0IHNwZWNzIHRvIENPU0Ugc29vbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkFzIGJhY2tncm91bmQsIEkgd29ya2VkIHRoZSBz cGVjDQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtY29zZS13ZWJhdXRobi1hbGdvcml0aG1zLTA4Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1jb3NlLXdlYmF1dGhuLWFsZ29yaXRobXMtMDg8L2E+IGluIENPU0Ugd2hp Y2ggYWxzbyBwZXJmb3JtcyBKT1NFIHJlZ2lzdHJhdGlvbnMuJm5ic3A7IFNvIHRoYXTigJlzIGRl ZmluaXRlbHkgYSB2aWFibGUgcGF0aCBmb3J3YXJkLiZuYnNwOyAoVGhpcyBkb2N1bWVudA0KIGlz IGN1cnJlbnRseSBpbiBBVVRINDggc3RhdHVzLCBhbmQgc28gaXMgYWJvdXQgdG8gYmVjb21lIGFu IFJGQy4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZpbGlwLCB0aGUgSk9TRSB3b3JraW5nIGdy b3VwIGNsb3NlZCBhZnRlciBSRkNzIDc1MTUtNzUxOCBhbmQgNzUyMCB3ZXJlIGNvbXBsZXRlZC4m bmJzcDsgTm90ZSB0aGF0IGl04oCZcyBwb3NzaWJsZSB0byByZWdpc3RlciBhbGdvcml0aG1zLCBl dGMuIGluIHRoZSBJQU5BIEpPU0UgcmVnaXN0cmllcw0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWFu YS5vcmcvYXNzaWdubWVudHMvam9zZS9qb3NlLnhodG1sIj5odHRwczovL3d3dy5pYW5hLm9yZy9h c3NpZ25tZW50cy9qb3NlL2pvc2UueGh0bWw8L2E+IHdpdGhvdXQgdGhlIHNwZWMgY29taW5nIGZy b20gYSB3b3JraW5nIGdyb3VwIOKAkyBhbmQgaW5kZWVkLCB3aXRob3V0IGNvbWluZyBmcm9tIGEg d29ya2luZyBncm91cCBhdCBhbGwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5Gcm9tOjwvYj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxi Pk9uIEJlaGFsZiBPZiA8L2I+DQpEaWNrIEhhcmR0PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwg QXVndXN0IDEwLCAyMDIwIDEwOjI3IEFNPGJyPg0KPGI+VG86PC9iPiBGaWxpcCBTa29rYW4gJmx0 O3BhbnZhLmlwQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoICZsdDtvYXV0aEBp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gRUNESC0xUFUg ZW5jcnlwdGlvbiBhbGdvcml0aG08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSdtIHN1cHBvcnRpdmUgb2YgdGhpcyB3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgbm90IGNsZWFyIHRoYXQgaXQgaXMgaW4gdGhlIGNo YXJ0ZXIgb2YgdGhlIE9BdXRoIFdHLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXVnIDEwLCAyMDIwIGF0IDk6MDEgQU0gRmls aXAgU2tva2FuICZsdDs8YSBocmVmPSJtYWlsdG86cGFudmEuaXBAZ21haWwuY29tIj5wYW52YS5p cEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBOZWlsLDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIGludGVyZXN0ZWQgaW4gc2VlaW5n IGJvdGggQUVTIFNJViBhbmQmbmJzcDtFQ0RILTFQVSBmb3IgSk9TRS4gTm90IHN1cmUgaG93IHRv IGdvIGFib3V0IGl0IHRobyBzaW5jZSBKT1NFIGlzIGEgY29uY2x1ZGVkIFdHLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PdXQgb2Yg Y3VyaW9zaXR5LCB3aHkgaXMgaXQgYSBjb25jbHVkZWQgV0c/IERpZCBJRVRGL0pPU0UgV0cgbm90 IGNvbnNpZGVyIHRoZSBuZWVkIHRvIGZ1cnRoZXIgbWFpbnRhaW4vZXhwYW5kIHRoZSBKT1NFIGFs Z29yaXRobXMgYXMgdGltZSBnb2VzIG9uPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlMgcG96ZHJhdmVtLDxicj4NCjxiPkZp bGlwIFNrb2thbjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gTW9uLCAxMCBBdWcgMjAyMCBhdCAxMDoyOSwgTmVpbCBNYWRkZW4g Jmx0OzxhIGhyZWY9Im1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tIiB0YXJnZXQ9Il9i bGFuayI+bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIFZs YWRpbWlyLDxicj4NCjxicj4NClJlc3BvbnNlcyBiZWxvdzxicj4NCjxicj4NCiZndDsgT24gOCBB dWcgMjAyMCwgYXQgMTA6NDAsIFZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7PGEgaHJlZj0ibWFpbHRv OnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmxhZGltaXJAY29ubmVj dDJpZC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsg77u/SGkgTmVpbCw8 YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBkZWZpbml0ZWx5IGxpa2UgdGhlIGVsZWdhbmNlIG9mIHRo ZSBwcm9wb3NlZCBhbGcgZm9yIEpPU0UsIGl0IHByb3ZpZGVzPGJyPg0KJmd0OyBzb21ldGhpbmcg dGhhdCBpc24ndCBjdXJyZW50bHkgYXZhaWxhYmxlIGluIHRoZSB2YXJpb3VzIGNsYXNzZXMgb2Yg YWxnczxicj4NCiZndDsgbWFkZSBzdGFuZGFyZCBpbiBKT1NFLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBJIGFsc28gd2FudGVkIHRvIGFzayB3aGF0J3MgaGFwcGVuaW5nIHdpdGggQUVTIFNJViBmb3Ig Sk9TRSwgaWYgdGhlcmUnczxicj4NCiZndDsgdHJhY3Rpb24gLyBmZWVkYmFjayAvIHN1cHBvcnQg dGhlcmUgYXMgd2VsbD88YnI+DQomZ3Q7IDxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hZGRlbi1qb3NlLXNpdi1tb2RlLTAyIiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFkZGVuLWpvc2Utc2l2 LW1vZGUtMDI8L2E+PGJyPg0KPGJyPg0KVGhhbmtzIGZvciBicmluZ2luZyB0aGlzIHVwLiBJ4oCZ dmUgbm90IHJlY2VpdmVkIG11Y2ggZmVlZGJhY2sgYWJvdXQgdGhpcyBvbmUsIGFuZCBJIGhhdmVu 4oCZdCBiZWVuIHZlcnkgZ29vZCBhdCBwdXNoaW5nIGl0LiBJZiB0aGVyZSBpcyBpbnRlcmVzdCB0 aGVuIEnigJlkIGNlcnRhaW5seSBiZSBpbnRlcmVzdGVkIGluIGJyaW5naW5nIHRoaXMgZm9yd2Fy ZCB0b28uDQo8YnI+DQo8YnI+DQpUaGF0IGRyYWZ0IG1pZ2h0IGJlIGEgYmV0dGVyIGZpdCBmb3Ig ZWcgdGhlIENPU0UgV0cgdGhvdWdoLCB3aGljaCBjb3VsZCB0aGVuIGFsc28gcmVnaXN0ZXIgaWRl bnRpZmllcnMgZm9yIEpPU0UuIFdoYXQgZG8geW91IHRoaW5rPzxicj4NCjxicj4NCiZndDsgPGJy Pg0KJmd0OyBWbGFkaW1pcjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsg T24gMDUvMDgvMjAyMCAxMzowMSwgTmVpbCBNYWRkZW4gd3JvdGU6PGJyPg0KJmd0OyZndDsgSGkg YWxsLDxicj4NCiZndDsmZ3Q7IFlvdSBtYXkgcmVtZW1iZXIgbWUgZnJvbSBzdWNoIEktRHM8YnI+ DQomZ3Q7Jmd0OyBhcyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bWFkZGVuLWpvc2UtZWNkaC0xcHUtMDMiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1tYWRkZW4tam9zZS1lY2RoLTFwdS0wMzwvYT4sIHdoaWNoPGJy Pg0KJmd0OyZndDsgcHJvcG9zZXMgYWRkaW5nIGEgbmV3IGVuY3J5cHRpb24gYWxnb3JpdGhtIHRv IEpPU0UuIEnigJlkIGxpa2UgdG88YnI+DQomZ3Q7Jmd0OyByZXNlcnZlIGEgYml0IG9mIHRpbWUg dG8gZGlzY3VzcyBpdCBhdCBvbmUgb2YgdGhlIHVwY29taW5nIGludGVyaW08YnI+DQomZ3Q7Jmd0 OyBtZWV0aW5ncy48YnI+DQomZ3Q7Jmd0OyBUaGUgYmFzaWMgaWRlYSBpcyB0aGF0IGluIG1hbnkg Y2FzZXMgaW4gT0F1dGggYW5kIE9JREMgeW91IHdhbnQgdG88YnI+DQomZ3Q7Jmd0OyBlbnN1cmUg Ym90aCBjb25maWRlbnRpYWxpdHkgYW5kIGF1dGhlbnRpY2l0eSBvZiBzb21lIHRva2VuIC0gZm9y PGJyPg0KJmd0OyZndDsgZXhhbXBsZSB3aGVuIHRyYW5zZmVycmluZyBhbiBJRCB0b2tlbiBjb250 YWluaW5nIFBJSSB0byB0aGUgY2xpZW50PGJyPg0KJmd0OyZndDsgdGhyb3VnaCB0aGUgZnJvbnQg Y2hhbm5lbCwgb3IgZm9yIGFjY2VzcyB0b2tlbnMgaW50ZW5kZWQgdG8gYmUgaGFuZGxlZDxicj4N CiZndDsmZ3Q7IGJ5IGEgc3BlY2lmaWMgUlMgd2l0aG91dCBvbmxpbmUgdG9rZW4gaW50cm9zcGVj dGlvbiAoc3VjaCBhcyB0aGUgSldUPGJyPg0KJmd0OyZndDsgYWNjZXNzIHRva2VuIGRyYWZ0KS4g SWYgeW91IGhhdmUgYSBzaGFyZWQgc2VjcmV0IGtleSBiZXR3ZWVuIHRoZSBBUzxicj4NCiZndDsm Z3Q7IGFuZCB0aGUgY2xpZW50L1JTIHRoZW4geW91IGNhbiB1c2Ugc3ltbWV0cmljIGF1dGhlbnRp Y2F0ZWQgZW5jcnlwdGlvbjxicj4NCiZndDsmZ3Q7IChhbGc9ZGlyIG9yIGFsZz1BMTI4S1cgZXRj KS4gQnV0IGlmIHlvdSBuZWVkIHRvIHVzZSBwdWJsaWMga2V5PGJyPg0KJmd0OyZndDsgY3J5cHRv Z3JhcGh5IHRoZW4gY3VycmVudGx5IHlvdSBhcmUgbGltaXRlZCB0byBhIG5lc3RlZDxicj4NCiZn dDsmZ3Q7IHNpZ25lZC10aGVuLWVuY3J5cHRlZCBKT1NFIHN0cnVjdHVyZSwgd2hpY2ggcHJvZHVj ZXMgbXVjaCBsYXJnZXIgdG9rZW48YnI+DQomZ3Q7Jmd0OyBzaXplcy48YnI+DQomZ3Q7Jmd0OyBU aGUgZHJhZnQgYWRkcyBhIG5ldyDigJxwdWJsaWMga2V5IGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGlv buKAnSBtb2RlIGJhc2VkPGJyPg0KJmd0OyZndDsgb24gRUNESCBpbiB0aGUgTklTVCBzdGFuZGFy ZCDigJxvbmUtcGFzcyB1bmlmaWVk4oCdIG1vZGVsLiBUaGUgcHJpbWFyeTxicj4NCiZndDsmZ3Q7 IGFkdmFudGFnZSBmb3IgT0F1dGggdXNhZ2UgaXMgdGhhdCB0aGUgdG9rZW5zIHByb2R1Y2VkIGFy ZSBtb3JlIGNvbXBhY3Q8YnI+DQomZ3Q7Jmd0OyBjb21wYXJlZCB0byBzaWduaW5nK2VuY3J5cHRp b24gKH4zMCUgc21hbGxlciBmb3IgdHlwaWNhbCBhY2Nlc3MvSUQ8YnI+DQomZ3Q7Jmd0OyB0b2tl biBzaXplcyBpbiBjb21wYWN0IHNlcmlhbGl6YXRpb24pLiBQZXJmb3JtYW5jZS13aXNlLCBpdOKA mXMgcm91Z2hseTxicj4NCiZndDsmZ3Q7IGVxdWl2YWxlbnQuIEkga25vdyB0aGF0IHNpemUgY29u Y2VybnMgYXJlIG9mdGVuIGEgbGltaXRpbmcgZmFjdG9yIGluPGJyPg0KJmd0OyZndDsgY2hvb3Np bmcgd2hldGhlciB0byBlbmNyeXB0IHRva2Vucywgc28gdGhpcyBzaG91bGQgaGVscC48YnI+DQom Z3Q7Jmd0OyBJbiB0ZXJtcyBvZiBpbXBsZW1lbnRhdGlvbiwgaXTigJlzIGVzc2VudGlhbGx5IGp1 c3QgYSBmZXcgZXh0cmEgbGluZXMgb2Y8YnI+DQomZ3Q7Jmd0OyBjb2RlIGNvbXBhcmVkIHRvIGFu IEVDREgtRVMgaW1wbGVtZW50YXRpb24uIChTb21lIEpPU0UgbGlicmFyeSBBUElzPGJyPg0KJmd0 OyZndDsgbWlnaHQgbmVlZCBhbiBhZGp1c3RtZW50IHRvIGFjY29tbW9kYXRlIHRoZSBleHRyYSBw cml2YXRlIGtleSBuZWVkZWQ8YnI+DQomZ3Q7Jmd0OyBmb3IgZW5jcnlwdGlvbi9wdWJsaWMga2V5 IGZvciBkZWNyeXB0aW9uKS48YnI+DQomZ3Q7Jmd0OyBJ4oCZdmUgcmVjZWl2ZWQgYSBmZXcgZW1h aWxzIG9mZi1saXN0IGZyb20gcGVvcGxlIGludGVyZXN0ZWQgaW4gdXNpbmcgaXQ8YnI+DQomZ3Q7 Jmd0OyBmb3Igbm9uLU9BdXRoIHVzZS1jYXNlcyBzdWNoIGFzIHNlY3VyZSBtZXNzYWdpbmcgYXBw bGljYXRpb25zLiBJIHRoaW5rPGJyPg0KJmd0OyZndDsgdGhlc2UgdXNlLWNhc2VzIGNhbiBiZSBh Y2NvbW1vZGF0ZWQgd2l0aG91dCBzaWduaWZpY2FudCBjaGFuZ2VzLCBzbyBJPGJyPg0KJmd0OyZn dDsgdGhpbmsgdGhlIE9BdXRoIFdHIHdvdWxkIGJlIGEgZ29vZCB2ZW51ZSBmb3IgYWR2YW5jaW5n IHRoaXMuPGJyPg0KJmd0OyZndDsgSeKAmWQgYmUgaW50ZXJlc3RlZCB0byBoZWFyIHRob3VnaHRz IGFuZCBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IHByaW9yIHRvPGJyPg0KJmd0OyZndDsgYW55IGRp c2N1c3Npb24gYXQgYW4gaW50ZXJpbSBtZWV0aW5nLjxicj4NCiZndDsmZ3Q7IOKAlCBOZWlsPGJy Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MN2PR00MB068857CCC85EB4D127F633E6F5441MN2PR00MB0688namp_-- From nobody Mon Aug 10 10:38:38 2020 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 064C03A0B8E for ; Mon, 10 Aug 2020 10:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=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 K8WmkLAGyvYo for ; Mon, 10 Aug 2020 10:38:35 -0700 (PDT) Received: from p3plsmtpa07-07.prod.phx3.secureserver.net (p3plsmtpa07-07.prod.phx3.secureserver.net [173.201.192.236]) (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 A81033A0B8F for ; Mon, 10 Aug 2020 10:38:35 -0700 (PDT) Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id 5Bknkbgl8lsQb5Bkok3IWi; Mon, 10 Aug 2020 10:38:34 -0700 X-CMAE-Analysis: v=2.3 cv=KaGsTjQD c=1 sm=1 tr=0 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=9cW_t1CCXrUA:10 a=q0rX5H01Qin5IyBaTmIA:9 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=ZhbJ1iEMXRcCrf8ZpzMA:9 a=QEXdDO2ut3YA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=H5r4HjhRfVyZ-DhAOYba:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: vladimir@connect2id.com Cc: oauth@ietf.org References: <51424c05-3199-0caf-65ea-6d7a4433c9b9@connect2id.com> From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd Organization: Connect2id Ltd. Message-ID: Date: Mon, 10 Aug 2020 20:38:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040902020200030403090204" X-CMAE-Envelope: MS4wfKdCOQLJG6G6sX1E/7Ev61pDZ0p+yuwsWNA3oRaD6//EtgmMAJbwM41hE1S3//2vd52i+x2Vcf+XJFAIZu6iewwkb6GdtyfutE2pMAWxxVuqrplNetQH Bqr8FjDKLnce3xvm8l3GEBEfsfnEEHt4gfAhAdGoQb79D/MEXYKkId0w Archived-At: Subject: Re: [OAUTH-WG] ECDH-1PU encryption algorithm 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, 10 Aug 2020 17:38:37 -0000 This is a cryptographically signed message in MIME format. --------------ms040902020200030403090204 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 10/08/2020 11:28, Neil Madden wrote: > Thanks Vladimir, > > Responses below > >> On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov = wrote: >> >> =EF=BB=BFHi Neil, >> >> I definitely like the elegance of the proposed alg for JOSE, it provid= es >> something that isn't currently available in the various classes of alg= s >> made standard in JOSE. >> >> I also wanted to ask what's happening with AES SIV for JOSE, if there'= s >> traction / feedback / support there as well? >> >> https://tools.ietf.org/html/draft-madden-jose-siv-mode-02 > Thanks for bringing this up. I=E2=80=99ve not received much feedback ab= out this one, and I haven=E2=80=99t been very good at pushing it. If ther= e is interest then I=E2=80=99d certainly be interested in bringing this f= orward too.=20 > > That draft might be a better fit for eg the COSE WG though, which could= then also register identifiers for JOSE. What do you think? If the COSE is the "proper" WG to get the spec completed and the algs registered, then let it be COSE. We can continue the conversation there. I support both drafts. > >> Vladimir >> >> >>>> On 05/08/2020 13:01, Neil Madden wrote: >>> Hi all, >>> You may remember me from such I-Ds >>> as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which >>> proposes adding a new encryption algorithm to JOSE. I=E2=80=99d like = to >>> reserve a bit of time to discuss it at one of the upcoming interim >>> meetings. >>> The basic idea is that in many cases in OAuth and OIDC you want to >>> ensure both confidentiality and authenticity of some token - for >>> example when transferring an ID token containing PII to the client >>> through the front channel, or for access tokens intended to be handle= d >>> by a specific RS without online token introspection (such as the JWT >>> access token draft). If you have a shared secret key between the AS >>> and the client/RS then you can use symmetric authenticated encryption= >>> (alg=3Ddir or alg=3DA128KW etc). But if you need to use public key >>> cryptography then currently you are limited to a nested >>> signed-then-encrypted JOSE structure, which produces much larger toke= n >>> sizes. >>> The draft adds a new =E2=80=9Cpublic key authenticated encryption=E2=80= =9D mode based >>> on ECDH in the NIST standard =E2=80=9Cone-pass unified=E2=80=9D model= =2E The primary >>> advantage for OAuth usage is that the tokens produced are more compac= t >>> compared to signing+encryption (~30% smaller for typical access/ID >>> token sizes in compact serialization). Performance-wise, it=E2=80=99s= roughly >>> equivalent. I know that size concerns are often a limiting factor in >>> choosing whether to encrypt tokens, so this should help. >>> In terms of implementation, it=E2=80=99s essentially just a few extra= lines of >>> code compared to an ECDH-ES implementation. (Some JOSE library APIs >>> might need an adjustment to accommodate the extra private key needed >>> for encryption/public key for decryption). >>> I=E2=80=99ve received a few emails off-list from people interested in= using it >>> for non-OAuth use-cases such as secure messaging applications. I thin= k >>> these use-cases can be accommodated without significant changes, so I= >>> think the OAuth WG would be a good venue for advancing this. >>> I=E2=80=99d be interested to hear thoughts and discussion on the list= prior to >>> any discussion at an interim meeting. >>> =E2=80=94 Neil --=20 Vladimir Dzhuvinov --------------ms040902020200030403090204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA4MTAxNzM4MzNaMC8G CSqGSIb3DQEJBDEiBCDc2rFzS4+YHOJPRTNP35SWzc576q6WVc/nE+69sdBF0jBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAGn2BU3SOxQidLNbccVYNtnhjRkdWH3MB/RPpOWuveiFXGZ5 K1E4IAzSGJo5zpVFoceXEXEPZ+sB7V/ImaOrXBur6MJSYqiGV4iQG+LFDuK+WOVSRZxq7543 NxRNlDlLCo63lhziKcGyWlbtP7xUemCYMzIZSdLT+Z+MHqOG7W+eTk7qczeLre5YGs5qKESV GQY+wq6BrfJUwqZb51VLRpzBx/k8jMew3LssgLcOD7xwr7VuI6u3NajpCcTBgvdZVj6k7vLn 12rxAfzsGWvThS9zZVjp3dgXXIxfUK6gU4kY1PI7r+ME7kmYmy5C25pO/Wd0BxioWgvyoDa5 DCE1/lYAAAAAAAA= --------------ms040902020200030403090204-- From nobody Mon Aug 10 10:47:34 2020 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 D0A423A03FC for ; Mon, 10 Aug 2020 10:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 nbFjnSHgLrUa for ; Mon, 10 Aug 2020 10:47:31 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 53D393A003F for ; Mon, 10 Aug 2020 10:47:31 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id v22so7027517edy.0 for ; Mon, 10 Aug 2020 10:47:31 -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=yCZ66D26bRTTsfyuTMRJaT6ndvHeV57K8LIXYhahv0g=; b=dQUazSYDmMofnRrnra7Ep6iFvNgk8bAjLq5pH2zpelN1mrlKFFvxrVMUL8S1L/PPKH nXRzR9bra+l5h3pm9I3xFki/MYtuOTm2AnzU9IWdSo1Kzvz1rZHpT4Gq2jbVLwsioD09 olUq8aoiVpMuACkGJJ4a5Ou5yzUhBuWE5c95sJoZieALJExr8nXjavBLoK1nSEj2Lsii txaeVZMM24zJuAhRshmjrbQxzsbtccM1TL6lJKajXWFJVOALK6b3r0jnxp6CqxVPNzZq BBtFn/ebjvgp4qRspYiBvsHZxzFhgnOyuFmjKijn+SEtflhlToFKDjivzJzdkfJbDASq kNEA== 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=yCZ66D26bRTTsfyuTMRJaT6ndvHeV57K8LIXYhahv0g=; b=DyhzfDc5w/gfzl0meE+pkBAVLm5sXXilSOB33XUGZky4gOymi+3Qr0qT+Xqc+dHd1d V+6i8aLiVwvMXsxoc3AN2hngWVbjzkG7kxM6XCq22Stmnubrj3e/0W/QkSVY6OevbeRE gZLoEXFRSTFSAUV4jQMM1zxM8ONMXptRWtu3F+5mdv5QNVIncTh6aeYIvyZZzfqd7yr1 V0Um82aqZnWKmeRUmg4pXQr9mX078Wxj6/+pTMkKnskM+4k/d+Jh0FLssT6BNclRWRYl l9KnHE4sldn8o3HiCLwEvbessISSlfQS084PvOecwQH+n5lgnOvo6PFUvnWKP1nMZ3HK AA4g== X-Gm-Message-State: AOAM532LhzcvvVCTFBoYH3F7OgPbOrzJkYYeuNWtVBJTj7D3s90tT9uQ ENzveI4BiPf5AxHPRyvAI1Y9uJ9ADw== X-Google-Smtp-Source: ABdhPJxSWtVx6ANyWmjLkTm4TdRirf09ApZDh93iDmYf69QhlNOKfCC67IiBqjsiHzoKljMHbDcS0w== X-Received: by 2002:a05:6402:b09:: with SMTP id bm9mr23063109edb.9.1597081649585; Mon, 10 Aug 2020 10:47:29 -0700 (PDT) Received: from [192.168.68.100] (173.c3.airnet.cz. [94.74.199.173]) by smtp.gmail.com with ESMTPSA id of19sm7541397ejb.3.2020.08.10.10.47.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Aug 2020 10:47:29 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-947F1A7B-C329-4F0A-A1E8-56F9591690A7 Content-Transfer-Encoding: 7bit From: Filip Skokan Mime-Version: 1.0 (1.0) Date: Mon, 10 Aug 2020 19:47:28 +0200 Message-Id: References: Cc: Dick Hardt , OAuth WG In-Reply-To: To: Aaron Parecki X-Mailer: iPhone Mail (17G68) Archived-At: Subject: Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1? 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, 10 Aug 2020 17:47:33 -0000 --Apple-Mail-947F1A7B-C329-4F0A-A1E8-56F9591690A7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don=E2=80=99t think there=E2=80=99s anything new introduced in PAR that wo= uld alter existing status quo of privacy consiserations. As such if privacy c= onsideration was to be added for completeness it should be along the lines o= f =E2=80=9Cthis document does not expand on or otherwise alter the privacy c= onsiderations=E2=80=9D or =E2=80=9Cthere are no new privacy considerations i= ntroduced by this document=E2=80=9D.=20 Filip Odesl=C3=A1no z iPhonu > 10. 8. 2020 v 19:21, Aaron Parecki : >=20 > =EF=BB=BF > I agree that there is nothing unique to PAR that would justify adding the p= rivacy considerations mentioned to that draft. I wouldn't oppose adding a pr= ivacy considerations section to OAuth 2.1 though. >=20 > Aaron >=20 >=20 >> On Mon, Aug 10, 2020 at 9:42 AM Dick Hardt wrote: >> In the PAR meeting today, Denis requested there be a privacy consideratio= ns section in PAR. I don't think there is anything specific in PAR that woul= d change the privacy considerations of OAuth, and am checking if there is WG= interest, and consensus, on including a Privacy Considerations section in t= he OAuth 2.1 draft. >>=20 >> /Dick >> =E1=90=A7 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-947F1A7B-C329-4F0A-A1E8-56F9591690A7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don=E2=80=99t think there=E2=80=99s anyth= ing new introduced in PAR that would alter existing status quo of privacy co= nsiserations. As such if privacy consideration was to be added for completen= ess it should be along the lines of =E2=80=9Cthis document does not expand o= n or otherwise alter the privacy considerations=E2=80=9D or =E2=80=9Cthere a= re no new privacy considerations introduced by this document=E2=80=9D. =

Filip

Odesl=C3=A1no z iPhon= u

10. 8. 2020 v 19:= 21, Aaron Parecki <aaron@parecki.com>:

=EF=BB=BF
I agree that= there is nothing unique to PAR that would justify adding the privacy consid= erations mentioned to that draft. I wouldn't oppose adding a privacy conside= rations section to OAuth 2.1 though.

Aaron

=

On Mon, Aug 10, 2020 at 9:42 AM Dick Hardt <dick.hardt@gmail.com> wrote:
In the PAR meeting today,= Denis requested there be a privacy considerations section in PAR. I don't t= hink there is anything specific in PAR that would change the privacy conside= rations of OAuth, and am checking if there is WG interest, and consensus, on= including a Privacy Considerations section in the OAuth 2.1 draft.

=
/Dick
=E1=90=A7=
_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
= --Apple-Mail-947F1A7B-C329-4F0A-A1E8-56F9591690A7-- From nobody Mon Aug 10 12:40:08 2020 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 E00423A0C67 for ; Mon, 10 Aug 2020 12:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.949, 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=outer-planes-net.20150623.gappssmtp.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 uuPS4Lrxef7h for ; Mon, 10 Aug 2020 12:39:56 -0700 (PDT) Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 D724C3A0C6C for ; Mon, 10 Aug 2020 12:39:56 -0700 (PDT) Received: by mail-oo1-xc35.google.com with SMTP id y30so2143456ooj.3 for ; Mon, 10 Aug 2020 12:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qM0+2LlfjyLYojljWqFx+kmGfv7ph+sTlBUoyx10FO8=; b=OwVud2ZD2pA2O7VSfiFOqIlAGsmpvPQ0wArEVWfLKnzyOspHmmojypiiXtWMwe2BOB Tp1S3ErndcdDFPjA5C8VwsAngkLRlkqbR0Svi1DmxCbNxzLUTGVyg6fQ/+59n6RDI5WO BjszK46Dt1JRsbycFKVV1ZdkfB0nT2rTuvuWBHpP/roSO50gOZV/VmKG/LqIu7vQcj5A 0XOP9v07qh0x9B0tVdaLrW+MJOFvoPRNtd/mNTP4nwiwrZSk859VGo8hEOHkgIG+VWC4 oDcKsZPLbBq+58IHuL6kbFgfLH6A1mhhLsU8CxR69eS4m91oSESFwPa2H2iKGeYT8j2B xvFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=qM0+2LlfjyLYojljWqFx+kmGfv7ph+sTlBUoyx10FO8=; b=IQil7CI40mnWs4S1Cu3lJbxx3JZcB8JlhmuJVLT9JP4Q9Ahfi02FBl7jIN+0mHhD8R 0rHQ6KhHRlo9RA3Xl0psdOslpisBu3VbDFGsrarCWz94YgmHXSPoEiMOiSSYj0Mt4tjJ qpv4nr6nf31owIrg2lj5/pZ2CtSXIZEJ4XWGNh3Izc8bD6gf0eFUAlgefkfEEHsgcKP8 Y/kGwHxBd2J7RG/iQmTcQYmX8nUbR/izZAgK74wk8H4lGRM+XXA1QQNKGvgblzsSmXgY kMesx9ug4+5jwIcxGF4Af7wLd03hkq8AhZm1lRkS26RaWjGoLTCnvgOUouwaDD+0hXMu 0piA== X-Gm-Message-State: AOAM530gIhANq1ZzFRfv7sTSc1doTYitMyZSifJnHWsvFR4p74rvKEIm JDnscBHrV0e2uE4Vx9N/GKqXloDmk7cEcg== X-Google-Smtp-Source: ABdhPJwNbMuUzvVZ0BpuLwjTFUct2ACkySe1xj1AlZcNkJbq+wr5kga3WZ8JoykSbhoHt7dkrHOuiw== X-Received: by 2002:a4a:e92e:: with SMTP id a14mr2099692ooe.23.1597088395567; Mon, 10 Aug 2020 12:39:55 -0700 (PDT) Received: from mmiller-44677.local ([2601:280:4f00:14a:2994:7b7a:c8fe:8ca0]) by smtp.gmail.com with ESMTPSA id h90sm3603204oth.38.2020.08.10.12.39.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Aug 2020 12:39:54 -0700 (PDT) To: Vladimir Dzhuvinov Cc: oauth@ietf.org References: <51424c05-3199-0caf-65ea-6d7a4433c9b9@connect2id.com> From: "Matthew A. Miller" Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBVAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBDHXWI3skGkNa8yY4Oz0 ck4QngW7BQJeDg4fBQkVMJSlAAoJEOz0ck4QngW7XCcH/RBVW3Nd0ezXtL9XSn5DHJxRTb5q 6ZVIBQgVIMcH2DVzO/aCs3o1ECONHAazVGQ9b6cwHCtPWJpM0ENGx7DERa/Ay4vDeKXc1TEX VuukdGrX2zWOaFHDT/oU1SEg0C+f3JGnaTwYQ7i2KXkFuYNmqROkB+Z0PDaLu4biCYdjhkIm Yu3frzySHhEX2VVMcJA6lcqdBTE3j2+ywQ7icpiWUcvLuhCeuFER1JjTRchcXwtuiOAKPQCZ BM9B70Q73hiKKK4ylNjhLFKGomkWDqsQ6sAENn6YkWyBuXNr5Y66uFxFS0VY938o/ZoXw4tb qUIdBzMnHkHxxiNUUBb6dPkaEGO5AQ0EUmgCigEIAMD+u4fBiVDul2Mljq3CRlwyZ52RA0vq vm00F5CTBWu+K1SMdMoqKmPEHaQSRRmjE+AwjWHv96cOtWUwwyqrpEgnzof7LHXfM0hk0GUl +ZUeAePtNPyylroD+ohxx2IhE2wVW+W8XGkfyxONVsd89h7Ft05HmQellZPNjE3JUtcwrmN6 fQHgr6+NuAUkC+ygt/MtnkHPeRvp2m7FQ3OqEPKGTn9Q9oIgW9lYG2JEqaSo/ASrwbZowmrl nhKvwJGSmgwHbmvEI9LxH4HKIfGmr5TyYq6o9WDUsnNwDuEeaazxoE3qXFKVvIqfMSDwBaCV 37r7GUle7lT9+oMAKVOPmZ8AEQEAAYkBPAQYAQoAJgIbDBYhBDHXWI3skGkNa8yY4Oz0ck4Q ngW7BQJeM+W5BQkPjlg/AAoJEOz0ck4QngW7a+IIANBU7R3t17LKflQo3nSUoqMBLkjxo9/e yzKAb3u0Fjb5md+9ESrFb03w1ZUkKLh/b6leTFq50IJbfxgDlVgkTn/j0XPOmIHpfDtVYPnA /rI5sqMzjb3qFOPFZFX9Til360uv9Zc5mlkJcM57X4aLRl7wSGRXPqh7v356s+JlvLF8rBtZ 7LU5SrCWeoWZu/7NvqW+UNEOOP2xAlOId4BeYWflkpzNcSPkhAkD2Xvw/GmyOm24Im7Ef2O5 scQhEO/dG+3jU4QnSGFtLXHndHpNM20vD6T+uWUpyp5g27KrIHApWq9M3o6KR68pTOLJrMxc th8xmHLOpuWVAKEABNQRDfE= Message-ID: <5ecf3c86-7bdb-2c64-0000-76f354a6beea@outer-planes.net> Date: Mon, 10 Aug 2020 13:39:52 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] ECDH-1PU encryption algorithm 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, 10 Aug 2020 19:40:06 -0000 Hi all, I have not read these drafts yet, so please forgive me if speaking out of turn. Speaking as co-chair of COSE WG, we're intermittently discussing a recharter, and accepting new algorithms without recharter has consensus so far. Note, though, that the COSE WG is focused on COSE and not JOSE. Not to say the work couldn't be done there, but if there's little-to-no interest in COSE then it is not likely to make progress. Also, if there's not a clear place to progress work, I would strongly suggest bringing it up on secdispatch@ietf.org, whose purpose is to find homes for new work. - m&m Matthew A. Miller On 20/08/10 11:38, Vladimir Dzhuvinov wrote: > On 10/08/2020 11:28, Neil Madden wrote: >> Thanks Vladimir, >> >> Responses below >> >>> On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov wrote: >>> >>> Hi Neil, >>> >>> I definitely like the elegance of the proposed alg for JOSE, it provides >>> something that isn't currently available in the various classes of algs >>> made standard in JOSE. >>> >>> I also wanted to ask what's happening with AES SIV for JOSE, if there's >>> traction / feedback / support there as well? >>> >>> https://tools.ietf.org/html/draft-madden-jose-siv-mode-02 >> Thanks for bringing this up. I’ve not received much feedback about this one, and I haven’t been very good at pushing it. If there is interest then I’d certainly be interested in bringing this forward too. >> >> That draft might be a better fit for eg the COSE WG though, which could then also register identifiers for JOSE. What do you think? > > If the COSE is the "proper" WG to get the spec completed and the algs > registered, then let it be COSE. We can continue the conversation there. > I support both drafts. > >> >>> Vladimir >>> >>> >>>>> On 05/08/2020 13:01, Neil Madden wrote: >>>> Hi all, >>>> You may remember me from such I-Ds >>>> as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which >>>> proposes adding a new encryption algorithm to JOSE. I’d like to >>>> reserve a bit of time to discuss it at one of the upcoming interim >>>> meetings. >>>> The basic idea is that in many cases in OAuth and OIDC you want to >>>> ensure both confidentiality and authenticity of some token - for >>>> example when transferring an ID token containing PII to the client >>>> through the front channel, or for access tokens intended to be handled >>>> by a specific RS without online token introspection (such as the JWT >>>> access token draft). If you have a shared secret key between the AS >>>> and the client/RS then you can use symmetric authenticated encryption >>>> (alg=dir or alg=A128KW etc). But if you need to use public key >>>> cryptography then currently you are limited to a nested >>>> signed-then-encrypted JOSE structure, which produces much larger token >>>> sizes. >>>> The draft adds a new “public key authenticated encryption” mode based >>>> on ECDH in the NIST standard “one-pass unified” model. The primary >>>> advantage for OAuth usage is that the tokens produced are more compact >>>> compared to signing+encryption (~30% smaller for typical access/ID >>>> token sizes in compact serialization). Performance-wise, it’s roughly >>>> equivalent. I know that size concerns are often a limiting factor in >>>> choosing whether to encrypt tokens, so this should help. >>>> In terms of implementation, it’s essentially just a few extra lines of >>>> code compared to an ECDH-ES implementation. (Some JOSE library APIs >>>> might need an adjustment to accommodate the extra private key needed >>>> for encryption/public key for decryption). >>>> I’ve received a few emails off-list from people interested in using it >>>> for non-OAuth use-cases such as secure messaging applications. I think >>>> these use-cases can be accommodated without significant changes, so I >>>> think the OAuth WG would be a good venue for advancing this. >>>> I’d be interested to hear thoughts and discussion on the list prior to >>>> any discussion at an interim meeting. >>>> — Neil > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Mon Aug 10 23:20:45 2020 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 8DD0A3A0CB3 for ; Mon, 10 Aug 2020 23:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.837 X-Spam-Level: X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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=hackmanit-de.20150623.gappssmtp.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 PpFfx38c-X46 for ; Mon, 10 Aug 2020 23:20:40 -0700 (PDT) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 227A83A0C9B for ; Mon, 10 Aug 2020 23:20:39 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id l4so11802337ejd.13 for ; Mon, 10 Aug 2020 23:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackmanit-de.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=99WLM10iJChoC1OUMrDoqbSzNoo26ic1PYBHipF1tsY=; b=Uwpmw8B662MtA+NAbXcKJPhqUjCB5utt5j07uVsw3eN37xngGEzKRDVIwuXJyRM8f3 aTsu/E5zs/+J55FsvIQZ0cz+ayGZNSupwrVAAK9fjyK8fBsz3HFF5a2KkoPEycKuIDrL KiP++6sPen6KWRdz++AMSvwSg5AejIgaaKYpQhydf94BXQgMKNnfMVYmOCSFD15k8X8m Uf8BBNaOfkXJiSKb4ebttGEBZ2LVJtksNdI12M5Z5lvTgwr/hvApcoT9HHpofZsxL7We uwVgGJAr0SeaTcggy6XUWf6x7GpniMPBIRg7Wr981I45uhWIOGYUnCBPQEDuHP9A0cuV BHXA== 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:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=99WLM10iJChoC1OUMrDoqbSzNoo26ic1PYBHipF1tsY=; b=oVZyUX9bYVLe03ZD15HDmyeeK3IEhbB0RLaeNh5meyWlAwJIt5PP/RvnzS4cwhgCrR F10+iM2yV7T6L8oEzQTg42uSrLWBESDGVUCVlrNS5l8HR3jBUqE0lKM6ffZTUZn8oSBX Dq/4o6lxJ8hrLu54vtQcBkpenodRfZl5Wo8EAD1QngnXaSFzC6cCcK6dXEC6WCIf4H81 8IPAEbZqKnTJdU/52y5jURp5Ufk2ahKYSVJVUyMFw7N7LZP9QAJ7mJm8dQKksMpIfvJt COECU4De/ZsguZyarjrDYu2WkOsNH+CPz3WtjiRim9Dpas5c7YN+Zc0liHVArCVtjyJo 2YQg== X-Gm-Message-State: AOAM533dij34yyF+O3kPxuZzc0R+0/c+Xa42VHyfMzExuhQUR3Jk608D I2JpIOLo1z9AF+84Q+6+CEXa2owDwvI= X-Google-Smtp-Source: ABdhPJyo5LlULvT2TebOuyMMixWgRx4vnjag5DpYeTpJsPAtD3JN4/6uopkWef+kyxNLFaJLQiC+vw== X-Received: by 2002:a17:907:104a:: with SMTP id oy10mr25042589ejb.267.1597126837860; Mon, 10 Aug 2020 23:20:37 -0700 (PDT) Received: from [192.168.178.22] (b2b-37-24-87-133.unitymedia.biz. [37.24.87.133]) by smtp.gmail.com with ESMTPSA id gh25sm14310012ejb.109.2020.08.10.23.20.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Aug 2020 23:20:37 -0700 (PDT) To: oauth@ietf.org References: <101390f1-0d6e-e5fe-861b-4d7e9b7816dd@danielfett.de> <7877fdc2-eeb0-18dd-5a89-ecb30800eacf@danielfett.de> From: Karsten Meyer zu Selhausen Autocrypt: addr=karsten.meyerzuselhausen@hackmanit.de; keydata= mQINBFh1IBMBEADV73c10lB7zeFy6/ezLFzOBp8z6Zy1zUyIrf6RoBk1GQWREcGEGeaL90Pj F5plZeASVJdsEYnYXdgcIPE0tlBq6al6OYoWtH/VbFPWEPLVhA3rL1iXVJveD3J40OzSYP8N G7bla3zQ2+TXOB3iDPPsHZUdHCLASkIIWQK6+fE1C2epAdPtnsLsb++1d080jfXXwgyUUh4y bimcy9Jg5oZ4QMwnSq3Y+x38PNb+nTgjDi1X/89/WsNd7Bdh4Zvw3CAuc/W58CFaDjb7liUD YRoAp6ysnjPKEUSnAnMpgaiXJc1gFoL+ahdKJ3D9XTn28NTjUrvOkVidsuKbyxnXP9I6BO6i 2jzjrH6TEAfIYMjZlYTyPZTt271SW5iAHYwvPZWlqQTBT2P/d4gHl0To5b4e+UXxjQgxqUyi QIcxh3Ris21Kx4lKQKDXYWiwNTZzx8AdqrcxCWfK+MRpFyk0B+4uDMm7Apm5ZWwDKN/JnVsJ yokkkrrHs/elRCUGtN9NyhJQf3VnE87862Pej8PVvQJr3uVnoNX2yieTvJZftIOBG1b9ta6Z BcYyn3un1rSn7lBPg+RSnPemposVorQpjGwT+Dhg13Bpv5q0JfSc//js/nB6A4iq5YssdtQ7 35QBWLLaF1oCxalvrQVDD4Sh06eAUQsga9xeE0yv7sxqdsozdwARAQABtEJLYXJzdGVuIE1l eWVyIHp1IFNlbGhhdXNlbiA8a2Fyc3Rlbi5tZXllcnp1c2VsaGF1c2VuQGhhY2ttYW5pdC5k ZT6JAj8EEwEIACkFAlh1IBMCGyMFCQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAK CRBFNcDn2xbxSK7sEAC5hk0VQHo2+fMV3b4TgSt4qSPLz6EnWwoqcEzUGYHErQXy7tCENpqS rsZsFphpgvWo1tcQdpyQTFm0dry4ASJD78lEiYC/8Hedp0fIaJTGwxrSLpRxV/Wb+iqkbgz8 /Qydl3QyupSqznSHQMd0uhvzHLxoYvHAIKy52gCK0T9gmxcCIh7UEjDfm+kqHp+oU4sbNe+2 ZEtJLuCKW+amNyqnHXr7ehAIaYmTdKOEcUb2UM7Yzp9g4kSkg1GbPlAn6yjyAqJ96sobKFXX S3rkXksRTxkGKW278Nrs4UBO+OIu32kIXCM2m3fKaUK777jAQu1e8sdj2nL0sPWQvMikZRx6 0dy+wVuH8gGHZsd7rW201Sv5pAhSAK4l58GS3xSLId6smXCend9Vu+tcYA+Bb+45943LmoPA PrdIUeI+zC9pjGwm+x+jFiCxbChqAiJF7RyYv9crziEYnTQ70gHGNOTOTIS5t0ufc9D4wD4O IkkrPQYg3KcAqP2Kyj1uHcqdk7XEhV1fdTXdeEt1e7auWPh0d3Fo+BTtiGXfNMuORArE0El6 ky8eUOqZEJ8rYpEGDLt0JFkJM5AhX4PrQWekjaMhQ5yl/+M+Ss0V0JkImagSgWdvUn1+eAs0 zEuVxTc6ON69mIyMalQ5d4ofvPnKr3GNVmEiXAVDMGUZHoeabfgSBbkCDQRYdSATARAAsp2V mr3N7iNND8+M/OyA/OwcDQ6utZh+m4TnKsOVdiNLGpu2U3/2Qg3yrbjic2dWx1CsS6VH2/oO 1e/a4FlxA93wFv/OZjiUjHtEvdIJeHWlCvWOUlMsqyGDc3Q75fNjFw6DGKkiOu9lZaBs6naS BmkvAMGjV5bNKLyIL5j7Im1pCdZ2lCjD7eVwR3RQQKobTmu916htX8g1cB9yFmquu37X+ZBl A4GLJi63Kw0L2r8i8iO1NqDLOfT8IeNkOroEm3SDAuEApGAubKLSPBJ1khQ7kDhpdfzSYKUF tiIHpGWVOImDjqf4JIcF7OIdRPQfFPlwoPnsyBAS8znQJvmqbbMowgFZe3UMLAN78CETZHGM OLBPB873oWyZ07Ar4v/SL5/aD+FRj2VnYEcGwt0HMmMyaN6ed8Udj4OTNZ7ceZA1Tw8/lZuI KCamj0XfJIK6376RCGnqjsEfS65P1KWZXfWphCKWp2c7uWKtau1q8pgiVRoBSAmjvfXRrIvK LhhQyNOiCUDKrvEWpoeq9y5GTrY27ncLov8nSR/SUPOw5HwJmzdFjhOF9XAOtiND/QRH886O IohdlnUu668mwLCmL2ROe7XWcTkFQWLDg+5b0bC9dgfL+HHpWGUdQPG3CCyPG5LfDmnmuXkE eU1kSD27kFe1kM6pfqpCydJW66DuwoMAEQEAAYkCJQQYAQgADwUCWHUgEwIbDAUJCWYBgAAK CRBFNcDn2xbxSAAbEACeIsfrsq2tlyigZv+bwkiVP1oKtWfXN1e3K3lDOBqPJaPXWFOopq/1 9osk58PFtVEaDlYPlN/NP6Jq5nTTC8QyLG3swAdo4ZJXWEg1NTRu8ddYUvZWuRHWRghaq7qh eW5lVPqilCndSG7bkDPU/Vyd93nPKnKTKKs/Nd7ePneWA0JQohEg5gO/GU0v5SN3YfTxG1LV Cxu3HHHFodDLK4KITSYmt1+g0WCADeclwm5+L5lIvgKQvcIpjpMGNK1wj2E3exsLlgo/ZEyS AslOPXyQw2yfYLrcfGpvWa3e+AvU7eLVBgihskpibJg53yw31B0CXAJBbjg7AsxR8UE5pl6h 2gTjN2t++GvqefGtw/bPvx2RzFsorh1/RYaFgcaFyefghmpi55iiIhgEOiSIct0LoYl3cmH8 DGYKhSskpSDgfE41Esk/P2odeax9SmJuv4mnqkiGFPpTwCfUka2k0mCpBDpfTdECWUFhreGS qFbrvJDZRBiyaVyCjOvOc0v6Z0/iIRgHWTjITpqaQh69kqAtt9GQWV6i3THnpHFlIC2ecvdc YCagneZdoLEHCS8Nois/uDbp5qZwZcF5zKMI+T7u6Qf8EGdvxCB1fp0Sdlmeto0c6/gnFUix 4J/tozBwSXSg7JCxTrUdnJtcQAJzosOUZTVO/ZZR/n0+904kud6o3w== Message-ID: Date: Tue, 11 Aug 2020 08:20:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3A8BBA9CF55FF556CECD6D79" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Mix-Up Revisited 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, 11 Aug 2020 06:20:44 -0000 This is a multi-part message in MIME format. --------------3A8BBA9CF55FF556CECD6D79 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi all, I think we all agree that proper countermeasures of mix-up attacks should definitely be part of the BCP and 2.1 due to the severe impact successful mix-up attacks have. Theoretically speaking every client which supports multiple AS is potentially vulnerable to mix-up attacks. While in practice it might seem unlikely it is possible that one of the honest AS the client supports gets compromised and can be utilized for a mix-up attack.  In a previous thread of last November (https://mailarchive.ietf.org/arch/msg/oauth/A7F5xSEa8DdfxHKWHW3Mqol_a4A/) I discussed why “use distinct redirect URIs for each AS” is not an effective countermeasure against mix-up attacks (if dynamic client registration is used). I would argue that this is especially important for mobile applications, SPAs, and other native applications because it is very common for them to use dynamic client registration. Many iOS applications now must support multiple AS since Apple forces the support for “Sign in with Apple” if any single sign-on provider is supported. This policy makes mix-up attacks applicable. I fully agree with Daniel, Brian, and Mike that it is important to define and register the “iss” parameter properly to ensure that both clients and AS understand and use it in the correct way. I understand that OAuth 2.1 is not meant to introduce and define new parameters but I strongly suggest that the “iss” parameter should be introduced and defined elsewhere so that it can be natively included in 2.1. In other words the “iss” parameter should be integrated in 2.1 the same way PKCE is: the initial definition of the parameter(s) is in another document (RFC 7636 in the case of PKCE) and then included in 2.1. What do you think would be the best place to define and register the “iss” parameter? Would it be worthwhile to reactivate and update “draft-ietf-oauth-mix-up-mitigation”? Best regards,Karsten On 18.06.2020 22:49, Mike Jones wrote: > > I support documenting the use of the issuer to mitigate mix-up > attacks.  Note that while issuer was first defined by OpenID Connect, > it became art of OAuth 2.0 in RFC 8414 - OAuth 2.0 Authorization > Server Metadata. > >   > >                                                        -- Mike > >   > > *From:* OAuth *On Behalf Of * Brian Campbell > *Sent:* Thursday, June 18, 2020 1:32 PM > *To:* Daniel Fett > *Cc:* oauth > *Subject:* [EXTERNAL] Re: [OAUTH-WG] Mix-Up Revisited > >   > > In my (probably simplistic) understanding of things, the root > underlying issue that allows for mix-up in its variations is the lack > of anything identifying the AS in the authorization response. > Following from that, introducing and using an `iss` authorization > response parameter has always seemed like the most straightforward > approach for mitigating the issue (which was part of the > draft-ietf-oauth-mix-up-mitigation but other parameters were also > included and, for reasons I'm not sure about, interest in that work > faded in favor of telling clients to use per AS redirect URIs) . > Though for the `iss` authorization response parameter to be effective, > all parties involved need to know about it and act on it. So I think > it'd need to be something more than a passing recommendation in the > BCP. It should be defined, registered, explained, etc.. Actually > introducing a new parameter is maybe going beyond the expected scope > of the BCP (or 2.1). But maybe that's ok, if we're at least more > intentional about it.  > >   > > On Sun, Jun 7, 2020 at 7:53 AM Daniel Fett > wrote: > > Hi all, > > I was wondering if we should move towards introducing and (more > explicitly) recommending the iss parameter in the security BCP, > for the reasons laid out below and in the article (which is now at > https://danielfett.de/2020/05/04/mix-up-revisited/). > >   > > Any thoughts on this? > >   > > -Daniel > >   > > Am 04.05.20 um 19:34 schrieb Daniel Fett: > > Hi all, > > to make substantiated recommendations for FAPI 2.0, the > security considerations for PAR, and the security BCP, I did > another analysis on the threats that arise from mix-up > attacks. I was interested in particular in two questions: > > * Does PAR help preventing mix-up attacks? > * Do we need JARM to prevent mix-up attacks? > > I wrote down several attack variants and configurations in the > following document: > https://danielfett.github.io/notes/oauth/Mix-Up%20Revisited.html > > The key takeaways are: > > 1. The security BCP needs to make clear that per-*AS* > redirect URIs are only sufficient if OAuth Metadata is not > used to resolve multiple issuers. Otherwise, per-*Issuer* > redirect URIs or the iss parameter MUST be used. > 2. PAR-enabled authorization servers can protect the > integrity better and protect against Mix-Up Attacks better > if they ONLY accept PAR requests. > 3. We should emphasize the importance of the iss parameter > (or issuer) in the authorization response. Maybe introduce > this parameter in the security BCP or another document? > 4. Sender-constrained access tokens help against mix-up > attacks when the access token is targeted. > 5. Sender-constraining the authorization code (PAR + > PAR-DPoP?) might be worth looking into. > > I would like to hear your thoughts! > > -Daniel > >   > > _______________________________________________ > > 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 > > > */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 -- Karsten Meyer zu Selhausen IT Security Consultant Phone: +49 (0)234 / 54456499 Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Unsere nächste Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 24.09 + 25.09: https://hackmanit.de/de/schulungen/109-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-24-und-25-09-2020 Hackmanit GmbH Universitätsstraße 60 (Exzenterhaus) 44789 Bochum Registergericht: Amtsgericht Bochum, HRB 14896 Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz --------------3A8BBA9CF55FF556CECD6D79 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04Ij4NCiAgPC9oZWFkPg0KICA8Ym9k eSB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICA8cCBkaXI9Imx0ciIN CiAgICAgIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4O21hcmdpbi10b3A6MHB0O21hcmdpbi1i b3R0b206MHB0OyINCiAgICAgIGlkPSJkb2NzLWludGVybmFsLWd1aWQtOWIxYTU4ZmItN2Zm Zi1iN2VlLTdhYzAtNThlYmJhZDFjNzhmIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7 Zm9udC1mYW1pbHk6TnVuaXRvLHNhbnMtc2VyaWY7Y29sb3I6IzAwMDAwMDtiYWNrZ3JvdW5k LWNvbG9yOnRyYW5zcGFyZW50O2ZvbnQtd2VpZ2h0OjQwMDtmb250LXN0eWxlOm5vcm1hbDtm b250LXZhcmlhbnQ6bm9ybWFsO3RleHQtZGVjb3JhdGlvbjpub25lO3ZlcnRpY2FsLWFsaWdu OmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcDsiPkhpIGFs bCw8L3NwYW4+PC9wPg0KICAgIDxicj4NCiAgICA8cCBkaXI9Imx0ciINCiAgICAgIHN0eWxl PSJsaW5lLWhlaWdodDoxLjM4O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0OyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0O2ZvbnQtZmFtaWx5Ok51bml0byxzYW5zLXNl cmlmO2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1jb2xvcjp0cmFuc3BhcmVudDtmb250LXdl aWdodDo0MDA7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDt0ZXh0LWRl Y29yYXRpb246bm9uZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmU7 d2hpdGUtc3BhY2U6cHJlLXdyYXA7Ij5JIHRoaW5rIHdlIGFsbCBhZ3JlZSB0aGF0IHByb3Bl ciBjb3VudGVybWVhc3VyZXMgb2YgbWl4LXVwIGF0dGFja3Mgc2hvdWxkIGRlZmluaXRlbHkg YmUgcGFydCBvZiB0aGUgQkNQIGFuZCAyLjEgZHVlIHRvIHRoZSBzZXZlcmUgaW1wYWN0IHN1 Y2Nlc3NmdWwgbWl4LXVwIGF0dGFja3MgaGF2ZS48L3NwYW4+PC9wPg0KICAgIDxwIGRpcj0i bHRyIg0KICAgICAgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuMzg7bWFyZ2luLXRvcDowcHQ7bWFy Z2luLWJvdHRvbTowcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Zm9udC1mYW1p bHk6TnVuaXRvLHNhbnMtc2VyaWY7Y29sb3I6IzAwMDAwMDtiYWNrZ3JvdW5kLWNvbG9yOnRy YW5zcGFyZW50O2ZvbnQtd2VpZ2h0OjQwMDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlh bnQ6bm9ybWFsO3RleHQtZGVjb3JhdGlvbjpub25lO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5l O3doaXRlLXNwYWNlOnByZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcDsiPlRoZW9yZXRpY2FsbHkg c3BlYWtpbmcgZXZlcnkgY2xpZW50IHdoaWNoIHN1cHBvcnRzIG11bHRpcGxlIEFTIGlzIHBv dGVudGlhbGx5IHZ1bG5lcmFibGUgdG8gbWl4LXVwIGF0dGFja3MuIFdoaWxlIGluIHByYWN0 aWNlIGl0IG1pZ2h0IHNlZW0gdW5saWtlbHkgaXQgaXMgcG9zc2libGUgdGhhdCBvbmUgb2Yg dGhlIGhvbmVzdCBBUyB0aGUgY2xpZW50IHN1cHBvcnRzIGdldHMgY29tcHJvbWlzZWQgYW5k IGNhbiBiZSB1dGlsaXplZCBmb3IgYSBtaXgtdXAgYXR0YWNrLsKgPC9zcGFuPjwvcD4NCiAg ICA8YnI+DQogICAgPHAgZGlyPSJsdHIiDQogICAgICBzdHlsZT0ibGluZS1oZWlnaHQ6MS4z ODttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTFwdDtmb250LWZhbWlseTpOdW5pdG8sc2Fucy1zZXJpZjtjb2xvcjojMDAwMDAw O2JhY2tncm91bmQtY29sb3I6dHJhbnNwYXJlbnQ7Zm9udC13ZWlnaHQ6NDAwO2ZvbnQtc3R5 bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dmVy dGljYWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlO3doaXRlLXNwYWNlOnByZS13 cmFwOyI+SW4gYSBwcmV2aW91cyB0aHJlYWQgb2YgbGFzdCBOb3ZlbWJlciAoPC9zcGFuPjxh DQpocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoL0E3 RjV4U0VhOERkZnhIS1dIVzNNcW9sX2E0QS8iDQogICAgICAgIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246bm9uZTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDtmb250LWZhbWlseTpO dW5pdG8sc2Fucy1zZXJpZjtjb2xvcjojMTE1NWNjO2JhY2tncm91bmQtY29sb3I6dHJhbnNw YXJlbnQ7Zm9udC13ZWlnaHQ6NDAwO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpu b3JtYWw7dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTstd2Via2l0LXRleHQtZGVjb3JhdGlv bi1za2lwOm5vbmU7dGV4dC1kZWNvcmF0aW9uLXNraXAtaW5rOm5vbmU7dmVydGljYWwtYWxp Z246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlO3doaXRlLXNwYWNlOnByZS13cmFwOyI+aHR0 cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9vYXV0aC9BN0Y1eFNFYThEZGZ4 SEtXSFczTXFvbF9hNEEvPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7 Zm9udC1mYW1pbHk6TnVuaXRvLHNhbnMtc2VyaWY7Y29sb3I6IzAwMDAwMDtiYWNrZ3JvdW5k LWNvbG9yOnRyYW5zcGFyZW50O2ZvbnQtd2VpZ2h0OjQwMDtmb250LXN0eWxlOm5vcm1hbDtm b250LXZhcmlhbnQ6bm9ybWFsO3RleHQtZGVjb3JhdGlvbjpub25lO3ZlcnRpY2FsLWFsaWdu OmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcDsiPikgSSBk aXNjdXNzZWQgd2h5IOKAnHVzZSBkaXN0aW5jdCByZWRpcmVjdCBVUklzIGZvciBlYWNoIEFT 4oCdIGlzIG5vdCBhbiBlZmZlY3RpdmUgY291bnRlcm1lYXN1cmUgYWdhaW5zdCBtaXgtdXAg YXR0YWNrcyAoaWYgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIGlzIHVzZWQpLiBJIHdv dWxkIGFyZ3VlIHRoYXQgdGhpcyBpcyBlc3BlY2lhbGx5IGltcG9ydGFudCBmb3IgbW9iaWxl IGFwcGxpY2F0aW9ucywgU1BBcywgYW5kIG90aGVyIG5hdGl2ZSBhcHBsaWNhdGlvbnMgYmVj YXVzZSBpdCBpcyB2ZXJ5IGNvbW1vbiBmb3IgdGhlbSB0byB1c2UgZHluYW1pYyBjbGllbnQg cmVnaXN0cmF0aW9uLiBNYW55IGlPUyBhcHBsaWNhdGlvbnMgbm93IG11c3Qgc3VwcG9ydCBt dWx0aXBsZSBBUyBzaW5jZSBBcHBsZSBmb3JjZXMgdGhlIHN1cHBvcnQgZm9yIOKAnFNpZ24g aW4gd2l0aCBBcHBsZeKAnSBpZiBhbnkgc2luZ2xlIHNpZ24tb24gcHJvdmlkZXIgaXMgc3Vw cG9ydGVkLiBUaGlzIHBvbGljeSBtYWtlcyBtaXgtdXAgYXR0YWNrcyBhcHBsaWNhYmxlLjwv c3Bhbj48L3A+DQogICAgPGJyPg0KICAgIDxwIGRpcj0ibHRyIg0KICAgICAgc3R5bGU9Imxp bmUtaGVpZ2h0OjEuMzg7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQ7Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExcHQ7Zm9udC1mYW1pbHk6TnVuaXRvLHNhbnMtc2VyaWY7 Y29sb3I6IzAwMDAwMDtiYWNrZ3JvdW5kLWNvbG9yOnRyYW5zcGFyZW50O2ZvbnQtd2VpZ2h0 OjQwMDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO3RleHQtZGVjb3Jh dGlvbjpub25lO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZTt3aGl0 ZS1zcGFjZTpwcmUtd3JhcDsiPkkgZnVsbHkgYWdyZWUgd2l0aCBEYW5pZWwsIEJyaWFuLCBh bmQgTWlrZSB0aGF0IGl0IGlzIGltcG9ydGFudCB0byBkZWZpbmUgYW5kIHJlZ2lzdGVyIHRo ZSDigJxpc3PigJ0gcGFyYW1ldGVyIHByb3Blcmx5IHRvIGVuc3VyZSB0aGF0IGJvdGggY2xp ZW50cyBhbmQgQVMgdW5kZXJzdGFuZCBhbmQgdXNlIGl0IGluIHRoZSBjb3JyZWN0IHdheS4g SSB1bmRlcnN0YW5kIHRoYXQgT0F1dGggMi4xIGlzIG5vdCBtZWFudCB0byBpbnRyb2R1Y2Ug YW5kIGRlZmluZSBuZXcgcGFyYW1ldGVycyBidXQgSSBzdHJvbmdseSBzdWdnZXN0IHRoYXQg dGhlIOKAnGlzc+KAnSBwYXJhbWV0ZXIgc2hvdWxkIGJlIGludHJvZHVjZWQgYW5kIGRlZmlu ZWQgZWxzZXdoZXJlIHNvIHRoYXQgaXQgY2FuIGJlIG5hdGl2ZWx5IGluY2x1ZGVkIGluIDIu MS4gSW4gb3RoZXIgd29yZHMgdGhlIOKAnGlzc+KAnSBwYXJhbWV0ZXIgc2hvdWxkIGJlIGlu dGVncmF0ZWQgaW4gMi4xIHRoZSBzYW1lIHdheSBQS0NFIGlzOiB0aGUgaW5pdGlhbCBkZWZp bml0aW9uIG9mIHRoZSBwYXJhbWV0ZXIocykgaXMgaW4gYW5vdGhlciBkb2N1bWVudCAoUkZD IDc2MzYgaW4gdGhlIGNhc2Ugb2YgUEtDRSkgYW5kIHRoZW4gaW5jbHVkZWQgaW4gMi4xLjwv c3Bhbj48L3A+DQogICAgPGJyPg0KICAgIDxwIGRpcj0ibHRyIg0KICAgICAgc3R5bGU9Imxp bmUtaGVpZ2h0OjEuMzg7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQ7Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExcHQ7Zm9udC1mYW1pbHk6TnVuaXRvLHNhbnMtc2VyaWY7 Y29sb3I6IzAwMDAwMDtiYWNrZ3JvdW5kLWNvbG9yOnRyYW5zcGFyZW50O2ZvbnQtd2VpZ2h0 OjQwMDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO3RleHQtZGVjb3Jh dGlvbjpub25lO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZTt3aGl0 ZS1zcGFjZTpwcmUtd3JhcDsiPldoYXQgZG8geW91IHRoaW5rIHdvdWxkIGJlIHRoZSBiZXN0 IHBsYWNlIHRvIGRlZmluZSBhbmQgcmVnaXN0ZXIgdGhlIOKAnGlzc+KAnSBwYXJhbWV0ZXI/ IFdvdWxkIGl0IGJlIHdvcnRod2hpbGUgdG8gcmVhY3RpdmF0ZSBhbmQgdXBkYXRlIOKAnGRy YWZ0LWlldGYtb2F1dGgtbWl4LXVwLW1pdGlnYXRpb27igJ0/PC9zcGFuPjwvcD4NCiAgICA8 YnI+DQogICAgPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0O2ZvbnQtZmFtaWx5Ok51bml0 byxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1jb2xvcjp0cmFuc3BhcmVu dDtmb250LXdlaWdodDo0MDA7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1h bDt0ZXh0LWRlY29yYXRpb246bm9uZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1z cGFjZTpwcmU7d2hpdGUtc3BhY2U6cHJlLXdyYXA7Ij5CZXN0IHJlZ2FyZHMsPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDtmb250LWZhbWlseTpOdW5pdG8sc2Fucy1zZXJp Zjtjb2xvcjojMDAwMDAwO2JhY2tncm91bmQtY29sb3I6dHJhbnNwYXJlbnQ7Zm9udC13ZWln aHQ6NDAwO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7dGV4dC1kZWNv cmF0aW9uOm5vbmU7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlO3do aXRlLXNwYWNlOnByZS13cmFwOyI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFw dDtmb250LWZhbWlseTpOdW5pdG8sc2Fucy1zZXJpZjtjb2xvcjojMDAwMDAwO2JhY2tncm91 bmQtY29sb3I6dHJhbnNwYXJlbnQ7Zm9udC13ZWlnaHQ6NDAwO2ZvbnQtc3R5bGU6bm9ybWFs O2ZvbnQtdmFyaWFudDpub3JtYWw7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dmVydGljYWwtYWxp Z246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlO3doaXRlLXNwYWNlOnByZS13cmFwOyI+DQpL YXJzdGVuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDtmb250LWZhbWlseTpO dW5pdG8sc2Fucy1zZXJpZjtjb2xvcjojMDAwMDAwO2JhY2tncm91bmQtY29sb3I6dHJhbnNw YXJlbnQ7Zm9udC13ZWlnaHQ6NDAwO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpu b3JtYWw7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7d2hp dGUtc3BhY2U6cHJlO3doaXRlLXNwYWNlOnByZS13cmFwOyI+PC9zcGFuPg0KICAgIDxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDtmb250LWZhbWlseTpOdW5pdG8sc2Fucy1zZXJp Zjtjb2xvcjojMDAwMDAwO2JhY2tncm91bmQtY29sb3I6dHJhbnNwYXJlbnQ7Zm9udC13ZWln aHQ6NDAwO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7dGV4dC1kZWNv cmF0aW9uOm5vbmU7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlO3do aXRlLXNwYWNlOnByZS13cmFwOyI+DQo8L3NwYW4+PC9wPg0KICAgIDxkaXYgY2xhc3M9Im1v ei1jaXRlLXByZWZpeCI+T24gMTguMDYuMjAyMCAyMjo0OSwgTWlrZSBKb25lcyB3cm90ZTo8 YnI+DQogICAgPC9kaXY+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSINCmNpdGU9Im1p ZDpNTjJQUjAwTUIwNjg2NjA4NEZGOTVDNDk1NkE3NkI0NzJGNTlCMEBNTjJQUjAwTUIwNjg2 Lm5hbXByZDAwLnByb2Qub3V0bG9vay5jb20iPg0KICAgICAgPG1ldGEgaHR0cC1lcXVpdj0i Q29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPg0KICAg ICAgPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAo ZmlsdGVyZWQNCiAgICAgICAgbWVkaXVtKSI+DQogICAgICA8c3R5bGU+PCEtLQ0KLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7 DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTotYXBwbGUtc3lzdGVtOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4u SFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1h aWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjY0NDUxNDc7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNTIxMDc0OTI0O30NCkBsaXN0IGwwOmxldmVsMQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMQ0KCXttc28tbGlzdC1pZDoxNDUxODIxODY0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMjE0Mjg2MDkyMjt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9w Oi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6 bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVs Nw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1s ZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCiAgICAgIDxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIHN1cHBvcnQNCiAgICAgICAgICAgIGRvY3VtZW50 aW5nIHRoZSB1c2Ugb2YgdGhlIGlzc3VlciB0byBtaXRpZ2F0ZSBtaXgtdXANCiAgICAgICAg ICAgIGF0dGFja3MuwqAgTm90ZSB0aGF0IHdoaWxlIGlzc3VlciB3YXMgZmlyc3QgZGVmaW5l ZCBieSBPcGVuSUQNCiAgICAgICAgICAgIENvbm5lY3QsIGl0IGJlY2FtZSBhcnQgb2YgT0F1 dGggMi4wIGluIFJGQyA4NDE0IC0gT0F1dGggMi4wDQogICAgICAgICAgICBBdXRob3JpemF0 aW9uIFNlcnZlciBNZXRhZGF0YS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQogICAgICAgIDxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPsKg PC9vOnA+PC9zcGFuPjwvcD4NCiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoA0KICAgICAgICAgICAgLS0gTWlrZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPjxvOnA+wqA8L286cD48L3NwYW4+PC9wPg0KICAgICAgICA8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTENCiAgICAgICAg ICAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCiAgICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gT0F1dGgNCiAgICAgICAgICAgIDxhIGNsYXNz PSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnIj4mbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDs8L2E+IDxiPk9uIEJlaGFs ZiBPZiA8L2I+DQogICAgICAgICAgICBCcmlhbiBDYW1wYmVsbDxicj4NCiAgICAgICAgICAg IDxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVuZSAxOCwgMjAyMCAxOjMyIFBNPGJyPg0KICAg ICAgICAgICAgPGI+VG86PC9iPiBEYW5pZWwgRmV0dCA8YSBjbGFzcz0ibW96LXR4dC1saW5r LXJmYzIzOTZFIiBocmVmPSJtYWlsdG86ZmV0dEBkYW5pZWxmZXR0LmRlIj4mbHQ7ZmV0dEBk YW5pZWxmZXR0LmRlJmd0OzwvYT48YnI+DQogICAgICAgICAgICA8Yj5DYzo8L2I+IG9hdXRo IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpvYXV0aEBp ZXRmLm9yZyI+Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT48YnI+DQogICAgICAgICAgICA8 Yj5TdWJqZWN0OjwvYj4gW0VYVEVSTkFMXSBSZTogW09BVVRILVdHXSBNaXgtVXAgUmV2aXNp dGVkPG86cD48L286cD48L3A+DQogICAgICAgIDwvZGl2Pg0KICAgICAgICA8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPsKgPC9vOnA+PC9wPg0KICAgICAgICA8ZGl2Pg0KICAgICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIG15IChwcm9iYWJseSBzaW1wbGlzdGljKSB1bmRl cnN0YW5kaW5nDQogICAgICAgICAgICBvZiB0aGluZ3MsIHRoZSByb290IHVuZGVybHlpbmcg aXNzdWUgdGhhdCBhbGxvd3MgZm9yIG1peC11cA0KICAgICAgICAgICAgaW4gaXRzIHZhcmlh dGlvbnMgaXMgdGhlIGxhY2sgb2YgYW55dGhpbmcgaWRlbnRpZnlpbmcgdGhlIEFTDQogICAg ICAgICAgICBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZS4gRm9sbG93aW5nIGZyb20g dGhhdCwNCiAgICAgICAgICAgIGludHJvZHVjaW5nIGFuZCB1c2luZyBhbiBgaXNzYCBhdXRo b3JpemF0aW9uIHJlc3BvbnNlDQogICAgICAgICAgICBwYXJhbWV0ZXIgaGFzIGFsd2F5cyBz ZWVtZWQgbGlrZSB0aGUgbW9zdCBzdHJhaWdodGZvcndhcmQNCiAgICAgICAgICAgIGFwcHJv YWNoIGZvciBtaXRpZ2F0aW5nIHRoZSBpc3N1ZSAod2hpY2ggd2FzIHBhcnQgb2YgdGhlDQog ICAgICAgICAgICBkcmFmdC1pZXRmLW9hdXRoLW1peC11cC1taXRpZ2F0aW9uIGJ1dCBvdGhl ciBwYXJhbWV0ZXJzIHdlcmUNCiAgICAgICAgICAgIGFsc28gaW5jbHVkZWQgYW5kLCBmb3Ig cmVhc29ucyBJJ20gbm90IHN1cmUgYWJvdXQsIGludGVyZXN0DQogICAgICAgICAgICBpbiB0 aGF0IHdvcmsgZmFkZWQgaW4gZmF2b3Igb2YgdGVsbGluZyBjbGllbnRzIHRvIHVzZSBwZXIg QVMNCiAgICAgICAgICAgIHJlZGlyZWN0IFVSSXMpIC4gVGhvdWdoIGZvciB0aGUgYGlzc2Ag YXV0aG9yaXphdGlvbiByZXNwb25zZQ0KICAgICAgICAgICAgcGFyYW1ldGVyIHRvIGJlIGVm ZmVjdGl2ZSwgYWxsIHBhcnRpZXMgaW52b2x2ZWQgbmVlZCB0byBrbm93DQogICAgICAgICAg ICBhYm91dCBpdCBhbmQgYWN0IG9uIGl0LiBTbyBJIHRoaW5rIGl0J2QgbmVlZCB0byBiZSBz b21ldGhpbmcNCiAgICAgICAgICAgIG1vcmUgdGhhbiBhIHBhc3NpbmcgcmVjb21tZW5kYXRp b24gaW4gdGhlIEJDUC4gSXQgc2hvdWxkIGJlDQogICAgICAgICAgICBkZWZpbmVkLCByZWdp c3RlcmVkLCBleHBsYWluZWQsIGV0Yy4uIEFjdHVhbGx5IGludHJvZHVjaW5nIGENCiAgICAg ICAgICAgIG5ldyBwYXJhbWV0ZXIgaXMgbWF5YmUgZ29pbmcgYmV5b25kIHRoZSBleHBlY3Rl ZCBzY29wZSBvZg0KICAgICAgICAgICAgdGhlIEJDUCAob3IgMi4xKS4gQnV0IG1heWJlIHRo YXQncyBvaywgaWYgd2UncmUgYXQgbGVhc3QNCiAgICAgICAgICAgIG1vcmUgaW50ZW50aW9u YWwgYWJvdXQgaXQuwqANCiAgICAgICAgICAgIDxvOnA+PC9vOnA+PC9wPg0KICAgICAgICA8 L2Rpdj4NCiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD7CoDwvbzpwPjwvcD4N CiAgICAgICAgPGRpdj4NCiAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gU3VuLCBKdW4gNywgMjAyMCBhdCA3OjUzIEFNIERhbmllbA0KICAg ICAgICAgICAgICBGZXR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZmV0dEBkYW5pZWxmZXR0LmRl Ig0KICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRy dWUiPmZldHRAZGFuaWVsZmV0dC5kZTwvYT4mZ3Q7DQogICAgICAgICAgICAgIHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgIDxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDDQogICAgICAg ICAgICAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluDQogICAgICAgICAgICA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCiAgICAgICAgICAgIDxkaXY+DQog ICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg ICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHdhcyB3b25kZXJpbmcgaWYgd2Ugc2hvdWxkIG1vdmUNCiAgICAgICAgICAgICAgICAgIHRv d2FyZHMgaW50cm9kdWNpbmcgYW5kIChtb3JlIGV4cGxpY2l0bHkpIHJlY29tbWVuZGluZw0K ICAgICAgICAgICAgICAgICAgdGhlIGlzcyBwYXJhbWV0ZXIgaW4gdGhlIHNlY3VyaXR5IEJD UCwgZm9yIHRoZSByZWFzb25zDQogICAgICAgICAgICAgICAgICBsYWlkIG91dCBiZWxvdyBh bmQgaW4gdGhlIGFydGljbGUgKHdoaWNoIGlzIG5vdyBhdA0KICAgICAgICAgICAgICAgICAg PGENCiAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly9kYW5pZWxmZXR0LmRlLzIw MjAvMDUvMDQvbWl4LXVwLXJldmlzaXRlZC8iDQogICAgICAgICAgICAgICAgICAgIHRhcmdl dD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vZGFuaWVsZmV0dC5k ZS8yMDIwLzA1LzA0L21peC11cC1yZXZpc2l0ZWQvPC9hPikuPG86cD48L286cD48L3A+DQog ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAg ICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+wqA8L286cD48L3A+DQogICAgICAgICAg ICAgIDwvZGl2Pg0KICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgIDxwIGNs YXNzPSJNc29Ob3JtYWwiPkFueSB0aG91Z2h0cyBvbiB0aGlzPzxvOnA+PC9vOnA+PC9wPg0K ICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPsKgPC9vOnA+PC9wPg0KICAgICAgICAg ICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICA8cCBj bGFzcz0iTXNvTm9ybWFsIj4tRGFuaWVsPG86cD48L286cD48L3A+DQogICAgICAgICAgICAg IDwvZGl2Pg0KICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgIDxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+wqA8L286cD48L3A+DQogICAgICAgICAgICAgIDwvZGl2Pg0K ICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFtIDA0LjA1LjIwIHVtIDE5OjM0IHNjaHJpZWIgRGFuaWVsDQogICAgICAgICAgICAg ICAgICBGZXR0OjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg ICAgICAgICAgPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQogICAgICAgICAgICAgICAgPHA+SGkgYWxsLDxvOnA+PC9vOnA+PC9w Pg0KICAgICAgICAgICAgICAgIDxwPnRvIG1ha2Ugc3Vic3RhbnRpYXRlZCByZWNvbW1lbmRh dGlvbnMgZm9yIEZBUEkgMi4wLA0KICAgICAgICAgICAgICAgICAgdGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIGZvciBQQVIsIGFuZCB0aGUgc2VjdXJpdHkNCiAgICAgICAgICAgICAg ICAgIEJDUCwgSSBkaWQgYW5vdGhlciBhbmFseXNpcyBvbiB0aGUgdGhyZWF0cyB0aGF0IGFy aXNlDQogICAgICAgICAgICAgICAgICBmcm9tIG1peC11cCBhdHRhY2tzLiBJIHdhcyBpbnRl cmVzdGVkIGluIHBhcnRpY3VsYXIgaW4NCiAgICAgICAgICAgICAgICAgIHR3byBxdWVzdGlv bnM6PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgPHVsIHR5cGU9ImRpc2MiPg0K ICAgICAgICAgICAgICAgICAgPGxpIGNsYXNzPSJNc29Ob3JtYWwiDQogICAgICAgICAgICAg ICAgICAgIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMA0KICAgICAgICAgICAgICAgICAgICBsZXZlbDEgbGZv MSI+DQogICAgICAgICAgICAgICAgICAgIERvZXMgUEFSIGhlbHAgcHJldmVudGluZyBtaXgt dXAgYXR0YWNrcz88bzpwPjwvbzpwPjwvbGk+DQogICAgICAgICAgICAgICAgICA8bGkgY2xh c3M9Ik1zb05vcm1hbCINCiAgICAgICAgICAgICAgICAgICAgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwDQog ICAgICAgICAgICAgICAgICAgIGxldmVsMSBsZm8xIj4NCiAgICAgICAgICAgICAgICAgICAg RG8gd2UgbmVlZCBKQVJNIHRvIHByZXZlbnQgbWl4LXVwIGF0dGFja3M/PG86cD48L286cD48 L2xpPg0KICAgICAgICAgICAgICAgIDwvdWw+DQogICAgICAgICAgICAgICAgPHA+SSB3cm90 ZSBkb3duIHNldmVyYWwgYXR0YWNrIHZhcmlhbnRzIGFuZA0KICAgICAgICAgICAgICAgICAg Y29uZmlndXJhdGlvbnMgaW4gdGhlIGZvbGxvd2luZyBkb2N1bWVudDoNCiAgICAgICAgICAg ICAgICAgIDxhDQogICAgICAgICAgICAgICAgICAgIGhyZWY9Imh0dHBzOi8vZGFuaWVsZmV0 dC5naXRodWIuaW8vbm90ZXMvb2F1dGgvTWl4LVVwJTIwUmV2aXNpdGVkLmh0bWwiDQogICAg ICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUi Pg0KaHR0cHM6Ly9kYW5pZWxmZXR0LmdpdGh1Yi5pby9ub3Rlcy9vYXV0aC9NaXgtVXAlMjBS ZXZpc2l0ZWQuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICA8cD5U aGUga2V5IHRha2Vhd2F5cyBhcmU6PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAg PG9sIHR5cGU9IjEiIHN0YXJ0PSIxIj4NCiAgICAgICAgICAgICAgICAgIDxsaSBjbGFzcz0i TXNvTm9ybWFsIg0KICAgICAgICAgICAgICAgICAgICBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDENCiAgICAg ICAgICAgICAgICAgICAgbGV2ZWwxIGxmbzIiPg0KICAgICAgICAgICAgICAgICAgICBUaGUg c2VjdXJpdHkgQkNQIG5lZWRzIHRvIG1ha2UgY2xlYXIgdGhhdCBwZXItPGI+QVM8L2I+DQog ICAgICAgICAgICAgICAgICAgIHJlZGlyZWN0IFVSSXMgYXJlIG9ubHkgc3VmZmljaWVudCBp ZiBPQXV0aCBNZXRhZGF0YQ0KICAgICAgICAgICAgICAgICAgICBpcyBub3QgdXNlZCB0byBy ZXNvbHZlIG11bHRpcGxlIGlzc3VlcnMuIE90aGVyd2lzZSwNCiAgICAgICAgICAgICAgICAg ICAgcGVyLTxiPklzc3VlcjwvYj4gcmVkaXJlY3QgVVJJcyBvciB0aGUgaXNzIHBhcmFtZXRl cg0KICAgICAgICAgICAgICAgICAgICBNVVNUIGJlIHVzZWQuPG86cD48L286cD48L2xpPg0K ICAgICAgICAgICAgICAgICAgPGxpIGNsYXNzPSJNc29Ob3JtYWwiDQogICAgICAgICAgICAg ICAgICAgIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMQ0KICAgICAgICAgICAgICAgICAgICBsZXZlbDEgbGZv MiI+DQogICAgICAgICAgICAgICAgICAgIFBBUi1lbmFibGVkIGF1dGhvcml6YXRpb24gc2Vy dmVycyBjYW4gcHJvdGVjdCB0aGUNCiAgICAgICAgICAgICAgICAgICAgaW50ZWdyaXR5IGJl dHRlciBhbmQgcHJvdGVjdCBhZ2FpbnN0IE1peC1VcCBBdHRhY2tzDQogICAgICAgICAgICAg ICAgICAgIGJldHRlciBpZiB0aGV5IE9OTFkgYWNjZXB0IFBBUiByZXF1ZXN0cy48bzpwPjwv bzpwPjwvbGk+DQogICAgICAgICAgICAgICAgICA8bGkgY2xhc3M9Ik1zb05vcm1hbCINCiAg ICAgICAgICAgICAgICAgICAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxDQogICAgICAgICAgICAgICAgICAg IGxldmVsMSBsZm8yIj4NCiAgICAgICAgICAgICAgICAgICAgV2Ugc2hvdWxkIGVtcGhhc2l6 ZSB0aGUgaW1wb3J0YW5jZSBvZiB0aGUgaXNzDQogICAgICAgICAgICAgICAgICAgIHBhcmFt ZXRlciAob3IgaXNzdWVyKSBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZS4NCiAgICAg ICAgICAgICAgICAgICAgTWF5YmUgaW50cm9kdWNlIHRoaXMgcGFyYW1ldGVyIGluIHRoZSBz ZWN1cml0eSBCQ1ANCiAgICAgICAgICAgICAgICAgICAgb3IgYW5vdGhlciBkb2N1bWVudD88 bzpwPjwvbzpwPjwvbGk+DQogICAgICAgICAgICAgICAgICA8bGkgY2xhc3M9Ik1zb05vcm1h bCINCiAgICAgICAgICAgICAgICAgICAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxDQogICAgICAgICAgICAg ICAgICAgIGxldmVsMSBsZm8yIj4NCiAgICAgICAgICAgICAgICAgICAgU2VuZGVyLWNvbnN0 cmFpbmVkIGFjY2VzcyB0b2tlbnMgaGVscCBhZ2FpbnN0IG1peC11cA0KICAgICAgICAgICAg ICAgICAgICBhdHRhY2tzIHdoZW4gdGhlIGFjY2VzcyB0b2tlbiBpcyB0YXJnZXRlZC48bzpw PjwvbzpwPjwvbGk+DQogICAgICAgICAgICAgICAgICA8bGkgY2xhc3M9Ik1zb05vcm1hbCIN CiAgICAgICAgICAgICAgICAgICAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxDQogICAgICAgICAgICAgICAg ICAgIGxldmVsMSBsZm8yIj4NCiAgICAgICAgICAgICAgICAgICAgU2VuZGVyLWNvbnN0cmFp bmluZyB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIChQQVIgKw0KICAgICAgICAgICAgICAgICAg ICBQQVItRFBvUD8pIG1pZ2h0IGJlIHdvcnRoIGxvb2tpbmcgaW50by48bzpwPjwvbzpwPjwv bGk+DQogICAgICAgICAgICAgICAgPC9vbD4NCiAgICAgICAgICAgICAgICA8cD5JIHdvdWxk IGxpa2UgdG8gaGVhciB5b3VyIHRob3VnaHRzITxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAg ICAgICAgIDxwPi1EYW5pZWw8bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICA8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPsKgPC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgIDxw cmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw PjwvbzpwPjwvcHJlPg0KICAgICAgICAgICAgICAgIDxwcmU+T0F1dGggbWFpbGluZyBsaXN0 PG86cD48L286cD48L3ByZT4NCiAgICAgICAgICAgICAgICA8cHJlPjxhIGhyZWY9Im1haWx0 bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1 ZSI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCiAgICAgICAgICAgICAg ICA8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3By ZT4NCiAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICA8cD48bzpw PsKgPC9vOnA+PC9wPg0KICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCiAgICAgICAgICAgICAgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KICAg ICAgICAgICAgICA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIg0KICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+T0F1dGhAaWV0 Zi5vcmc8L2E+PGJyPg0KICAgICAgICAgICAgICA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIg0KICAgICAgICAgICAgICAgIHRhcmdldD0i X2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQogICAgICAgICAgPC9i bG9ja3F1b3RlPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KICAgICAgICAgIDxiPjxpPjxzcGFuDQpzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDstYXBwbGUtc3lzdGVtJnF1b3Q7LHNlcmlmO2NvbG9yOiM1 NTU1NTU7Ym9yZGVyOm5vbmUNCiAgICAgICAgICAgICAgICB3aW5kb3d0ZXh0IDEuMHB0O3Bh ZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOg0KICAgICAgICAgICAgICAgIFRo aXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkDQogICAg ICAgICAgICAgICAgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50KHMpLg0KICAgICAgICAgICAgICAgIEFueSByZXZpZXcsIHVzZSwgZGlzdHJp YnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzDQogICAgICAgICAgICAgICAgc3Ry aWN0bHkgcHJvaGliaXRlZC4uwqAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcw0KICAgICAg ICAgICAgICAgIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlcg0KICAgICAgICAgICAgICAgIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRl IHRoZSBtZXNzYWdlIGFuZCBhbnkNCiAgICAgICAgICAgICAgICBmaWxlIGF0dGFjaG1lbnRz IGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9v OnA+PC9wPg0KICAgICAgPC9kaXY+DQogICAgICA8YnI+DQogICAgICA8ZmllbGRzZXQgY2xh c3M9Im1pbWVBdHRhY2htZW50SGVhZGVyIj48L2ZpZWxkc2V0Pg0KICAgICAgPHByZSBjbGFz cz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQo8YSBjbGFzcz0ibW96 LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9B dXRoQGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT4NCjwvcHJlPg0KICAg IDwvYmxvY2txdW90ZT4NCiAgICA8cHJlIGNsYXNzPSJtb3otc2lnbmF0dXJlIiBjb2xzPSI3 MiI+LS0gDQpLYXJzdGVuIE1leWVyIHp1IFNlbGhhdXNlbg0KSVQgU2VjdXJpdHkgQ29uc3Vs dGFudA0KUGhvbmU6CSs0OSAoMCkyMzQgLyA1NDQ1NjQ5OQ0KV2ViOgk8YSBjbGFzcz0ibW96 LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL2hhY2ttYW5pdC5kZSI+aHR0cHM6 Ly9oYWNrbWFuaXQuZGU8L2E+IHwgSVQgU2VjdXJpdHkgQ29uc3VsdGluZywgUGVuZXRyYXRp b24gVGVzdGluZywgU2VjdXJpdHkgVHJhaW5pbmcNCg0KVW5zZXJlIG7DpGNoc3RlIExpdmUg T25saW5lLVNjaHVsdW5nIHp1ciBTaWNoZXJoZWl0IHZvbiBPQXV0aCB1bmQgT3BlbklEIENv bm5lY3QgYW0gMjQuMDkgKyAyNS4wOToNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRl eHQiIGhyZWY9Imh0dHBzOi8vaGFja21hbml0LmRlL2RlL3NjaHVsdW5nZW4vMTA5LWxpdmUt b25saW5lLXNjaHVsdW5nLXNpbmdsZS1zaWduLW9uLXNpY2hlcmhlaXQtb2F1dGgtb3Blbmlk LWNvbm5lY3QtYW0tMjQtdW5kLTI1LTA5LTIwMjAiPmh0dHBzOi8vaGFja21hbml0LmRlL2Rl L3NjaHVsdW5nZW4vMTA5LWxpdmUtb25saW5lLXNjaHVsdW5nLXNpbmdsZS1zaWduLW9uLXNp Y2hlcmhlaXQtb2F1dGgtb3BlbmlkLWNvbm5lY3QtYW0tMjQtdW5kLTI1LTA5LTIwMjA8L2E+ DQoNCkhhY2ttYW5pdCBHbWJIDQpVbml2ZXJzaXTDpHRzc3RyYcOfZSA2MCAoRXh6ZW50ZXJo YXVzKQ0KNDQ3ODkgQm9jaHVtDQoNClJlZ2lzdGVyZ2VyaWNodDogQW10c2dlcmljaHQgQm9j aHVtLCBIUkIgMTQ4OTYNCkdlc2Now6RmdHNmw7xocmVyOiBQcm9mLiBEci4gSsO2cmcgU2No d2VuaywgUHJvZi4gRHIuIEp1cmFqIFNvbW9yb3Zza3ksIERyLiBDaHJpc3RpYW4gTWFpbmth LCBEci4gTWFyY3VzIE5pZW1pZXR6PC9wcmU+DQogIDwvYm9keT4NCjwvaHRtbD4NCg== --------------3A8BBA9CF55FF556CECD6D79-- From nobody Tue Aug 11 03:33:59 2020 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 988F13A0F7A for ; Tue, 11 Aug 2020 03:33: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 (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 g005P7WW8x1G for ; Tue, 11 Aug 2020 03:33:55 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 413E73A0D08 for ; Tue, 11 Aug 2020 03:33:54 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id a15so10944254wrh.10 for ; Tue, 11 Aug 2020 03:33:54 -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=DuRkFJYYREwiGTFt/c4p12pxugDeDE0obAjcXppHDVw=; b=fcWmgs12Hz1uifvdgT+1ilrMgy2atwnQXQJJI4rn+hRWR3kvfXZBiqKG49N8RkT9HL OtC5WlTA3yncOVLDyetDnWFzlFpxGoTYmwe9Sqc9Q4Fj9kmeK2SMiMHBfThSAEF5h778 aqYug0clWRhcpU75VVx1ZYxSrxAAfUlpuaCQo= 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=DuRkFJYYREwiGTFt/c4p12pxugDeDE0obAjcXppHDVw=; b=Bj1MWM4kDRTx1ATr+iPVUQNwybliFFimlt8vDKnZzCrDbyLB4kMRs4mgWu9mKa7e8X cDLvdWLlmLW94+/OyCdQmPmq8Vf3CLku0a6HumA/0CSRwWwobPWRcfwjl4i0ue14S+8K 0htgFOF+/B3aJJm8OzveOgznoe9hgLltOxHDE95VTMkxH7uKMEruQE3qsRUFKNB3EGOm P1jw9Ci92jmwwqoL/jA7LDFUDD+gVwD9l0M6zQD70tNzRl2HeR2UBzoZ1ab1QMGvtlmt jA0JfOg+C7SuGXNm4KpKXXwM3tydZAZOdTgR1v/wFAXpkjIaaybmJ50KHZwM7xewkdS5 N+3g== X-Gm-Message-State: AOAM530+IOiwtoilBEKv5nIINN6tISjX3zTJzYBqGFiI+Hdx82gEh1EP PYQEN2gCDSTr4gBwHfgFk+3iHFqk2UA= X-Google-Smtp-Source: ABdhPJyeo9+27uhY2YORYZRjhDpnYAdldY6BFzBlollxamlXH1q8Wteh9/Fmaz2vVLMko1kymhYW0w== X-Received: by 2002:a5d:46ce:: with SMTP id g14mr30382304wrs.188.1597142032599; Tue, 11 Aug 2020 03:33:52 -0700 (PDT) Received: from [10.0.0.6] (38.227.143.150.dyn.plus.net. [150.143.227.38]) by smtp.gmail.com with ESMTPSA id h189sm4118015wme.17.2020.08.11.03.33.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2020 03:33:52 -0700 (PDT) From: Neil Madden Message-Id: <61F896E3-896B-4741-844C-E9205A114948@forgerock.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F2AC836E-18C4-4512-92C3-A64BEE03FF3B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 11 Aug 2020 11:33:51 +0100 In-Reply-To: <5ecf3c86-7bdb-2c64-0000-76f354a6beea@outer-planes.net> Cc: Vladimir Dzhuvinov , oauth@ietf.org To: "Matthew A. Miller" References: <51424c05-3199-0caf-65ea-6d7a4433c9b9@connect2id.com> <5ecf3c86-7bdb-2c64-0000-76f354a6beea@outer-planes.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] ECDH-1PU encryption algorithm 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, 11 Aug 2020 10:33:59 -0000 --Apple-Mail=_F2AC836E-18C4-4512-92C3-A64BEE03FF3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think the SIV draft is well suited to COSE - it shares many similar = properties to CCM, which is widely used in embedded/IoT applications = (and COSE). The misuse resistance is also particularly appealing in = those environments (indeed, I created the draft to support some IoT = activity at ForgeRock). For example, Teserakt (https://teserakt.io = ) use SIV mode in their IoT platform [1]. The ECDH-1PU draft is also potentially interesting for constrained = environments, given that it eliminates the need for a separate signature = so would provide a reduction in code size. COSE already has an ECDH-SS = mode which is also authenticated, so this would compliment that with = some stronger security properties. I think therefore that the COSE WG could be a natural home, so I will = send a message there to see if there is interest and otherwise take them = to secdispatch. The drafts can then register identifiers for COSE and = JOSE at the same time. [1]: = https://teserakt-io.github.io/e4-doc/specifications/cryptography-primitive= s/#authenticated-encryption = =20 =E2=80=94 Neil > On 10 Aug 2020, at 20:39, Matthew A. Miller = wrote: >=20 > Hi all, >=20 > I have not read these drafts yet, so please forgive me if speaking out > of turn. >=20 > Speaking as co-chair of COSE WG, we're intermittently discussing a > recharter, and accepting new algorithms without recharter has = consensus > so far. Note, though, that the COSE WG is focused on COSE and not = JOSE. > Not to say the work couldn't be done there, but if there's = little-to-no > interest in COSE then it is not likely to make progress. >=20 > Also, if there's not a clear place to progress work, I would strongly > suggest bringing it up on secdispatch@ietf.org = , whose purpose is to find > homes for new work. >=20 >=20 > - m&m >=20 > Matthew A. Miller > On 20/08/10 11:38, Vladimir Dzhuvinov wrote: >> On 10/08/2020 11:28, Neil Madden wrote: >>> Thanks Vladimir, >>>=20 >>> Responses below >>>=20 >>>> On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov = wrote: >>>>=20 >>>> =EF=BB=BFHi Neil, >>>>=20 >>>> I definitely like the elegance of the proposed alg for JOSE, it = provides >>>> something that isn't currently available in the various classes of = algs >>>> made standard in JOSE. >>>>=20 >>>> I also wanted to ask what's happening with AES SIV for JOSE, if = there's >>>> traction / feedback / support there as well? >>>>=20 >>>> https://tools.ietf.org/html/draft-madden-jose-siv-mode-02 >>> Thanks for bringing this up. I=E2=80=99ve not received much feedback = about this one, and I haven=E2=80=99t been very good at pushing it. If = there is interest then I=E2=80=99d certainly be interested in bringing = this forward too.=20 >>>=20 >>> That draft might be a better fit for eg the COSE WG though, which = could then also register identifiers for JOSE. What do you think? >>=20 >> If the COSE is the "proper" WG to get the spec completed and the algs >> registered, then let it be COSE. We can continue the conversation = there. >> I support both drafts. >>=20 >>>=20 >>>> Vladimir >>>>=20 >>>>=20 >>>>>> On 05/08/2020 13:01, Neil Madden wrote: >>>>> Hi all, >>>>> You may remember me from such I-Ds >>>>> as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, = which >>>>> proposes adding a new encryption algorithm to JOSE. I=E2=80=99d = like to >>>>> reserve a bit of time to discuss it at one of the upcoming interim >>>>> meetings. >>>>> The basic idea is that in many cases in OAuth and OIDC you want to >>>>> ensure both confidentiality and authenticity of some token - for >>>>> example when transferring an ID token containing PII to the client >>>>> through the front channel, or for access tokens intended to be = handled >>>>> by a specific RS without online token introspection (such as the = JWT >>>>> access token draft). If you have a shared secret key between the = AS >>>>> and the client/RS then you can use symmetric authenticated = encryption >>>>> (alg=3Ddir or alg=3DA128KW etc). But if you need to use public key >>>>> cryptography then currently you are limited to a nested >>>>> signed-then-encrypted JOSE structure, which produces much larger = token >>>>> sizes. >>>>> The draft adds a new =E2=80=9Cpublic key authenticated = encryption=E2=80=9D mode based >>>>> on ECDH in the NIST standard =E2=80=9Cone-pass unified=E2=80=9D = model. The primary >>>>> advantage for OAuth usage is that the tokens produced are more = compact >>>>> compared to signing+encryption (~30% smaller for typical access/ID >>>>> token sizes in compact serialization). Performance-wise, it=E2=80=99= s roughly >>>>> equivalent. I know that size concerns are often a limiting factor = in >>>>> choosing whether to encrypt tokens, so this should help. >>>>> In terms of implementation, it=E2=80=99s essentially just a few = extra lines of >>>>> code compared to an ECDH-ES implementation. (Some JOSE library = APIs >>>>> might need an adjustment to accommodate the extra private key = needed >>>>> for encryption/public key for decryption). >>>>> I=E2=80=99ve received a few emails off-list from people interested = in using it >>>>> for non-OAuth use-cases such as secure messaging applications. I = think >>>>> these use-cases can be accommodated without significant changes, = so I >>>>> think the OAuth WG would be a good venue for advancing this. >>>>> I=E2=80=99d be interested to hear thoughts and discussion on the = list prior to >>>>> any discussion at an interim meeting. >>>>> =E2=80=94 Neil >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_F2AC836E-18C4-4512-92C3-A64BEE03FF3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think the SIV draft is well suited to COSE - it shares many similar = properties to CCM, which is widely used in embedded/IoT applications = (and COSE). The misuse resistance is also particularly appealing in = those environments (indeed, I created the draft to support some IoT = activity at ForgeRock). For example, Teserakt (https://teserakt.io) use SIV = mode in their IoT platform [1].

The ECDH-1PU draft is also potentially interesting for = constrained environments, given that it eliminates the need for a = separate signature so would provide a reduction in code size. COSE = already has an ECDH-SS mode which is also authenticated, so this would = compliment that with some stronger security properties.

I think therefore that = the COSE WG could be a natural home, so I will send a message there to = see if there is interest and otherwise take them to secdispatch. The = drafts can then register identifiers for COSE and JOSE at the same = time.

[1]: https://teserakt-io.github.io/e4-doc/specifications/cryptograph= y-primitives/#authenticated-encryption 

=E2=80=94 Neil

On 10 Aug 2020, at 20:39, Matthew A. Miller <linuxwolf+ietf@outer-planes.net> wrote:

Hi = all,

I have not read these drafts yet, so please forgive me if = speaking out
of turn.

Speaking as co-chair of COSE WG, we're intermittently = discussing a
recharter, and accepting new algorithms without recharter has = consensus
so far.  Note, though, that the COSE WG is focused on = COSE and not JOSE.
Not to say the work couldn't be done there, but if there's = little-to-no
interest in COSE then it is not likely to make = progress.

Also, if there's not a clear place to progress work, I would = strongly
suggest bringing it up on secdispatch@ietf.org, whose purpose is to find
homes for new = work.


- m&m

Matthew A. Miller
On 20/08/10 11:38, Vladimir Dzhuvinov wrote:
On 10/08/2020 11:28, Neil Madden = wrote:
Thanks = Vladimir,

Responses below

On 8 Aug 2020, at 10:40, = Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

=EF=BB=BFHi Neil,

I definitely = like the elegance of the proposed alg for JOSE, it provides
something that isn't currently available in the various = classes of algs
made standard in JOSE.

I also wanted to ask what's happening with AES SIV for JOSE, = if there's
traction / feedback / support there as well?

https://tools.ietf.org/html/draft-madden-jose-siv-mode-02
Thanks for bringing this up. I=E2=80=99ve not = received much feedback about this one, and I haven=E2=80=99t been very = good at pushing it. If there is interest then I=E2=80=99d certainly be = interested in bringing this forward too. 

That draft might be a better fit for eg the COSE WG though, = which could then also register identifiers for JOSE. What do you = think?

If the COSE is the = "proper" WG to get the spec completed and the algs
registered, then let it be COSE. We can continue the = conversation there.
I support both drafts.

Vladimir

On 05/08/2020 13:01, = Neil Madden wrote:
Hi all,
You = may remember me from such I-Ds
as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, = which
proposes adding a new encryption algorithm to JOSE. = I=E2=80=99d like to
reserve a bit of time to discuss it at = one of the upcoming interim
meetings.
The = basic idea is that in many cases in OAuth and OIDC you want to
ensure both confidentiality and authenticity of some token - = for
example when transferring an ID token containing PII = to the client
through the front channel, or for access = tokens intended to be handled
by a specific RS without = online token introspection (such as the JWT
access token = draft). If you have a shared secret key between the AS
and = the client/RS then you can use symmetric authenticated encryption
(alg=3Ddir or alg=3DA128KW etc). But if you need to use = public key
cryptography then currently you are limited to = a nested
signed-then-encrypted JOSE structure, which = produces much larger token
sizes.
The draft = adds a new =E2=80=9Cpublic key authenticated encryption=E2=80=9D mode = based
on ECDH in the NIST standard =E2=80=9Cone-pass = unified=E2=80=9D model. The primary
advantage for OAuth = usage is that the tokens produced are more compact
compared = to signing+encryption (~30% smaller for typical access/ID
token sizes in compact serialization). Performance-wise, = it=E2=80=99s roughly
equivalent. I know that size concerns = are often a limiting factor in
choosing whether to encrypt = tokens, so this should help.
In terms of implementation, = it=E2=80=99s essentially just a few extra lines of
code = compared to an ECDH-ES implementation. (Some JOSE library APIs
might need an adjustment to accommodate the extra private key = needed
for encryption/public key for decryption).
I=E2=80=99ve received a few emails off-list from people = interested in using it
for non-OAuth use-cases such as = secure messaging applications. I think
these use-cases can = be accommodated without significant changes, so I
think = the OAuth WG would be a good venue for advancing this.
I=E2=80= =99d be interested to hear thoughts and discussion on the list prior = to
any discussion at an interim meeting.
=E2=80= =94 Neil


_______________________________________________
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=_F2AC836E-18C4-4512-92C3-A64BEE03FF3B-- From nobody Tue Aug 11 05:55:21 2020 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 70CC93A1046 for ; Tue, 11 Aug 2020 05:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 CuWM4DjSwkvl for ; Tue, 11 Aug 2020 05:55:18 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE163A1045 for ; Tue, 11 Aug 2020 05:55:17 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BQt8z649gzytC; Tue, 11 Aug 2020 14:55:15 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <6A795E47-860D-4A1C-89B6-565937BEEFC7@tzi.org> Date: Tue, 11 Aug 2020 14:55:15 +0200 Cc: Stephen Farrell , "oauth@ietf.org" X-Mao-Original-Outgoing-Id: 618843315.138872-2f36e249d0829bd62b44b3e9edaeed45 Content-Transfer-Encoding: quoted-printable Message-Id: <8957772C-0E46-44BD-A6BB-93A7B050C570@tzi.org> References: <20141002120308.9386.79961.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C2A@TK5EX14MBXC286.redmond.corp.microsoft.com> <6A795E47-860D-4A1C-89B6-565937BEEFC7@tzi.org> To: Mike Jones X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and 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, 11 Aug 2020 12:55:20 -0000 On 2020-08-03, at 16:42, Carsten Bormann wrote: >=20 > On 2014-10-06, at 09:54, Mike Jones = wrote: >=20 >>> - 4.1.7: maybe worth adding that jti+iss being unique enough is not = sufficient and >>> jti alone has to meet that need. In >>> X.509 the issuer/serial has the equivalent property so someone might = assume >>> sequential jti values starting at 0 are ok. >>=20 >> Makes sense to add a warning of some kind along these lines. I think = I know the reasons you say that, but can you expand on that thought a = bit before I take a stab on writing this up? For instance, while = normally true, I don't think your observation is true if a relying party = will only accept tokens from a single issuer. >=20 > So can someone remind me why jti needs to be unique globally, and not = just per issuer? Anyone? Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Aug 11 07:44:11 2020 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 5D8C83A10EF for ; Tue, 11 Aug 2020 07:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-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 VQOiCzJJ30jN for ; Tue, 11 Aug 2020 07:44:07 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A0383A10EE for ; Tue, 11 Aug 2020 07:44:06 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d44 with ME id EEk02300M2bcEcA03Ek1d7; Tue, 11 Aug 2020 16:44:05 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 11 Aug 2020 16:44:05 +0200 X-ME-IP: 90.79.51.120 To: Brian Campbell , Dick Hardt Cc: oauth References: From: Denis Message-ID: <762bc6d7-eddc-e417-9bd3-da33a82a3733@free.fr> Date: Tue, 11 Aug 2020 16:43:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D2AF2013AF03E2793BFB0564" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1? 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, 11 Aug 2020 14:44:09 -0000 This is a multi-part message in MIME format. --------------D2AF2013AF03E2793BFB0564 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit OAuth 2. 0 and the OAuth 2.1 draft share a common point: they do not include a Privacy considerations section. This is "normal" for OAuth 2. 0 since RFC 6749 was published before RFC 6973 ever existed. RFC 6973 is a good guidance document that should be read and used to add a Privacy Considerations section to the OAuth 2.1 draft. Denis > I didn't have the reference offhand during the meeting today but > https://tools.ietf.org/html/rfc6973 looks to be a good source of > considerations for writing privacy considerations. As I mentioned, > I've written a number of such sections. Though these probably > shouldn't be considered exemplary they were published: > https://tools.ietf.org/html/rfc8707#section-4, > https://tools.ietf.org/html/rfc8705#section-8https://tools.ietf.org/html/rfc8693#section-6 > , > https://tools.ietf.org/html/rfc7523#section-7, > https://tools.ietf.org/html/rfc7522#section-7, and > https://tools.ietf.org/html/rfc7521#section-8.4. > > > I think including a pragmatic Privacy Considerations section in the > OAuth 2.1 draft could be worthwhile. > > On Mon, Aug 10, 2020 at 10:42 AM Dick Hardt > wrote: > > In the PAR meeting today, Denis requested there be a privacy > considerations section in PAR. I don't think there is anything > specific in PAR that would change the privacy considerations of > OAuth, and am checking if there is WG interest, and consensus, on > including a Privacy Considerations section in the OAuth 2.1 draft. > > /Dick > ᐧ > _______________________________________________ > 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 --------------D2AF2013AF03E2793BFB0564 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
OAuth 2. 0 and the OAuth 2.1 draft share a common point: they do not include a Privacy considerations section.

This is "normal" for OAuth 2. 0 since RFC 6749 was published before RFC 6973 ever existed.

RFC 6973 is a good guidance document that should be read and used to add a Privacy Considerations section to the OAuth 2.1 draft.

Denis


I didn't have the reference offhand during the meeting today but https://tools.ietf.org/html/rfc6973 looks to be a good source of considerations for writing privacy considerations. As I mentioned, I've written a number of such sections. Though these probably shouldn't be considered exemplary they were published: https://tools.ietf.org/html/rfc8707#section-4, https://tools.ietf.org/html/rfc8705#section-8https://tools.ietf.org/html/rfc8693#section-6, https://tools.ietf.org/html/rfc7523#section-7, https://tools.ietf.org/html/rfc7522#section-7, and https://tools.ietf.org/html/rfc7521#section-8.4.

I think including a pragmatic Privacy Considerations section in the OAuth 2.1 draft could be worthwhile. 

On Mon, Aug 10, 2020 at 10:42 AM Dick Hardt <dick.hardt@gmail.com> wrote:
In the PAR meeting today, Denis requested there be a privacy considerations section in PAR. I don't think there is anything specific in PAR that would change the privacy considerations of OAuth, and am checking if there is WG interest, and consensus, on including a Privacy Considerations section in the OAuth 2.1 draft.

/Dick
ᐧ
_______________________________________________
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


--------------D2AF2013AF03E2793BFB0564-- From nobody Tue Aug 11 07:47:01 2020 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 B5CB43A10F1 for ; Tue, 11 Aug 2020 07:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-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 rbrANHIEnb_f for ; Tue, 11 Aug 2020 07:46:57 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423243A10F2 for ; Tue, 11 Aug 2020 07:46:56 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d44 with ME id EEmt230092bcEcA03Emtt7; Tue, 11 Aug 2020 16:46:54 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 11 Aug 2020 16:46:54 +0200 X-ME-IP: 90.79.51.120 To: Filip Skokan , Aaron Parecki Cc: OAuth WG References: From: Denis Message-ID: <91699c07-5f82-e69e-191c-962daf06a115@free.fr> Date: Tue, 11 Aug 2020 16:46:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------71663EB706F8814C359E1B27" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1? 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, 11 Aug 2020 14:47:00 -0000 This is a multi-part message in MIME format. --------------71663EB706F8814C359E1B27 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Filip, > I don’t think there’s anything new introduced in PAR that would alter > existing status quo of privacy consiserations. > As such if privacy consideration was to be added for completeness it > should be along the lines of “this document > does not expand on or otherwise alter the privacy considerations” or > “there are no new privacy considerations introduced by this document”. OAuth 2.0 (RFC 6749) had no Privacy considerations section as it was issued before RFC 6973 (Privacy Considerations for Internet Protocols) existed. I browsed through the RFCs published by this WG and the guidance provided in RFC 6973 has not really be used and followed. So adding no text to nearly zero text will not help that much. I believe that a Privacy considerations section will be added to the OAuth 2.1 draft. While doing that exercise, a shorter version of it could be included in PAR. Hereafter is my detailed analysis: RFC 6973 (Privacy Considerations for Internet Protocols) has been issued in July 2013.RFCs issued earlier to RFC 6973 do not include a Privacy Considerations section. This is the case for : -RFC 6749 (The OAuth 2.0 Authorization Framework) -RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage) -RFC 6755 (An IETF URN Sub-Namespace for OAuth) -RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) For RFCs issued after RFC 6973, six of them don't have a have a Privacy Considerations section. This is the case for: -*RFC 7009 *(OAuth 2.0 Token Revocation) - *    RFC 7519* updated by RFC 8725 (JSON Web Token Best Current Practices) -*RFC 7636* (Proof Key for Code Exchange by OAuth Public Clients) -*RFC 8252 *(OAuth 2.0 for Native Apps) does not have a Privacy Considerations section -*RFC 8414 *(OAuth 2.0 Authorization Server Metadata) -*RFC 8628* (OAuth 2.0 Device Authorization Grant) Eleven of them have a Privacy Considerations section. They are enumerated below, with a copy of these sections. -*RFC 7521* (Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants) 8.4.Privacy Considerations An assertion may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties, should only be transmitted over encrypted channels, such as TLS.In cases where it is desirable to prevent disclosure of certain information to the client, the assertion (or portions of it) should be encrypted to the authorization server. Deployments should determine the minimum amount of information necessary to complete the exchange and include only such information in the assertion.In some cases, the Subject identifier can be a value representing an anonymous or pseudonymous user, as described in Section 6.3.1. -*RFC 7522* (Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants 7. Privacy Considerations A SAML Assertion may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties, should only be transmitted over encrypted channels, such as Transport Layer Security (TLS).In cases where it is desirable to prevent disclosure of certain information to the client, the Subject and/or individual attributes of a SAML Assertion should be encrypted to the authorization server. Deployments should determine the minimum amount of information necessary to complete the exchange and include only that information in an Assertion (typically by limiting what information is included in an or by omitting it altogether).In some cases, the Subject can be a value representing an anonymous or pseudonymous user, as described in Section 6.3.1 of the OAuth Assertion Framework [RFC7521 ]. -*RFC 7523 *JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants 7.Privacy Considerations A JWT may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties, should only be transmitted over encrypted channels, such as Transport Layer Security (TLS).In cases where it is desirable to prevent disclosure of certain information to the client, the JWT should be encrypted to the authorization server. Deployments should determine the minimum amount of information necessary to complete the exchange and include only such claims in the JWT. In some cases, the "sub" (subject) claim can be a value representing an anonymous or pseudonymous user, as described in Section 6.3.1 of the OAuth Assertion Framework [RFC7521]. -*RFC 7591* (OAuth 2.0 Dynamic Client Registration Protocol) 6.Privacy Considerations As the protocol described in this specification deals almost exclusively with information about software and not people, there are very few privacy concerns for its use.The notable exception is the "contacts" field as defined in Section 2, which contains contact information for the developers or other parties responsible for the client software.These values are intended to be displayed to end- users and will be available to the administrators of the authorization server.As such, the developer may wish to provide an email address or other contact information expressly dedicated to the purpose of supporting the client instead of using their personal or professional addresses.Alternatively, the developer may wish to provide a collective email address for the client to allow for continuing contact and support of the client software after the developer moves on and someone else takes over that responsibility. In general, the metadata for a client, such as the client name and software identifier, are common across all instances of a piece of client software and therefore pose no privacy issues for end-users. Client identifiers, on the other hand, are often unique to a specific instance of a client. For clients such as web sites that are used by many users, there may not be significant privacy concerns regarding the client identifier, but for clients such as native applications that are installed on a single end-user's device, the client identifier could be uniquely tracked during OAuth 2.0 transactions and its use tied to that single end-user.However, as the client software still needs to be authorized by a resource owner through an OAuth 2.0 authorization grant, this type of tracking can occur whether or not the client identifier is unique by correlating the authenticated resource owner with the requesting client identifier. Note that clients are forbidden by this specification from creating their own client identifier.If the client were able to do so, an individual client instance could be tracked across multiple colluding authorization servers, leading to privacy and security issues. Additionally, client identifiers are generally issued uniquely per registration request, even for the same instance of software.In this way, an application could marginally improve privacy by registering multiple times and appearing to be completely separate applications.However, this technique does incur significant usability cost in the form of requiring multiple authorizations per resource owner and is therefore unlikely to be used in practice. -*RFC 7592* (OAuth 2.0 Dynamic Client Registration Management Protocol) 6.Privacy Considerations This specification poses no additional privacy considerations beyond those described in the core "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591]. -***RFC 7662 *(OAuth 2.0 Token Introspection) 5.Privacy Considerations The introspection response may contain privacy-sensitive information such as user identifiers for resource owners.When this is the case, measures MUST be taken to prevent disclosure of this information to unintended parties.One method is to transmit user identifiers as opaque service-specific strings, potentially returning different identifiers to each protected resource. If the protected resource sends additional information about the client's request to the authorization server (such as the client's IP address) using an extension of this specification, such information could have additional privacy considerations that the extension should detail.However, the nature and implications of such extensions are outside the scope of this specification. Omitting privacy-sensitive information from an introspection response is the simplest way of minimizing privacy issues. -*RFC 7800* (Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) 5.Privacy Considerations A proof-of-possession key can be used as a correlation handle if the same key is used with multiple parties.Thus, for privacy reasons, it is recommended that different proof-of-possession keys be used when interacting with different parties. -*RFC 8176* (Authentication Method Reference Values) 4.Privacy Considerations The list of "amr" claim values returned in an ID Token reveals information about the way that the end user authenticated to the identity provider. In some cases, this information may have privacy implications. While this specification defines identifiers for particular kinds of credentials, it does not define how these credentials are stored or protected. For instance, ensuring the security and privacy of biometric credentials that are referenced by some of the defined Authentication Method Reference values is beyond the scope of this specification. -***RFC 8693* (OAuth 2.0 Token Exchange) 6.Privacy Considerations Tokens employed in the context of the functionality described herein may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties, MUST only be transmitted over encrypted channels, such as Transport Layer Security (TLS). In cases where it is desirable to prevent disclosure of certain information to the client, the token MUST be encrypted to its intended recipient. Deployments SHOULD determine the minimally necessary amount of data and only include such information in issued tokens.In some cases, data minimization may include representing only an anonymous or pseudonymous user. -***RFC 8705* (OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens) 8.Privacy Considerations In TLS versions prior to 1.3, the client's certificate is sent unencrypted in the initial handshake and can potentially be used by third parties to monitor, track, and correlate client activity.This is likely of little concern for clients that act on behalf of a significant number of end users because individual user activity will not be discernible amidst the client activity as a whole.However, clients that act on behalf of a single end user, such as a native application on a mobile device, should use TLS version 1.3 whenever possible or consider the potential privacy implications of using mutual TLS on earlier versions. -*RFC 8707* (Resource Indicators for OAuth 2.0) 4.Privacy Considerations In typical OAuth deployments the authorization sever is in a position to observe and track a significant amount of user and client behavior. It is largely just inherent to the nature of OAuth, and this document does little to affect that.In some cases, however, such as when access token introspection is not being used, use of the resource parameter defined herein may allow for tracking behavior at a somewhat more granular and specific level than would otherwise be possible in its absence. Denis > > Filip > > Odesláno z iPhonu > >> 10. 8. 2020 v 19:21, Aaron Parecki : >> >>  >> I agree that there is nothing unique to PAR that would justify adding >> the privacy considerations mentioned to that draft. I wouldn't oppose >> adding a privacy considerations section to OAuth 2.1 though. >> >> Aaron >> >> >> On Mon, Aug 10, 2020 at 9:42 AM Dick Hardt > > wrote: >> >> In the PAR meeting today, Denis requested there be a privacy >> considerations section in PAR. I don't think there is anything >> specific in PAR that would change the privacy considerations of >> OAuth, and am checking if there is WG interest, and consensus, on >> including a Privacy Considerations section in the OAuth 2.1 draft. >> >> /Dick >> ᐧ >> >> _______________________________________________ >> 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 --------------71663EB706F8814C359E1B27 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Filip,

I don’t think there’s anything new introduced in PAR that would alter existing status quo of privacy consiserations.
As such if privacy consideration was to be added for completeness it should be along the lines of “this document
does not expand on or otherwise alter the privacy considerations” or “there are no new privacy considerations introduced by this document”.

OAuth 2.0 (RFC 6749) had no Privacy considerations section as it was issued before RFC 6973 (Privacy Considerations for Internet Protocols) existed.

I browsed through the RFCs published by this WG and the guidance provided in RFC 6973 has not really be used and followed.

So adding no text to nearly zero text will not help that much. I believe that a Privacy considerations section will be added to the OAuth 2.1 draft.
While doing that exercise, a shorter version of it could be included in PAR.

Hereafter is my detailed analysis:

RFC 6973 (Privacy Considerations for Internet Protocols) has been issued in July 2013. RFCs issued earlier to RFC 6973 do not include a Privacy Considerations section.

This is the case for :

-          RFC 6749 (The OAuth 2.0 Authorization Framework)

-          RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage)

-          RFC 6755 (An IETF URN Sub-Namespace for OAuth)

-          RFC 6819 (OAuth 2.0 Threat Model and Security Considerations)

For RFCs issued after RFC 6973, six of them don't have a have a Privacy Considerations section. This is the case for:

-          RFC 7009 (OAuth 2.0 Token Revocation)

-       RFC 7519 updated by RFC 8725 (JSON Web Token Best Current Practices)

-          RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients)

-          RFC 8252 (OAuth 2.0 for Native Apps) does not have a Privacy Considerations section

-          RFC 8414 (OAuth 2.0 Authorization Server Metadata)

-          RFC 8628 (OAuth 2.0 Device Authorization Grant)

Eleven of them have a Privacy Considerations section. They are enumerated below, with a copy of these sections.

-          RFC 7521 (Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants)

8.4.  Privacy Considerations

An assertion may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties,
should only be transmitted over encrypted channels, such as TLS.  In cases where it is desirable to prevent disclosure of
certain information to the client, the assertion (or portions of it) should be encrypted to the authorization server.

Deployments should determine the minimum amount of information necessary to complete the exchange and include only
such information in the assertion.  In some cases, the Subject identifier can be a value representing an anonymous or pseudonymous
user, as described in Section 6.3.1.

-          RFC 7522 (Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants

7. Privacy Considerations

A SAML Assertion may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties, 
should only be transmitted over encrypted channels, such as Transport Layer Security (TLS).  In cases where it is desirable to prevent 
disclosure of certain information to the client, the Subject and/or individual attributes of a SAML Assertion should be encrypted to the 
authorization server. 

Deployments should determine the minimum amount of information necessary to complete the exchange and include only that information 
in an Assertion (typically by limiting what information is included in an <AttributeStatement> or by omitting it altogether).  In some cases, 
the Subject can be a value representing an anonymous or pseudonymous user, as described in Section 6.3.1 of the OAuth Assertion Framework [RFC7521].

-          RFC 7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

7.  Privacy Considerations

A JWT may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties, should only be transmitted
over encrypted channels, such as Transport Layer Security (TLS).  In cases where it is desirable to prevent disclosure of certain information to the client,
the JWT should be encrypted to the authorization server.

Deployments should determine the minimum amount of information necessary to complete the exchange and include only such claims in the JWT. 
In some cases, the "sub" (subject) claim can be a value representing an anonymous or pseudonymous user, as described in Section 6.3.1 of
the OAuth Assertion Framework [RFC7521].

-          RFC 7591 (OAuth 2.0 Dynamic Client Registration Protocol)

6.  Privacy Considerations

As the protocol described in this specification deals almost exclusively with information about software and not people, there are very few
privacy concerns for its use.  The notable exception is the "contacts" field as defined in Section 2, which contains contact information for
the developers or other parties responsible for the client software.  These values are intended to be displayed to end- users and will be available
to the administrators of the authorization server.  As such, the developer may wish to provide an email address or other contact information expressly
dedicated to the purpose of supporting the client instead of using their personal or professional addresses.  Alternatively, the developer may wish
to provide a collective email address for the client to allow for continuing contact and support of the client software after the developer moves on and
someone else takes over that responsibility.

In general, the metadata for a client, such as the client name and software identifier, are common across all instances of a piece of client software
and therefore pose no privacy issues for end-users. Client identifiers, on the other hand, are often unique to a specific instance of a client. 
For clients such as web sites that are used by many users, there may not be significant privacy concerns regarding the client identifier, but for clients
such as native applications that are installed on a single end-user's device, the client identifier could be uniquely tracked during OAuth 2.0 transactions
and its use tied to that single end-user.  However, as the client software still needs to be authorized by a resource owner through an OAuth 2.0
authorization grant, this type of tracking can occur whether or not the client identifier is unique by correlating the authenticated resource owner with
the requesting client identifier.

Note that clients are forbidden by this specification from creating their own client identifier.  If the client were able to do so, an individual client instance
could be tracked across multiple colluding authorization servers, leading to privacy and security issues. Additionally, client identifiers are generally issued
uniquely per registration request, even for the same instance of software.  In this way, an application could marginally improve privacy by registering
multiple times and appearing to be completely separate applications.  However, this technique does incur significant usability cost in the form of requiring
multiple authorizations per resource owner and is therefore unlikely to be used in practice.

-          RFC 7592 (OAuth 2.0 Dynamic Client Registration Management Protocol)

6.  Privacy Considerations

This specification poses no additional privacy considerations beyond those described in the core "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591].

-          RFC 7662 (OAuth 2.0 Token Introspection)

5.  Privacy Considerations

The introspection response may contain privacy-sensitive information such as user identifiers for resource owners.  When this is the case,
measures MUST be taken to prevent disclosure of this information to unintended parties.  One method is to transmit user identifiers as opaque service-specific
strings, potentially returning different identifiers to each protected resource.

If the protected resource sends additional information about the client's request to the authorization server (such as the client's IP address) using an extension
of this specification, such information could have additional privacy considerations that the extension should detail.  However, the nature and implications of such
extensions are outside the scope of this specification.

Omitting privacy-sensitive information from an introspection response is the simplest way of minimizing privacy issues.

-          RFC 7800 (Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)

5.  Privacy Considerations

A proof-of-possession key can be used as a correlation handle if the same key is used with multiple parties.  Thus, for privacy reasons, it is recommended
that different proof-of-possession keys be used when interacting with different parties.

-          RFC 8176 (Authentication Method Reference Values)

4.  Privacy Considerations

The list of "amr" claim values returned in an ID Token reveals information about the way that the end user authenticated to the identity provider. 
In some cases, this information may have privacy implications.

While this specification defines identifiers for particular kinds of credentials, it does not define how these credentials are stored or protected. 
For instance, ensuring the security and privacy of biometric credentials that are referenced by some of the defined Authentication Method Reference
values is beyond the scope of this specification.

-          RFC 8693 (OAuth 2.0 Token Exchange)

6.  Privacy Considerations

Tokens employed in the context of the functionality described herein may contain privacy-sensitive information and, to prevent disclosure
of such information to unintended parties, MUST only be transmitted over encrypted channels, such as Transport Layer Security (TLS). 
In cases where it is desirable to prevent disclosure of certain information to the client, the token MUST be encrypted to its intended recipient. 
Deployments SHOULD determine the minimally necessary amount of data and only include such information in issued tokens.  In some cases,
data minimization may include representing only an anonymous or pseudonymous user.

-          RFC 8705 (OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens)

8.  Privacy Considerations

In TLS versions prior to 1.3, the client's certificate is sent unencrypted in the initial handshake and can potentially be used by third parties
to monitor, track, and correlate client activity.  This is likely of little concern for clients that act on behalf of a significant number of end users
because individual user activity will not be discernible amidst the client activity as a whole.  However, clients that act on behalf of a single end user,
such as a native application on a mobile device, should use TLS version 1.3 whenever possible or consider the potential privacy implications of
using mutual TLS on earlier versions.

-          RFC 8707 (Resource Indicators for OAuth 2.0)

4.  Privacy Considerations

In typical OAuth deployments the authorization sever is in a position to observe and track a significant amount of user and client behavior. 
It is largely just inherent to the nature of OAuth, and this document does little to affect that.  In some cases, however, such as when access token
introspection is not being used, use of the resource parameter defined herein may allow for tracking behavior at a somewhat more granular
and specific level than would otherwise be possible in its absence.

Denis


 

Filip
Odesláno z iPhonu
10. 8. 2020 v 19:21, Aaron Parecki <aaron@parecki.com>:


I agree that there is nothing unique to PAR that would justify adding the privacy considerations mentioned to that draft. I wouldn't oppose adding a privacy considerations section to OAuth 2.1 though.

Aaron
On Mon, Aug 10, 2020 at 9:42 AM Dick Hardt <dick.hardt@gmail.com> wrote:
In the PAR meeting today, Denis requested there be a privacy considerations section in PAR. I don't think there is anything specific in PAR that would change the privacy considerations of OAuth, and am checking if there is WG interest, and consensus, on including a Privacy Considerations section in the OAuth 2.1 draft.

/Dick
ᐧ
_______________________________________________
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


--------------71663EB706F8814C359E1B27-- From nobody Tue Aug 11 08:32:29 2020 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 2D0733A1108 for ; Tue, 11 Aug 2020 08:32:27 -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_FONT_LOW_CONTRAST=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 r5u-MN_rNeG4 for ; Tue, 11 Aug 2020 08:32:24 -0700 (PDT) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 54C013A1105 for ; Tue, 11 Aug 2020 08:32:24 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id e187so7262960ybc.5 for ; Tue, 11 Aug 2020 08:32:24 -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=D9tnfs0pwx9s3wO6gm9XotxXsofN9NFex0KKUbuNspY=; b=sQ9J/v51zswl631WneLyHNaktxwBx8eeZoYDUZS30+coqzV6FfJVD4Ld2z05o5MGLM KOtplHDdQANBRKAHATJM8Gw+vRvGMrKKKm3SfoKZxlUQ9sryQc/xjbkQu3O2ScWpFbaB q8lJbr40Oe78+OhzFSFXluffZHQF9ZxDZ9aeD5S+bsAaZQivlV78M/a3fZmdjcVju0IU GjA6hYazCKNzaP2BMKC7PaCIBOcDdNvcSN/ZugebfxvVZ8CuZIawhbwUxycZYidM6y0N kRvcrUA2quCPRc0LWJ1dgX6gfW4vfccJSOsiKknnS/HG0KOvQDx4Ha3Xj1Rh7usxUDrX FPbw== 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=D9tnfs0pwx9s3wO6gm9XotxXsofN9NFex0KKUbuNspY=; b=iPSTAdN5D5+gr5jBGgQsaU+zG4uR40yP7lFWK/MEpoB/xAedrUn4nukmT3y9+dyT70 fUOBzH5SXA0ryJirz1Bb1GWsbudI2h7MSybJLXU2U0AuwWVnqcyQVJOhY22Kf0ob26bT oyAEl0xvks6VIFYTjtq7lkc204hGz8QIlzppGeMSfjqR8CN2QrAmhhgKgWdWKDXkoICo Xov3n+zvoW4peIZsMw83QlKI6qjrqfwGL3qSCIb1QfO72cL3I+Ema9DSkY8KF3WsdUOP usvhT5wZ3sAcS86LTkHBMI1EN61Kej+bBWefdgoKNz7LUZqQIPsAtj1+MnLSXD/GHNOL UgBQ== X-Gm-Message-State: AOAM530se8WMFkYax3TMwa8LZ7x46JgGvuiTCkOW5cFca4CbxLwc11+m UHE9ilTdjZ07/R0ynJMAbUaedmRyBpI7wA17S2aldDw= X-Google-Smtp-Source: ABdhPJyJyKytVSdBvrGCdgfZ8+PY+/ZyM5YlKlbnwkxAvvsufb2GN2yhRgnEY+sjWkTnwO6ZVm8aidVoz4fh7zwWGKk= X-Received: by 2002:a25:7007:: with SMTP id l7mr45907853ybc.85.1597159943278; Tue, 11 Aug 2020 08:32:23 -0700 (PDT) MIME-Version: 1.0 References: <91699c07-5f82-e69e-191c-962daf06a115@free.fr> In-Reply-To: <91699c07-5f82-e69e-191c-962daf06a115@free.fr> From: Filip Skokan Date: Tue, 11 Aug 2020 17:31:46 +0200 Message-ID: To: Denis Cc: Aaron Parecki , OAuth WG Content-Type: multipart/alternative; boundary="0000000000001194e405ac9bc778" Archived-At: Subject: Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1? 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, 11 Aug 2020 15:32:27 -0000 --0000000000001194e405ac9bc778 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Denis, PAR is arguably not the document that should retrofit OAuth 2.0 with a full blown Privacy Consideration section. Now, do you find the draft introduces anything new from a privacy perspective? Does the AS get anything other than what it already does via the authorization_endpoint today? For the record i'm not arguing OAuth 2.0 should be without privacy considerations, i'm just saying - if it did, or rather, regardless if it does or doesn't - PAR does not expand on those in any way. S pozdravem, *Filip Skokan* On Tue, 11 Aug 2020 at 17:17, Denis wrote: > Hi Filip, > > I don=E2=80=99t think there=E2=80=99s anything new introduced in PAR that= would alter > existing status quo of privacy consiserations. > As such if privacy consideration was to be added for completeness it > should be along the lines of =E2=80=9Cthis document > does not expand on or otherwise alter the privacy considerations=E2=80=9D= or > =E2=80=9Cthere are no new privacy considerations introduced by this docum= ent=E2=80=9D. > > OAuth 2.0 (RFC 6749) had no Privacy considerations section as it was > issued before RFC 6973 (Privacy Considerations for Internet Protocols) > existed. > > I browsed through the RFCs published by this WG and the guidance provided > in RFC 6973 has not really be used and followed. > > So adding no text to nearly zero text will not help that much. I believe > that a Privacy considerations section will be added to the OAuth 2.1 draf= t. > While doing that exercise, a shorter version of it could be included in > PAR. > > Hereafter is my detailed analysis: > > RFC 6973 (Privacy Considerations for Internet Protocols) has been issued > in July 2013. RFCs issued earlier to RFC 6973 do not include a Privacy > Considerations section. > > This is the case for : > - RFC 6749 (The OAuth 2.0 Authorization Framework) - RF= C > 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage) - > RFC 6755 (An IETF URN Sub-Namespace for OAuth) - RFC 6819 (OAuth > 2.0 Threat Model and Security Considerations) For RFCs issued after RFC > 6973, six of them don't have a have a Privacy Considerations section. Thi= s > is the case for: > - *RFC 7009 *(OAuth 2.0 Token Revocation) - * RFC 7519* > updated by RFC 8725 (JSON Web Token Best Current Practices) - *R= FC > 7636* (Proof Key for Code Exchange by OAuth Public Clients) - *R= FC > 8252 *(OAuth 2.0 for Native Apps) does not have a Privacy Considerations > section - *RFC 8414 *(OAuth 2.0 Authorization Server Metadata) - > *RFC 8628* (OAuth 2.0 Device Authorization Grant) Eleven of them have a > Privacy Considerations section. They are enumerated below, with a copy of > these sections. - *RFC 7521* (Assertion Framework for OAuth 2.0 > Client Authentication and Authorization Grants) 8.4. Privacy > Considerations An assertion may contain privacy-sensitive information > and, to prevent disclosure of such information to unintended parties, > should only be transmitted over encrypted channels, such as TLS. In > cases where it is desirable to prevent disclosure of > certain information to the client, the assertion (or portions of it) > should be encrypted to the authorization server. Deployments should > determine the minimum amount of information necessary to complete the > exchange and include only > such information in the assertion. In some cases, the Subject identifier > can be a value representing an anonymous or pseudonymous > user, as described in Section 6.3.1. - *RFC 7522* (Security > Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client > Authentication and Authorization Grants 7. Privacy Considerations > > A SAML Assertion may contain privacy-sensitive information and, to preven= t disclosure of such information to unintended parties, > should only be transmitted over encrypted channels, such as Transport Lay= er Security (TLS). In cases where it is desirable to prevent > disclosure of certain information to the client, the Subject and/or indiv= idual attributes of a SAML Assertion should be encrypted to the > authorization server. > > Deployments should determine the minimum amount of information necessary = to complete the exchange and include only that information > in an Assertion (typically by limiting what information is included in an= or by omitting it altogether). In some cases, > the Subject can be a value representing an anonymous or pseudonymous user= , as described in Section 6.3.1 of the OAuth Assertion Framework [RFC7521 ]. > > - *RFC 7523 *JSON Web Token (JWT) Profile for OAuth 2.0 Client > Authentication and Authorization Grants 7. Privacy Considerations A JWT > may contain privacy-sensitive information and, to prevent disclosure of > such information to unintended parties, should only be transmitted > over encrypted channels, such as Transport Layer Security (TLS). In > cases where it is desirable to prevent disclosure of certain information = to > the client, > the JWT should be encrypted to the authorization server. Deployments > should determine the minimum amount of information necessary to complete > the exchange and include only such claims in the JWT. > In some cases, the "sub" (subject) claim can be a value representing an > anonymous or pseudonymous user, as described in Section 6.3.1 of > the OAuth Assertion Framework [RFC7521]. - *RFC 7591* (OAuth 2.0 > Dynamic Client Registration Protocol) 6. Privacy Considerations As the > protocol described in this specification deals almost exclusively with > information about software and not people, there are very few > privacy concerns for its use. The notable exception is the "contacts" > field as defined in Section 2, which contains contact information for > the developers or other parties responsible for the client software. The= se > values are intended to be displayed to end- users and will be available > to the administrators of the authorization server. As such, the > developer may wish to provide an email address or other contact informati= on > expressly > dedicated to the purpose of supporting the client instead of using their > personal or professional addresses. Alternatively, the developer may > wish > to provide a collective email address for the client to allow for > continuing contact and support of the client software after the developer > moves on and > someone else takes over that responsibility. In general, the metadata for > a client, such as the client name and software identifier, are common > across all instances of a piece of client software > and therefore pose no privacy issues for end-users. Client identifiers, o= n > the other hand, are often unique to a specific instance of a client. > For clients such as web sites that are used by many users, there may not > be significant privacy concerns regarding the client identifier, but for > clients > such as native applications that are installed on a single end-user's > device, the client identifier could be uniquely tracked during OAuth 2.0 > transactions > and its use tied to that single end-user. However, as the client > software still needs to be authorized by a resource owner through an OAut= h > 2.0 > authorization grant, this type of tracking can occur whether or not the > client identifier is unique by correlating the authenticated resource own= er > with > the requesting client identifier. Note that clients are forbidden by this > specification from creating their own client identifier. If the client > were able to do so, an individual client instance > could be tracked across multiple colluding authorization servers, leading > to privacy and security issues. Additionally, client identifiers are > generally issued > uniquely per registration request, even for the same instance of software= . > In this way, an application could marginally improve privacy by > registering > multiple times and appearing to be completely separate applications. How= ever, > this technique does incur significant usability cost in the form of > requiring > multiple authorizations per resource owner and is therefore unlikely to b= e > used in practice. - *RFC 7592* (OAuth 2.0 Dynamic Client > Registration Management Protocol) 6. Privacy Considerations This > specification poses no additional privacy considerations beyond those > described in the core "OAuth 2.0 Dynamic Client Registration Protocol" > [RFC7591]. - *RFC 7662 *(OAuth 2.0 Token Introspection) 5. Priv= acy > Considerations The introspection response may contain privacy-sensitive > information such as user identifiers for resource owners. When this is > the case, > measures MUST be taken to prevent disclosure of this information to > unintended parties. One method is to transmit user identifiers as opaque > service-specific > strings, potentially returning different identifiers to each protected > resource. If the protected resource sends additional information about > the client's request to the authorization server (such as the client's IP > address) using an extension > of this specification, such information could have additional privacy > considerations that the extension should detail. However, the nature and > implications of such > extensions are outside the scope of this specification. Omitting > privacy-sensitive information from an introspection response is the > simplest way of minimizing privacy issues. - *RFC 7800* > (Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) 5. Privacy > Considerations A proof-of-possession key can be used as a correlation > handle if the same key is used with multiple parties. Thus, for privacy > reasons, it is recommended > that different proof-of-possession keys be used when interacting with > different parties. - *RFC 8176* (Authentication Method Reference > Values) 4. Privacy Considerations The list of "amr" claim values > returned in an ID Token reveals information about the way that the end us= er > authenticated to the identity provider. > In some cases, this information may have privacy implications. While this > specification defines identifiers for particular kinds of credentials, it > does not define how these credentials are stored or protected. > For instance, ensuring the security and privacy of biometric credentials > that are referenced by some of the defined Authentication Method Referenc= e > values is beyond the scope of this specification. - *RFC 8693* > (OAuth 2.0 Token Exchange) 6. Privacy Considerations Tokens employed in > the context of the functionality described herein may contain > privacy-sensitive information and, to prevent disclosure > of such information to unintended parties, MUST only be transmitted over > encrypted channels, such as Transport Layer Security (TLS). > In cases where it is desirable to prevent disclosure of certain > information to the client, the token MUST be encrypted to its intended > recipient. > Deployments SHOULD determine the minimally necessary amount of data and > only include such information in issued tokens. In some cases, > data minimization may include representing only an anonymous or > pseudonymous user. - *RFC 8705* (OAuth 2.0 Mutual-TLS Client > Authentication and Certificate-Bound Access Tokens) 8. Privacy > Considerations In TLS versions prior to 1.3, the client's certificate is > sent unencrypted in the initial handshake and can potentially be used by > third parties > to monitor, track, and correlate client activity. This is likely of > little concern for clients that act on behalf of a significant number of > end users > because individual user activity will not be discernible amidst the clien= t > activity as a whole. However, clients that act on behalf of a single end > user, > such as a native application on a mobile device, should use TLS version > 1.3 whenever possible or consider the potential privacy implications of > using mutual TLS on earlier versions. - *RFC 8707* (Resource > Indicators for OAuth 2.0) 4. Privacy Considerations In typical OAuth > deployments the authorization sever is in a position to observe and track= a > significant amount of user and client behavior. > It is largely just inherent to the nature of OAuth, and this document doe= s > little to affect that. In some cases, however, such as when access token > introspection is not being used, use of the resource parameter defined > herein may allow for tracking behavior at a somewhat more granular > and specific level than would otherwise be possible in its absence. > > Denis > > > > > Filip > > Odesl=C3=A1no z iPhonu > > 10. 8. 2020 v 19:21, Aaron Parecki > : > > =EF=BB=BF > I agree that there is nothing unique to PAR that would justify adding the > privacy considerations mentioned to that draft. I wouldn't oppose adding = a > privacy considerations section to OAuth 2.1 though. > > Aaron > > > On Mon, Aug 10, 2020 at 9:42 AM Dick Hardt wrote: > >> In the PAR meeting today, Denis requested there be a privacy >> considerations section in PAR. I don't think there is anything specific = in >> PAR that would change the privacy considerations of OAuth, and am checki= ng >> if there is WG interest, and consensus, on including a Privacy >> Considerations section in the OAuth 2.1 draft. >> >> /Dick >> =E1=90=A7 >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > --0000000000001194e405ac9bc778 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Denis, PAR is arguably not the document that should= =C2=A0retrofit OAuth 2.0 with a full blown Privacy Consideration section. N= ow, do you find the draft introduces anything new from a privacy perspectiv= e? Does the AS get anything other than what it already does via the authori= zation_endpoint today?

For the record i'm not = arguing OAuth 2.0 should be without privacy considerations, i'm just sa= ying - if it did, or rather, regardless if it does or doesn't - PAR doe= s not expand on those in any way.

S pozdrave= m,
Filip Skokan


On Tue, 11 Aug 2020 at 17:17, Deni= s <denis.ietf@free.fr> wrot= e:
=20 =20 =20
Hi Filip,

=20 I don=E2=80=99t think there=E2=80=99s anything n= ew introduced in PAR that would alter existing status quo of privacy consiserations.
As such if privacy consideration was to be added for completeness it should be along the lines of =E2=80=9Cthis document=
does not expand on or otherwise alter the privacy considerations=E2=80=9D or =E2=80=9Cthere are no new privacy consid= erations introduced by this document=E2=80=9D.

OAuth 2.0 (RFC 6749) had no Privacy considerations section as it was issued before RFC 6973 (Privacy Considerations for Internet Protocols) existed.

I browsed through the RFCs published by this WG and the guidance provided in RFC 6973 has not really be used and followed.

So adding no text to nearly zero text will not help that much. I believe that a Privacy considerations section will be added to the OAuth 2.1 draft.
While doing that exercise, a shorter version of it could be included in PAR.

Hereafter is my detailed analysis:

RFC 6973 (Privacy Considerations for Internet Protocols) has been issued in July 2013. RFCs issued earlier to RFC 6973 do not include a Privacy Considerations section.

This is the case for :

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 RFC 6749 (The OAuth 2.0 Authorization Framework)

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage)

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 RFC 6755 (A= n IETF URN Sub-Namespace for OAuth)

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 RFC 6819 (OAuth 2.0 Threat Model and Security Considerations)

For RFCs issued after RFC 6973, six of them don't have a have a Privacy Considerations section. This is the case for:

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 7009 = (OAuth 2.0 Token Revocation)

-=C2=A0=C2=A0 =C2=A0 =C2=A0 RFC 7519 updated by RFC 8725 (JSON Web Token Best Current Practices)

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients)

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 8252 (OAuth 2.0 for Native Apps) does not have a Privacy Considerations section

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 8414 (OAuth 2.0 Authorization Server Metadata)

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 8628 (OAuth 2.0 Device Authorization Grant)

Eleven of them have a Privacy Considerations section. They are enumerated below, with a copy of these sections.

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 7521 (Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants)

8.4.=C2=A0 Pri= vacy Considerations

An assertion may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties,
should only be transmitted over encrypted channels, such as TLS.=C2=A0 In cases where it is desirable to prevent disclosure of
certain information to the client, the assertion (or portions of it) should be encrypted to the authorization server.

Deployments should determine the minimum amount of information necessary to complete the exchange and include only
such information in the assertion.=C2=A0 In some cases, the Subject identifier can be a value representing an anonymous or pseudonymous
user, as described in Section 6.3.1.

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 7522 (Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants

7. Privacy Considerations

A SAML Assertion may contain privacy-sensitiv=
e information and, to prevent disclosure of such information to unintended =
parties,=20
should only be transmitted over encrypted channels, such as Transport Layer=
 Security (TLS).=C2=A0 In cases where it is desirable to preve=
nt=20
disclosure of certain information to the client, the Subject and/or individ=
ual attributes of a SAML Assertion should be encrypted to the=20
authorization server.=20

Deployments should determine the minimum amou=
nt of information necessary to complete the exchange and include only that =
information=20
in an Assertion (typically by limiting what information is included in an &=
lt;AttributeStatement> or by omitting it altogether).=C2=A0 In some cases,=20
the Subject can be a value representing an anonymous or pseudonymous user, =
as described in Section 6.3.1 of the OAuth Assertion Framework [RFC7521].

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

7.=C2=A0 Privacy Considerations

A JWT may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties, should only be transmitted
over encrypted channels, such as Transport Layer Security (TLS).=C2=A0 In cases where it is desirable to prevent disclosure of certain information to the client,
the JWT should be encrypted to the authorization server.

Deployments should determine the minimum amount of information necessary to complete the exchange and include only such claims in the JWT.=C2=A0
In some cases, the "sub" (subject) claim can be a value represe= nting an anonymous or pseudonymous user, as described in Section 6.3.1 of
the OAuth Assertion Framework [RFC7521].

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 7591 (OAuth 2.0 Dynamic Client Registration Protocol)

6.=C2=A0 Privacy Considerations

As the protocol described in this specification deals almost exclusively with information about software and not people, there are very few
privacy concerns for its use.=C2=A0 The notable exception is the "contacts" field as defined in Section 2, which contains contact information for
the developers or other parties responsible for the client software.=C2=A0 These values are intended to be displayed to end- users and will be available
to the administrators of the authorization server.=C2=A0 As such, the developer may wish to provide an email address or other contact information expressly
dedicated to the purpose of supporting the client instead of using their personal or professional addresses.=C2=A0 Alternatively, the developer may wish
to provide a collective email address for the client to allow for continuing contact and support of the client software after the developer moves on and
someone else takes over that responsibility.

In general, the metadata for a client, such as the client name and software identifier, are common across all instances of a piece of client software
and therefore pose no privacy issues for end-users. Client identifiers, on the other hand, are often unique to a specific instance of a client.=C2=A0
For clients such as web sites that are used by many users, there may not be significant privacy concerns regarding the client identifier, but for clients
such as native applications that are installed on a single end-user's device, the client identifier could be uniquely tracked during OAuth 2.0 transactions
and its use tied to that single end-user.=C2=A0 However, as the client software still needs to be authorized by a resource owner through an OAuth 2.0
authorization grant, this type of tracking can occur whether or not the client identifier is unique by correlating the authenticated resource owner with
the requesting client identifier.

Note that clients are forbidden by this specification from creating their own client identifier.=C2=A0 If the client were able to do so, an individual client instance
could be tracked across multiple colluding authorization servers, leading to privacy and security issues. Additionally, client identifiers are generally issued
uniquely per registration request, even for the same instance of software.=C2=A0 In this way, an application could marginally improve privacy by registering
multiple times and appearing to be completely separate applications.=C2=A0 However, this technique does incur significant usability cost in the form of requiring
multiple authorizations per resource owner and is therefore unlikely to be used in practice.

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 7592 (OAuth 2.0 Dynamic Client Registration Management Protocol)

6.=C2=A0 Privacy Considerations

This specification poses no additional privacy considerations beyond those described in the core "OAuth 2.0 Dynamic Client Registration Protocol" [RFC75= 91].

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 7662 (OAuth 2.0 Token Introspection)

5.=C2=A0 Privacy Considerations

The introspection response may contain privacy-sensitive information such as user identifiers for resource owners.=C2=A0 When this is the case,
measures MUST be taken to prevent disclosure of this information to unintended parties.=C2=A0 One method is to transmit user identifiers as opaque service-specific
strings, potentially returning different identifiers to each protected resource.

If the protected resource sends additional information about the client's request to the authorization server (such as the client's IP address) using an extension
of this specification, such information could have additional privacy considerations that the extension should detail.=C2=A0 However, the nature and implications of such
extensions are outside the scope of this specification.

Omitting privacy-sensitive information from an introspection response is the simplest way of minimizing privacy issues.

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 7800 (Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)

5.=C2=A0 Privacy Considerations

A proof-of-possession key can be used as a correlation handle if the same key is used with multiple parties.=C2=A0 Thus, for privacy reasons, it is recommended
that different proof-of-possession keys be used when interacting with different parties.

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 8176 (Authentication Method Reference Values)

4.=C2=A0 Privacy Considerations

The list of "amr" claim values returned in an ID Token reveals information about the way that the end user authenticated to the identity provider.=C2=A0
In some cases, this information may have privacy implications.

While this specification defines identifiers for particular kinds of credentials, it does not define how these credentials are stored or protected.=C2=A0
For instance, ensuring the security and privacy of biometric credentials that are referenced by some of the defined Authentication Method Reference
values is beyond the scope of this specification.

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 8693 (OAuth 2.0 Token Exchange)

6.=C2=A0 Privacy Considerations

Tokens employed in the context of the functionality described herein may contain privacy-sensitive information and, to prevent disclosure
of such information to unintended parties, MUST only be transmitted over encrypted channels, such as Transport Layer Security (TLS).=C2=A0
In cases where it is desirable to prevent disclosure of certain information to the client, the token MUST be encrypted to its intended recipient.=C2=A0
Deployments SHOULD determine the minimally necessary amount of data and only include such information in issued tokens.=C2=A0 In some cases,
data minimization may include representing only an anonymous or pseudonymous user.

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 8705 (OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens)

8.=C2=A0 Privacy Considerations

In TLS versions prior to 1.3, the client's certificate is sent unencrypted in the initial handshake and can potentially be used by third parties
to monitor, track, and correlate client activity.=C2=A0 This is likely of little concern for clients that act on behalf of a significant number of end users
because individual user activity will not be discernible amidst the client activity as a whole.=C2=A0 However, clients that act on behalf of a single end user,
such as a native application on a mobile device, should use TLS version 1.3 whenever possible or consider the potential privacy implications of
using mutual TLS on earlier versions.

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 8707 (Resource Indicators for OAuth 2.0)

4.=C2=A0 Privacy Considerations

In typical OAuth deployments the authorization sever is in a position to observe and track a significant amount of user and client behavior.=C2=A0
It is largely just inherent to the nature of OAuth, and this document does little to affect that.=C2=A0 In some cases, however, such as when access token
introspection is not being used, use of the resource parameter defined herein may allow for tracking behavior at a somewhat more granular
and specific level than would otherwise be possible in its absence.

Denis


=C2=A0

Filip
Odesl=C3=A1no z=C2=A0iPhonu
10. 8. 2020 v=C2=A019:21, Aaron Parecki <aaron@parecki.com>:

=EF=BB=BF
I agree that there is nothing unique to PAR that would justify adding the privacy considerations mentioned to that draft. I wouldn't oppose adding a privacy considerations section to OAuth 2.1 though.

Aaron
On Mon, Aug 10, 2020 at 9:42 AM Dick Hardt <dick.hardt@gmail.com> wrote:
In the PAR meeting today, Denis requested there be a privacy considerations section in PAR. I don't think there is anything specific in PAR that would change the privacy considerations of OAuth, and am checking if there is WG interest, and consensus, on including a Privacy Considerations section in the OAuth 2.1 draft.

/Dick
3D""=E1=90=A7=
____________________________________= ___________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/oauth 

___________________________________________=
____
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth


--0000000000001194e405ac9bc778-- From nobody Tue Aug 11 08:53:00 2020 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 8CC4A3A0C3D; Tue, 11 Aug 2020 08:52:55 -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-jwsreq@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Hannes.Tschofenig@gmx.net X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159716117548.28832.15844996438952874291@ietfa.amsl.com> Date: Tue, 11 Aug 2020 08:52:55 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (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, 11 Aug 2020 15:52:56 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwsreq-26: 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the many updates as we worked through the issues. Let's also add a note about "whose JWT Claims Set holds the JSON encoded OAuth 2.0 authorization request parameters" to the definition of Request Object in Section 2.1 (in addition to the note in the Introduction); my apologies for not including that when I suggested the change to the Introduction. Please update the Content-Length in the example in Section 5.2.3. Section 4 The client determines the algorithms used to sign and encrypt request objects. This decision can be based on metadata the client registered via dynamic client registration [RFC7591] using the parameters "request_object_signing_alg", "request_object_encryption_alg", "request_object_encryption_enc" as defined in the the IANA "OAuth Dynamic Client Registration Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]. I had to read this ("this decision can be based on [...]") a few times to understand it. If I understand correctly, the idea is that the client will register with the AS the keys it will use for constructing the JAR, and in that way the AS has a binding from JAR-signing key to the specific client and request. So it's true that the decision of what key to use "can be based on" the metadata that the client registered, in that deciding to use a different key than the registered one(s) is likely to cause the AS to reject the request, but that's perhaps not the main point. Would it work to instead just say that "The keys used to sign and encrypt request objects (and thus, the algorithms that can be used with those keys) can be registered via dynamic client registration [...]"? Section 5.2 The contents of the resource referenced by the URI MUST be a Request Object, unless the URI was provided to the client by the Authorization Server. The "request_uri" value MUST be either URN as defined in RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230 [RFC7230] . The "request_uri" value MUST be reachable by the Authorization Server. I defer to my ART-area colleagues, but I'm not sure what it means for a URN URI to be "reachable"; is this requirement intended to only apply to the "https:" case? Section 5.2.1 It is possible for the Request Object to include values that are to be revealed only to the Authorization Server. As such, the "request_uri" MUST have appropriate entropy for its lifetime. For Is there a good reference for what the lifetime of such a request might be? Perhaps I've been reading too much of GNAP, but my intuition is that much of the time these requests will be single-use, and I don't have as clear of a picture for when they might persist longer. There are also potential security considerations for long-lived request objects, in terms of making sure that there is a binding between the client's intent to use a given request object for a given request, the user's authorization, etc. Section 5.2.3 (side note) I'd consider updating the timestamps in the example response (and perhaps moving to Apache 2.4+ as well?). Section 6.x (nit) I suggest consistency in subsection headings, so, e.g., "JWE Encrypted Request Object" and "JWS Signed Request Object". Section 6.2 The Authorization Server MUST perform the signature validation of the JSON Web Signature [RFC7515] signed request object. For this, the "alg" Header Parameter in its JOSE Header MUST match the value of the pre-registered algorithm. The signature MUST be validated against the appropriate key for that "client_id" and algorithm. This text suggests that pre-registration is mandatory, whereas up in Section 4 the client's choice of algorithm was merely something that "can be based on [metadata registered via dynamic registration]". I know that dynamic registration is not the only kind of registration possible, but we may want to wordsmith one (or both) location to improve the consistency. Section 6.3 I'd suggest reiterating here the requirement to verify "client_id" consistency between Request Object and request parameters. Section 10 I'd consider reiterating the security importance (i.e., what breaks if you don't apply the check) of a few key compliance requirements and which entity is responsible for enforcing them: - the "request" and "request_uri" parameters MUST NOT be included in request objects, from Section 4 - The request object has the mime-type "application/oauth.authz.req+jwt", also from Section 4 - The client_id in the request object has to match the client_id from the request query parameters, from Section 5 - The AS must only use parameters from the request object, even if the client has duplicated them in the query parameters, also from Section 5 Section 10.2 (e) When a third party, such as a Trust Framework Provider(TFP), provides an endpoint that provides a Request Object URI in exchange for a Request Object. The same requirements as (b) and (c) above apply. In addition, the Authorization Server MUST The (b) case is "the symmetric key for JWE encryption"; do we mean "(c) and (d)" here? Section 10.3 I'm not sure whether the key point of this section is "the following endpoints are RECOMMENDED [...] to use this practice" or "an extension specification should be created as a measure to address the risk". That is, can a deployment unilaterally apply the message-position and intended-interaction-endpoint protections now, or is there need for additional specification work first? Section 10.4 I'm not sure how much of this is distinct from the Request URI Rewrite discussed in Section 10.4.2, but having the request object contents be in a separately dereferenceable URI introduces risk of the dereferenced Request Object being dissociated from the triggering request. (This could happen due to internal error on the client or service hosting the requested URI or content skew over time, in addition to a request URI rewrite.) Having an externally provided single-use nonce in the reqest object would provide a mitigation, but it also (if I understand correctly) not compatible with all of the envisioned use cases for JAR. Section 10.5 Should the rejection of "alg":"none" be limited to the require_signed_request_object case, or universally applied? Section 12.1 (2) (Translation Process) The client uses the client credential that it got to push the request object to the TFP to get the "request_uri". If I understand correctly, the TFP also verifies that the request object is consistent with the claims the client is eligible for based on the certification step in (1). Section 12.2.2 Therefore, per-user Request Object URI should be avoided. If I understand correctly, the only possible alternative is to have per-request URIs (right?), as coalescing multiple user's requests into a single request object URI seems to pose several difficulties. We could perhaps make the recommended alternative more clear. From nobody Tue Aug 11 13:35:55 2020 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 B422D3A0CF9 for ; Tue, 11 Aug 2020 13:35:53 -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 OxvRFr3rP9WJ for ; Tue, 11 Aug 2020 13:35:51 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 2751D3A0E19 for ; Tue, 11 Aug 2020 13:35:49 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id v9so15032420ljk.6 for ; Tue, 11 Aug 2020 13:35:49 -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=BoZfZFuXocwUrWtpqLasVJ7IeTdTPSTLz0azAbkvPuc=; b=YzJEgRpwaPB13GEgmBDEXVEuh/43sqRLbLFof7wh2+NqVYrhiL57TP3HL0Y+yZTsnR ejNMpHwAxdJ5T9wqhfYuY0JbpqV93z/TZ375RlR6Vv9iDX3O26EJJqKOjb6cLnjHfUlj O1WINyLvmxY2IsM8HPSjBOUCuj5DyfWn3ay6WTfQ1+UTvnVqZVyZ+BtVkfUdz3bt+xq4 Q0plLLU+ktxJXIaiZVxfzK2iLG//WQslyXIpAy9XLEAJbDCDh+ibLsNngfu0KC4PFbZd vKx8A7KmSrfxwpCwa4XxAOC7f5s5uWLR5xAb0kpws5KebBN6plpHvxW9AS9AnuAqxeiO ZOcg== 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=BoZfZFuXocwUrWtpqLasVJ7IeTdTPSTLz0azAbkvPuc=; b=mETEpcSMBsMcq0tjHLKRG4Xayv5cBlvvN2GKi0fAGwfD8TPS5atXm4qtGZO354JQtn u2Id9PX9aL3CrjqFl9/ta5R2N0BwDnVr46hc+NzaplhW83ha0fyvmJahPxmNtlNQ/tpw XIPePzqai+Z0jP/6zho/g4lZM+T/d7g24850O5NE0DUKvDAkdBbEZ55Gt+CHXFiJ1k3n U08hY7iDzSid6GcvQz6HaeyPWwAJOPN8w2T2Xokomaih0uZXQ1RVra4nsNjapvXzPDZ9 9xung+I/zH/jjLBICRl6jyTcTZE8y3Xd4dfeMjhNYU84EgdUsv1gpagKklgnXCRCyO7x OxKg== X-Gm-Message-State: AOAM531KR1WNVw4FkcGJIMQWmzpu4ISMsPZFlRbdj8iP8ERHvB9IxKU+ dVJkN5UC5iXLVOKElBfJtYR1RhsaneNFF/jPtUPusk7OE3jQlg2SrH25GZT6sXAAfOc1wwvA8py zqSW7gaFCmCM35vlSwiI= X-Google-Smtp-Source: ABdhPJyPMDp+ebqLaSkriY8RHF7lhao8vyL3FAZTdb3cwbhiIF/vNH92fh7MOiZ2b6CEjVAnTm3FszNdUlULwh4SIHI= X-Received: by 2002:a05:651c:d0:: with SMTP id 16mr3870651ljr.313.1597178147256; Tue, 11 Aug 2020 13:35:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Tue, 11 Aug 2020 14:35:20 -0600 Message-ID: To: Dominick Baier Cc: oauth Content-Type: multipart/alternative; boundary="0000000000001c5a5705aca00463" Archived-At: Subject: Re: [OAUTH-WG] swapping a jwsreq/JAR JWT for a client authentication JWT 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, 11 Aug 2020 20:35:54 -0000 --0000000000001c5a5705aca00463 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I also suspect the Jwsreq authors won't respond to this and the request/suggestion will be ignored. Which is discouraging. I realize it's late in the process for this document but it's been in IESG Evaluation since early 2017. And the recent ballot comments https://mailarchive.ietf.org/arch/msg/oauth/FMljWETMEkGTI4pUluqIqtAJ_9A/ suggests changes to the draft should still be forthcoming. So also adding a brief statement to the security considerations doesn't seem inconceivable. On Thu, Jul 23, 2020 at 2:29 PM Brian Campbell wrote: > In hindsight, yeah, having explicit JWT typing everywhere would be nice.. > But retrofitting would be a very major undertaking, which I don't think > could reasonably be justified considering cost=E2=80=93benefit. > > I can't speak directly for the Jwsreq authors but I suspect consideration= s > around backward/forward compatibility with OIDC's JWT request and even > existing implementations of the Jwsreq draft that has been in draft forev= er > came into play. > > On Wed, Jul 22, 2020 at 11:38 PM Dominick Baier > wrote: > >> Even more. Jwsreq should have it. But the authors decided against it. >> >> =E2=80=94=E2=80=94=E2=80=94 >> Dominick Baier >> >> On 23. July 2020 at 07:38:04, Dominick Baier (dbaier@leastprivilege.com) >> wrote: >> >> Good point. Thanks, Brian. >> >> We should retrofit typs everywhere..in hindsight. >> >> =E2=80=94=E2=80=94=E2=80=94 >> Dominick Baier >> >> On 22. July 2020 at 23:55:20, Brian Campbell (bcampbell@pingidentity.com= ) >> wrote: >> >> Because it wouldn't actually prevent it in this case due to JWT assertio= n >> client authentication (a.k.a. private_key_jwt) having come about well >> before the JWT BCP and the established concept of using the 'typ' header= to >> prevent cross-JWT confusion. Thus there's no validation rule regarding t= he >> 'typ' header defined in RFC 7523 for JWT client authentication. Explicit= ly >> typing the request object JWT doesn't do anything to prevent it from bei= ng >> used in the context of previously existing JWT applications like client >> auth. >> >> On Wed, Jul 22, 2020 at 10:32 AM Dominick Baier < >> dbaier@leastprivilege.com> wrote: >> >>> Why not use a typ header as suggested by the JWT BCP? >>> >>> =E2=80=94=E2=80=94=E2=80=94 >>> Dominick Baier >>> >>> On 22. July 2020 at 17:37:41, Brian Campbell ( >>> bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: >>> >>> The TL;DR here is a somewhat tentative suggestion that a brief security >>> consideration be added to >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ >>> that >>> prohibits the inclusion of a 'sub' claim containing the client id value= in >>> the request object JWT so as to prevent the request object JWT (which i= s >>> exposed to the user agent) from being erroneously accepted as a valid J= WT >>> for client authentication. >>> >>> Some more details and the discussion that led to this here email can be >>> found at https://github.com/oauthstuff/draft-oauth-par/issues/41 >>> >>> *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 >>> >>> >> *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 send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> --=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._ --0000000000001c5a5705aca00463 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also suspect the Jwsreq authors won'= ;t respond to this and the request/suggestion will be ignored. Which is dis= couraging. I realize it's late in the process for this document but it&= #39;s been in IESG Evaluation since early 2017. And the recent ballot comme= nts https://mailarchive.ietf.org/arch/msg/oauth/FMljWETMEkGTI4pUl= uqIqtAJ_9A/ suggests changes to the draft should still be forthcoming. = So also adding a brief statement to the security considerations doesn't= seem inconceivable.

On Thu, Jul 23, 2020 at 2:29 PM Brian Campbell <= ;bcampbell@= pingidentity.com> wrote:
In hindsight, yeah, having explicit J= WT typing everywhere would be nice.. But retrofitting would be a very major= undertaking, which I don't think could reasonably be justified conside= ring cost=E2=80=93benefit.

I can't speak = directly for the Jwsreq authors but I suspect considerations around backwar= d/forward compatibility with OIDC's JWT request and even existing imple= mentations of the Jwsreq draft that has been in draft forever came into pla= y.

On Wed, Jul 22, 2020 at 11:38 PM Dominick Baier <dbaier@leastprivilege.com= > wrote:
Even more. Jwsre= q should have it. But the authors decided against it.

=E2= =80=94=E2=80=94=E2=80=94
Dominick Baier

On 23. July = 2020 at 07:38:04, Dominick Baier (dbaier@leastprivilege.com) wrote:

Good point. Thanks, Brian.

We should retrofit typs everywhere..in hin= dsight.

=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

On 22. July 2020 at 23:55:20, Brian Campbell (bcampbell@pingidentity.co= m) wrote:

Because it wouldn't actually prevent it in this case due t= o JWT assertion client authentication (a.k.a. private_key_jwt) having come= about well before the JWT BCP and the established concept of using the &#= 39;typ' header to prevent cross-JWT confusion. Thus there's no vali= dation rule regarding the 'typ' header defined in RFC 7523 for JWT = client authentication. Explicitly typing the request object JWT doesn't= do anything to prevent it from being used in the context of previously exi= sting JWT applications like client auth.=C2=A0

On Wed, Jul 22, 2020 at 1= 0:32 AM Dominick Baier <dbaier@leastprivilege.com> wrote:
Why not use a typ header as suggested by the JW= T BCP?

=E2=80=94=E2=80=94=E2=80=94
Dominick Baier
=

On 22. July 2020 at 17:37:41, Brian Campbell (bcampbe= ll=3D40pingidentity.com@dmarc.ietf.org) wrote:



CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited...=C2=A0 If you have received this communication in e= rror, 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

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.=C2=A0 If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message a= nd any file attachments from your computer. Thank you.

<= 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. --0000000000001c5a5705aca00463-- From nobody Tue Aug 11 13:46:23 2020 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 ABAE53A0CCF; Tue, 11 Aug 2020 13:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 gP4TtX92TGqH; Tue, 11 Aug 2020 13:46:19 -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 D94B13A0BF4; Tue, 11 Aug 2020 13:46:18 -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 07BKkEZq026477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Aug 2020 16:46:16 -0400 Date: Tue, 11 Aug 2020 13:46:14 -0700 From: Benjamin Kaduk To: Brian Campbell Cc: Dominick Baier , oauth Message-ID: <20200811204614.GI92412@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [OAUTH-WG] swapping a jwsreq/JAR JWT for a client authentication JWT 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, 11 Aug 2020 20:46:22 -0000 On Tue, Aug 11, 2020 at 02:35:20PM -0600, Brian Campbell wrote: > I also suspect the Jwsreq authors won't respond to this and the > request/suggestion will be ignored. Which is discouraging. I realize it's > late in the process for this document but it's been in IESG Evaluation > since early 2017. And the recent ballot comments > https://mailarchive.ietf.org/arch/msg/oauth/FMljWETMEkGTI4pUluqIqtAJ_9A/ > suggests changes to the draft should still be forthcoming. So also adding a > brief statement to the security considerations doesn't seem inconceivable. Yup, I expect further changes to the document before publication. Thanks for resurfacing this topic; I updated my ballot position to include a reference to it. -Ben From nobody Tue Aug 11 13:50:43 2020 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 4AC133A0BF4; Tue, 11 Aug 2020 13:50:37 -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-jwsreq@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Hannes.Tschofenig@gmx.net X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159717903728.5275.9808713434051601265@ietfa.amsl.com> Date: Tue, 11 Aug 2020 13:50:37 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (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, 11 Aug 2020 20:50:37 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwsreq-26: 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [updated to note that, per https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit typing is not used would be in order] Thanks for the many updates as we worked through the issues. Let's also add a note about "whose JWT Claims Set holds the JSON encoded OAuth 2.0 authorization request parameters" to the definition of Request Object in Section 2.1 (in addition to the note in the Introduction); my apologies for not including that when I suggested the change to the Introduction. Please update the Content-Length in the example in Section 5.2.3. Section 4 The client determines the algorithms used to sign and encrypt request objects. This decision can be based on metadata the client registered via dynamic client registration [RFC7591] using the parameters "request_object_signing_alg", "request_object_encryption_alg", "request_object_encryption_enc" as defined in the the IANA "OAuth Dynamic Client Registration Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]. I had to read this ("this decision can be based on [...]") a few times to understand it. If I understand correctly, the idea is that the client will register with the AS the keys it will use for constructing the JAR, and in that way the AS has a binding from JAR-signing key to the specific client and request. So it's true that the decision of what key to use "can be based on" the metadata that the client registered, in that deciding to use a different key than the registered one(s) is likely to cause the AS to reject the request, but that's perhaps not the main point. Would it work to instead just say that "The keys used to sign and encrypt request objects (and thus, the algorithms that can be used with those keys) can be registered via dynamic client registration [...]"? Section 5.2 The contents of the resource referenced by the URI MUST be a Request Object, unless the URI was provided to the client by the Authorization Server. The "request_uri" value MUST be either URN as defined in RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230 [RFC7230] . The "request_uri" value MUST be reachable by the Authorization Server. I defer to my ART-area colleagues, but I'm not sure what it means for a URN URI to be "reachable"; is this requirement intended to only apply to the "https:" case? Section 5.2.1 It is possible for the Request Object to include values that are to be revealed only to the Authorization Server. As such, the "request_uri" MUST have appropriate entropy for its lifetime. For Is there a good reference for what the lifetime of such a request might be? Perhaps I've been reading too much of GNAP, but my intuition is that much of the time these requests will be single-use, and I don't have as clear of a picture for when they might persist longer. There are also potential security considerations for long-lived request objects, in terms of making sure that there is a binding between the client's intent to use a given request object for a given request, the user's authorization, etc. Section 5.2.3 (side note) I'd consider updating the timestamps in the example response (and perhaps moving to Apache 2.4+ as well?). Section 6.x (nit) I suggest consistency in subsection headings, so, e.g., "JWE Encrypted Request Object" and "JWS Signed Request Object". Section 6.2 The Authorization Server MUST perform the signature validation of the JSON Web Signature [RFC7515] signed request object. For this, the "alg" Header Parameter in its JOSE Header MUST match the value of the pre-registered algorithm. The signature MUST be validated against the appropriate key for that "client_id" and algorithm. This text suggests that pre-registration is mandatory, whereas up in Section 4 the client's choice of algorithm was merely something that "can be based on [metadata registered via dynamic registration]". I know that dynamic registration is not the only kind of registration possible, but we may want to wordsmith one (or both) location to improve the consistency. Section 6.3 I'd suggest reiterating here the requirement to verify "client_id" consistency between Request Object and request parameters. Section 10 I'd consider reiterating the security importance (i.e., what breaks if you don't apply the check) of a few key compliance requirements and which entity is responsible for enforcing them: - the "request" and "request_uri" parameters MUST NOT be included in request objects, from Section 4 - The request object has the mime-type "application/oauth.authz.req+jwt", also from Section 4 - The client_id in the request object has to match the client_id from the request query parameters, from Section 5 - The AS must only use parameters from the request object, even if the client has duplicated them in the query parameters, also from Section 5 Section 10.2 (e) When a third party, such as a Trust Framework Provider(TFP), provides an endpoint that provides a Request Object URI in exchange for a Request Object. The same requirements as (b) and (c) above apply. In addition, the Authorization Server MUST The (b) case is "the symmetric key for JWE encryption"; do we mean "(c) and (d)" here? Section 10.3 I'm not sure whether the key point of this section is "the following endpoints are RECOMMENDED [...] to use this practice" or "an extension specification should be created as a measure to address the risk". That is, can a deployment unilaterally apply the message-position and intended-interaction-endpoint protections now, or is there need for additional specification work first? Section 10.4 I'm not sure how much of this is distinct from the Request URI Rewrite discussed in Section 10.4.2, but having the request object contents be in a separately dereferenceable URI introduces risk of the dereferenced Request Object being dissociated from the triggering request. (This could happen due to internal error on the client or service hosting the requested URI or content skew over time, in addition to a request URI rewrite.) Having an externally provided single-use nonce in the reqest object would provide a mitigation, but it also (if I understand correctly) not compatible with all of the envisioned use cases for JAR. Section 10.5 Should the rejection of "alg":"none" be limited to the require_signed_request_object case, or universally applied? Section 12.1 (2) (Translation Process) The client uses the client credential that it got to push the request object to the TFP to get the "request_uri". If I understand correctly, the TFP also verifies that the request object is consistent with the claims the client is eligible for based on the certification step in (1). Section 12.2.2 Therefore, per-user Request Object URI should be avoided. If I understand correctly, the only possible alternative is to have per-request URIs (right?), as coalescing multiple user's requests into a single request object URI seems to pose several difficulties. We could perhaps make the recommended alternative more clear. From nobody Tue Aug 11 14:55:40 2020 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 384BC3A0D3E for ; Tue, 11 Aug 2020 14:55:37 -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 uu1AxLw5YNe3 for ; Tue, 11 Aug 2020 14:55:34 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 0139C3A0BCF for ; Tue, 11 Aug 2020 14:55:33 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id w14so15240640ljj.4 for ; Tue, 11 Aug 2020 14:55:33 -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=uqkekHKEwvK+nMiW2wYWljockfxGIZlMBY61B4YWWCY=; b=BUR8ebmi2+45x7lcqUN6YG5EDxaBiPUN/icC6H3AkpgCyau6Qc36BYOnSa1Dv4L5L8 lUcKXkDKE/bIhN2/56znYJGLa4FlowWVNhUbR1muLRLiQM0k8tJNwElicDAIFqSDO0km oqyTFOgvvLZJJ3kEUXHd0lUBXGNpttNy+HZAO5a7TeT3ltkexw/ObGvVQgnamIG7UdaD +PeEt3HMCiEzjW9UTrcISZYg9NYanbj2EQ93qtw5ZMZYHbp4SCbGBenMNZnJeoU/N+aN DWu9ajBHGAs4VQ6bTQQyW6w3afn66c4cfDB1QYDwzNUTL32zZBY0lhfALbkzuXPY4tcX Y6/Q== 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=uqkekHKEwvK+nMiW2wYWljockfxGIZlMBY61B4YWWCY=; b=oKCwNotX8pAdFOqvNFYdDjSeIgT3zBNZA4gyjcG+3gAMJY5U1Mhb2Ys0L4oLUPuES7 OdGgyuL9DhNk+UJpBAKhhUFH3ozylVMG6dAH0jmr9zuydcVFTAAAKC+d2BCz27gnrPUV 1A6YRNcXrYLGMrCxWt6cF0yS/sunKhhAUamXvmZ9zbCOQ9bm6CfG2tY58u83TMi06LZh j/DAfrhwbGNPzTZXCbksVgMUPBaJGmvO6kPrRlnhKme/NrQ8iVrA4/Rmin89nlpsqgge cU4g0R1IlamcQyz3D1v1MM0N0j7p+K7HdRqQDCqNve8Zl6slT0iatmJsviNFh/AeD5jd bC1g== X-Gm-Message-State: AOAM5334TXE0qJpW7uVZStItJlSZOP1O1MCiqmnas/rim862dSBpFqrn D7XhTbZsm1ZItg86FItd0IuXHtpVWFDol0mZrnfls9UhRXI7KkZu4yAGe8IYV7vb/p0LRU9bx6d /tQkurp7S/xYaDQ== X-Google-Smtp-Source: ABdhPJyZhuSiaX44ZCp5NR/qd/OVb7mLoEpNUUxeV+8tQimNbde8va0ms9eE+7+2xaPNZ9I3uIpdpDieVlZ0pZuYbOE= X-Received: by 2002:a2e:d1a:: with SMTP id 26mr3781242ljn.422.1597182930975; Tue, 11 Aug 2020 14:55:30 -0700 (PDT) MIME-Version: 1.0 References: <159620115034.32558.6249632084531225541@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Tue, 11 Aug 2020 15:55:04 -0600 Message-ID: To: Francis Pouatcha Cc: OAuth WG Content-Type: multipart/alternative; boundary="0000000000003e1fc705aca12105" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-03.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, 11 Aug 2020 21:55:37 -0000 --0000000000003e1fc705aca12105 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Francis, My apologies for the tardy response to this - I was away for some time on holiday. But thank you for the review and feedback on the draft. I've tried to respond inline below. On Fri, Jul 31, 2020 at 5:01 PM Francis Pouatcha wrote: > Bellow is the only remark I found from reviewing the draft draft: > > 2.1. Request: > > requires the parameters "code_challenge" and "code_challenge_method" but > > https://openid.net/specs/openid-financial-api-part-2-ID2.html#confidentia= l-client mentions > that RFC7636 is not required for confidential clients. I guess those two > parameters have to be taken off the mandatory list and pushed to the list > below. > The list of parameters in Section 2.1 is qualified with a "basic parameter set will typically include" and is definitely not intended to convey a set of required parameters. It's just a list of parameters that make up a hypothetical typical request. Perhaps some text in the section or even the formatting needs to be adjusted so as to (hopefully) avoid any confusion like this that the list somehow conveys normative requirements? > - Using jwsreq, non repudiation is provided as request is signed (jws). > This section also mentions that the request can be sent as form url > encoded (x-www-form-urlencoded). In this case, there is no way to provide > non repudiation unless we mention that request can be signed by client > using signature methods declared by the AS (AS metadata). > I am not aware of any signature methods or means of an AS declaring support for a signature method in metadata that are sufficiently standardized to be mentioned in the context of this draft. The "request" parameter https://tools.ietf.org/html/draft-ietf-oauth-par-03#section-3 can be sent to the PAR endpoint and should provide the same notation of non-repudiation as does jwsreq. I think that's sufficient treatment of non-repudiation for the PAR draft. --=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._ --0000000000003e1fc705aca12105 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francis,

My apologies for the tardy response to this - I was away for some tim= e on holiday. But thank you for the review and feedback on the draft. I'= ;ve tried to respond inline below.


On Fri, Jul 31, 2020 at 5:01 PM Francis Pouatcha <fpo=3D40adorsys.de@= dmarc.ietf.org> wrote:
Bellow is the only remark I found from = reviewing the draft draft:

2.1.=C2=A0 Request:=C2= =A0

requires the parameters "code_challenge" and "code_challenge_metho= d" but
https= ://openid.net/specs/openid-financial-api-part-2-ID2.html#confidential-clien= t=C2=A0mentions that=C2=A0RFC7636 is not required for con= fidential clients. I guess those two parameters have to be taken off the ma= ndatory list and pushed to the list below.
<= div>
The list of parameters in Section 2.1 is qualified with = a "basic parameter set will typically include" and is definitely = not intended to convey a set of required parameters. It's just a list o= f parameters that make up a hypothetical typical request.=C2=A0 Perhaps som= e text in the section or even the formatting needs to be adjusted so as to = (hopefully) avoid any confusion like this that the list somehow conveys nor= mative requirements?

=C2=A0
- Using jw= sreq, non repudiation is provided as request is signed (jws). This section = also mentions that the request can be sent as form url=C2=A0 encoded (x-www-form-urlencod= ed). In this case, there is no way to=C2=A0provide non= repudiation unless we mention that request can be signed by client using s= ignature methods declared by the AS (AS metadata).

=C2=A0I am not aware of any signature methods o= r means of an AS declaring support for a signature method in metadata that = are sufficiently standardized to be mentioned in the context of this draft.= The "request" parameter https://tools.ietf.org/html/draft-ietf-oa= uth-par-03#section-3 can be sent to the PAR endpoint and should provide= the same notation of non-repudiation as does jwsreq. I think that's su= fficient treatment of non-repudiation for the PAR draft.=C2=A0
<= br>
=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. --0000000000003e1fc705aca12105-- From nobody Tue Aug 11 15:07:59 2020 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 AC3713A0D47 for ; Tue, 11 Aug 2020 15:07:57 -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 zJhNiq_mRpGB for ; Tue, 11 Aug 2020 15:07:56 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 2B95F3A0B34 for ; Tue, 11 Aug 2020 15:07:56 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id g75so129642wme.4 for ; Tue, 11 Aug 2020 15:07:56 -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=KJIDRryGeh5u8Nwu42nC/3xe881IqDGDl4+GAptlXqk=; b=Y48eI4iSP8haquvSWYxvp4J+26GfUg0DwPVonjq3d8sh5ZDivYbdeLRrYOGFpn2DRd WsR9YXlJNMe1aENWjJK6t8M5v6aOqbKFPty2Tm/i+JZabRtswX9zgBuDfTcTRSZjvPjM auj7HiGuNCOT8AofvfcmS0fAcCk9jQ4SjytgxUmr/WHJV8ODsSMPNr3+eni8nz8r0rR8 PlQijr81E5pFtWXgYYkfp3XL+6SDjuX+RqrGmM5+QbHUOOa3ETiAlp8Wdq0WQQ+b3X6v M9eBSUxGqv8iyDIWSbLQaLE+m+J7NulWS6ZKYQxa/F8AptuPxYWUboJcL/V/Q2mM3kC4 7/5A== 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=KJIDRryGeh5u8Nwu42nC/3xe881IqDGDl4+GAptlXqk=; b=s7IU7EHvcCH/ot+LoZzYG8WfZ+3U3Z9iCD0e/CPSqwoVFrfSVKHryZF2OnjH6h/ADb s0I7P+OA1+x4O/KebUN8fAo0OHpZY+OPb0dt6pf6fwyvdP/MYp5nBSnqJJL8NGcB50RR AMwbtDJFFjuoTLiPDzDGInEbbgdAmholhmMUFNHPfGMFt4CMoLShnuHIq6dwWGm3jbU+ u6WAdHyTH4nk7ZkPTxLk7KaT5mGgx6hgzlANrgFzfgfreE6XUECYe9L0W3chdxlDpUZr sCJg32fpQShSQ5/sEDG6lclsknh2S00r8nDW/3XcGHL05q0glYCL/kzBJvHT4LdVbCZb KDhg== X-Gm-Message-State: AOAM5333UldredaDvXsF3Vzw2ueHlnvgeU9+q8CEDvgyKNkXoWUDNItX GydgkWzX7cvEMLIIDXgBym/Vf+h8DnzGWYVkYXiQRyJe X-Google-Smtp-Source: ABdhPJxIsSEhRvCsbXbXYMiblFeG25lAYVq/UEAUzWFGlxKeriGk50UYLxJPXit15UaAmViBIFzQNS/vjDlZhDJmBBU= X-Received: by 2002:a1c:1f85:: with SMTP id f127mr6050709wmf.154.1597183674588; Tue, 11 Aug 2020 15:07:54 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Tue, 11 Aug 2020 18:07:43 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000909f2c05aca14d81" Archived-At: Subject: [OAUTH-WG] WGLC on Pushed Authorization Requests draft 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, 11 Aug 2020 22:07:58 -0000 --000000000000909f2c05aca14d81 Content-Type: text/plain; charset="UTF-8" All, This is a WGLC on the *Pushed Authorization Requests *document: https://www.ietf.org/id/draft-ietf-oauth-par-03.html Please, take a look and provide feedback on the list by *August 25th.* Regards, Rifaat & Hannes --000000000000909f2c05aca14d81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

This is a WGLC on the=C2=A0Push= ed Authorization Requests document:

Please, take a look and = provide feedback on the list by August 25th.

Regards,
=C2=A0Rifaat & Hannes

--000000000000909f2c05aca14d81-- From nobody Tue Aug 11 15:27:11 2020 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 2590B3A0D4F for ; Tue, 11 Aug 2020 15:27:09 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.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 xal-dOyDEIup for ; Tue, 11 Aug 2020 15:27:07 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 0737F3A0D58 for ; Tue, 11 Aug 2020 15:27:06 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id k8so173830wma.2 for ; Tue, 11 Aug 2020 15:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M5ArFy5n9N2Sal+AFtXBoQMjOYnrWgErfgCzBxH1juU=; b=DJqJHXSJFy0IsP8mPpRNSz/k3m+Va0bckJxWw8qE7pmoZJC3a8ZqZlcuj6l9tXn6Y4 i7O8XtUojXzeyXjM4s8PP1hPEzqnKua1HnrHQPtsAL+oEZH73z4CFVWhY5D1O2kVf/zm WkVHacc6wsjmtjXF5enlnpSeNzkT9WqFXYY64= 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=M5ArFy5n9N2Sal+AFtXBoQMjOYnrWgErfgCzBxH1juU=; b=O2UZBsWUBdPRgzrRlzLKj4TBWf9NEXAirGpeHrvROIbYipmLxGlnKh6vK75Egplyai yHSIyg71V3pplIrpZZLYohrt7XlTCbH+w6LPDDmaHoKyCBisL8hRcKuzduRN7qErxGhK kIZUjplrPSBXAq5WgjIr1IMI1U5KHPD5Qjd9X/MdIaa0XHo1cb3nR8cfluYzT0Me++oe o1vLeDXSRr+VkHf7WXsA3Z4cuMcEoKk8iFVKrh9z2j1Oa3uHMTvFfLTFFEe+oqRqGoYd tIFu7lgSg6LjSu+Gv1iiTNeOXq05VSsy4DLPTsZWKkbXlBx/MmacOMsCEuCSkDadNqSV hmQw== X-Gm-Message-State: AOAM531yMHQkeyVrCqkCoFgLFSZbci5wkTdqJo2eUopMQI8YyFuNIo5r cp+Npi4yJHSxDTxYeAW9J6yE4uACvbwwgUBC2D1jFjZmu0Q= X-Google-Smtp-Source: ABdhPJxf568tZn5eP3AHl98Z5nUAB9WjZ1oUHoQ0Cjif8YlpBu69aSFYrucD9lACTLCZz3sibeJT2R5p//C+1LnYU04= X-Received: by 2002:a7b:c3d4:: with SMTP id t20mr5641378wmj.8.1597184825249; Tue, 11 Aug 2020 15:27:05 -0700 (PDT) MIME-Version: 1.0 References: <159620115034.32558.6249632084531225541@ietfa.amsl.com> In-Reply-To: From: Francis Pouatcha Date: Tue, 11 Aug 2020 18:26:54 -0400 Message-ID: To: Brian Campbell Cc: OAuth WG Content-Type: multipart/alternative; boundary="00000000000026657e05aca192cc" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-03.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, 11 Aug 2020 22:27:09 -0000 --00000000000026657e05aca192cc Content-Type: text/plain; charset="UTF-8" Hello Brian, On Tue, Aug 11, 2020 at 5:55 PM Brian Campbell wrote: > Hi Francis, > > My apologies for the tardy response to this - I was away for some time on > holiday. But thank you for the review and feedback on the draft. I've tried > to respond inline below. > > > On Fri, Jul 31, 2020 at 5:01 PM Francis Pouatcha 40adorsys.de@dmarc.ietf.org> wrote: > >> Bellow is the only remark I found from reviewing the draft draft: >> >> 2.1. Request: >> >> requires the parameters "code_challenge" and "code_challenge_method" but >> >> https://openid.net/specs/openid-financial-api-part-2-ID2.html#confidential-client mentions >> that RFC7636 is not required for confidential clients. I guess those two >> parameters have to be taken off the mandatory list and pushed to the list >> below. >> > > The list of parameters in Section 2.1 is qualified with a "basic parameter > set will typically include" and is definitely not intended to convey a set > of required parameters. It's just a list of parameters that make up a > hypothetical typical request. Perhaps some text in the section or even the > formatting needs to be adjusted so as to (hopefully) avoid any confusion > like this that the list somehow conveys normative requirements? > > > >> - Using jwsreq, non repudiation is provided as request is signed (jws). >> This section also mentions that the request can be sent as form url >> encoded (x-www-form-urlencoded). In this case, there is no way >> to provide non repudiation unless we mention that request can be signed by >> client using signature methods declared by the AS (AS metadata). >> > > I am not aware of any signature methods or means of an AS declaring > support for a signature method in metadata that are sufficiently > standardized to be mentioned in the context of this draft. The "request" > parameter https://tools.ietf.org/html/draft-ietf-oauth-par-03#section-3 > can be sent to the PAR endpoint and should provide the same notation of > non-repudiation as does jwsreq. I think that's sufficient treatment of > non-repudiation for the PAR draft. > This is the case when PAR uses "Content-type: application/oauth.authz.req+jwt". This is fine as the jws form param is signed. This is also equivalent to jwsreq in matter of providing non repudiation. Content-Type: application/x-www-form-urlencoded ... request=eyJraWQiOiJrMmJ.....3Gkk488RQohhgt1I0onw This is not equivalent to jwsreq. As request body is not signed. This does not provide non repudiation. Content-Type: application/x-www-form-urlencoded ... response_type=code& state=af0ifjsldkj It is worth mentioning this in the draft Best regards /Francis -- Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --00000000000026657e05aca192cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Brian,

On Tue, Aug 11, 2020 at 5:55 = PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Hi Francis,

My apologies for the tar= dy response to this - I was away for some time on holiday. But thank you fo= r the review and feedback on the draft. I've tried to respond inline be= low.


On Fri, Jul 31, 2= 020 at 5:01 PM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:<= br>
Bellow is the only remark I found from reviewing the draft draft:

2.1.=C2=A0 Request:=C2=A0

re= quires the parameters "code_challenge" and "code_challenge_method" but
https://openid.net/specs/openid-fina= ncial-api-part-2-ID2.html#confidential-client=C2=A0mentions that=C2=A0<= span style=3D"color:rgb(0,0,0);font-family:verdana,charcoal,helvetica,arial= ,sans-serif">RFC7636 is not required for confidential clients. I guess thos= e two parameters have to be taken off the mandatory list and pushed to the = list below.

The list of = parameters in Section 2.1 is qualified with a "basic parameter set wil= l typically include" and is definitely not intended to convey a set of= required parameters. It's just a list of parameters that make up a hyp= othetical typical request.=C2=A0 Perhaps some text in the section or even t= he formatting needs to be adjusted so as to (hopefully) avoid any confusion= like this that the list somehow conveys normative requirements?
<= div>
=C2=A0
- Using jwsreq, non repudiation is provid= ed as request is signed (jws). This section also mentions that the request = can be sent as form url=C2=A0 encoded (x-www-form-urlencoded). In th= is case, there is no way to=C2=A0provide non repudiation unless we mention = that request can be signed by client using signature methods declared by th= e AS (AS metadata).

=C2= =A0I am not aware of any signature methods or means of an AS declaring sup= port for a signature method in metadata that are sufficiently standardized = to be mentioned in the context of this draft. The "request" param= eter https://tools.ietf.org/html/draft-ietf-oauth-par-03#s= ection-3 can be sent to the PAR endpoint and should provide the same no= tation of non-repudiation as does jwsreq. I think that's sufficient tre= atment of non-repudiation for the PAR draft.=C2=A0
<= /blockquote>
This is the case when PAR uses &q= uot;Content-type: application/oauth.authz.= req+jwt".

This is fine as the jws form param is sig= ned. This is also equivalent to jwsreq in matter of providing non repudiati= on.
Content-Type: a=
pplication/x-www-form-urlencoded
...
request=3DeyJraWQiOiJrMm=
J.....3Gkk488RQohhgt1I0onw

Thi=
s is not equivalent to jwsreq. As request body is not signed. This does not=
 provide non repudiation.
Content-Type: application/x-w=
ww-form-urlencoded
...
response=
_type=3Dcode&
state=3Daf0ifjsldkj
=
It is worth ment= ioning this in the draft
Best regards
/Francis

--
Francis Pouatcha
Co-Founder and= Technical Lead
adorsys GmbH & Co. KG
--00000000000026657e05aca192cc-- From nobody Wed Aug 12 00:56:32 2020 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 02D123A0D0F; Wed, 12 Aug 2020 00:56:26 -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-jwsreq@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Hannes.Tschofenig@gmx.net X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <159721898593.8472.15430392178541116697@ietfa.amsl.com> Date: Wed, 12 Aug 2020 00:56:25 -0700 Archived-At: Subject: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-jwsreq-26: (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, 12 Aug 2020 07:56:26 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-oauth-jwsreq-26: 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The directorate reviews are from 15 or more versions ago. I wonder if returning documents like this should be sent through the directorates again as matter of course. Abstract: "... the communication through the user agents are not ..." -- s/are/is/ Section 1 expressly cites two IANA URLs. I suggest simply naming the registry or sub-registry; the URLs might not be permanent. Or if you like the URL, do it as a reference, as you did with [IANA.MediaType]. The two bullets at the end of Section 1 toggle between "crypto" and "cryptography". I suggest picking one, preferably the latter (as did the rest of the document). In Section 3, should URI and URL include references to their defining RFCs? I realize a reader familiar with this space probably knows those terms, but they seem to be the only acronyms without a reference here. When would an implementer legitimately disregard the SHOULD in Section 4? As Benjamin Kaduk also expressed, I'm a little puzzled by this text in Section 5.2: "The "request_uri" value MUST be reachable by the Authorization Server." Is this part of the protocol? All of the subsections of Section 9 say: "This specification adds the following values to the "OAuth Parameters" registry established ..." but they all are actually modifying different sub-registries. I suggest naming the sub-registries explicitly. I realize the subsection titles have it right, but this line of repeated prose had me squinting a bit. From nobody Wed Aug 12 10:03:17 2020 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 A22FF3A0039 for ; Wed, 12 Aug 2020 10:03:15 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=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=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 aqXLtK8CLb5Q for ; Wed, 12 Aug 2020 10:03:10 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 2117B3A0317 for ; Wed, 12 Aug 2020 10:03:09 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id t6so3037860ljk.9 for ; Wed, 12 Aug 2020 10:03: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=e9i42gq+AGRw5/LxQs/MtNc3ufBqQAZOIrv8rADFiQ0=; b=BESf8aV8c9fuN7VK3+dMwri/v+fVPLU58ng81w6blUUe5j/kZHWx5dZVix6qzCeA5p RqIOXmGn8ncz/eErlPxdDwdy5TMK1DJTxsqVKFQFeJeNsrTE9MTuXf2JnXOnSCjMciLk G4KQLZL0J2LSMm/4f9OHQ4V5bdR3k+4vi74ZRF5GhNkXy5aOJ8Ys3zDshLiqjOYOe8Jj KiKVVLY79H3V4VQD0HsshC0nXHI2HqdW83ECKjH2nUcfDj0zOGMSTHQRh01n4Sug+nFt v9DX8Z2eZ5diOc6iB3QdclmgxHvFRVudT2lC9Gw1+ywfGV8rhYanCH94XjDfnmzzru7B NiUA== 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=e9i42gq+AGRw5/LxQs/MtNc3ufBqQAZOIrv8rADFiQ0=; b=ITUP0CbmWHx5aCt6cFyThKhBAs+OL4Aed8FTMVIAGW5VpgaDvg4PUjzubft29NQCpC OKNqeuOZ16bAn+QH4BFJiVmiLO8JaeMoyW+h8ZXCu4ZahG6ynWp9pd0dcERqjUcq2IFc vcZ8N17qQ0wM46CUin6ZFdrFH0IpXRgXf2PPtzVg0LIrbAOC6pNbtk0Ml4uH7D+FNf8t +i0foUIZxpHx60Z82FXf8i2HCWX1XMtNIXO/hohv/dDPxOr60CxCZ54fvfvtEXaziA7L S5bavoLScMEVVw0iYpFUEM3jVD5i+lNNaofZdD3X1y9+/ttw6QbeaSMFRsjNSVhdjPRl Ifiw== X-Gm-Message-State: AOAM5316r1gCVPqTZXmirlNe3YaUVSRmy1dMISLt/kGKWG57EhJlHE1d AB3LMh9/YFAIqgYp1uVAxDS22xMuTbYbiWkD00AOu8WZtUd0r0xTGJC+IQWVnelIeOyhWd97gIO /hnB42Xk8/MGDfPISLjo= X-Google-Smtp-Source: ABdhPJwKf84WZVhA+ipo9f17y78zrscnEp9q4XLFlisPvHzGn33JRu1q4MrjhWL6r3xoEUJdvw3CQcwoTn4G1TdXmJ4= X-Received: by 2002:a05:651c:153:: with SMTP id c19mr97939ljd.170.1597251787865; Wed, 12 Aug 2020 10:03:07 -0700 (PDT) MIME-Version: 1.0 References: <159620115034.32558.6249632084531225541@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Wed, 12 Aug 2020 11:02:41 -0600 Message-ID: To: Francis Pouatcha Cc: OAuth WG Content-Type: multipart/alternative; boundary="0000000000006edf7605acb12938" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-03.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: Wed, 12 Aug 2020 17:03:16 -0000 --0000000000006edf7605acb12938 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm honestly having a hard time following what you are asking for. But there is already the following text in sec 1 that mentions non-repudiation via JWT-based request objects and by implication the basic request method does not provide non-repudiation. The pushed authorization request endpoint fosters OAuth security by providing all clients a simple means for a confidential and integrity protected authorization request, but it also allows clients requiring an even higher security level, especially cryptographically confirmed non-repudiation, to explicitly adopt JWT-based request objects. On Tue, Aug 11, 2020 at 4:27 PM Francis Pouatcha wrote: > Hello Brian, > > On Tue, Aug 11, 2020 at 5:55 PM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> Hi Francis, >> >> My apologies for the tardy response to this - I was away for some time o= n >> holiday. But thank you for the review and feedback on the draft. I've tr= ied >> to respond inline below. >> >> >> On Fri, Jul 31, 2020 at 5:01 PM Francis Pouatcha > 40adorsys.de@dmarc.ietf.org> wrote: >> >>> Bellow is the only remark I found from reviewing the draft draft: >>> >>> 2.1. Request: >>> >>> requires the parameters "code_challenge" and "code_challenge_method" bu= t >>> >>> https://openid.net/specs/openid-financial-api-part-2-ID2.html#confident= ial-client mentions >>> that RFC7636 is not required for confidential clients. I guess those >>> two parameters have to be taken off the mandatory list and pushed to th= e >>> list below. >>> >> >> The list of parameters in Section 2.1 is qualified with a "basic >> parameter set will typically include" and is definitely not intended to >> convey a set of required parameters. It's just a list of parameters that >> make up a hypothetical typical request. Perhaps some text in the sectio= n >> or even the formatting needs to be adjusted so as to (hopefully) avoid a= ny >> confusion like this that the list somehow conveys normative requirements= ? >> >> >> >>> - Using jwsreq, non repudiation is provided as request is signed (jws). >>> This section also mentions that the request can be sent as form url >>> encoded (x-www-form-urlencoded). In this case, there is no way >>> to provide non repudiation unless we mention that request can be signed= by >>> client using signature methods declared by the AS (AS metadata). >>> >> >> I am not aware of any signature methods or means of an AS declaring >> support for a signature method in metadata that are sufficiently >> standardized to be mentioned in the context of this draft. The "request" >> parameter https://tools.ietf.org/html/draft-ietf-oauth-par-03#section-3 >> can be sent to the PAR endpoint and should provide the same notation of >> non-repudiation as does jwsreq. I think that's sufficient treatment of >> non-repudiation for the PAR draft. >> > This is the case when PAR uses "Content-type: > application/oauth.authz.req+jwt". > > This is fine as the jws form param is signed. This is also equivalent to > jwsreq in matter of providing non repudiation. > > Content-Type: application/x-www-form-urlencoded > > ... > > request=3DeyJraWQiOiJrMmJ.....3Gkk488RQohhgt1I0onw > > > This is not equivalent to jwsreq. As request body is not signed. This doe= s not provide non repudiation. > > Content-Type: application/x-www-form-urlencoded > > ... > > response_type=3Dcode& > state=3Daf0ifjsldkj > > > It is worth mentioning this in the draft > Best regards > /Francis > > -- > Francis Pouatcha > Co-Founder and Technical Lead > adorsys GmbH & Co. KG > https://adorsys-platform.de/solutions/ > --=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._ --0000000000006edf7605acb12938 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm honestly having a hard time following what yo= u are asking for. But there is already the following text in sec 1 that men= tions non-repudiation via JWT-based request objects and by implication the = basic request method does not provide non-repudiation.

<= /div>
   The pushed authorization request endpoint fosters OAuth s=
ecurity by
   providing all clients a simple means for a confidential and integrity
   protected authorization request, but it also allows clients requiring
   an even higher security level, especially cryptographically confirmed
   non-repudiation, to explicitly adopt JWT-based request objects.

On Tue, Aug 11, 2020 at 4:27 PM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf= .org> wrote:
Hello Brian,

On Tue, Aug 11, 2020 at 5= :55 PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>= wrote:
Hi Francis,

My= apologies for the tardy response to this - I was away for some time on hol= iday. But thank you for the review and feedback on the draft. I've trie= d to respond inline below.


On Fri, Jul 31, 2020 at 5:01 PM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ie= tf.org> wrote:
Bellow is the only remark I found from reviewin= g the draft draft:

2.1.=C2=A0 Request:=C2=A0
=

requires the parameters "code_challenge" and "code_challenge_method" b= ut
https://openid= .net/specs/openid-financial-api-part-2-ID2.html#confidential-client=C2= =A0mentions that=C2=A0RFC7636 is not required for confidentia= l clients. I guess those two parameters have to be taken off the mandatory = list and pushed to the list below.

=
The list of parameters in Section 2.1 is qualified with a "= basic parameter set will typically include" and is definitely not inte= nded to convey a set of required parameters. It's just a list of parame= ters that make up a hypothetical typical request.=C2=A0 Perhaps some text i= n the section or even the formatting needs to be adjusted so as to (hopeful= ly) avoid any confusion like this that the list somehow conveys normative r= equirements?

=C2=A0
- Using jwsreq, no= n repudiation is provided as request is signed (jws). This section also men= tions that the request can be sent as form url=C2=A0 encoded (x-www-form-urlencoded). In this case, there is no way to=C2=A0provide non repudia= tion unless we mention that request can be signed by client using signature= methods declared by the AS (AS metadata).
<= div>
=C2=A0I am not aware of any signature methods or means = of an AS declaring support for a signature method in metadata that are suff= iciently standardized to be mentioned in the context of this draft. The &qu= ot;request" parameter https://tools.ietf.org/html/dra= ft-ietf-oauth-par-03#section-3 can be sent to the PAR endpoint and shou= ld provide the same notation of non-repudiation as does jwsreq. I think tha= t's sufficient treatment of non-repudiation for the PAR draft.=C2=A0
This is the= case when PAR uses "Content-type: ap= plication/oauth.authz.req+jwt".

This is fine as the= jws form param is signed. This is also equivalent to jwsreq in matter of p= roviding non repudiation.
Content-Type: app=
lication/x-www-form-urlencoded
...
request=3DeyJraWQiOiJrM=
mJ.....3Gkk488RQohhgt1I0onw

This is not equivalent to jwsreq. As request body =
is not signed. This does not provide non repudiation.
Content-Type: application=
/x-www-form-urlencoded
...
response_type=3Dcode&
state=3Daf0ifjsldkj
=
It is worth ment= ioning this in the draft
Best regards
/Francis

--
=
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG

<= 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. --0000000000006edf7605acb12938-- From nobody Wed Aug 12 10:43:02 2020 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 C759C3A1168 for ; Wed, 12 Aug 2020 10:43:00 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.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 VgZbOQJH2_ED for ; Wed, 12 Aug 2020 10:42:58 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 716AA3A113E for ; Wed, 12 Aug 2020 10:42:58 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id f1so2858279wro.2 for ; Wed, 12 Aug 2020 10:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9lSZhmVvbZFQ0JFGH1qAy19aaezaoAC/1skwq3QhjQ8=; b=QXDLIKEZc5e3Yvx3WYjZWwI84knf7NtTVszPHoJckDry1qbdF4n2yWJuK19V4dwz77 YuLKjIEmFdryg0KYasLV9P+JPhGhdukGUCwx8+pz4nMseAjJw5QGgg2rs2tOBykScZx9 u1g1lTTZMODc8E+rTge9i/yUX3b7jk2oxISic= 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=9lSZhmVvbZFQ0JFGH1qAy19aaezaoAC/1skwq3QhjQ8=; b=KHLHLUX+iO4V1H4IwcL5bLO/kBjLGT6y1fVURXzCjkYCMsk6QW/CHhq9VJW6zji+Jk IQ0lmOyr6TNu2KgAsaIAC6f+jJiQLBmNvu51LlYQBTgAhhl2wzop94VQ/6PhNYq4azO0 KDV0+BoFo1Avmy3WtEfon6KeulPm01pvmY1uvyMrgESa7VNLRhUWscs3xDViDQLjwowd RHFpF6wN5iBcHBReTIe9CNeqLC7sSabqTDLsyDbhkPcJtBMDY7TdMj1s9qb7tr+Qsoy5 XIjETt0gk9qlSDa303E2yBE8WPqXlmKJBp2T1hVTewInvFWtbWLlGD51A9wbPAPgj6Bg cc2Q== X-Gm-Message-State: AOAM530YSiOKNoP1aaPfHxozgIqG6C7HNp8sbSIxZxf7XkCJacr+QMr0 5vqd+BujkY+HgkrKs563F8vMyUbze36T4UEMwiQouw== X-Google-Smtp-Source: ABdhPJyFA7XLX6a5cG/pu2h1Y8NMBgqOX/BtyS0A9YugUnoBD83b5S5LJjQOR5tvSUWeSZD8VXgdIZq97XkP7E95tzc= X-Received: by 2002:a5d:51c3:: with SMTP id n3mr344431wrv.104.1597254176514; Wed, 12 Aug 2020 10:42:56 -0700 (PDT) MIME-Version: 1.0 References: <159620115034.32558.6249632084531225541@ietfa.amsl.com> In-Reply-To: From: Francis Pouatcha Date: Wed, 12 Aug 2020 13:42:45 -0400 Message-ID: To: Brian Campbell Cc: OAuth WG Content-Type: multipart/alternative; boundary="000000000000cebee505acb1b757" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-03.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: Wed, 12 Aug 2020 17:43:01 -0000 --000000000000cebee505acb1b757 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 12, 2020 at 1:03 PM Brian Campbell wrote: > I'm honestly having a hard time following what you are asking for. But > there is already the following text in sec 1 that mentions non-repudiation > via JWT-based request objects and by implication the basic request method > does not provide non-repudiation. > > The pushed authorization request endpoint fosters OAuth security by > providing all clients a simple means for a confidential and integrity > protected authorization request, but it also allows clients requiring > an even higher security level, especially cryptographically confirmed > non-repudiation, to explicitly adopt JWT-based request objects. > > This is what I am looking for. I did oversee this block? Thanks. /Francis > > On Tue, Aug 11, 2020 at 4:27 PM Francis Pouatcha 40adorsys.de@dmarc.ietf..org <40adorsys.de@dmarc.ietf.org>> wrote: > >> Hello Brian, >> >> On Tue, Aug 11, 2020 at 5:55 PM Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote: >> >>> Hi Francis, >>> >>> My apologies for the tardy response to this - I was away for some time >>> on holiday. But thank you for the review and feedback on the draft. I've >>> tried to respond inline below. >>> >>> >>> On Fri, Jul 31, 2020 at 5:01 PM Francis Pouatcha >> 40adorsys.de@dmarc.ietf.org> wrote: >>> >>>> Bellow is the only remark I found from reviewing the draft draft: >>>> >>>> 2.1. Request: >>>> >>>> requires the parameters "code_challenge" and "code_challenge_method" >>>> but >>>> >>>> https://openid..net/specs/openid-financial-api-part-2-ID2.html#confidential-client >>>> mentions >>>> that RFC7636 is not required for confidential clients. I guess those >>>> two parameters have to be taken off the mandatory list and pushed to the >>>> list below. >>>> >>> >>> The list of parameters in Section 2.1 is qualified with a "basic >>> parameter set will typically include" and is definitely not intended to >>> convey a set of required parameters. It's just a list of parameters that >>> make up a hypothetical typical request. Perhaps some text in the section >>> or even the formatting needs to be adjusted so as to (hopefully) avoid any >>> confusion like this that the list somehow conveys normative requirements? >>> >>> >>> >>>> - Using jwsreq, non repudiation is provided as request is signed (jws). >>>> This section also mentions that the request can be sent as form url >>>> encoded (x-www-form-urlencoded). In this case, there is no way >>>> to provide non repudiation unless we mention that request can be signed by >>>> client using signature methods declared by the AS (AS metadata). >>>> >>> >>> I am not aware of any signature methods or means of an AS declaring >>> support for a signature method in metadata that are sufficiently >>> standardized to be mentioned in the context of this draft. The "request" >>> parameter https://tools.ietf.org/html/draft-ietf-oauth-par-03#section-3 >>> can be sent to the PAR endpoint and should provide the same notation of >>> non-repudiation as does jwsreq. I think that's sufficient treatment of >>> non-repudiation for the PAR draft. >>> >> This is the case when PAR uses "Content-type: >> application/oauth.authz.req+jwt". >> >> This is fine as the jws form param is signed. This is also equivalent to >> jwsreq in matter of providing non repudiation. >> >> Content-Type: application/x-www-form-urlencoded >> >> ... >> >> request=eyJraWQiOiJrMmJ.....3Gkk488RQohhgt1I0onw >> >> >> This is not equivalent to jwsreq. As request body is not signed. This does not provide non repudiation. >> >> Content-Type: application/x-www-form-urlencoded >> >> ... >> >> response_type=code& >> state=af0ifjsldkj >> >> >> It is worth mentioning this in the draft >> Best regards >> /Francis >> >> -- >> Francis Pouatcha >> Co-Founder and Technical Lead >> adorsys GmbH & Co. KG >> https://adorsys-platform.de/solutions/ >> > > *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.* -- Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --000000000000cebee505acb1b757 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 12, 2020 at 1:03 PM Brian Cam= pbell <bcampbell=3D= 40pingidentity.com@dmarc.ietf.org> wrote:
I'm honestly having a hard time following what you are asking fo= r. But there is already the following text in sec 1 that mentions non-repud= iation via JWT-based request objects and by implication the basic request m= ethod does not provide non-repudiation. 

=
   The pushed authorization request endpoint fosters OAuth security by
   providing all clients a simple means for a confidential and integrity
   protected authorization request, but it also allows clients requiring
   an even higher security level, especially cryptographically confirmed
   non-repudiation, to explicitly adopt JWT-based request objects.
This is what I=C2=A0am looking=C2=A0for. I did o= versee this block? Thanks.
/Francis=C2=A0

On Tue, Aug 11, 2020 at 4:27 PM Francis Pouatcha= <fpo=3D40adorsys.de@dmarc.ietf..org> wrote:
Hello Brian,=

= On Tue, Aug 11, 2020 at 5:55 PM Brian Campbell <bcampbell=3D40pingidentity.c= om@dmarc.ietf.org> wrote:
Hi Francis,

My apologies for the tardy response to this - I was = away for some time on holiday. But thank you for the review and feedback on= the draft. I've tried to respond inline below.


On Fri, Jul 31, 2020 at 5:01 PM Francis Pouat= cha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:
Bellow is the only r= emark I found from reviewing the draft draft:

2.1.= =C2=A0 Request:=C2=A0

requires the parameters &quo= t;code_challenge"= ; and "co= de_challenge_method" but
https://openid..net/specs/openid-financial-api-part-2-ID2.html= #confidential-client=C2=A0mentions that=C2=A0RFC7636 is n= ot required for confidential clients. I guess those two parameters have to = be taken off the mandatory list and pushed to the list below.
<= /div>

The list of parameters in Section 2.1= is qualified with a "basic parameter set will typically include"= and is definitely not intended to convey a set of required parameters. It&= #39;s just a list of parameters that make up a hypothetical typical request= .=C2=A0 Perhaps some text in the section or even the formatting needs to be= adjusted so as to (hopefully) avoid any confusion like this that the list = somehow conveys normative requirements?

=C2=A0=
- Using jwsreq, non repudiation is provided as request is signed (= jws). This section also mentions that the request can be sent as form url= =C2=A0 encoded (x-www-form-urlencoded). In this case, there is no wa= y to=C2=A0provide non repudiation unless we mention that request can be sig= ned by client using signature methods declared by the AS (AS metadata).

=C2=A0I am not aware of any= signature methods or means of an AS declaring support for a signature met= hod in metadata that are sufficiently standardized to be mentioned in the c= ontext of this draft. The "request" parameter ht= tps://tools.ietf.org/html/draft-ietf-oauth-par-03#section-3 can be sent= to the PAR endpoint and should provide the same notation of non-repudiatio= n as does jwsreq. I think that's sufficient treatment of non-repudiatio= n for the PAR draft.=C2=A0
This is the case when PAR uses "Content-type: application/oauth.authz.req+jwt".
This is fine as the jws form param is signed. This is also equiva= lent to jwsreq in matter of providing non repudiation.
<= div>
Content-Type: application/x-www-form-urlencoded
..=
.
request=3DeyJraWQiOiJrMmJ.....3Gkk488RQohhgt1I0onw

This is not equival=
ent to jwsreq. As request body is not signed. This does not provide non rep=
udiation.
Content-Type: application/x-www-form-urlencoded
...
response_type=3Dcod=
e&
state=3Daf0ifjsldkj
=
It is worth ment= ioning this in the draft
Best regards
/Francis

--
=
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG

<= 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 th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you.


--
Francis Pouatcha
Co-Founder and Technical L= ead
adorsys GmbH & Co. KG
--000000000000cebee505acb1b757-- From nobody Wed Aug 12 11:53:35 2020 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 741063A07D4; Wed, 12 Aug 2020 11:53:26 -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-jwsreq@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Hannes.Tschofenig@gmx.net X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <159725840640.26497.2671991928381311278@ietfa.amsl.com> Date: Wed, 12 Aug 2020 11:53:26 -0700 Archived-At: Subject: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-jwsreq-26: (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, 12 Aug 2020 18:53:27 -0000 Robert Wilton has entered the following ballot position for draft-ietf-oauth-jwsreq-26: 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Only one minor comment: I liked the reference to max URL size for older versions of Internet Explorer, but wonder if that is still really relevant in 2020? Or perhaps it could now be removed? Regards, Rob From nobody Wed Aug 12 17:07:53 2020 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 0FD7C3A0DF9 for ; Wed, 12 Aug 2020 17:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=authlete-com.20150623.gappssmtp.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 bwoBugYI_GJR for ; Wed, 12 Aug 2020 17:07:50 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 35CB83A0E47 for ; Wed, 12 Aug 2020 17:07:50 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id r4so3606762wrx.9 for ; Wed, 12 Aug 2020 17:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=SgDeCLA7Np4zNueUHZdcyM76QsoPkq+ApsRC/CedlDM=; b=JpOeA0O5YavbslOZFbDWfUSXm6xnGH4EvPyyYuu6TUPc97cVRw99WJFZqSYE6UAi/t lVVUSxNtduvhOzHF3NT0XiWPgby93YMs6a8qfGPDEXgYKLSuhA8RVLw9kTgkcWsiUUjf sIKp1eUFRAcOSyTEn/J3gVolPsnqEyHOg6T6obv5XrkFHqWbUQ4jZJ7drYd2+5qL/iWp DccKRBR7FJQ7R+mQhI/Ja29nHckMuqfNjx2O7hw4v7C2v7dP9kolaBZx4QJufW3/r76T umCK6cS+7SP4xquTGDXEvHOPsSRoEyIEYRhoFjACAAu4d14B3Xnczz8HH4DAeUxq3bTq GvlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=SgDeCLA7Np4zNueUHZdcyM76QsoPkq+ApsRC/CedlDM=; b=p2JzXynMVWA9h7wQJ/r03S7lKDB9QWJvY+vzmO0nAsOBbF0n4OVHQDOYei9xDuvkii GzEmFO+KuozQNxKXt5z/fE3x5/wRHxy3GUrP4fuiUkjSYJaVWDmRgD4HC4FuTEMB2UJG svuKtudI41O63sGHM+BBOq9ZwD2WEWccxlPehtyWGBrqG9+7ClnSdRFlQtDFfwMQRWhM KS+c+LFbIKGDR+eyay1a7NGt0cOV96LUAI/kEqgPnUZfvrPaMVw4I7e6464f2zr4ZOqZ WI3DikUhq+4p/voomkctMCGOgNlGIXLZIZQlsVYdGdfmZ+S+5w7ux/QP8s+RHEgGISPA /GRw== X-Gm-Message-State: AOAM533nRDliGyggV5F5MEN6pGzveSdDg+8P5WfXN+Firqv5uA59Nzxk DeIiS7BzzATtZW2kozJVQh2JWzYCKvkJaA== X-Google-Smtp-Source: ABdhPJxWhowwWbQe4B+crvvIaKD6hdkbwQ2USKLtfiwV2OQiY/Tb0Md4IukLZXFHAJuLXP18j+oGNw== X-Received: by 2002:a5d:5641:: with SMTP id j1mr1357549wrw.399.1597277268299; Wed, 12 Aug 2020 17:07:48 -0700 (PDT) Received: from [192.168.1.112] (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id x2sm7492515wrg.73.2020.08.12.17.07.47 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Aug 2020 17:07:47 -0700 (PDT) From: Joseph Heenan Content-Type: multipart/alternative; boundary="Apple-Mail=_D34D71AA-7415-4885-8E03-DC45E2FB3DED" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 13 Aug 2020 01:07:47 +0100 References: To: oauth In-Reply-To: Message-Id: <334EDEFB-AE33-4A19-9F2F-4C8158597C5C@authlete.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] WGLC on Pushed Authorization Requests draft 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, 13 Aug 2020 00:07:52 -0000 --Apple-Mail=_D34D71AA-7415-4885-8E03-DC45E2FB3DED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Rifaat, Hannes, and also thanks to all the authors. I=E2=80=99ve been through the latest spec and it basically looks great = to me; I raised 3 minor niggles under = https://github.com/oauthstuff/draft-oauth-par/issues = https://github.com/oauthstuff/draft-oauth-par/issues/59 = - possible = ambiguity in the text around error responses from new endpoint https://github.com/oauthstuff/draft-oauth-par/issues/62 = & = https://github.com/oauthstuff/draft-oauth-par/issues/63 = - minor = typographical points For info, Authlete has at least one deployed implementation of this = spec. Authlete has also assisted in getting tests for PAR added to the Open ID = Foundation FAPI Certification test suite for Authorization Servers, and = (although there=E2=80=99s still a few niggles in the tests to work out) = the tests seem to interoperate with Authlete, Filip=E2=80=99s = node-oidc-provider and a Ping implementation fine. (Many thanks to Filip = & Ping for testing them! If anyone else would like to try them please = let me know.) Thanks Joseph >=20 > On 11 Aug 2020, at 23:07, Rifaat Shekh-Yusef = wrote: >=20 > All, >=20 > This is a WGLC on the Pushed Authorization Requests document: > https://www.ietf.org/id/draft-ietf-oauth-par-03.html = >=20 > Please, take a look and provide feedback on the list by August 25th. >=20 > Regards, > Rifaat & Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_D34D71AA-7415-4885-8E03-DC45E2FB3DED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Rifaat, Hannes, and also thanks to all the = authors.

I=E2=80=99ve = been through the latest spec and it basically looks great to me; I = raised 3 minor niggles under https://github.com/oauthstuff/draft-oauth-par/issues
<= div class=3D"">
https://github.com/oauthstuff/draft-oauth-par/issues/59&nbs= p;- possible ambiguity in the text around error responses from new = endpoint

https://github.com/oauthstuff/draft-oauth-par/issues/62&nbs= p;& https://github.com/oauthstuff/draft-oauth-par/issues/63&nbs= p;- minor typographical points


For info, Authlete has = at least one deployed implementation of this spec.

Authlete has also assisted in getting tests for = PAR added to the Open ID Foundation FAPI Certification test suite for = Authorization Servers, and (although there=E2=80=99s still a few niggles = in the tests to work out) the tests seem to interoperate with Authlete, = Filip=E2=80=99s node-oidc-provider and a Ping implementation fine. (Many = thanks to Filip & Ping for testing them! If anyone else would like = to try them please let me know.)

Thanks

Joseph


On 11 Aug 2020, at 23:07, Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:

All,

This = is a WGLC on the Pushed Authorization Requests = document:
https://www.ietf.org/id/draft-ietf-oauth-par-03.html

Please, take a look and provide feedback on the list by August 25th.

Regards,
 Rifaat & = Hannes

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

= --Apple-Mail=_D34D71AA-7415-4885-8E03-DC45E2FB3DED-- From nobody Thu Aug 13 06:43:40 2020 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 0D0073A0C3E; Thu, 13 Aug 2020 06:43: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, 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 kgiQjh7uUA3e; Thu, 13 Aug 2020 06:43:32 -0700 (PDT) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 8F7B63A0C3C; Thu, 13 Aug 2020 06:43:32 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id f12so5306992wru.13; Thu, 13 Aug 2020 06:43:32 -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=KxZ8Ii9tfwQJ7LpIa9Zc2eocVKRCVElXETA2jpQ/99s=; b=BHjJzuw0gRHdZe1eEVx04sJ8RZhxXXqMxUPjZYbtsGy3JfIuJBx1Zpz1G2afrLFcg+ 65RixP/O/R+tDuEgp+voLNQCxRAnfrnu4aWv9lduYcoTMd/wfLqvxrrm80qrfkp1yHrJ n0hsikC9wZcpVXq+CKwJHb1iOerLMZMzB9ruP1IxNKLvrrbVHybgEyEcdxDNILp6Vr5p nNJKN6FQ9pufGzF10Uksk+T44Q1DUe2Ta4XTkT4UZGnkoXY+Ymh8j4iIHhem2eNfQqrq X6acU5BZKmXM3Iw3tMDROKua9HQLFWDcZA6P+Cfor2HzIWmT/tS/wFWGkMURvytHUiin 81pQ== 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=KxZ8Ii9tfwQJ7LpIa9Zc2eocVKRCVElXETA2jpQ/99s=; b=RpsUHOMk9iC5fl6bwNv/6udjgasaey8sylgOokgFpzdIljEWUI6fSKFTSwnGX00oSP KeNwV18MW1woyFFJF6LARWeP4iL8GzMZSpqvu1sS/2tnatdUtvfPCJ5Xa4NjlTS3pn9x dGTWFl1n8Kaymo/0ivWV1dA9AvFUhYPPfjN9Yp4LVANZNoG9dNvahrKfcYbW9kfrY2CS W20uhwGm8ZBVTGoPOYy64kKJfEgWBRZzU3BWpfgQP3ZBMAOFPh952Msv9IixPY9r8AFl Wl4n9RIbt0+LRAqPXSP6D1om8nA5cpRhR1G5eHRP5T4zijNZk2JP5mD4ydgQgECz82TK f8IA== X-Gm-Message-State: AOAM530gUFf3AZ8UT7tkTK3nk4TA3cSxeEm4ahLJqN2wbf1UkQClprDk TdNITn/ivLb3XLgnjgtF5z/cHKS+AXuCIiaFyTc= X-Google-Smtp-Source: ABdhPJwrf98kZS6nssN3L377SQXpWRu+lzbGygC5aGIvka6eTcN7p0E+ci4MLFU17+I+mkwPQj+7pZhBbXdxbGebM5k= X-Received: by 2002:adf:ec8b:: with SMTP id z11mr4039400wrn.51.1597326210804; Thu, 13 Aug 2020 06:43:30 -0700 (PDT) MIME-Version: 1.0 References: <159661722741.30500.10022053097818080667@ietfa.amsl.com> In-Reply-To: <159661722741.30500.10022053097818080667@ietfa.amsl.com> From: Nat Sakimura Date: Thu, 13 Aug 2020 22:43:19 +0900 Message-ID: To: =?UTF-8?B?w4lyaWMgVnluY2tl?= Cc: The IESG , oauth , oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org Content-Type: multipart/alternative; boundary="00000000000062b39505acc27d2d" Archived-At: Subject: Re: [OAUTH-WG] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-oauth-jwsreq-26=3A_=28with_COMMENT=29?= 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, 13 Aug 2020 13:43:35 -0000 --00000000000062b39505acc27d2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, =C3=89ric. Reply inline: On Wed, Aug 5, 2020 at 5:47 PM =C3=89ric Vyncke via Datatracker wrote: > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-oauth-jwsreq-26: 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 IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. > > Please find below a couple of non-blocking COMMENTs. > > I hope that this helps to improve the document, > > Regards, > > -=C3=A9ric > > =3D=3D COMMENTS =3D=3D > Should the document shepherd's write-up be updated ? It is dated October > 2016... about 4 years ago. > > -- Section 5.2 -- > Based on the long history of this document, is the following statement > "Many > phones in the market as of this writing still" still valid ? > Yes, partly because the demand for the authorization request payload is becoming large these days. As we can see in the PAR draft, we are precipitating to request_uri pattern. > > -- Section 5.2.1 -- > Suggest to give a hint about the use of tfp.example.org (TFP is expanded > only > in section 10.2). > You are right. Perhaps it may be better to give two examples, one with TFP with one-liner explanation and another with URN that is being stored at the authorization server. > > =3D=3D NITS =3D=3D > > Please check the ID-NITS at > > https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-= oauth-jwsreq-26.txt Thanks. Will do. > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --00000000000062b39505acc27d2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, =C3=89ric.=C2=A0

Rep= ly inline:=C2=A0

On Wed, Aug 5, 2020 at 5:47 PM =C3=89ric Vyncke via Datatra= cker <noreply@ietf.org> wrote= :
=C3=89ric Vync= ke has entered the following ballot position for
draft-ietf-oauth-jwsreq-26: 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/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ie= tf-oauth-jwsreq/



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

Thank you for the work put into this document.

Please find below a couple of non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-=C3=A9ric

=3D=3D COMMENTS =3D=3D
Should the document shepherd's write-up be updated ? It is dated Octobe= r
2016... about 4 years ago.

-- Section 5.2 --
Based on the long history of this document, is the following statement &quo= t;Many
phones in the market as of this writing still"=C2=A0 still valid ?
=

Yes, partly because the demand for the aut= horization request payload is becoming large these days.=C2=A0
As= we can see in the PAR draft, we are precipitating to request_uri pattern.= =C2=A0
=C2=A0

-- Section 5.2.1 --
Suggest to give a hint about the use of tfp.example.org (TFP is expanded o= nly
in section 10.2).

You are right. Perhap= s it may be better to give two examples, one with TFP with one-liner explan= ation and another with URN that is being stored at the authorization server= .=C2=A0
=C2=A0

=3D=3D NITS =3D=3D

Please check the ID-NITS at
https://= tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-oauth-jwsr= eq-26.txt

Thanks. Will do.=C2=A0
<= div>=C2=A0




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


--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en
--00000000000062b39505acc27d2d-- From nobody Thu Aug 13 06:44:57 2020 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 315873A0C3C; Thu, 13 Aug 2020 06:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=A8gWE8Aj; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Nuu7RJRL 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 g_aTFEZJctyg; Thu, 13 Aug 2020 06:44:50 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C593A0C3E; Thu, 13 Aug 2020 06:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14953; q=dns/txt; s=iport; t=1597326290; x=1598535890; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9CJxKR9+fe1ocV41hk3gxe25Id3BYAUGnwOBHFNQ7nY=; b=A8gWE8AjAxb3KiVCEiKOhXVpHN4moPrB8Svs4cOfQjQk6iaLuYifeHWX Ry1WeSgmqcRrGcby/GpUwZJh5vj3J5o0kzgMpN+CG7YRGP/vuV2QeGhC4 vZBkKyuMQ7COT11QQkou0aaazs3avVMuPfMN7d53NQCrzoCUB1rdzPuiv Y=; X-IPAS-Result: =?us-ascii?q?A0BbAQCIQzVf/4ENJK1fHAEBAQEBAQcBARIBAQQEAQGBe?= =?us-ascii?q?QQBAQsBgSIvKSgHcFgvLIQ2g0YDjViKCIlyhG2BQoERA1ULAQEBDAEBGAEMC?= =?us-ascii?q?AIEAQGETAIXgikCJDcGDgIDAQEBAwIDAQEBAQUBAQECAQYEbYVcDIVxAQEBB?= =?us-ascii?q?AEBEBEdAQEsCwEPAgEIEQMBAigDAgICHwYLFAYDCAIEDgUigwQBgX5NAy4BD?= =?us-ascii?q?qZhAoE5iGF2gTKDAQEBBYFHQYMcDQuCDgmBOAGCcINggiCEIBqBQT+BESccg?= =?us-ascii?q?k0+ghpCAQEBAQEBFYERARIBCTgNCQiCWTOCLY9kgxuGYZtXJFEKgmKHG4FIj?= =?us-ascii?q?DsEhHoDHoJ+iVmRF4InhDaYPYJkjluDOAIEAgQFAg4BAQWBQCkkZ1gRB3AVM?= =?us-ascii?q?QoFJQFVHYEjKQlHFwINjh83bgEIgkOFFIVCdAIBATMCBgEJAQEDCQF7kCwBA?= =?us-ascii?q?Q?= IronPort-PHdr: =?us-ascii?q?9a23=3AOuWL4hcZACp61KNz1KtRFX5ulGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQAdfU7vtFj6zdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutaFjbo3n05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.76,308,1592870400"; d="scan'208,217";a="518793870" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Aug 2020 13:44:48 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 07DDimZw017134 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Aug 2020 13:44:48 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 08:44:48 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 08:44:48 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 13 Aug 2020 08:44:47 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MqvFqO/bpcD4CTdXFeq2M+Z8dOfE/ZOxOV3COj+PwqFiN7G4ptq9ih5b2/Euy1V3vIb/s/v2oI+EuBKDOz8+dxr11c/SwrYbhLyDzeyIonmN/+xj4dIe2tY6YcYlWYgv3pj5M6t2LZ2keWoHCtecDR7FRZA6nJB75h2WuErch6oiCeN299dmh7Tt4Meal6jhBCFOG4LSxbghrCC8sigSSPWQpBGBglcvlLrnz3xp5I1WkFeJVZQDnFNsGdk8/IuCE5mf0CiGRo5ebwV5rBpABfxKoVPpOND2sxMcLCwwicjj3zTG3trrXE+6BaMlYbH9WKIAT4YN5qKqggcaQo65og== 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=9CJxKR9+fe1ocV41hk3gxe25Id3BYAUGnwOBHFNQ7nY=; b=KPdL3K5iCCPFGaRlQ9/kqzuOuvW/gMUny4F41Oh3QxF6DVXujRufJzaMj0osY8lRjHUu6xMtQ74h6lCpHygLWJUG9Sj7La2wnHGZDrFQJVSEDkniXF5Yt6iqQX2BuZu6UnDKwGF6fvwtHbJpjpMgU82gOMw/zmMQJTzde7NfTnzWnm52j8SNmLnOvVTuRn71xz13o4uhPAEfEmC0a5OmfmWggcOR0IDw5HUEYNV9laOmo4a/+3tv6C1qc2yo6uJaO+MhR8Bl5pzOEvDKObv6hwPT1ca98xDq3nmqRbh/mhHjqqZzCcEtxqO4utQwQYwU7bdbIRJNDCDVYslurVmFDA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9CJxKR9+fe1ocV41hk3gxe25Id3BYAUGnwOBHFNQ7nY=; b=Nuu7RJRLsdDc0JCxshR4/KMaJyYBUJVeuCei7zcsLdOUlZBtfJF2HcQLc6hf8xEQqjwiQv51pMI6kie4AYN1XOwh9G9EM/cVkfYJ5nh5G+eicBSw67zgxJrH6XcPKrOiQXSXDob/R6PvyllBjuTKVDUi4D1FRHjslsDpcxd9tWY= Received: from MWHPR11MB1853.namprd11.prod.outlook.com (2603:10b6:300:112::17) by MWHPR1101MB2112.namprd11.prod.outlook.com (2603:10b6:301:50::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Thu, 13 Aug 2020 13:44:47 +0000 Received: from MWHPR11MB1853.namprd11.prod.outlook.com ([fe80::c960:30b3:a9ea:f22e]) by MWHPR11MB1853.namprd11.prod.outlook.com ([fe80::c960:30b3:a9ea:f22e%8]) with mapi id 15.20.3283.015; Thu, 13 Aug 2020 13:44:46 +0000 From: "Eric Vyncke (evyncke)" To: Nat Sakimura CC: The IESG , oauth , "oauth-chairs@ietf.org" , "draft-ietf-oauth-jwsreq@ietf.org" Thread-Topic: =?utf-8?B?W09BVVRILVdHXSDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJh?= =?utf-8?Q?ft-ietf-oauth-jwsreq-26:_(with_COMMENT)?= Thread-Index: AQHWcXfBWkPiMoDFT0WHVemWTX3T2ak2LmaA Date: Thu, 13 Aug 2020 13:44:46 +0000 Message-ID: References: <159661722741.30500.10022053097818080667@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a02:1811:851a:3e00:ad31:843f:ef59:d60f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7fa70e17-4052-4cf4-9aba-08d83f8f0afa x-ms-traffictypediagnostic: MWHPR1101MB2112: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1853.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(376002)(396003)(136003)(346002)(4326008)(966005)(6486002)(66574015)(54906003)(478600001)(21615005)(2616005)(5660300002)(224303003)(86362001)(316002)(83380400001)(8936002)(166002)(6512007)(71200400001)(6506007)(2906002)(186003)(33656002)(83080400001)(36756003)(91956017)(76116006)(66946007)(66476007)(66556008)(64756008)(66446008)(53546011)(6916009); DIR:OUT; SFP:1101; x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AF5574BA22E24CB1A6828EFD04A3DB89ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1853.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7fa70e17-4052-4cf4-9aba-08d83f8f0afa X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2020 13:44:46.8035 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /sn+/TmDA0Ua4DaeVJOP1/Vf+r4PS/g1FgnOA0Qr95eLkWJ8GY6tptGXnOIrX1583JNgUsPgdvOhPilhXYoZvg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2112 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [OAUTH-WG] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-oauth-jwsreq-26=3A_=28with_COMMENT=29?= 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, 13 Aug 2020 13:44:53 -0000 --_000_AF5574BA22E24CB1A6828EFD04A3DB89ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbiB5b3UgTmF0IGZvciB0aGUgcXVpY2sgcmVwbHkgYW5kIHRoZSBmaXhlcw0KDQpSZWdhcmRz DQoNCi3DqXJpYw0KDQpGcm9tOiBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT4NCkRh dGU6IFRodXJzZGF5LCAxMyBBdWd1c3QgMjAyMCBhdCAxNTo0Mw0KVG86IEVyaWMgVnluY2tlIDxl dnluY2tlQGNpc2NvLmNvbT4NCkNjOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4sIG9hdXRoIDxv YXV0aEBpZXRmLm9yZz4sICJvYXV0aC1jaGFpcnNAaWV0Zi5vcmciIDxvYXV0aC1jaGFpcnNAaWV0 Zi5vcmc+LCAiZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXFAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLW9h dXRoLWp3c3JlcUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIMOJcmljIFZ5bmNr ZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0yNjogKHdpdGggQ09N TUVOVCkNCg0KVGhhbmtzLCDDiXJpYy4NCg0KUmVwbHkgaW5saW5lOg0KDQpPbiBXZWQsIEF1ZyA1 LCAyMDIwIGF0IDU6NDcgUE0gw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBp ZXRmLm9yZzxtYWlsdG86bm9yZXBseUBpZXRmLm9yZz4+IHdyb3RlOg0Kw4lyaWMgVnluY2tlIGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1v YXV0aC1qd3NyZXEtMjY6IE5vIE9iamVjdGlvbg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBr ZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCmVtYWlsIGFkZHJl c3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0 aGlzDQppbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIg dG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5o dG1sDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQg cG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9z aXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVO VDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhhbmsgeW91IGZvciB0aGUgd29yayBwdXQgaW50byB0aGlz IGRvY3VtZW50Lg0KDQpQbGVhc2UgZmluZCBiZWxvdyBhIGNvdXBsZSBvZiBub24tYmxvY2tpbmcg Q09NTUVOVHMuDQoNCkkgaG9wZSB0aGF0IHRoaXMgaGVscHMgdG8gaW1wcm92ZSB0aGUgZG9jdW1l bnQsDQoNClJlZ2FyZHMsDQoNCi3DqXJpYw0KDQo9PSBDT01NRU5UUyA9PQ0KU2hvdWxkIHRoZSBk b2N1bWVudCBzaGVwaGVyZCdzIHdyaXRlLXVwIGJlIHVwZGF0ZWQgPyBJdCBpcyBkYXRlZCBPY3Rv YmVyDQoyMDE2Li4uIGFib3V0IDQgeWVhcnMgYWdvLg0KDQotLSBTZWN0aW9uIDUuMiAtLQ0KQmFz ZWQgb24gdGhlIGxvbmcgaGlzdG9yeSBvZiB0aGlzIGRvY3VtZW50LCBpcyB0aGUgZm9sbG93aW5n IHN0YXRlbWVudCAiTWFueQ0KcGhvbmVzIGluIHRoZSBtYXJrZXQgYXMgb2YgdGhpcyB3cml0aW5n IHN0aWxsIiAgc3RpbGwgdmFsaWQgPw0KDQpZZXMsIHBhcnRseSBiZWNhdXNlIHRoZSBkZW1hbmQg Zm9yIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgcGF5bG9hZCBpcyBiZWNvbWluZyBsYXJnZSB0 aGVzZSBkYXlzLg0KQXMgd2UgY2FuIHNlZSBpbiB0aGUgUEFSIGRyYWZ0LCB3ZSBhcmUgcHJlY2lw aXRhdGluZyB0byByZXF1ZXN0X3VyaSBwYXR0ZXJuLg0KDQoNCi0tIFNlY3Rpb24gNS4yLjEgLS0N ClN1Z2dlc3QgdG8gZ2l2ZSBhIGhpbnQgYWJvdXQgdGhlIHVzZSBvZiB0ZnAuZXhhbXBsZS5vcmc8 aHR0cDovL3RmcC5leGFtcGxlLm9yZz4gKFRGUCBpcyBleHBhbmRlZCBvbmx5DQppbiBzZWN0aW9u IDEwLjIpLg0KDQpZb3UgYXJlIHJpZ2h0LiBQZXJoYXBzIGl0IG1heSBiZSBiZXR0ZXIgdG8gZ2l2 ZSB0d28gZXhhbXBsZXMsIG9uZSB3aXRoIFRGUCB3aXRoIG9uZS1saW5lciBleHBsYW5hdGlvbiBh bmQgYW5vdGhlciB3aXRoIFVSTiB0aGF0IGlzIGJlaW5nIHN0b3JlZCBhdCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIuDQoNCg0KPT0gTklUUyA9PQ0KDQpQbGVhc2UgY2hlY2sgdGhlIElELU5JVFMg YXQNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWRuaXRzP3VybD1odHRwczovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTI2LnR4dA0KDQpUaGFua3MuIFdpbGwgZG8u DQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCi0t DQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0dHA6 Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg== --_000_AF5574BA22E24CB1A6828EFD04A3DB89ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0A8B000B45161A46B7BC42E117C8B852@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1CRSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPlRoYW4geW91IE5hdCBmb3IgdGhlIHF1aWNrIHJlcGx5IGFuZCB0aGUg Zml4ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi3DqXJp YzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5OYXQgU2FraW11cmEgJmx0O3Nha2ltdXJhQGdtYWlsLmNv bSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIDEzIEF1Z3VzdCAyMDIwIGF0IDE1OjQz PGJyPg0KPGI+VG86IDwvYj5FcmljIFZ5bmNrZSAmbHQ7ZXZ5bmNrZUBjaXNjby5jb20mZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj5UaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDssIG9hdXRoICZsdDtv YXV0aEBpZXRmLm9yZyZndDssICZxdW90O29hdXRoLWNoYWlyc0BpZXRmLm9yZyZxdW90OyAmbHQ7 b2F1dGgtY2hhaXJzQGlldGYub3JnJmd0OywgJnF1b3Q7ZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXFA aWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LWlldGYtb2F1dGgtandzcmVxQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSDDiXJpYyBWeW5ja2UncyBObyBPYmpl Y3Rpb24gb24gZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjY6ICh3aXRoIENPTU1FTlQpPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+VGhhbmtzLCDDiXJpYy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+UmVwbHkgaW5saW5lOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gV2VkLCBBdWcgNSwgMjAyMCBhdCA1OjQ3IFBNIMOJ cmljIFZ5bmNrZSB2aWEgRGF0YXRyYWNrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpub3JlcGx5QGll dGYub3JnIj5ub3JlcGx5QGlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij7DiXJpYyBWeW5ja2UgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3Qg cG9zaXRpb24gZm9yPGJyPg0KZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjY6IE5vIE9iamVjdGlv bjxicj4NCjxicj4NCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGlu ZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbDxicj4NCmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBp biB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzPGJyPg0KaW50cm9k dWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIHJlZmVy IHRvIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3Mt Y3JpdGVyaWEuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVz Zy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPC9hPjxicj4NCmZvciBtb3JlIGluZm9y bWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuPGJyPg0KPGJy Pg0KPGJyPg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMs IGNhbiBiZSBmb3VuZCBoZXJlOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLzwvYT48 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KQ09NTUVOVDo8YnI+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KVGhhbmsgeW91IGZvciB0aGUgd29yayBwdXQgaW50byB0 aGlzIGRvY3VtZW50Ljxicj4NCjxicj4NClBsZWFzZSBmaW5kIGJlbG93IGEgY291cGxlIG9mIG5v bi1ibG9ja2luZyBDT01NRU5Ucy48YnI+DQo8YnI+DQpJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIHRv IGltcHJvdmUgdGhlIGRvY3VtZW50LDxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KLcOp cmljPGJyPg0KPGJyPg0KPT0gQ09NTUVOVFMgPT08YnI+DQpTaG91bGQgdGhlIGRvY3VtZW50IHNo ZXBoZXJkJ3Mgd3JpdGUtdXAgYmUgdXBkYXRlZCA/IEl0IGlzIGRhdGVkIE9jdG9iZXI8YnI+DQoy MDE2Li4uIGFib3V0IDQgeWVhcnMgYWdvLjxicj4NCjxicj4NCi0tIFNlY3Rpb24gNS4yIC0tPGJy Pg0KQmFzZWQgb24gdGhlIGxvbmcgaGlzdG9yeSBvZiB0aGlzIGRvY3VtZW50LCBpcyB0aGUgZm9s bG93aW5nIHN0YXRlbWVudCAmcXVvdDtNYW55PGJyPg0KcGhvbmVzIGluIHRoZSBtYXJrZXQgYXMg b2YgdGhpcyB3cml0aW5nIHN0aWxsJnF1b3Q7Jm5ic3A7IHN0aWxsIHZhbGlkID88bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlllcywgcGFy dGx5IGJlY2F1c2UgdGhlIGRlbWFuZCBmb3IgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBwYXls b2FkIGlzIGJlY29taW5nIGxhcmdlIHRoZXNlIGRheXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij5BcyB3ZSBjYW4gc2VlIGluIHRoZSBQQVIgZHJhZnQsIHdlIGFyZSBwcmVjaXBpdGF0aW5n IHRvIHJlcXVlc3RfdXJpIHBhdHRlcm4uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxicj4NCi0tIFNlY3Rpb24gNS4yLjEgLS08 YnI+DQpTdWdnZXN0IHRvIGdpdmUgYSBoaW50IGFib3V0IHRoZSB1c2Ugb2YgPGEgaHJlZj0iaHR0 cDovL3RmcC5leGFtcGxlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdGZwLmV4YW1wbGUub3JnPC9h PiAoVEZQIGlzIGV4cGFuZGVkIG9ubHk8YnI+DQppbiBzZWN0aW9uIDEwLjIpLjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+WW91IGFyZSBy aWdodC4gUGVyaGFwcyBpdCBtYXkgYmUgYmV0dGVyIHRvIGdpdmUgdHdvIGV4YW1wbGVzLCBvbmUg d2l0aCBURlAgd2l0aCBvbmUtbGluZXIgZXhwbGFuYXRpb24gYW5kIGFub3RoZXIgd2l0aCBVUk4g dGhhdCBpcyBiZWluZyBzdG9yZWQgYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 YnI+DQo9PSBOSVRTID09PGJyPg0KPGJyPg0KUGxlYXNlIGNoZWNrIHRoZSBJRC1OSVRTIGF0PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZG5pdHM/dXJsPWh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjYudHh0IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZG5pdHM/dXJsPWh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaWQvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjYudHh0PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhhbmtzLiBXaWxs IGRvLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnIgY2xlYXI9 ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LS0gPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+TmF0IFNha2ltdXJhICg9bmF0KTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkNoYWlybWFuLCBPcGVuSUQg Rm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+DQpAX25hdF9lbjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_AF5574BA22E24CB1A6828EFD04A3DB89ciscocom_-- From nobody Thu Aug 13 07:25:53 2020 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 B19193A0C75; Thu, 13 Aug 2020 07:25:44 -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 isN9TkZ8fIdD; Thu, 13 Aug 2020 07:25:41 -0700 (PDT) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 6D3873A0C73; Thu, 13 Aug 2020 07:25:41 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id r2so5469939wrs.8; Thu, 13 Aug 2020 07:25:41 -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=5Tv2R9ZoCpM9fmmjmkZx5OZSSb0DhJRqWpctSTnVSdM=; b=l1ITLD6OaRHTG8FOMEFSuC2TO1GGnwBXNBlNhRZkpof9jT2Q4TOGQMh/PxJ/9CUuc/ FnBta+uVlrvcxwBJFcASQCP7ccpYz68z9a8DrV4T07XJKLrQ1DGkQWHx0W7xv2s5Sz8N Zlev2Nxc6yHQfPSKFEWOomcxw4ojVIXnaKw8atS8KDOnPBGTpdPbuwG5tFT0Uf8/d2Eu V8YGbEb6HdapaQkSP4ZHJNLG+njnBbpmr+3/wZibb5+wx5JnwAhcoMqi876QFyKeqC3g +M1mpDqAnLlsd2lhc7XB2c5wQ2aSWJ9SKQv64eLatuKhaDXZnY/BMhYvjAqfyD6GdwR5 rrgw== 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=5Tv2R9ZoCpM9fmmjmkZx5OZSSb0DhJRqWpctSTnVSdM=; b=eIwgit8tdmBWVPazhW4mevkq3Q9XgNC/oOMAxE0aSvtMXxRMGhi9MtC7Gm3g3Mp4kd 2sQbamw4t5UxjDVixq1oUJR/qfquRLuiFQ0TZguQxexAg7LXe1MgbzVTsdWgw2Ndhh41 +y2PrkI/YzOEukbiLnRHjgyZv1XXN2rOWHVA6D5BWIO31OhzsrUIXLAcWQUt2h3Db8dT nAxQmJZiOFjzjg3jWlb3gzjmxjpW3a/DJLZedGy11l/KBioc2bIHhEZF5gYGoLnJ+sSI x2eBNkLuwcpx7XhCdDTAgMTlLilgdSIYFHipx8Q2yMyrV2CKqjVTw2SvZKtlwqE2OKr/ KYbg== X-Gm-Message-State: AOAM530HAKjLDBe7I7G82ocqQm2sTWqEWF9T0LaxkNGl5RqmkL0hC5d8 0gkkBIMoolt5uByVqhhAI7jYW3/aFYPmUZPTKTE= X-Google-Smtp-Source: ABdhPJwoUflWOCADeDk+TB5KCrL9PwDizvsQYR1RF/2hJ34MXAhM6E3gyynhgLVEK5Bqu3TKArF+YozfBskWFxwklm0= X-Received: by 2002:adf:ec8b:: with SMTP id z11mr4204860wrn.51.1597328739551; Thu, 13 Aug 2020 07:25:39 -0700 (PDT) MIME-Version: 1.0 References: <159716117548.28832.15844996438952874291@ietfa.amsl.com> In-Reply-To: <159716117548.28832.15844996438952874291@ietfa.amsl.com> From: Nat Sakimura Date: Thu, 13 Aug 2020 23:25:27 +0900 Message-ID: To: Benjamin Kaduk Cc: The IESG , oauth , oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org Content-Type: multipart/alternative; boundary="0000000000001c4df005acc314f3" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (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, 13 Aug 2020 14:25:45 -0000 --0000000000001c4df005acc314f3 Content-Type: text/plain; charset="UTF-8" Thanks Benjamin. My replies inline below: On Wed, Aug 12, 2020 at 12:53 AM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-oauth-jwsreq-26: 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 IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the many updates as we worked through the issues. > > Let's also add a note about "whose JWT Claims Set holds the JSON encoded > OAuth 2.0 authorization request parameters" to the definition of Request > Object in Section 2.1 (in addition to the note in the Introduction); my > apologies for not including that when I suggested the change to the > Introduction. > Sure. Thanks for pointing out. > > Please update the Content-Length in the example in Section 5.2.3. > > Ditto. > > Section 4 > > The client determines the algorithms used to sign and encrypt request > objects. This decision can be based on metadata the client > registered via dynamic client registration [RFC7591] using the > parameters "request_object_signing_alg", > "request_object_encryption_alg", "request_object_encryption_enc" as > defined in the the IANA "OAuth Dynamic Client Registration Metadata" > registry [IANA.OAuth.Parameters] established by [RFC7591]. > > I had to read this ("this decision can be based on [...]") a few times > to understand it. If I understand correctly, the idea is that the > client will register with the AS the keys it will use for constructing > the JAR, and in that way the AS has a binding from JAR-signing key to > the specific client and request. So it's true that the decision of what > key to use "can be based on" the metadata that the client registered, in > that deciding to use a different key than the registered one(s) is > likely to cause the AS to reject the request, but that's perhaps not the > main point. Would it work to instead just say that "The keys used to > sign and encrypt request objects (and thus, the algorithms that can be > used with those keys) can be registered via dynamic client registration > [...]"? > This paragraph is just talking about the algorithms and not the keys themselves. Keys are obtained through jwks_uri registered through the dynreg. It could have multiple keys in it. This paragraph is in some sense putting constraints on what algorithms the client can choose. I agree that the sentence is super long and difficult to parse. I will think about the way to rephrase. > > Section 5.2 > > The contents of the resource referenced by the URI MUST be a Request > Object, unless the URI was provided to the client by the > Authorization Server. The "request_uri" value MUST be either URN as > defined in RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of > RFC7230 [RFC7230] . The "request_uri" value MUST be reachable by the > Authorization Server. > > I defer to my ART-area colleagues, but I'm not sure what it means for a > URN URI to be "reachable"; is this requirement intended to only apply to > the "https:" case? > Again, it may be a phrasing problem, but the AS need to be able to obtain the content of the request object that is represented by the URN. That's what it is being expressed by "reachable". If there is a better expression, I am open to adopting it. > Section 5.2.1 > > It is possible for the Request Object to include values that are to > be revealed only to the Authorization Server. As such, the > "request_uri" MUST have appropriate entropy for its lifetime. For > > Is there a good reference for what the lifetime of such a request might > be? Perhaps I've been reading too much of GNAP, but my intuition is > that much of the time these requests will be single-use, and I don't > have as clear of a picture for when they might persist longer. There > are also potential security considerations for long-lived request > objects, in terms of making sure that there is a binding between the > client's intent to use a given request object for a given request, the > user's authorization, etc. > This can actually be use-case dependent. In the majority of the case, it will be pretty short. But at the time, it may be possible for the client to push the request object to the AS not by the user action but on its own and wait for user action after notifying the user. In such a case, it could be pretty long, I imagine. > > Section 5.2.3 > > (side note) I'd consider updating the timestamps in the example response > (and perhaps moving to Apache 2.4+ as well?). > OK. Good point. > > Section 6.x > > (nit) I suggest consistency in subsection headings, so, e.g., "JWE > Encrypted Request Object" and "JWS Signed Request Object". > Good point. > > Section 6.2 > > The Authorization Server MUST perform the signature validation of the > JSON Web Signature [RFC7515] signed request object. For this, the > "alg" Header Parameter in its JOSE Header MUST match the value of the > pre-registered algorithm. The signature MUST be validated against > the appropriate key for that "client_id" and algorithm. > > This text suggests that pre-registration is mandatory, whereas up in > Section 4 the client's choice of algorithm was merely something that > "can be based on [metadata registered via dynamic registration]". I > know that dynamic registration is not the only kind of registration > possible, but we may want to wordsmith one (or both) location to improve > the consistency. > Good point. I will work on it but also I would welcome a concrete proposal on it as well. > > Section 6.3 > > I'd suggest reiterating here the requirement to verify "client_id" > consistency between Request Object and request parameters. > OK. > > Section 10 > > I'd consider reiterating the security importance (i.e., what breaks if > you don't apply the check) of a few key compliance requirements and > which entity is responsible for enforcing them: > > - the "request" and "request_uri" parameters MUST NOT be included in > request objects, from Section 4 > > - The request object has the mime-type > "application/oauth.authz.req+jwt", also from Section 4 > > - The client_id in the request object has to match the client_id from > the request query parameters, from Section 5 > > - The AS must only use parameters from the request object, even if the > client has duplicated them in the query parameters, also from Section 5 > OK. > > Section 10.2 > > (e) When a third party, such as a Trust Framework Provider(TFP), > provides an endpoint that provides a Request Object URI in > exchange for a Request Object. The same requirements as (b) and > (c) above apply. In addition, the Authorization Server MUST > > The (b) case is "the symmetric key for JWE encryption"; do we mean "(c) > and (d)" here? > Good point. Let me check with John and get back to you. > > Section 10.3 > > I'm not sure whether the key point of this section is "the following > endpoints are RECOMMENDED [...] to use this practice" or "an extension > specification should be created as a measure to address the risk". That > is, can a deployment unilaterally apply the message-position and > intended-interaction-endpoint protections now, or is there need for > additional specification work first? > It can be covered by operational rules to some extent but I believe having an extension spec would make things more explicit and less error-prone. > > Section 10.4 > > I'm not sure how much of this is distinct from the Request URI Rewrite > discussed in Section 10.4.2, but having the request object contents be > in a separately dereferenceable URI introduces risk of the dereferenced > Request Object being dissociated from the triggering request. (This > could happen due to internal error on the client or service hosting the > requested URI or content skew over time, in addition to a request URI > rewrite.) Having an externally provided single-use nonce in the reqest > object would provide a mitigation, but it also (if I understand > correctly) not compatible with all of the envisioned use cases for JAR. > Hmm. Current implementations since it is out of OIDC has nonce, I believe. I need to think a bit about this. > > Section 10.5 > > Should the rejection of "alg":"none" be limited to the > require_signed_request_object case, or universally applied? > I believe it is for the case require_signed_request_object is true. > > Section 12.1 > > (2) (Translation Process) The client uses the client credential that > it got to push the request object to the TFP to get the > "request_uri". > > If I understand correctly, the TFP also verifies that the request object > is consistent with the claims the client is eligible for based on the > certification step in (1). > Yes. Perhaps I should add text for that. > > Section 12.2.2 > > Therefore, per-user Request Object URI should be avoided. > > If I understand correctly, the only possible alternative is to have > per-request URIs (right?), as coalescing multiple user's requests into a > single request object URI seems to pose several difficulties. We could > perhaps make the recommended alternative more clear. > > Right. I will try to come up with a text for this. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --0000000000001c4df005acc314f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0Benjamin.=C2=A0

My replies inline below:=C2=A0

On Wed, Aug 12, 2020 at 12:53 AM = Benjamin Kaduk via Datatracker <nore= ply@ietf.org> wrote:
Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwsreq-26: 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/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ie= tf-oauth-jwsreq/



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

Thanks for the many updates as we worked through the issues.

Let's also add a note about "whose JWT Claims Set holds the JSON e= ncoded
OAuth 2.0 authorization request parameters" to the definition of Reque= st
Object in Section 2.1 (in addition to the note in the Introduction); my
apologies for not including that when I suggested the change to the
Introduction.

Sure. Thanks for pointing= out.=C2=A0=C2=A0

Please update the Content-Length in the example in Section 5.2.3.

Ditto.=C2=A0
=C2=A0

Section 4

=C2=A0 =C2=A0The client determines the algorithms used to sign and encrypt = request
=C2=A0 =C2=A0objects.=C2=A0 This decision can be based on metadata the clie= nt
=C2=A0 =C2=A0registered via dynamic client registration [RFC7591] using the=
=C2=A0 =C2=A0parameters "request_object_signing_alg",
=C2=A0 =C2=A0"request_object_encryption_alg", "request_objec= t_encryption_enc" as
=C2=A0 =C2=A0defined in the the IANA "OAuth Dynamic Client Registratio= n Metadata"
=C2=A0 =C2=A0registry [IANA.OAuth.Parameters] established by [RFC7591].

I had to read this ("this decision can be based on [...]") a few = times
to understand it.=C2=A0 If I understand correctly, the idea is that the
client will register with the AS the keys it will use for constructing
the JAR, and in that way the AS has a binding from JAR-signing key to
the specific client and request.=C2=A0 So it's true that the decision o= f what
key to use "can be based on" the metadata that the client registe= red, in
that deciding to use a different key than the registered one(s) is
likely to cause the AS to reject the request, but that's perhaps not th= e
main point.=C2=A0 Would it work to instead just say that "The keys use= d to
sign and encrypt request objects (and thus, the algorithms that can be
used with those keys) can be registered via dynamic client registration
[...]"?

This paragraph is just tal= king about the algorithms and not the keys themselves.=C2=A0
Keys= are obtained through jwks_uri registered through <= span style=3D"font-size:13.3333px">the dynreg.=C2=A0
It could have= multiple keys in it.=C2=A0
This paragraph is in so= me sense putting constraints on what algorithms the client can choose.=C2= =A0
<= br>
I agree that the sentence is super long and dif= ficult to parse.=C2=A0
I will think about the way to rephrase.=C2= =A0

=C2=A0

Section 5.2

=C2=A0 =C2=A0The contents of the resource referenced by the URI MUST be a R= equest
=C2=A0 =C2=A0Object, unless the URI was provided to the client by the
=C2=A0 =C2=A0Authorization Server.=C2=A0 The "request_uri" value = MUST be either URN as
=C2=A0 =C2=A0defined in RFC8141 [RFC8141] or "https" URI, as defi= ned in 2.7.2 of
=C2=A0 =C2=A0RFC7230 [RFC7230] .=C2=A0 The "request_uri" value MU= ST be reachable by the
=C2=A0 =C2=A0Authorization Server.

I defer to my ART-area colleagues, but I'm not sure what it means for a=
URN URI to be "reachable"; is this requirement intended to only a= pply to
the "https:" case?

Again, it = may be a phrasing problem, but the AS need to be able to obtain the content= of the request object that is represented by the URN. That's what it i= s being expressed by "reachable". If there is a better expression= , I am open to adopting it.=C2=A0=C2=A0


Section 5.2.1

=C2=A0 =C2=A0It is possible for the Request Object to include values that a= re to
=C2=A0 =C2=A0be revealed only to the Authorization Server.=C2=A0 As such, t= he
=C2=A0 =C2=A0"request_uri" MUST have appropriate entropy for its = lifetime.=C2=A0 For

Is there a good reference for what the lifetime of such a request might
be?=C2=A0 Perhaps I've been reading too much of GNAP, but my intuition = is
that much of the time these requests will be single-use, and I don't have as clear of a picture for when they might persist longer.=C2=A0 There<= br> are also potential security considerations for long-lived request
objects, in terms of making sure that there is a binding between the
client's intent to use a given request object for a given request, the<= br> user's authorization, etc.

This can= actually be use-case dependent.=C2=A0
In the majority of the cas= e, it will be pretty short.=C2=A0
But at the time, it may be poss= ible for the client to push the request object to the AS not by the user ac= tion but on its own and wait for user action after notifying the user. In s= uch a case, it could be pretty long, I imagine.=C2=A0
=C2=A0

Section 5.2.3

(side note) I'd consider updating the timestamps in the example respons= e
(and perhaps moving to Apache 2.4+ as well?).

OK. Good point.=C2=A0
=C2=A0

Section 6.x

(nit) I suggest consistency in subsection headings, so, e.g., "JWE
Encrypted Request Object" and "JWS Signed Request Object".

Good point.=C2=A0
=C2=A0
=

Section 6.2

=C2=A0 =C2=A0The Authorization Server MUST perform the signature validation= of the
=C2=A0 =C2=A0JSON Web Signature [RFC7515] signed request object.=C2=A0 For = this, the
=C2=A0 =C2=A0"alg" Header Parameter in its JOSE Header MUST match= the value of the
=C2=A0 =C2=A0pre-registered algorithm.=C2=A0 The signature MUST be validate= d against
=C2=A0 =C2=A0the appropriate key for that "client_id" and algorit= hm.

This text suggests that pre-registration is mandatory, whereas up in
Section 4 the client's choice of algorithm was merely something that "can be based on [metadata registered via dynamic registration]".= =C2=A0 I
know that dynamic registration is not the only kind of registration
possible, but we may want to wordsmith one (or both) location to improve the consistency.

Good point. I will wor= k on it but also I would welcome a concrete proposal on it as well.=C2=A0
=C2=A0

Section 6.3

I'd suggest reiterating here the requirement to verify "client_id&= quot;
consistency between Request Object and request parameters.
=

OK.=C2=A0
=C2=A0

Section 10

I'd consider reiterating the security importance (i.e., what breaks if<= br> you don't apply the check) of a few key compliance requirements and
which entity is responsible for enforcing them:

- the "request" and "request_uri" parameters MUST NOT b= e included in
=C2=A0 request objects, from Section 4

- The request object has the mime-type
=C2=A0 "application/oauth.authz.req+jwt", also from Section 4

- The client_id in the request object has to match the client_id from
=C2=A0 the request query parameters, from Section 5

- The AS must only use parameters from the request object, even if the
=C2=A0 client has duplicated them in the query parameters, also from Sectio= n 5

OK.=C2=A0
=C2=A0

Section 10.2

=C2=A0 =C2=A0(e)=C2=A0 When a third party, such as a Trust Framework Provid= er(TFP),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 provides an endpoint that provides a Request Ob= ject URI in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 exchange for a Request Object.=C2=A0 The same r= equirements as (b) and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (c) above apply.=C2=A0 In addition, the Authori= zation Server MUST

The (b) case is "the symmetric key for JWE encryption"; do we mea= n "(c)
and (d)" here?

Good point. Let me = check with John and get back to you.=C2=A0
=C2=A0

Section 10.3

I'm not sure whether the key point of this section is "the followi= ng
endpoints are RECOMMENDED [...] to use this practice" or "an exte= nsion
specification should be created as a measure to address the risk".=C2= =A0 That
is, can a deployment unilaterally apply the message-position and
intended-interaction-endpoint protections now, or is there need for
additional specification work first?

It= can be covered by operational rules to some extent but I believe having an= extension spec would make things more explicit and less error-prone.=C2=A0=
=C2=A0

Section 10.4

I'm not sure how much of this is distinct from the Request URI Rewrite<= br> discussed in Section 10.4.2, but having the request object contents be
in a separately dereferenceable URI introduces risk of the dereferenced
Request Object being dissociated from the triggering request.=C2=A0 (This could happen due to internal error on the client or service hosting the
requested URI or content skew over time, in addition to a request URI
rewrite.)=C2=A0 Having an externally provided single-use nonce in the reqes= t
object would provide a mitigation, but it also (if I understand
correctly) not compatible with all of the envisioned use cases for JAR.
=

Hmm. Current implementations=C2=A0since it= is out of OIDC has nonce, I believe.=C2=A0
I need to think a bit= about this.=C2=A0

=C2=A0

Section 10.5

Should the rejection of "alg":"none" be limited to the<= br> require_signed_request_object case, or universally applied?

I believe it is for the case require_signed_request_ob= ject is true.=C2=A0
=C2=A0

Section 12.1

=C2=A0 =C2=A0(2)=C2=A0 (Translation Process) The client uses the client cre= dential that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 it got to push the request object to the TFP to= get the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "request_uri".

If I understand correctly, the TFP also verifies that the request object is consistent with the claims the client is eligible for based on the
certification step in (1).

Yes.=C2=A0
Perhaps I should add text for that.=C2=A0
=C2=A0

Section 12.2.2

=C2=A0 =C2=A0Therefore, per-user Request Object URI should be avoided.

If I understand correctly, the only possible alternative is to have
per-request URIs (right?), as coalescing multiple user's requests into = a
single request object URI seems to pose several difficulties.=C2=A0 We coul= d
perhaps make the recommended alternative more clear.


Right. I will try to come up with a te= xt for this.=C2=A0
=C2=A0


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


--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en
--0000000000001c4df005acc314f3-- From nobody Thu Aug 13 08:12:24 2020 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 921C33A0CD0; Thu, 13 Aug 2020 08:12:22 -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 Y9H92qkyj5mZ; Thu, 13 Aug 2020 08:12:20 -0700 (PDT) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 425D53A0CCF; Thu, 13 Aug 2020 08:12:20 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id 88so5633743wrh.3; Thu, 13 Aug 2020 08:12:20 -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=g1wqeM8Gi3hVx+dKYlQJq84/Wx6DTbwRWfhA/r81bh8=; b=o8xpnQXqEMPDSJ2VfRDtqzY9mcgcfCOhUF0cY5aAZC08PsntKzgZDVBnuvER2NDX5r qhcJxM5dZaW6gewHaUOrxtoJ4PQmtx9thF+SRKXvPc0Y8Bft7u67gI/FBAhmrTticgjO OGBpdjVy3wMFx1Nselce/zjf02825px1pJMltuqdqwAmxPr5FPEBia6ggI2AxOExijmP Fti7N6ocbRqcwwy8/kcUucj2g2/UGq7jhvTtQb5zKk8jbnFB1V93qcp1z7XJCRjCB56n Z8azRiU48MLpat/3Wgvs5XMuXN4GOGcolgkeCNOaOTORhOow88A7LC/RvRmG3jTykZZM sDCQ== 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=g1wqeM8Gi3hVx+dKYlQJq84/Wx6DTbwRWfhA/r81bh8=; b=ByT9KY1u+yLtGIIzVaqhRjz1+BNTbtpmdlUMJqSdZ83iSD6VZ4wKHFK1leOiuI+ge9 Z9CYIqQ+NGerqQbDpFJG8Yyhx3bPfkT0cKqxhliSdXVbzXhOKZAFNlZhpZRm4dGgXXD4 vaPUzyEkdhfTjjjtvZ0IMiWRAS7rqrGHQ8pnCMHGzUNExG/PcyGIrR6hpQhmQ5MsJ10N T7xN3b8DlzWMK2t/R+/6AHwj+0/xiEUHr1srAVxPbXF6h5L74khcLGLV0xagRxOKBwhm NHLnYMCsee7Lb1wkoJa5LH1CTP/Tf7BNTJEfKgVTdlpzemVPDk3oflCwnl/+k5v3eMbj FP7A== X-Gm-Message-State: AOAM532dPxvG4CKx5sLHgD9pK9KUqlo6dmY81S1hx/f4Qz+6B7dqkrjH kvZvnmbSIAZSskgsWQhyEwTe/4agvkSk03Jl5YU= X-Google-Smtp-Source: ABdhPJyi2fXd5icIiGk324DM+vLdeVQ8vId4SdCkvCSZUEekGmFLof2CCQ/DIQrHBHzR6sNaSicNtZI+StHU7zX3/2M= X-Received: by 2002:adf:aa9e:: with SMTP id h30mr4299595wrc.377.1597331538524; Thu, 13 Aug 2020 08:12:18 -0700 (PDT) MIME-Version: 1.0 References: <159725840640.26497.2671991928381311278@ietfa.amsl.com> In-Reply-To: <159725840640.26497.2671991928381311278@ietfa.amsl.com> From: Nat Sakimura Date: Fri, 14 Aug 2020 00:12:07 +0900 Message-ID: To: Robert Wilton Cc: The IESG , oauth , oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org Content-Type: multipart/alternative; boundary="000000000000f141fe05acc3bafb" Archived-At: Subject: Re: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-jwsreq-26: (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, 13 Aug 2020 15:12:23 -0000 --000000000000f141fe05acc3bafb Content-Type: text/plain; charset="UTF-8" Dear Robert, Thanks for the comment. Internet Explorer limitation is interesting from the historical perspective but can probably now safely removed as well. We may want to put an example such as a Mobile App spawning external browser to make an authorization request instead. Cheers, Nat On Thu, Aug 13, 2020 at 3:53 AM Robert Wilton via Datatracker < noreply@ietf.org> wrote: > Robert Wilton has entered the following ballot position for > draft-ietf-oauth-jwsreq-26: 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 IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > Only one minor comment: > > I liked the reference to max URL size for older versions of Internet > Explorer, > but wonder if that is still really relevant in 2020? Or perhaps it could > now > be removed? > > Regards, > Rob > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --000000000000f141fe05acc3bafb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Robert,=C2=A0

Thanks for the comme= nt.=C2=A0
Internet Explorer limitation is interesting from the hi= storical perspective but can probably now safely removed as well.=C2=A0
We may want to put an example such as a Mobile App spawning external= browser to make an authorization request instead.=C2=A0

Cheers,=C2=A0

Nat

On Thu, Aug 13, 2020= at 3:53 AM Robert Wilton via Datatracker <noreply@ietf.org> wrote:
Robert Wilton has entered the following ballot posit= ion for
draft-ietf-oauth-jwsreq-26: 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/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ie= tf-oauth-jwsreq/



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

Hi,

Only one minor comment:

I liked the reference to max URL size for older versions of Internet Explor= er,
but wonder if that is still really relevant in 2020?=C2=A0 Or perhaps it co= uld now
be removed?

Regards,
Rob



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


--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en
--000000000000f141fe05acc3bafb-- From nobody Thu Aug 13 08:15:41 2020 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 B19FA3A0D08; Thu, 13 Aug 2020 08:15: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 lMk2655U5T4t; Thu, 13 Aug 2020 08:15:33 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 C8FE93A0D09; Thu, 13 Aug 2020 08:15:32 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id f1so5644684wro.2; Thu, 13 Aug 2020 08:15:32 -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=2jKaFsHLmAPpzi+md4Y5szqX3irmunBGf8tcF8Co99k=; b=eRiSUy5I20p9mUSOiw6YbFxSh+Im1Cm3XrBd/Y2KjDozDlBI+hsy9rT9ciiwnGPyjl vqMXwDMWw2fp4m4Yrf6SqN/n74xQcuj0xQdZ98csJv6/5MaLTZEc2a4CPpofMGCYBzgX Zr44+ODYnSYTFh8k+U82YltH2AxHP7roIsonuAS5p0KPNzDzfbpnFRrUyXlEnhWuZCq2 jCY2GmX12ChNg3fqV/cKx8AbL0vEuHIU/kk7wLTstILHo7b/E2D2JhCAJADsirfi6MVH 0yV2VuV4zlQgYH4zkgOKtODwiYndsyT9MRCoQTQGJwINc6eXAd4qTcYWpfc8SnsH+U8c 8S4w== 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=2jKaFsHLmAPpzi+md4Y5szqX3irmunBGf8tcF8Co99k=; b=cBvcPPiRVWS1ecJQRRSvJ62ciKNOfHPRnp3kQ61EFH0rf+/4KKP04tDt9oK4mJhxiS PWXjsryE72tlVFpKW9lWgYz4WdROQ1Pz2W8qXO0y/VOxdB1l10Wmk4qdLgAOY938Cgob DEP81v8fgBs7vYii4fUK39rWRq5EuCRdbQuOdtzTSeePw9pkF0YD1K5uSZ8D3ebF2xXA P3DV3mvSSbGFOWJAJTCGsk2V0BzdpkGnlhCTWP3HzGjxXSOR+WkIfo0IjBzLvhqjp9V+ a7YQ2U37BLy6Rl1WAmtp4tWzKLlZ4mN0v8hc06jPgZbhCpl/sAHLDwnYbgZ6NlrBVvhu tPgQ== X-Gm-Message-State: AOAM531LZocF+QzLjU9uoYH4ul91JwvdFf1P+xJ7dZJjMI2I2WHgDTJJ ptFVuNukGUhTjqT8F8tB1hqGW0vNcQacDJheq5L/PvOM X-Google-Smtp-Source: ABdhPJzVmKXS6cV92a7srj7CS0h+bBLmGBMfzqEtteIWHmoROW+RdWCImx1+JHg9ohdDYdnC1pHAQsGIe7G2bt0AS4k= X-Received: by 2002:adf:aa9e:: with SMTP id h30mr4311599wrc.377.1597331730999; Thu, 13 Aug 2020 08:15:30 -0700 (PDT) MIME-Version: 1.0 References: <159661722741.30500.10022053097818080667@ietfa.amsl.com> In-Reply-To: From: Nat Sakimura Date: Fri, 14 Aug 2020 00:15:19 +0900 Message-ID: To: "Eric Vyncke (evyncke)" Cc: The IESG , oauth , "oauth-chairs@ietf.org" , "draft-ietf-oauth-jwsreq@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006a2e8a05acc3c6dd" Archived-At: Subject: Re: [OAUTH-WG] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-oauth-jwsreq-26=3A_=28with_COMMENT=29?= 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, 13 Aug 2020 15:15:35 -0000 --0000000000006a2e8a05acc3c6dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You are welcome. Actually, for 5.2, I should probably replace with more modern examples instead of old phones and old Internet Explorer. E.g., a) a mobile app making an authorization request through a mobile browser; b) RAR. On Thu, Aug 13, 2020 at 10:44 PM Eric Vyncke (evyncke) wrote: > Than you Nat for the quick reply and the fixes > > > > Regards > > > > -=C3=A9ric > > > > *From: *Nat Sakimura > *Date: *Thursday, 13 August 2020 at 15:43 > *To: *Eric Vyncke > *Cc: *The IESG , oauth , " > oauth-chairs@ietf.org" , " > draft-ietf-oauth-jwsreq@ietf.org" > *Subject: *Re: [OAUTH-WG] =C3=89ric Vyncke's No Objection on > draft-ietf-oauth-jwsreq-26: (with COMMENT) > > > > Thanks, =C3=89ric. > > > > Reply inline: > > > > On Wed, Aug 5, 2020 at 5:47 PM =C3=89ric Vyncke via Datatracker < > noreply@ietf.org> wrote: > > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-oauth-jwsreq-26: 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 IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. > > Please find below a couple of non-blocking COMMENTs. > > I hope that this helps to improve the document, > > Regards, > > -=C3=A9ric > > =3D=3D COMMENTS =3D=3D > Should the document shepherd's write-up be updated ? It is dated October > 2016... about 4 years ago. > > -- Section 5.2 -- > Based on the long history of this document, is the following statement > "Many > phones in the market as of this writing still" still valid ? > > > > Yes, partly because the demand for the authorization request payload is > becoming large these days. > > As we can see in the PAR draft, we are precipitating to request_uri > pattern. > > > > > -- Section 5.2.1 -- > Suggest to give a hint about the use of tfp.example.org (TFP is expanded > only > in section 10.2). > > > > You are right. Perhaps it may be better to give two examples, one with TF= P > with one-liner explanation and another with URN that is being stored at t= he > authorization server. > > > > > =3D=3D NITS =3D=3D > > Please check the ID-NITS at > > https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-= oauth-jwsreq-26.txt > > > > Thanks. Will do. > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --0000000000006a2e8a05acc3c6dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You are welcome.=C2=A0

Actually, fo= r 5.2, I should probably replace with=C2=A0more modern examples instead of = old phones and old Internet Explorer.=C2=A0
E.g., a) a mobile app= making an authorization request through a mobile browser; b) RAR.=C2=A0

On Thu, Aug 13, 2020 at 10:44 PM Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:

Than you Nat for the quick repl= y and the fixes

=C2=A0

Regards

=C2=A0

-=C3=A9ric=

=C2=A0

From: Nat Sakimura <sakimura@gmail.com&= gt;
Date: Thursday, 13 August 2020 at 15:43
To: Eric Vyncke <evyncke@cisco.com>
Cc: The IESG <= iesg@ietf.org>, oauth <oauth@ietf.org>, "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>= , "draft-ietf-oauth-jwsreq@ietf.org" <draft-ietf-oauth-jwsreq@ietf.o= rg>
Subject: Re: [OAUTH-WG] =C3=89ric Vyncke's No Objection on draft= -ietf-oauth-jwsreq-26: (with COMMENT)

=C2=A0

Thanks, =C3=89ric.=C2=A0<= u>

=C2=A0

Reply inline:=C2=A0

=C2=A0

On Wed, Aug 5, 2020 at 5:= 47 PM =C3=89ric Vyncke via Datatracker <noreply@ietf.org> wrote:

=C3=89ric Vyncke has ente= red the following ballot position for
draft-ietf-oauth-jwsreq-26: 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 IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/<= br>


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

Thank you for the work put into this document.

Please find below a couple of non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-=C3=A9ric

=3D=3D COMMENTS =3D=3D
Should the document shepherd's write-up be updated ? It is dated Octobe= r
2016... about 4 years ago.

-- Section 5.2 --
Based on the long history of this document, is the following statement &quo= t;Many
phones in the market as of this writing still"=C2=A0 still valid ?<= /u>

=C2=A0

Yes, partly because the d= emand for the authorization request payload is becoming large these days.= =C2=A0

As we can see in the PAR = draft, we are precipitating to request_uri pattern.=C2=A0

=C2=A0


-- Section 5.2.1 --
Suggest to give a hint about the use of tfp.example.org (TFP is expanded only
in section 10.2).

=C2=A0

You are right. Perhaps it= may be better to give two examples, one with TFP with one-liner explanatio= n and another with URN that is being stored at the authorization server.=C2= =A0

=C2=A0


=3D=3D NITS =3D=3D

Please check the ID-NITS at
https://tools.ietf.org/idni= ts?url=3Dhttps://tools.ietf.org/id/draft-ietf-oauth-jwsreq-26.txt

=C2=A0

Thanks. Will do.=C2=A0=

=C2=A0





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


=C2=A0

--

Nat Sakimura (=3Dnat)<= /u>

Chairman, OpenID Foundati= on
http://nat.sakimura.= org/
@_nat_en



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en
--0000000000006a2e8a05acc3c6dd-- From nobody Thu Aug 13 08:24:16 2020 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 2ADA43A0D7C; Thu, 13 Aug 2020 08:24:11 -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 cH3lENJsHSQV; Thu, 13 Aug 2020 08:24:09 -0700 (PDT) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 121AD3A0D78; Thu, 13 Aug 2020 08:24:09 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id 3so5418221wmi.1; Thu, 13 Aug 2020 08:24:08 -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=wmfLl5gtYWvYH29MjjDDByItaVELkTxhjK0gm9YGFAo=; b=D/to+vcQ0KK4d719royXDgsE1xt2+eiGmnZajFOYooP68/gRcbXi1voeF7GlBcdClV YZ1E2HX4fw7aKrpUd684uEZudNmyiBX/aWiWHxnWxeA5he9kP/IGWLcFfb9sSRq0frVn di9lSvgl6GgF5xS7cPQFkAr4Z0Ke8xtNIRiZ1xQH032cVORwr8YYunxmzmb45LkUTRSc /vnDrC6fxYAZe81cR7f+PDcD1vVUoiQVlPycPm7XoVa8Ldb+YwWKY7l6qZViLrZvDr87 OzUeAyOglP8EPb0CBiyidgv2FeBpIhMX3+cc3FSDjW8gfzxq7OZ5wN2GpMG+QMIfqYYv taPA== 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=wmfLl5gtYWvYH29MjjDDByItaVELkTxhjK0gm9YGFAo=; b=GXnv54Y3QH6ZC9BNzM7hsXDZdMw2lFCOWjgE9tVeMotmlIdVFkPelevY3aa+aWELd6 1nJALvMEwVbMiTRqiQwY1ydIEzOiUxVepY/lJbwN7WItkPnnKl2ROBSOubmC6Jh1YSR3 6ECR9oxpmZETU3mEOuAmcH0h+4FaS+4BEH+NGfmPrWPMaksxufw4sV6QrckgWhs3Jzru YF/scBgBYbB1BSYDbOyqpVs1p6evg9IOHTLCrcjdu6EsJOyRJYQzKQEAi/O6rRID3RJa n/KNwu7yomrOKDR2XVMajAUIgHVr6ZNpa4F/NM6+QSEx6L5DzeAXjQBFmaU+NtqBN8wC 5PqQ== X-Gm-Message-State: AOAM531exZ6xVk/6GXKEgN5YM7l+mBP9oSTPa99/tSXwg1/SNeC+jV1G BmHKUJQri+Gn0EjVdbG8GfBeOgplfzX8oPPvF7Y= X-Google-Smtp-Source: ABdhPJxGKKSEDSOC9BQdv/Mikl25+LpyK8Tso2FtriFsIerrJJUGRBMSUCug2eH9MEFGiGL+kFx48I3qWqHSUORMZHk= X-Received: by 2002:a1c:6a03:: with SMTP id f3mr5069457wmc.181.1597332247239; Thu, 13 Aug 2020 08:24:07 -0700 (PDT) MIME-Version: 1.0 References: <159721898593.8472.15430392178541116697@ietfa.amsl.com> In-Reply-To: <159721898593.8472.15430392178541116697@ietfa.amsl.com> From: Nat Sakimura Date: Fri, 14 Aug 2020 00:23:55 +0900 Message-ID: To: Murray Kucherawy Cc: The IESG , oauth , oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org Content-Type: multipart/alternative; boundary="0000000000002fe18105acc3e5b6" Archived-At: Subject: Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-jwsreq-26: (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, 13 Aug 2020 15:24:11 -0000 --0000000000002fe18105acc3e5b6 Content-Type: text/plain; charset="UTF-8" Murray, Thanks very much for your comment. My replies inline: On Wed, Aug 12, 2020 at 4:56 PM Murray Kucherawy via Datatracker < noreply@ietf.org> wrote: > Murray Kucherawy has entered the following ballot position for > draft-ietf-oauth-jwsreq-26: 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 IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The directorate reviews are from 15 or more versions ago. I wonder if > returning documents like this should be sent through the directorates > again as > matter of course. > > Abstract: "... the communication through the user agents are not ..." -- > s/are/is/ > Thanks for pointing out. > > Section 1 expressly cites two IANA URLs. I suggest simply naming the > registry > or sub-registry; the URLs might not be permanent. Or if you like the URL, > do > it as a reference, as you did with [IANA.MediaType]. > > Good point. Will do. > The two bullets at the end of Section 1 toggle between "crypto" and > "cryptography". I suggest picking one, preferably the latter (as did the > rest > of the document). > Ditto. > > In Section 3, should URI and URL include references to their defining > RFCs? I > realize a reader familiar with this space probably knows those terms, but > they > seem to be the only acronyms without a reference here. > Good point. It will certainly improve the consistency. Will do. > When would an implementer legitimately disregard the SHOULD in Section 4? > E.g., in the case where there is only one client and the server in the system, it may be redundant to have `iss` and `aud`. > As Benjamin Kaduk also expressed, I'm a little puzzled by this text in > Section > 5.2: "The "request_uri" value MUST be reachable by the Authorization > Server." > Is this part of the protocol? > Please refer to my response to Ben. > > All of the subsections of Section 9 say: "This specification adds the > following > values to the "OAuth Parameters" registry established ..." but they all are > actually modifying different sub-registries. I suggest naming the > sub-registries explicitly. I realize the subsection titles have it right, > but > this line of repeated prose had me squinting a bit. > OK. Good point. Thanks. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --0000000000002fe18105acc3e5b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Murray, Thanks very much for your comment= .=C2=A0

My replies inline:=C2=A0

On Wed, Aug 12, 20= 20 at 4:56 PM Murray Kucherawy via Datatracker <noreply@ietf.org> wrote:
Murray Kucherawy has entered the following ball= ot position for
draft-ietf-oauth-jwsreq-26: 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/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ie= tf-oauth-jwsreq/



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

The directorate reviews are from 15 or more versions ago.=C2=A0 I wonder if=
returning documents like this should be sent through the directorates again= as
matter of course.

Abstract: "... the communication through the user agents are not ...&q= uot; --
s/are/is/

Thanks for pointing out.=C2= =A0
=C2=A0

Section 1 expressly cites two IANA URLs.=C2=A0 I suggest simply naming the = registry
or sub-registry; the URLs might not be permanent.=C2=A0 Or if you like the = URL, do
it as a reference, as you did with [IANA.MediaType].

Good point. Will do.=C2=A0
=C2=A0
The two bullets at the end of Section 1 toggle between "crypto" a= nd
"cryptography".=C2=A0 I suggest picking one, preferably the latte= r (as did the rest
of the document).

Ditto.=C2=A0
=C2=A0

In Section 3, should URI and URL include references to their defining RFCs?= =C2=A0 I
realize a reader familiar with this space probably knows those terms, but t= hey
seem to be the only acronyms without a reference here.

Good point.=C2=A0It will certainly improve the consistency.= =C2=A0 Will do.=C2=A0


When would an implementer legitimately disregard the SHOULD in Section 4?

E.g., in the case where there is only on= e client and=C2=A0 the server in the system,=C2=A0
it may be redu= ndant to have `iss` and `aud`.=C2=A0


As Benjamin Kaduk also expressed, I'm a little puzzled by this text in = Section
5.2: "The "request_uri" value MUST be reachable by the Autho= rization Server."
Is this part of the protocol?

Please re= fer to my response to Ben.=C2=A0
=C2=A0

All of the subsections of Section 9 say: "This specification adds the = following
values to the "OAuth Parameters" registry established ..." b= ut they all are
actually modifying different sub-registries.=C2=A0 I suggest naming the
sub-registries explicitly.=C2=A0 I realize the subsection titles have it ri= ght, but
this line of repeated prose had me squinting a bit.
OK. Good point. Thanks.=C2=A0
=C2=A0



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


--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en
--0000000000002fe18105acc3e5b6-- From nobody Thu Aug 13 13:27:56 2020 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 D2FBD3A10FB; Thu, 13 Aug 2020 13:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 Uz24VRZEkiXc; Thu, 13 Aug 2020 13:27:53 -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 B070C3A10F8; Thu, 13 Aug 2020 13:27:52 -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 07DKRkvX018215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 16:27:49 -0400 Date: Thu, 13 Aug 2020 13:27:46 -0700 From: Benjamin Kaduk To: Nat Sakimura Cc: The IESG , oauth , oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org Message-ID: <20200813202746.GD92412@kduck.mit.edu> References: <159716117548.28832.15844996438952874291@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (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, 13 Aug 2020 20:27:55 -0000 Hi Nat, Also inline. On Thu, Aug 13, 2020 at 11:25:27PM +0900, Nat Sakimura wrote: > Thanks Benjamin. > My replies inline below: > On Wed, Aug 12, 2020 at 12:53 AM Benjamin Kaduk via Datatracker > wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-oauth-jwsreq-26: 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 IESG DISCUSS and COMMENT positions. > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the many updates as we worked through the issues. > > Let's also add a note about "whose JWT Claims Set holds the JSON encoded > OAuth 2.0 authorization request parameters" to the definition of Request > Object in Section 2.1 (in addition to the note in the Introduction); my > apologies for not including that when I suggested the change to the > Introduction. > > Sure. Thanks for pointing out. > > Please update the Content-Length in the example in Section 5.2.3. > > Ditto. Thanks for both of these. > > Section 4 > > The client determines the algorithms used to sign and encrypt request > objects. This decision can be based on metadata the client > registered via dynamic client registration [RFC7591] using the > parameters "request_object_signing_alg", > "request_object_encryption_alg", "request_object_encryption_enc" as > defined in the the IANA "OAuth Dynamic Client Registration Metadata" > registry [IANA.OAuth.Parameters] established by [RFC7591]. > > I had to read this ("this decision can be based on [...]") a few times > to understand it. If I understand correctly, the idea is that the > client will register with the AS the keys it will use for constructing > the JAR, and in that way the AS has a binding from JAR-signing key to > the specific client and request. So it's true that the decision of what > key to use "can be based on" the metadata that the client registered, in > that deciding to use a different key than the registered one(s) is > likely to cause the AS to reject the request, but that's perhaps not the > main point. Would it work to instead just say that "The keys used to > sign and encrypt request objects (and thus, the algorithms that can be > used with those keys) can be registered via dynamic client registration > [...]"? > > This paragraph is just talking about the algorithms and not the keys > themselves. > Keys are obtained through jwks_uri registered through the dynreg. > It could have multiple keys in it. > This paragraph is in some sense putting constraints on what algorithms the > client can choose. > I agree that the sentence is super long and difficult to parse. > I will think about the way to rephrase. Okay. (I do not have any good ideas right now.) > > Section 5.2 > > The contents of the resource referenced by the URI MUST be a Request > Object, unless the URI was provided to the client by the > Authorization Server. The "request_uri" value MUST be either URN as > defined in RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of > RFC7230 [RFC7230] . The "request_uri" value MUST be reachable by the > Authorization Server. > > I defer to my ART-area colleagues, but I'm not sure what it means for a > URN URI to be "reachable"; is this requirement intended to only apply to > the "https:" case? > > Again, it may be a phrasing problem, but the AS need to be able to obtain > the content of the request object that is represented by the URN. That's > what it is being expressed by "reachable". If there is a better > expression, I am open to adopting it. Oops, I see my question was badly written. There are three relevant choices/distinctions, but I assumed only two when I wrote the above. (1) Is the URI provided to the client by the AS or not (2) Is the "request_uri" a URN or an "https" URI (3) Is the "request_uri" value reachable by the AS I asked how (3) related to (2), but really I meant to ask how (3) related to (1). That is, if the AS provides the URI, in some sense there does not need to be an "actual resource" that would be "reachable" by someone with the URI. However, the answer to (2) seems to be independent of the answer to (1), in that a URI not provided by the AS can still be a URN, so the requirement of reachability will apply regardless of the answer to question (2). Accordingly, I no longer think there's an opportunity for tightening up the description here. Sorry for the noise! > Section 5.2.1 > > It is possible for the Request Object to include values that are to > be revealed only to the Authorization Server. As such, the > "request_uri" MUST have appropriate entropy for its lifetime. For > > Is there a good reference for what the lifetime of such a request might > be? Perhaps I've been reading too much of GNAP, but my intuition is > that much of the time these requests will be single-use, and I don't > have as clear of a picture for when they might persist longer. There > are also potential security considerations for long-lived request > objects, in terms of making sure that there is a binding between the > client's intent to use a given request object for a given request, the > user's authorization, etc. > > This can actually be use-case dependent. > In the majority of the case, it will be pretty short. > But at the time, it may be possible for the client to push the request > object to the AS not by the user action but on its own and wait for user > action after notifying the user. In such a case, it could be pretty long, > I imagine. Ah, I see; thanks. > > Section 5.2.3 > > (side note) I'd consider updating the timestamps in the example response > (and perhaps moving to Apache 2.4+ as well?). > > OK. Good point. > > > Section 6.x > > (nit) I suggest consistency in subsection headings, so, e.g., "JWE > Encrypted Request Object" and "JWS Signed Request Object". > > Good point. > > > Section 6.2 > > The Authorization Server MUST perform the signature validation of the > JSON Web Signature [RFC7515] signed request object. For this, the > "alg" Header Parameter in its JOSE Header MUST match the value of the > pre-registered algorithm. The signature MUST be validated against > the appropriate key for that "client_id" and algorithm. > > This text suggests that pre-registration is mandatory, whereas up in > Section 4 the client's choice of algorithm was merely something that > "can be based on [metadata registered via dynamic registration]". I > know that dynamic registration is not the only kind of registration > possible, but we may want to wordsmith one (or both) location to improve > the consistency. > > Good point. I will work on it but also I would welcome a concrete proposal > on it as well. I am not 100% sure I know or remember all the relevant details, but to talk through a few things: IIUC, some form of client registration is required, since for a public client we don't have any credentials that would make the request object usable. This means that we require either static provisioning or dynamic registration, in which case section 4 could talk about something like "this decision can be based on metadata the client registered via dynamic client registration [...] or statically provisioned along with the client's registration at the AS". > > Section 6.3 > > I'd suggest reiterating here the requirement to verify "client_id" > consistency between Request Object and request parameters. > > OK. > > > Section 10 > > I'd consider reiterating the security importance (i.e., what breaks if > you don't apply the check) of a few key compliance requirements and > which entity is responsible for enforcing them: > > - the "request" and "request_uri" parameters MUST NOT be included in > request objects, from Section 4 > > - The request object has the mime-type > "application/oauth.authz.req+jwt", also from Section 4 > > - The client_id in the request object has to match the client_id from > the request query parameters, from Section 5 > > - The AS must only use parameters from the request object, even if the > client has duplicated them in the query parameters, also from Section > 5 > > OK. > > > Section 10.2 > > (e) When a third party, such as a Trust Framework Provider(TFP), > provides an endpoint that provides a Request Object URI in > exchange for a Request Object. The same requirements as (b) and > (c) above apply. In addition, the Authorization Server MUST > > The (b) case is "the symmetric key for JWE encryption"; do we mean "(c) > and (d)" here? > > Good point. Let me check with John and get back to you. > > > Section 10.3 > > I'm not sure whether the key point of this section is "the following > endpoints are RECOMMENDED [...] to use this practice" or "an extension > specification should be created as a measure to address the risk". That > is, can a deployment unilaterally apply the message-position and > intended-interaction-endpoint protections now, or is there need for > additional specification work first? > > It can be covered by operational rules to some extent but I believe having > an extension spec would make things more explicit and less error-prone. Okay. (I can't argue with that conclusion!) > > Section 10.4 > > I'm not sure how much of this is distinct from the Request URI Rewrite > discussed in Section 10.4.2, but having the request object contents be > in a separately dereferenceable URI introduces risk of the dereferenced > Request Object being dissociated from the triggering request. (This > could happen due to internal error on the client or service hosting the > requested URI or content skew over time, in addition to a request URI > rewrite.) Having an externally provided single-use nonce in the reqest > object would provide a mitigation, but it also (if I understand > correctly) not compatible with all of the envisioned use cases for JAR. > > Hmm. Current implementations since it is out of OIDC has nonce, I > believe. > I need to think a bit about this. Okay. (Thanks for the reminder that OIDC has the nonce; I had forgotten that.) > > Section 10.5 > > Should the rejection of "alg":"none" be limited to the > require_signed_request_object case, or universally applied? > > I believe it is for the case require_signed_request_object is true. > > > Section 12.1 > > (2) (Translation Process) The client uses the client credential that > it got to push the request object to the TFP to get the > "request_uri". > > If I understand correctly, the TFP also verifies that the request object > is consistent with the claims the client is eligible for based on the > certification step in (1). > > Yes. > Perhaps I should add text for that. I think that would be useful, thanks. > > Section 12.2.2 > > Therefore, per-user Request Object URI should be avoided. > > If I understand correctly, the only possible alternative is to have > per-request URIs (right?), as coalescing multiple user's requests into a > single request object URI seems to pose several difficulties. We could > perhaps make the recommended alternative more clear. > > Right. I will try to come up with a text for this. Maybe just "should be avoided, in favor of per-request URIs"? Perhaps that is too strong of a statement, though. Thanks again for all the updates, and my apologies that progress on this document has been so spread out in time. -Ben From nobody Thu Aug 13 14:01:19 2020 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 BE8FC3A05A7 for ; Thu, 13 Aug 2020 14:01:05 -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 QozjS7_nhw6U for ; Thu, 13 Aug 2020 14:01:01 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 32FEC3A0593 for ; Thu, 13 Aug 2020 14:01:01 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id f26so7692944ljc.8 for ; Thu, 13 Aug 2020 14:01:01 -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=DkDCNfr6dEiFmeBiQsqGfwFDU4Fm7kXTx4fnIhh9Fjs=; b=aCDgVvBS6zI/0aIFzhpKRcHHOvyAx8U93Ddnhv0kmYnCF7LOIdwvgLV3Mt6F2dWKki OA1ysJn32TsEz4JXIGRZgtrAju4kbxYSOgwi+mb8Ml1gGaPtQANgjjRr1d/FHpYvTv// Y8kufCtZWX15af1JaXroyM1L+hv79waJXog1J2QgmtCvMo52gnthkzIQ3dvT3K3JeeCV NNV+MCvIU/3Lm6JV+YjAbIiUUwO/2ML24aS74TgUSOqHaal0i7zuIASPEcTfgX8uEZY9 cY5090wDiSKM+o4emb8DdhGb84P86UTjbxEvS33gNytk9Qd/pvoc4LmWJFv6Wdt1jYVX x35w== 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=DkDCNfr6dEiFmeBiQsqGfwFDU4Fm7kXTx4fnIhh9Fjs=; b=YHV6VtYsGFPK3biFr2MN8pLUJtTAknVDJHj9ZMmYhwLAJnV41VPbYlIh/t08gMYabi PgI8ryqk/pm4P+UA7dQaPNpscx4c98fhOEFQ9CEZiXR6OZnsyKV7JEwPa9NqWsKllRuf wT5S8mUMl3HYmylgeM9Y07ZQ36uoAWkH5e5f7Zc+RKsz3JGdzwxLrbt67CV7sBgD5prh RxZeYcBDKUErMImjFetgNBnOBpBSKEzDnOZi/UMLQqKiZl+wH30XLnXlzkwgPys9uykb aAYX50818sg7B2PL1fl3xiR4XZb9S2yTkYOLJMM7bh8d9P3i0DG1b/4S3RADM9J0ZghE GE8g== X-Gm-Message-State: AOAM532JZugZnsaIFlzlIl5Uo8KBKTOrTiRiK6vAWVtuOh1fQofHP4dw vb3kEcL484QtGWhMSFwqpagBu5WuMwquq8MNYN/HcNfS937bZY+Bny7Rzft89bpJG7WecWPvkDl P7lB6wShVGg+meQ== X-Google-Smtp-Source: ABdhPJxaVJwJSxJl1j54AU7Yd9cDacKjbeD5+fP/Zwlmc82INX+6V0tICXFWMcImNo/MAH9jQFdX9S3A3If+z7/DzSU= X-Received: by 2002:a2e:83d5:: with SMTP id s21mr2379722ljh.280.1597352459333; Thu, 13 Aug 2020 14:00:59 -0700 (PDT) MIME-Version: 1.0 References: <159717903728.5275.9808713434051601265@ietfa.amsl.com> In-Reply-To: <159717903728.5275.9808713434051601265@ietfa.amsl.com> From: Brian Campbell Date: Thu, 13 Aug 2020 15:00:33 -0600 Message-ID: To: Benjamin Kaduk Cc: The IESG , oauth , oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org Content-Type: multipart/alternative; boundary="000000000000eb940f05acc899db" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (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, 13 Aug 2020 21:01:06 -0000 --000000000000eb940f05acc899db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While some discussion of why explicit typing was not used might be useful to have, that thread started with a request for security considerations prohibiting use of the "sub" with a client ID value. Because such a request JWT could be repurposed for JWT client authentication. And explicit typing wouldn't help in that situation. On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [updated to note that, per > https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0eaE/ > and the JWT BCP (RFC 8725), some discussion of why explicit typing is not > used would be in order] > > --=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._ --000000000000eb940f05acc899db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

While some discussion of why explicit typing was not used might be usefu= l to have, that thread started with a request for security considerations p= rohibiting use of the "sub" with a client ID value. Because such = a request JWT could be repurposed for JWT client authentication. And expli= cit typing wouldn't help in that situation.

On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatrac= ker <noreply@ietf.= org> wrote:

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

[updated to note that, per h= ttps://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0eaE/=
and the JWT BCP (RFC 8725), some discussion of why explicit typing is not u= sed would be in order]


<= 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. --000000000000eb940f05acc899db-- From nobody Thu Aug 13 14:59:16 2020 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 3C3783A083D; Thu, 13 Aug 2020 14:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 yQ_3Dm6KtWLR; Thu, 13 Aug 2020 14:59:09 -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 B94FB3A083B; Thu, 13 Aug 2020 14:59:08 -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 07DLx4kO018013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 17:59:06 -0400 Date: Thu, 13 Aug 2020 14:59:03 -0700 From: Benjamin Kaduk To: Brian Campbell Cc: The IESG , oauth , oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org Message-ID: <20200813215903.GE92412@kduck.mit.edu> References: <159717903728.5275.9808713434051601265@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (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, 13 Aug 2020 21:59:10 -0000 Oops, that's my bad. Thanks for the correction -- I've linked to your message in the datatracker (but didn't bother to have the datatracker send a third copy of my updated-again ballot position). -Ben On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote: > While some discussion of why explicit typing was not used might be useful > to have, that thread started with a request for security considerations > prohibiting use of the "sub" with a client ID value. Because such a request > JWT could be repurposed for JWT client authentication. And explicit typing > wouldn't help in that situation. > > On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > [updated to note that, per > > https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0eaE/ > > and the JWT BCP (RFC 8725), some discussion of why explicit typing is not > > used would be in order] > > > > > > -- > _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._ From nobody Thu Aug 13 16:00:10 2020 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 B1FC73A091B; Thu, 13 Aug 2020 15:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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 (1024-bit key) header.d=microsoft.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 T1-TsxERrmrY; Thu, 13 Aug 2020 15:59:05 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650129.outbound.protection.outlook.com [40.107.65.129]) (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 3459F3A091D; Thu, 13 Aug 2020 15:59:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=csnzAXRGsJvkLO8cS1cw/y5T6ObNbRvnrqGC8cFVuMTuqaaBFr688yYPzVwe1uEgM0gfS/kAqEioK6XPmUQdTwaUmqrQbJK+pke4oOHDzQo8uKJhk8qTNv1bTcWgpApzgktSLtcVwekfeKPP1NB87z7lip0OVDZQllk9UOaLkyc1HUSTSl9Cj47sFyGKuuKEofjyHwTRLXNgW5YVhpo4vkBTNlXv73QfTdlhLj5ycT7XYMGr8QabrT66DRuLVYeZXfr8c/Bzy+JjEwMEOcq5ZiJCQkbYRVK6Lbp97KlJySbGsSJ+N6D1W5iJwvvIZON0FvNbTF2OAtCXokTGQhd4EQ== 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=Qsd4aln5bj2eBEJALIcyNDAbUVNNo7kcQ6ZuDX1SUJw=; b=fzfUJPNWlLo4vcTi+WwII8WwDwufvPQ5aET6M0/aFBvjsviqOyi7zIDk7JVAh/wiqWW/D794nNmxNloBTw71PcGqjvSVGoo2V8NysZgIzHXTPZUSGze+OPXe6nSVKfCXls4PuWk2/xfB0oe5tzklaHCZX3T3skUbcpdufkWVgn8Ros9Vcw4qnyGWhjEL/wtOeAm1lkRvCmau2d3ghrV/6b3rZjZT0wfWb34gMZ3Xw+bwfrojUuruTLCnWy3elcMDNr4f5nbVegsUbk/fvzkFyCUVoBDO9glDycAxxrIwWH53bIvnezAMSLP+hwC8xzNfLY/G8wRPznNv6iOjW1nx6w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qsd4aln5bj2eBEJALIcyNDAbUVNNo7kcQ6ZuDX1SUJw=; b=GmH0dUnLnEVOdDJ4JOef7h90FkD6HcTX1Sph+YXbf1xYUIjfHwoa0/GLpt/b6tnz87ZEBnuMSpNEHhuXQrdmj7Aa203TlAu93y3e3GA5QcHWJPaxPTTsnKV+ttE6VSTU0Fy6DQrsVTKe9B93DTo1b5PAPtGSdo0O23zfJp81Otc= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0893.namprd00.prod.outlook.com (2603:10b6:208:fd::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.0; Thu, 13 Aug 2020 22:58:58 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::e9b3:c850:e214:627e]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::e9b3:c850:e214:627e%6]) with mapi id 15.20.3326.000; Thu, 13 Aug 2020 22:58:58 +0000 From: Mike Jones To: Benjamin Kaduk , Brian Campbell CC: "draft-ietf-oauth-jwsreq@ietf.org" , "oauth-chairs@ietf.org" , The IESG , oauth Thread-Topic: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT) Thread-Index: AdZxxVKnjSQXMUSOT4WoNI/yLDFAqg== Date: Thu, 13 Aug 2020 22:58:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-13T22:54:52Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=38474cca-947b-45dd-a8c6-74bfe46720c7; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.88.234] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: cdb934fd-4eb2-4faa-4c0e-08d83fdc766f x-ms-traffictypediagnostic: MN2PR00MB0893: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oFqRtfypyL1ivy62I+w5LM4WbUjRu7y9agyb2F+o1IoV7rq1qbTzHIfCpay74DZt/AkZgYL+Cv+6uRHRDKvH3ZcrPLm4NFWec4PFF88DqDCU4xpHXmofUp0m3jETtCiFMmmzYTRPTtHIVpnqBRWy12IHx2IrkdgXmkmgyKQlSFccoX9n23Djbo8p3drB3OsN/GlqGOxoim328lngXP/Ivi0ySfrMDK5EuBl10E08pLI6ipAJk7Uqjv4+ShWHANfMCGgQDNp//tp5qH2GQ0uIoLukXAD6CB8BdJ+uc57OaRj39pfh5TovyASnGZt/4Tge6rj4DMMxO1CYXBtofUGHSQ2SVdduY1jjr5QVvYyV2ZuWZXX9KX34VBPX0tGuF4EmsIt+23YV/Z2SkySNaHCLIw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(366004)(346002)(376002)(39860400002)(26005)(186003)(2906002)(71200400001)(478600001)(53546011)(966005)(110136005)(316002)(54906003)(10290500003)(86362001)(8936002)(8676002)(6506007)(4326008)(7696005)(66946007)(64756008)(66476007)(5660300002)(76116006)(66446008)(66556008)(52536014)(82960400001)(82950400001)(33656002)(9686003)(55016002)(83380400001)(8990500004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: RrmnUqFuMP+cLYfF2UA2eV1xl6Cna7DL0Aia9rZ8+JusQiF64Sq8ArRKtmgflwuF8bEHoE97DK7FUyOZu/U32fwwAy/Avlfdr1WARFiPzeWxe01HIiG2lJuufuuvUVQKUSBHW+JcPoLAvkBFfToywocXwAHkLSlGS8UWYVnKdiQLhS9Q88Ub0eR/tpFia05cNAl1TSFNjf8wUhygScG+uESbF4O1ONAqpPVagoPmHEh//wkmDO0kGSTyhYv5TjyWaN/PUD1SVIw19u4EeVaB3K5hrKuZDqvvimtjFAfdde27I0W4fkYcPZpL85hwVWVk0ju3tdlF5/i5fD2l/S2QY/hyHuq7vzMyiJ5yRswOFWmPDr1IL11nMovNnobXM05N9XoYjMVWbBlP0j4z88CDzP+Fd1B1KLk0hza+Gpu7e3LqKe30HZzZPCePzkAtFeU42rJWfsJTSgLlOn9Y0T36G0YSC28zEt5eSE8jky5SPEp6xUjOblxgNLb6nEUnWXmwyS9f4Qip03xZhExtN4TMt2pywWTAwoJO1xKRLaFmfzbDdc72UJJR0VAN4qyCwJbDFAbfLDhfKVjb2S8qTwXgTqqWsKgOytfLesIqfPAE9QjcroKvGqyDDf8NGfoe0aTkwQ1hwRKecGzS5hGkP06CSw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0686.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cdb934fd-4eb2-4faa-4c0e-08d83fdc766f X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2020 22:58:58.4489 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: S154wvOtkPDjv4gsZxuF3joo0k49uyANh68MTyGys0+vEwKdqT7tfjvVvFvJTOPsn7tflWw4BDM/kPQ8cqOAig== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0893 Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (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, 13 Aug 2020 22:59:07 -0000 At Nat's request, I've created a pull request addressing Cross-JWT Confusio= n security considerations. It addresses both Brian's comment and the IESG = comments about explicit typing. See the full PR at https://bitbucket.org/N= at/oauth-jwsreq/pull-requests/10. See the source diffs at https://bitbucke= t.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-working-group-comm= ents/diff#chg-draft-ietf-oauth-jwsreq.xml. Please review! This is only the first commit, albeit, one that addresses some of the must = substantive issues. More commits will follow addressing additional IESG co= mments. -- Mike -----Original Message----- From: OAuth On Behalf Of Benjamin Kaduk Sent: Thursday, August 13, 2020 2:59 PM To: Brian Campbell Cc: draft-ietf-oauth-jwsreq@ietf.org; oauth-chairs@ietf.org; The IESG ; oauth Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-j= wsreq-26: (with COMMENT) Oops, that's my bad. Thanks for the correction -- I've linked to your mess= age in the datatracker (but didn't bother to have the datatracker send a th= ird copy of my updated-again ballot position). -Ben On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote: > While some discussion of why explicit typing was not used might be=20 > useful to have, that thread started with a request for security=20 > considerations prohibiting use of the "sub" with a client ID value.=20 > Because such a request JWT could be repurposed for JWT client=20 > authentication. And explicit typing wouldn't help in that situation. >=20 > On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker <=20 > noreply@ietf.org> wrote: >=20 > > > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > > > > [updated to note that, per > > https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0 > > eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit=20 > > typing is not used would be in order] > > > > >=20 > -- > _CONFIDENTIALITY NOTICE: This email may contain confidential and=20 > privileged material for the sole use of the intended recipient(s). Any=20 > review, use, distribution or disclosure by others is strictly=20 > prohibited.=A0 If you have received this communication in error, please=20 > notify the sender immediately by e-mail and delete the message and any=20 > file attachments from your computer. Thank you._ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Aug 14 03:59:41 2020 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 CBDA33A0B30; Fri, 14 Aug 2020 03:59: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=unavailable 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 nXqnN08-0PtL; Fri, 14 Aug 2020 03:59:32 -0700 (PDT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 A25DF3A0F3C; Fri, 14 Aug 2020 03:59:31 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id s195so4982706ybc.8; Fri, 14 Aug 2020 03:59:31 -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=PsDSTFMQjOuUcKy59uyBR0q2iPA/YFpGKvayb77jfDE=; b=HGDEjfrSuhEIesVmSnbT3EGwNO6aGNilwv7Rp4nDnXsvoYP/EjpbIR7SBWVMn+evRb 55R3whuMlgdT5C4UoBRjfngMqpt8mPUDVHp5bMcHi9ectcy5avRdaJ2qfQENnJRXevVp vcZ8WG0ZBR8nsBFdxDKVPdB7psYWCLxbtxDUQGTPlxwLp6AxUov8s9BQJ5r95ByftTx3 B4K33F9SavLQqZceTcE7VdJbnk2mhFdD7+ezXQxpqHVUq4mJjSQ2zpbuMnCGy4MwcBRV YB6aJ6KU869u/K9sS1YnuSSFrMhUiyUApEGn6FS5/EtoZyLA70Ob8ee2A/Ze0P3sUrWh IqzQ== 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=PsDSTFMQjOuUcKy59uyBR0q2iPA/YFpGKvayb77jfDE=; b=J8OoxZowzAcceRyv9oblEl80VRs9DQJfYhjKYg/TStK74B+bQgpa26Q2a9V0K1Vdbe uIIXasJXdNJ47VJN/3o0wn/cPQQ1yBALdsYag4SgRHByBkcW/iHasKFTHLAuV9c4qSfz STlCrB7B1W5Rz8hgosLeThlKFNIUSQEmt0qGwuOWFLQY/i9rJf88yBqaFgSydEL51dmd ByLEM64Q/Z+Eh4eMbVnvNpeHi6EUMDTaMN+zRzoussQqREndioDm+a0RxPb7jdATzjB3 PeW7Y+Q+nxYf97J3BQTdY31uWhkjaeWuWZ8Prr/p0ZCIaaLfH3LfLUBqEhWhAHtskZUg 7WNw== X-Gm-Message-State: AOAM532zLw2zX9aoqn50iurmY+Wa646pYsB7lyNgfXq1QwHqnBgQ442w x+a5aHKRTfwYsxi2yRNAS7YxuMgiMJt7GiEtlg== X-Google-Smtp-Source: ABdhPJzpIC7hZIie2WBzXqQMztZkfAqbcSlw/dJWH5g254LAcWkl1BsQs4yrzYz+gL9CQ+SacbWzv9r4dURU4+fJFTc= X-Received: by 2002:a25:257:: with SMTP id 84mr2725157ybc.259.1597402769596; Fri, 14 Aug 2020 03:59:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Filip Skokan Date: Fri, 14 Aug 2020 12:58:53 +0200 Message-ID: To: Mike Jones , Nat Sakimura Cc: Benjamin Kaduk , Brian Campbell , The IESG , oauth , "oauth-chairs@ietf.org" , "draft-ietf-oauth-jwsreq@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a525d705acd45066" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (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: Fri, 14 Aug 2020 10:59:35 -0000 --000000000000a525d705acd45066 Content-Type: text/plain; charset="UTF-8" Hi Mike, Nat, I thought we would go as far as making these normative requirements - if the Request Object includes a sub claim with the value of the client_id the AS MUST reject the request - if the Request Object is explicitly typed (typ) its value MUST be ... First rejects client assertions to be passed as Request Objects. Second rejects all future typed JWT profiles from being used as Request Objects without worrying about the claims they may or may not contain. Or is that breaking? S pozdravem, *Filip Skokan* On Fri, 14 Aug 2020 at 00:59, Mike Jones wrote: > At Nat's request, I've created a pull request addressing Cross-JWT > Confusion security considerations. It addresses both Brian's comment and > the IESG comments about explicit typing. See the full PR at > https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10. See the source > diffs at > https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-working-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml. > Please review! > > This is only the first commit, albeit, one that addresses some of the must > substantive issues. More commits will follow addressing additional IESG > comments. > > -- Mike > > -----Original Message----- > From: OAuth On Behalf Of Benjamin Kaduk > Sent: Thursday, August 13, 2020 2:59 PM > To: Brian Campbell > Cc: draft-ietf-oauth-jwsreq@ietf.org; oauth-chairs@ietf.org; The IESG < > iesg@ietf.org>; oauth > Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on > draft-ietf-oauth-jwsreq-26: (with COMMENT) > > Oops, that's my bad. Thanks for the correction -- I've linked to your > message in the datatracker (but didn't bother to have the datatracker send > a third copy of my updated-again ballot position). > > -Ben > > On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote: > > While some discussion of why explicit typing was not used might be > > useful to have, that thread started with a request for security > > considerations prohibiting use of the "sub" with a client ID value. > > Because such a request JWT could be repurposed for JWT client > > authentication. And explicit typing wouldn't help in that situation. > > > > On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker < > > noreply@ietf.org> wrote: > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > [updated to note that, per > > > https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0 > > > eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit > > > typing is not used would be in order] > > > > > > > > > > -- > > _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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000a525d705acd45066 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mike, Nat,

I thought we w= ould go as far as making these normative requirements
  • if = the Request Object includes a sub claim with the value of the client_id the= AS MUST reject the request
  • if the Request Object is explicitly typ= ed (typ) its value MUST be ...
First rejects client ass= ertions to be passed as Request Objects. Second rejects all future typed JW= T profiles from being used as Request Objects without worrying about the cl= aims they may or may not contain.

Or is that break= ing?

S pozdravem,
Filip Skokan
<= /div>

On Fri, 14 Aug 2020 at 00:59, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org= > wrote:
= At Nat's request, I've created a pull request addressing Cross-JWT = Confusion security considerations.=C2=A0 It addresses both Brian's comm= ent and the IESG comments about explicit typing.=C2=A0 See the full PR at <= a href=3D"https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10" rel=3D"n= oreferrer" target=3D"_blank">https://bitbucket.org/Nat/oauth-jwsreq/pull-re= quests/10.=C2=A0 See the source diffs at https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-= working-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml.=C2=A0 Plea= se review!

This is only the first commit, albeit, one that addresses some of the must = substantive issues.=C2=A0 More commits will follow addressing additional IE= SG comments.

=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 -- Mike

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Benjamin Kaduk
Sent: Thursday, August 13, 2020 2:59 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: d= raft-ietf-oauth-jwsreq@ietf.org; oauth-chairs@ietf.org; The IESG <iesg@ietf.org>; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oau= th-jwsreq-26: (with COMMENT)

Oops, that's my bad.=C2=A0 Thanks for the correction -- I've linked= to your message in the datatracker (but didn't bother to have the data= tracker send a third copy of my updated-again ballot position).

-Ben

On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote:
> While some discussion of why explicit typing was not used might be > useful to have, that thread started with a request for security
> considerations prohibiting use of the "sub" with a client ID= value.
> Because such a request JWT could be repurposed for JWT client
> authentication. And explicit typing wouldn't help in that situatio= n.
>
> On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org= > wrote:
>
> >
> > -----------------------------------------------------------------= ---
> > --
> > COMMENT:
> > -----------------------------------------------------------------= ---
> > --
> >
> > [updated to note that, per
> > https://mailarchive.ie= tf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0
> > eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit =
> > typing is not used would be in order]
> >
> >
>
> --
> _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.=C2=A0 If you have received this communication in error, pl= ease
> 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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000a525d705acd45066-- From nobody Sat Aug 15 02:08:18 2020 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 83E493A0BB3 for ; Sat, 15 Aug 2020 02:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-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 gaxBl8xrXLTC for ; Sat, 15 Aug 2020 02:08:15 -0700 (PDT) Received: from p3plsmtpa11-01.prod.phx3.secureserver.net (p3plsmtpa11-01.prod.phx3.secureserver.net [68.178.252.102]) (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 3647B3A03F6 for ; Sat, 15 Aug 2020 02:08:15 -0700 (PDT) Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id 6sAfkxyBbHQQg6sAfkNmFD; Sat, 15 Aug 2020 02:08:14 -0700 X-CMAE-Analysis: v=2.3 cv=dP7YZ9Rb c=1 sm=1 tr=0 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=xtERp6CFAAAA:8 a=LS6YZpeZAAAA:8 a=CkCSO0AFltHdHg0NKiIA:9 a=UR4Lg1ZIErWInBm7:21 a=3IWyPOl_RQVtTCPE:21 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=H9G8NMRP0_dzQifCOcoA:9 a=QJSBtuG2y9jNsrI-:21 a=_VuVndoiVJT99tJ2:21 a=kDDuPKFVSR0Q3G_W:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=IRr2vCDBpksuBOXhfkKu:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: oauth@ietf.org References: From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd X-Enigmail-Draft-Status: N11100 Organization: Connect2id Ltd. Message-ID: Date: Sat, 15 Aug 2020 12:08:12 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050908070906080700000000" X-CMAE-Envelope: MS4wfPHXgaYTr2x/Eq8ARmtBPlecj7FGU41plCkoARC/9CIMIz/vTbduDyFD1vxXt1PwRh66GcHXf7xhMQ4gikkyBWxkFiN0hJVQG9kes36NjbwLM/UXPg0k eGSZS52jcPpwEyQC1d+A3WC4vv4oSTxhm3t4pdPNUOH+kJ1mPbGemX7/ Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (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: Sat, 15 Aug 2020 09:08:18 -0000 This is a cryptographically signed message in MIME format. --------------ms050908070906080700000000 Content-Type: multipart/alternative; boundary="------------F32E1E21EEB13A3B522C4822" Content-Language: en-US This is a multi-part message in MIME format. --------------F32E1E21EEB13A3B522C4822 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 to make the "typ" check, as Filip suggested, normative, as existing client and RP deployments with undefined "typ" will not be affected. New deployments should be encouraged to type the JWT, and thus be made safer.= Regarding the "sub !=3D client_id" check -- could a simple rejection of all JWTs with "sub" present suffice? I find it difficult to imagine what else a client could end up setting the "sub" claim to, if it does end up populating it for some reason. Rejecting JWTs with "sub=3Dclient_id" or "sub" present will break deployments where a client for some reason sets the "typical" JWT claims, and "sub" is a typical one, but if those deployments happen to accept client_secret_jwt or private_key_jwt client authentication, they could well be vulnerable to cross-JWT confusion attacks. Vladimir On 14/08/2020 13:58, Filip Skokan wrote: > Hi Mike, Nat, > > I thought we would go as far as making these normative requirements > > * if the Request Object includes a sub claim with the value of the > client_id the AS MUST reject the request > * if the Request Object is explicitly typed (typ) its value MUST be .= =2E. > > First rejects client assertions to be passed as Request Objects. > Second rejects all future typed JWT profiles from being used as > Request Objects without worrying about the claims they may or may not > contain. > > Or is that breaking? > > S pozdravem, > *Filip Skokan* > > > On Fri, 14 Aug 2020 at 00:59, Mike Jones > > wrote: > > At Nat's request, I've created a pull request addressing Cross-JWT > Confusion security considerations.=C2=A0 It addresses both Brian's > comment and the IESG comments about explicit typing.=C2=A0 See the = full > PR at https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10.=C2=A0= > See the source diffs at > https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-ies= g-and-working-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml.=C2=A0 > Please review! > > This is only the first commit, albeit, one that addresses some of > the must substantive issues.=C2=A0 More commits will follow address= ing > additional IESG comments. > > =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 -- Mike > > -----Original Message----- > From: OAuth > On Behalf Of Benjamin Kaduk > Sent: Thursday, August 13, 2020 2:59 PM > To: Brian Campbell > > Cc: draft-ietf-oauth-jwsreq@ietf.org > ; oauth-chairs@ietf.org > ; The IESG >; oauth > > Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on > draft-ietf-oauth-jwsreq-26: (with COMMENT) > > Oops, that's my bad.=C2=A0 Thanks for the correction -- I've linked= to > your message in the datatracker (but didn't bother to have the > datatracker send a third copy of my updated-again ballot position).= > > -Ben > > On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote: > > While some discussion of why explicit typing was not used might b= e > > useful to have, that thread started with a request for security > > considerations prohibiting use of the "sub" with a client ID valu= e. > > Because such a request JWT could be repurposed for JWT client > > authentication. And explicit typing wouldn't help in that situati= on. > > > > On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker < > > noreply@ietf.org > wrote: > > > > > > > > > -------------------------------------------------------------------= - > > > -- > > > COMMENT: > > > > -------------------------------------------------------------------= - > > > -- > > > > > > [updated to note that, per > > > > https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o= 0 > > > eaE/ and the JWT BCP (RFC 8725), some discussion of why explici= t > > > typing is not used would be in order] > > > > > > > > > > -- > > _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.=C2=A0 If you have received this communication in erro= r, > 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 > > _______________________________________________ > 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 --=20 Vladimir Dzhuvinov --------------F32E1E21EEB13A3B522C4822 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

+1 to make the "typ" check, as Filip suggested, normative, as existing client and RP deployments with undefined "typ" will not be affected. New deployments should be encouraged to type the JWT, and thus be made safer.


Regarding the "sub !=3D client_id" check -- could a simple rejection of all JWTs with "sub" present suffice?

I find it difficult to imagine what else a client could end up setting the "sub" claim to, if it does end up populating it for some reason.

Rejecting JWTs with "sub=3Dclient_id" or "sub" present will break deployments where a client for some reason sets the "typical" JWT claims, and "sub" is a typical one, but if those deployments happen to accept client_secret_jwt or private_key_jwt client authentication, they could well be vulnerable to cross-JWT confusion attacks.


Vladimir

On 14/08/2020 13:58, Filip Skokan wrote:
Hi Mike, Nat,

I thought we would go as far as making these normative requirements
  • if the Request Object includes a sub claim with the value of the client_id the AS MUST reject the request
  • if the Request Object is explicitly typed (typ) its value MUST be ...
First rejects client assertions to be passed as Request Objects. Second rejects all future typed JWT profiles from being used as Request Objects without worrying about the claims they may or may not contain.

Or is that breaking?

S pozdravem,
Filip Skokan


On Fri, 14 Aug 2020 at 00:5= 9, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org&g= t; wrote:
= At Nat's request, I've created a pull request addressing Cross-JWT Confusion security considerations.=C2=A0 It addresses= both Brian's comment and the IESG comments about explicit typing.=C2=A0 See the full PR at https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10.=C2=A0 See the source diffs at https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and= -working-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml.=C2=A0 Please review!

This is only the first commit, albeit, one that addresses some of the must substantive issues.=C2=A0 More commits will follow addressing additional IESG comments.

=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 -- Mike

-----Original Message-----
From: OAuth <oauth-bounces@ietf= =2Eorg> On Behalf Of Benjamin Kaduk
Sent: Thursday, August 13, 2020 2:59 PM
To: Brian Campbell <bcampbell@pingidentity.com> Cc: draft-ietf-oauth-j= wsreq@ietf.org; oauth-chairs@ietf.org; The IESG <iesg@ietf.org>; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

Oops, that's my bad.=C2=A0 Thanks for the correction -- I've li= nked to your message in the datatracker (but didn't bother to have the datatracker send a third copy of my updated-again ballot position).

-Ben

On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote:
> While some discussion of why explicit typing was not used might be
> useful to have, that thread started with a request for security
> considerations prohibiting use of the "sub" with a client ID value.
> Because such a request JWT could be repurposed for JWT client
> authentication. And explicit typing wouldn't help in that situation.
>
> On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker <
> noreply@ietf.org> wrote:
>
> >
> > ---------------------------------------------------------------= -----
> > --
> > COMMENT:
> > ---------------------------------------------------------------= -----
> > --
> >
> > [updated to note that, per
> > https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0=
> > eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit
> > typing is not used would be in order]
> >
> >
>
> --
> _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.=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 attachments from your computer. Thank you._

_______________________________________________
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

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

--=20
Vladimir Dzhuvinov
--------------F32E1E21EEB13A3B522C4822-- --------------ms050908070906080700000000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA4MTUwOTA4MTJaMC8G CSqGSIb3DQEJBDEiBCDM0sYU0UTn0qQiZi8eWIwuqbTMPaCDF3s1TeJrxgSZozBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAFsOLeEJysLtV+eEGZbfvvCAuZGFMCQCPUPT3SbcLGjttmV3 hM2UL/h+BRha2+7nA43FcdV+/5Hd2qB8uxZ08R1k/1c7gLa6sIEAjugwKI27I1rxbdMzzWGJ qjxzV85eigH0ogdcdn85QQvk04vN4049wlO8q629xJaxodh8yUeW2Dn5q+X5Ck0aVaMm02OL a4UWYwPsFbH9DK6BzP2FoM68vkBzsnAJfmKRatX32QVMa72cHLzQVrA2m1tQSmG2lLNwipoc VD17pAk4D39JMi6oZdEiQO8YcKEU/PLeOYNrA7Y8fZZ2W0aKl3cwDmgGXLgRYYuBdJLmjxNC TAk5DDYAAAAAAAA= --------------ms050908070906080700000000-- From nobody Sat Aug 15 09:27:34 2020 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 7E6113A0F9D for ; Sat, 15 Aug 2020 09:27:33 -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, 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 (1024-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 JjYK_ZG3CopH for ; Sat, 15 Aug 2020 09:27:31 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 5ADD03A0F25 for ; Sat, 15 Aug 2020 09:27:31 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id k18so9266159qtm.10 for ; Sat, 15 Aug 2020 09:27:31 -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=3B9cjXUU+EpJeczfu+8AK4A04kUIWvWwjJjcaoZyF00=; b=kSElZGZSPHrkG88LvPfOLcBQwKbhK28kVNSSgkcyYhMkQb0XVx+0e8UycykGTInf/A 77R5Qre4o5DU0TWDR1m7rr1vKNdNS9RknapPD9qGJ2955PqL4k5aFxh8TB0MppK1Fy8N vAyXvmhzufcRru/kZW7wocAWLLsb4vECBITBI= 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=3B9cjXUU+EpJeczfu+8AK4A04kUIWvWwjJjcaoZyF00=; b=e3QrszF+wbEETPlEnKyukmFkrxX+5QJpoW/rQk3CCZl4Km2DX1D8wCK9NNN5XEbsSb rqaMJQeqyODV3VxrfH8SGjLZheKtD5teY2HxrsLvhyAGNze8mIXPISV/aoH8HLAn9wGZ 5P5I6VYBxn8bYQtybyUTSUQN3hmjlYRgUQbnWbLgTSvl6wWUpP2003vu9KjgGYjVC3pC umpV6FEP13tpWUTVcp73TA0sjO/fiCamN5FACRH9ILyEfrXi9rgMeFxza9z+ks+rU88U tM1zYsDMI4yJSkHndPNrprMz5lwChwjk6TUQTiMMTtlTKl9kWxBq6KDaVptZ/8i/oOiK hq8g== X-Gm-Message-State: AOAM532OU7Srq96lntGLrscx1uONEPJsFB4bFkmSJ937ZFsk80y8Is/S anm+YwpGJcfPoUZ06+oLMT1RedKSFIXnYGL5v2Lh/hNK0ntU X-Google-Smtp-Source: ABdhPJwvW3IHS6XwT5EFgY8PuVlxJOMp2Dv9bQs2O6K53uihPhfM0os1xImLrKgg4L3p78tJLQy3r8xB9RaCaNOi0JQ= X-Received: by 2002:ac8:688e:: with SMTP id m14mr6827143qtq.7.1597508850232; Sat, 15 Aug 2020 09:27:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Sat, 15 Aug 2020 18:27:19 +0200 Message-ID: To: Vladimir Dzhuvinov Cc: oauth Content-Type: multipart/alternative; boundary="0000000000008b484e05aced03c0" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (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: Sat, 15 Aug 2020 16:27:34 -0000 --0000000000008b484e05aced03c0 Content-Type: text/plain; charset="UTF-8" In the case of > if the Request Object includes a sub claim with the value of the client_id > the AS MUST reject the request What would the expectation be in terms of a client_credentials grant? >From experience, the *sub *is frequently populated with the client_id value and the client_id is not used. Which would mean breaking for that type of grant wouldn't it? Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Sat, Aug 15, 2020 at 11:08 AM Vladimir Dzhuvinov wrote: > +1 to make the "typ" check, as Filip suggested, normative, as existing > client and RP deployments with undefined "typ" will not be affected. New > deployments should be encouraged to type the JWT, and thus be made safer. > > > Regarding the "sub != client_id" check -- could a simple rejection of all > JWTs with "sub" present suffice? > > I find it difficult to imagine what else a client could end up setting the > "sub" claim to, if it does end up populating it for some reason. > > Rejecting JWTs with "sub=client_id" or "sub" present will break > deployments where a client for some reason sets the "typical" JWT claims, > and "sub" is a typical one, but if those deployments happen to accept > client_secret_jwt or private_key_jwt client authentication, they could well > be vulnerable to cross-JWT confusion attacks. > > > Vladimir > On 14/08/2020 13:58, Filip Skokan wrote: > > Hi Mike, Nat, > > I thought we would go as far as making these normative requirements > > - if the Request Object includes a sub claim with the value of the > client_id the AS MUST reject the request > - if the Request Object is explicitly typed (typ) its value MUST be ... > > First rejects client assertions to be passed as Request Objects. Second > rejects all future typed JWT profiles from being used as Request Objects > without worrying about the claims they may or may not contain. > > Or is that breaking? > > S pozdravem, > *Filip Skokan* > > > On Fri, 14 Aug 2020 at 00:59, Mike Jones 40microsoft.com@dmarc.ietf.org> wrote: > >> At Nat's request, I've created a pull request addressing Cross-JWT >> Confusion security considerations. It addresses both Brian's comment and >> the IESG comments about explicit typing. See the full PR at >> https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10. See the source >> diffs at >> https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-working-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml. >> Please review! >> >> This is only the first commit, albeit, one that addresses some of the >> must substantive issues. More commits will follow addressing additional >> IESG comments. >> >> -- Mike >> >> -----Original Message----- >> From: OAuth On Behalf Of Benjamin Kaduk >> Sent: Thursday, August 13, 2020 2:59 PM >> To: Brian Campbell >> Cc: draft-ietf-oauth-jwsreq@ietf.org; oauth-chairs@ietf.org; The IESG < >> iesg@ietf.org>; oauth >> Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on >> draft-ietf-oauth-jwsreq-26: (with COMMENT) >> >> Oops, that's my bad. Thanks for the correction -- I've linked to your >> message in the datatracker (but didn't bother to have the datatracker send >> a third copy of my updated-again ballot position). >> >> -Ben >> >> On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote: >> > While some discussion of why explicit typing was not used might be >> > useful to have, that thread started with a request for security >> > considerations prohibiting use of the "sub" with a client ID value. >> > Because such a request JWT could be repurposed for JWT client >> > authentication. And explicit typing wouldn't help in that situation. >> > >> > On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker < >> > noreply@ietf.org> wrote: >> > >> > > >> > > -------------------------------------------------------------------- >> > > -- >> > > COMMENT: >> > > -------------------------------------------------------------------- >> > > -- >> > > >> > > [updated to note that, per >> > > https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0 >> > > eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit >> > > typing is not used would be in order] >> > > >> > > >> > >> > -- >> > _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 >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > -- > Vladimir Dzhuvinov > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000008b484e05aced03c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the case of
if the Request Object includes a sub claim with the value of the= client_id the AS MUST reject the request

W= hat would the expectation be in terms of a client_credentials grant?
<= div>
From experience, the sub is frequently=C2=A0popul= ated with the client_id value and the client_id is not used. Which would me= an breaking for that type of grant wouldn't it?
=C2=A0
<= div>

War= ren Parad

Founder, CTO

Secure yo= ur user data and complete your authorization architecture. Implement=C2=A0<= /span>Authress.


On Sat, Aug 15, 2020 at 11:08 AM Vladimir Dzhuvinov = <vladimir@connect2id.com&= gt; wrote:
=20 =20 =20

+1 to make the "typ" check, as Filip suggested, normative,= as existing client and RP deployments with undefined "typ" wil= l not be affected. New deployments should be encouraged to type the JWT, and thus be made safer.


Regarding the "sub !=3D client_id" check -- could a simple rejection of all JWTs with "sub" present suffice?

I find it difficult to imagine what else a client could end up setting the "sub" claim to, if it does end up populating it= for some reason.

Rejecting JWTs with "sub=3Dclient_id" or "sub" p= resent will break deployments where a client for some reason sets the "typical&quo= t; JWT claims, and "sub" is a typical one, but if those deployment= s happen to accept client_secret_jwt or private_key_jwt client authentication, they could well be vulnerable to cross-JWT confusion attacks.


Vladimir

On 14/08/2020 13:58, Filip Skokan wrote:
=20
Hi Mike, Nat,

I thought we would go as far as making these normative requirements
  • if the Request Object includes a sub claim with the value of the client_id the AS MUST reject the request
  • if the Request Object is explicitly typed (typ) its value MUST be ...
First rejects client assertions to be passed as Request Objects. Second rejects all future typed JWT profiles from being used as Request Objects without worrying about the claims they may or may not contain.

Or is that breaking?

S pozdravem,
Filip Skokan


On Fri, 14 Aug 2020 at 00:59, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
At Nat's request, I've created a pull request addressing Cross-JWT Confusion security considerations.=C2=A0 It addresses both Brian's comment and the IESG comments about explicit typing.=C2=A0 See the full PR at ht= tps://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10.=C2=A0 See the source diffs at https://b= itbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-working-gro= up-comments/diff#chg-draft-ietf-oauth-jwsreq.xml.=C2=A0 Please review!

This is only the first commit, albeit, one that addresses some of the must substantive issues.=C2=A0 More commits will follow addressing additional IESG comments.

=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 -- Mike

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Benjamin Kaduk
Sent: Thursday, August 13, 2020 2:59 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: draft-ietf-oauth-jwsreq@ietf.org; oauth-= chairs@ietf.org; The IESG <iesg@ietf.= org>; oauth <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

Oops, that's my bad.=C2=A0 Thanks for the correction -- I'= ;ve linked to your message in the datatracker (but didn't bother to have the datatracker send a third copy of my updated-again ballot position).

-Ben

On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote:
> While some discussion of why explicit typing was not used might be
> useful to have, that thread started with a request for security
> considerations prohibiting use of the "sub" with a= client ID value.
> Because such a request JWT could be repurposed for JWT client
> authentication. And explicit typing wouldn't help in tha= t situation.
>
> On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker <
> norepl= y@ietf.org> wrote:
>
> >
> > -----------------------------------------------------------------= ---
> > --
> > COMMENT:
> > -----------------------------------------------------------------= ---
> > --
> >
> > [updated to note that, per
> > https://mail= archive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0
> > eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit
> > typing is not used would be in order]
> >
> >
>
> --
> _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.=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 attachments from your computer. Thank you._

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

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

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

--=20
Vladimir Dzhuvinov
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000008b484e05aced03c0-- From nobody Sat Aug 15 09:41:39 2020 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 F350C3A0743 for ; Sat, 15 Aug 2020 09:41:36 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=microsoft.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 wfWpU03ktip9 for ; Sat, 15 Aug 2020 09:41:34 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640119.outbound.protection.outlook.com [40.107.64.119]) (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 4892F3A073E for ; Sat, 15 Aug 2020 09:41:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jdnTnOKpF7e1i8sCgGoOPcfZuoagVLCq9gpKx93U/AJO5bVWqvIPY7HPpI947ixht+C5DDD9Xsq3x8vipuLOFBVwg7NXgPky9anE3dOMz96XOO6PfoipRuDd/EbZ8z++o8vzCkvcPdmiaCg1s9AL8KV5NeyJozmMJtoihUpmW4y7jNdEtX8euv3f+nEsxAOKRFA5NEPbflT8/JNzUhnFyn3Wxcv4mBThNThzmEzygFWM9eNgWOTlBmap+agfAmRv6zyZVcng+7ZgAJWRpGLKMmZhnux6/Vh/lkMqSm1AW/l0hKe1FvQ3vNAf7Kr2CBj3jvS3iKydHSpEbol5LqWGEg== 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=qtfKVN43+h5QE0zxuEBfSEg71X+CdiSmcPOpKiUdPUk=; b=c+cqA/5YIbwBNpmqowAVX9NUfb7oZQPEV4EbGYdZt9qMPKaXMWlGvsFOabbWdChgb/Sud/ju0Z4O5wGKdzrPpZRioM2Y1l6ROr4vl/Sm3YfoxNyP/hGEgRi/+aqtcfIL1yUKE/SnKQdnyAk7ru7cdWtAPhMj0CjbhwHZxquGesT9svdx6/HKBniEm3PVqCcXx0mrpEpDcd3et54yvFoEXkNHNhYZiR2ENYh0tA0YVWstgnX2Pz3LUninfOvy1Qidn/5ahU3sRrjes7zIF6AzTP/42crmGxgOAt3ZZqPey42qxAVPRD9je2Bc4zqsYNJI0Wm4CDMXy213U8sb6zqgDQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qtfKVN43+h5QE0zxuEBfSEg71X+CdiSmcPOpKiUdPUk=; b=iwDZl5cVijM5/4zfJ4cElZBWckvE7DXrVsIXFAMY2GqiA58JPuY1pVxBgjEZhm1ez0qeylou8oZNZwFtJWPtUnbfHnHUDXBUezZd+uaPCJUB5WHKMRcbY+MPUHVI6KZP6E8e+u6k6VShzjehvfUGQU/vVgyyYyyHm/BxpO7wD5M= Received: from DM6PR00MB0684.namprd00.prod.outlook.com (2603:10b6:5:21c::8) by DM5PR00MB0424.namprd00.prod.outlook.com (2603:10b6:4:a0::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3330.0; Sat, 15 Aug 2020 16:41:29 +0000 Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::7190:18d0:8dfa:9af5]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::7190:18d0:8dfa:9af5%3]) with mapi id 15.20.3333.000; Sat, 15 Aug 2020 16:41:29 +0000 From: Mike Jones To: Vladimir Dzhuvinov , "panva.ip@gmail.com" CC: oauth Thread-Topic: [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT) Thread-Index: AdZxxVKnjSQXMUSOT4WoNI/yLDFAqgAZJM6AAC5tBQAAD1YCgAAAGHWg Date: Sat, 15 Aug 2020 16:41:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-15T16:30:03Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a902d22a-3c9c-4f88-9895-017900c2f254; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: connect2id.com; dkim=none (message not signed) header.d=none;connect2id.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.88.234] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f21703a5-5371-4132-0663-08d8413a0f5f x-ms-traffictypediagnostic: DM5PR00MB0424: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: t76qzp6HH1Kpw3Rst1a8RSvJxVzptVS9xt9+KEWt37Wv/qjwNi1MNlhb0GHyhWFm3Tc/xoofP3hOxzoDViNv52qWTXC8NfhX/QGNTKsOseGiUXENcuooBDcrjpAFBkvaTS6dpXSmzu+ptFYSPn5xK8KMeq4mMTGVIgBxi3MuZW9jrBspK3JpHvGxfVCNrYgyKVaBCyD1moUpS6ijw0GdAlJuTbLLx6eWCkR0bSK2GU3XPzSaKJVlqRnfNHkAHxI7R6J3oh1Pl5RYLR3RqXCEE1kmWkpVzcQldoBFB1al8zGQFJBqDhPvzYjtvX/qNXNMcL2iU0e/IAVWLUkEC10JQ89et1qfl6jyckAqYnRMLrmllvbjuWDEmI/LEmclBlCwel/hQsPtPKzIEK3C3hEDcw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0684.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(376002)(396003)(136003)(346002)(9686003)(4326008)(86362001)(2906002)(186003)(8676002)(10290500003)(53546011)(55016002)(6506007)(26005)(52536014)(8936002)(71200400001)(76116006)(110136005)(316002)(5660300002)(83380400001)(83080400001)(82950400001)(66946007)(66476007)(64756008)(66446008)(966005)(7696005)(478600001)(166002)(8990500004)(66556008)(82960400001)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: MSyRKbLq4eI7I5SzBmEiSMOFG71Xz/iDAUa5oBmTJyoaR2qBueVmi5iv/9VAs9Y/YiCppOpo0zk4lCMdGBPwTtW4Cj3vPckiEO7hlE8Ruo8XXsSRE9Av/sODCAjQBRDbGxu9vIR1jFzPcjdRcKY/G2SPlZf1ami0PIkDZTXsZ/HEkCpFn1iX71drShU7Z8UdNmA7juuUrbHE83PtN6MHP0oOP81xcG7/z20TUzH7esA6C08YKDdOxi47dssQitrax4GvaxIYr2sSvWWkpwVa648SrQNSRS3D3Av5x0nUC9Bz85uEXcRlttda3FVGW0/Qdn+iVi/wkbJ8ii70I9wZ3hAEeNupA86JsPG8aQe8Zw+G8meTUly78O9jft8lSn+7OAVx3tyMF6QeyE8QLfORRc7lQKNeNPzYZ9wxdikLwkTXsZte0owt5z+DI6Q4yY+hub54HZaVaMleHdchf/N2CSzAnYHAjrBTlqarO4EpSDqp04ipaYV5H4GUg9oqcM5Y631q/LI5w0ERcsuanWgYtub0iwabdwfW155A1Jq2FAmtvM0/jj/a9sE61DyTGBTMMycPpM5lnYrmI9R0gQaZOLq70quuQI9Vr1OxD2lJi8PUIKhduwK3u0Fw+ETwYweyJSzI5CnxyH4RjG8s/0MVpA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0684908CEB778DED9943E0CDF5411DM6PR00MB0684namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0684.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f21703a5-5371-4132-0663-08d8413a0f5f X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2020 16:41:29.3883 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zp3gtR//LyutaFGjj27foO7HOK1S6CoFSdyE9JF+T9DiG3bwEhbQchdGJVa2BFPC+m6WTVAnYjXaAqV7VOtfNg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0424 Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (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: Sat, 15 Aug 2020 16:41:37 -0000 --_000_DM6PR00MB0684908CEB778DED9943E0CDF5411DM6PR00MB0684namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5zd2VyaW5nIEZpbGlwIGFuZCBWbGFkaXJtaXLigJlzIHF1ZXN0aW9uIGFib3V0IGFkZGluZyBu b3JtYXRpdmUgbGFuZ3VhZ2UgYXJvdW5kIOKAnHR5cOKAnSBhbmQg4oCcc3Vi4oCdOiAgQW55dGlt ZSB5b3UgYWRkIGEgbmV3IHJlcXVpcmVkIGZlYXR1cmUsIHlvdSBhcmUgYnJlYWtpbmcgZXhpc3Rp bmcgZGVwbG95bWVudHMuICBTdXBwb3NlIHdlIGFkZGVkIHRoZSBub3JtYXRpdmUgcmVxdWlyZW1l bnQg4oCcSWYgYSDigJh0eXDigJkgaGVhZGVyIHBhcmFtZXRlciBpcyBwcmVzZW50LCBBU3MgTVVT VCByZWplY3QgdGhlIFJlcXVlc3Qgb2JqZWN0IGlmIGl0cyB2YWx1ZSBpcyBub3Qg4oCYb2F1dGgu YXV0aHoucmVxK2p3dOKAmeKAnS4gIE9uZSBjb3VsZCB0aGVuIHdyaXRlIGEgY2VydGlmaWNhdGlv biB0ZXN0IHNlbmRpbmcgdGhlIEFTIGEgZGlmZmVyZW50IOKAnHR5cOKAnSB2YWx1ZSDigJMgd2hp Y2ggdG8gcGFzcywgQVNzIHdvdWxkIGhhdmUgdG8gcmVqZWN0IHRoZSBKV1QuICBFdmVyeSBleGlz dGluZyBkZXBsb3ltZW50IHdvdWxkIGZhaWwgdGhpcyB0ZXN0ISAgVGhhdOKAmXMgZXhhY3RseSB3 aGF0IHdlIGRvbuKAmXQgd2FudCB0byBoYXZlIGhhcHBlbi4NCg0KQnJpYW4gYXNrZWQgZm9yIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zLiAgVGhlIElFU0cgYXNrZWQgZm9yIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zLiAgSSBhZGRlZCB0aGVtIGluIHRoZSBQUiDigJMgd29ya2luZyB3aXRoIE5hdCBh bmQgSm9obi4gIFRoZXkgcG9pbnQgdGhlIHdheSB0byB0aGUgZnV0dXJlIHdpdGhvdXQgYnJlYWtp bmcgZXhpc3RpbmcgZGVwbG95bWVudHMuICBUaGF04oCZcyBhcyBpdCBzaG91bGQgYmUuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN aWtlDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Yg V2FycmVuIFBhcmFkDQpTZW50OiBTYXR1cmRheSwgQXVndXN0IDE1LCAyMDIwIDk6MjcgQU0NClRv OiBWbGFkaW1pciBEemh1dmlub3YgPHZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPg0KQ2M6IG9hdXRo IDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtPQVVUSC1XR10gQmVu amFtaW4gS2FkdWsncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjY6 ICh3aXRoIENPTU1FTlQpDQoNCkluIHRoZSBjYXNlIG9mDQppZiB0aGUgUmVxdWVzdCBPYmplY3Qg aW5jbHVkZXMgYSBzdWIgY2xhaW0gd2l0aCB0aGUgdmFsdWUgb2YgdGhlIGNsaWVudF9pZCB0aGUg QVMgTVVTVCByZWplY3QgdGhlIHJlcXVlc3QNCg0KV2hhdCB3b3VsZCB0aGUgZXhwZWN0YXRpb24g YmUgaW4gdGVybXMgb2YgYSBjbGllbnRfY3JlZGVudGlhbHMgZ3JhbnQ/DQoNCkZyb20gZXhwZXJp ZW5jZSwgdGhlIHN1YiBpcyBmcmVxdWVudGx5IHBvcHVsYXRlZCB3aXRoIHRoZSBjbGllbnRfaWQg dmFsdWUgYW5kIHRoZSBjbGllbnRfaWQgaXMgbm90IHVzZWQuIFdoaWNoIHdvdWxkIG1lYW4gYnJl YWtpbmcgZm9yIHRoYXQgdHlwZSBvZiBncmFudCB3b3VsZG4ndCBpdD8NCg0KDQpbaHR0cHM6Ly9s aDYuZ29vZ2xldXNlcmNvbnRlbnQuY29tL0ROaUR4MVFHSXJTcU1QS0ROMW9LZXZ4WXV5VlJYc3Fo WGRmWk9zVzU2UmYyQTc0bVVLYkFQdHJKU053NHF5bmtTam9sdFdrUFlkQmhhWkpnMUJPNDVZT2Mx eHM2cjlLSjFmWXNOSG9nWS1uaDZoanVJbTlHQ2VCUlJ6clNjOGtXY1VTTnR1QV0NCg0KV2FycmVu IFBhcmFkDQoNCkZvdW5kZXIsIENUTw0KU2VjdXJlIHlvdXIgdXNlciBkYXRhIGFuZCBjb21wbGV0 ZSB5b3VyIGF1dGhvcml6YXRpb24gYXJjaGl0ZWN0dXJlLiBJbXBsZW1lbnQgQXV0aHJlc3M8aHR0 cHM6Ly9iaXQubHkvMzdTU08xcD4uDQoNCg0KT24gU2F0LCBBdWcgMTUsIDIwMjAgYXQgMTE6MDgg QU0gVmxhZGltaXIgRHpodXZpbm92IDx2bGFkaW1pckBjb25uZWN0MmlkLmNvbTxtYWlsdG86dmxh ZGltaXJAY29ubmVjdDJpZC5jb20+PiB3cm90ZToNCg0KKzEgdG8gbWFrZSB0aGUgInR5cCIgY2hl Y2ssIGFzIEZpbGlwIHN1Z2dlc3RlZCwgbm9ybWF0aXZlLCBhcyBleGlzdGluZyBjbGllbnQgYW5k IFJQIGRlcGxveW1lbnRzIHdpdGggdW5kZWZpbmVkICJ0eXAiIHdpbGwgbm90IGJlIGFmZmVjdGVk LiBOZXcgZGVwbG95bWVudHMgc2hvdWxkIGJlIGVuY291cmFnZWQgdG8gdHlwZSB0aGUgSldULCBh bmQgdGh1cyBiZSBtYWRlIHNhZmVyLg0KDQoNCg0KUmVnYXJkaW5nIHRoZSAic3ViICE9IGNsaWVu dF9pZCIgY2hlY2sgLS0gY291bGQgYSBzaW1wbGUgcmVqZWN0aW9uIG9mIGFsbCBKV1RzIHdpdGgg InN1YiIgcHJlc2VudCBzdWZmaWNlPw0KDQpJIGZpbmQgaXQgZGlmZmljdWx0IHRvIGltYWdpbmUg d2hhdCBlbHNlIGEgY2xpZW50IGNvdWxkIGVuZCB1cCBzZXR0aW5nIHRoZSAic3ViIiBjbGFpbSB0 bywgaWYgaXQgZG9lcyBlbmQgdXAgcG9wdWxhdGluZyBpdCBmb3Igc29tZSByZWFzb24uDQoNClJl amVjdGluZyBKV1RzIHdpdGggInN1Yj1jbGllbnRfaWQiIG9yICJzdWIiIHByZXNlbnQgd2lsbCBi cmVhayBkZXBsb3ltZW50cyB3aGVyZSBhIGNsaWVudCBmb3Igc29tZSByZWFzb24gc2V0cyB0aGUg InR5cGljYWwiIEpXVCBjbGFpbXMsIGFuZCAic3ViIiBpcyBhIHR5cGljYWwgb25lLCBidXQgaWYg dGhvc2UgZGVwbG95bWVudHMgaGFwcGVuIHRvIGFjY2VwdCBjbGllbnRfc2VjcmV0X2p3dCBvciBw cml2YXRlX2tleV9qd3QgY2xpZW50IGF1dGhlbnRpY2F0aW9uLCB0aGV5IGNvdWxkIHdlbGwgYmUg dnVsbmVyYWJsZSB0byBjcm9zcy1KV1QgY29uZnVzaW9uIGF0dGFja3MuDQoNCg0KDQpWbGFkaW1p cg0KT24gMTQvMDgvMjAyMCAxMzo1OCwgRmlsaXAgU2tva2FuIHdyb3RlOg0KSGkgTWlrZSwgTmF0 LA0KDQpJIHRob3VnaHQgd2Ugd291bGQgZ28gYXMgZmFyIGFzIG1ha2luZyB0aGVzZSBub3JtYXRp dmUgcmVxdWlyZW1lbnRzDQoNCiAgKiAgIGlmIHRoZSBSZXF1ZXN0IE9iamVjdCBpbmNsdWRlcyBh IHN1YiBjbGFpbSB3aXRoIHRoZSB2YWx1ZSBvZiB0aGUgY2xpZW50X2lkIHRoZSBBUyBNVVNUIHJl amVjdCB0aGUgcmVxdWVzdA0KICAqICAgaWYgdGhlIFJlcXVlc3QgT2JqZWN0IGlzIGV4cGxpY2l0 bHkgdHlwZWQgKHR5cCkgaXRzIHZhbHVlIE1VU1QgYmUgLi4uDQpGaXJzdCByZWplY3RzIGNsaWVu dCBhc3NlcnRpb25zIHRvIGJlIHBhc3NlZCBhcyBSZXF1ZXN0IE9iamVjdHMuIFNlY29uZCByZWpl Y3RzIGFsbCBmdXR1cmUgdHlwZWQgSldUIHByb2ZpbGVzIGZyb20gYmVpbmcgdXNlZCBhcyBSZXF1 ZXN0IE9iamVjdHMgd2l0aG91dCB3b3JyeWluZyBhYm91dCB0aGUgY2xhaW1zIHRoZXkgbWF5IG9y IG1heSBub3QgY29udGFpbi4NCg0KT3IgaXMgdGhhdCBicmVha2luZz8NCg0KUyBwb3pkcmF2ZW0s DQpGaWxpcCBTa29rYW4NCg0KDQpPbiBGcmksIDE0IEF1ZyAyMDIwIGF0IDAwOjU5LCBNaWtlIEpv bmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86 NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpBdCBOYXQncyByZXF1ZXN0 LCBJJ3ZlIGNyZWF0ZWQgYSBwdWxsIHJlcXVlc3QgYWRkcmVzc2luZyBDcm9zcy1KV1QgQ29uZnVz aW9uIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLiAgSXQgYWRkcmVzc2VzIGJvdGggQnJpYW4ncyBj b21tZW50IGFuZCB0aGUgSUVTRyBjb21tZW50cyBhYm91dCBleHBsaWNpdCB0eXBpbmcuICBTZWUg dGhlIGZ1bGwgUFIgYXQgaHR0cHM6Ly9iaXRidWNrZXQub3JnL05hdC9vYXV0aC1qd3NyZXEvcHVs bC1yZXF1ZXN0cy8xMC4gIFNlZSB0aGUgc291cmNlIGRpZmZzIGF0IGh0dHBzOi8vYml0YnVja2V0 Lm9yZy9OYXQvb2F1dGgtandzcmVxL3B1bGwtcmVxdWVzdHMvMTAvYWRkcmVzcy1pZXNnLWFuZC13 b3JraW5nLWdyb3VwLWNvbW1lbnRzL2RpZmYjY2hnLWRyYWZ0LWlldGYtb2F1dGgtandzcmVxLnht bC4gIFBsZWFzZSByZXZpZXchDQoNClRoaXMgaXMgb25seSB0aGUgZmlyc3QgY29tbWl0LCBhbGJl aXQsIG9uZSB0aGF0IGFkZHJlc3NlcyBzb21lIG9mIHRoZSBtdXN0IHN1YnN0YW50aXZlIGlzc3Vl cy4gIE1vcmUgY29tbWl0cyB3aWxsIGZvbGxvdyBhZGRyZXNzaW5nIGFkZGl0aW9uYWwgSUVTRyBj b21tZW50cy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBCZW5qYW1p biBLYWR1aw0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMywgMjAyMCAyOjU5IFBNDQpUbzogQnJp YW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxA cGluZ2lkZW50aXR5LmNvbT4+DQpDYzogZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXFAaWV0Zi5vcmc8 bWFpbHRvOmRyYWZ0LWlldGYtb2F1dGgtandzcmVxQGlldGYub3JnPjsgb2F1dGgtY2hhaXJzQGll dGYub3JnPG1haWx0bzpvYXV0aC1jaGFpcnNAaWV0Zi5vcmc+OyBUaGUgSUVTRyA8aWVzZ0BpZXRm Lm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4+OyBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRv Om9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEJlbmphbWluIEthZHVr J3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTI2OiAod2l0aCBDT01N RU5UKQ0KDQpPb3BzLCB0aGF0J3MgbXkgYmFkLiAgVGhhbmtzIGZvciB0aGUgY29ycmVjdGlvbiAt LSBJJ3ZlIGxpbmtlZCB0byB5b3VyIG1lc3NhZ2UgaW4gdGhlIGRhdGF0cmFja2VyIChidXQgZGlk bid0IGJvdGhlciB0byBoYXZlIHRoZSBkYXRhdHJhY2tlciBzZW5kIGEgdGhpcmQgY29weSBvZiBt eSB1cGRhdGVkLWFnYWluIGJhbGxvdCBwb3NpdGlvbikuDQoNCi1CZW4NCg0KT24gVGh1LCBBdWcg MTMsIDIwMjAgYXQgMDM6MDA6MzNQTSAtMDYwMCwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6DQo+IFdo aWxlIHNvbWUgZGlzY3Vzc2lvbiBvZiB3aHkgZXhwbGljaXQgdHlwaW5nIHdhcyBub3QgdXNlZCBt aWdodCBiZQ0KPiB1c2VmdWwgdG8gaGF2ZSwgdGhhdCB0aHJlYWQgc3RhcnRlZCB3aXRoIGEgcmVx dWVzdCBmb3Igc2VjdXJpdHkNCj4gY29uc2lkZXJhdGlvbnMgcHJvaGliaXRpbmcgdXNlIG9mIHRo ZSAic3ViIiB3aXRoIGEgY2xpZW50IElEIHZhbHVlLg0KPiBCZWNhdXNlIHN1Y2ggYSByZXF1ZXN0 IEpXVCBjb3VsZCBiZSByZXB1cnBvc2VkIGZvciBKV1QgY2xpZW50DQo+IGF1dGhlbnRpY2F0aW9u LiBBbmQgZXhwbGljaXQgdHlwaW5nIHdvdWxkbid0IGhlbHAgaW4gdGhhdCBzaXR1YXRpb24uDQo+ DQo+IE9uIFR1ZSwgQXVnIDExLCAyMDIwIGF0IDI6NTAgUE0gQmVuamFtaW4gS2FkdWsgdmlhIERh dGF0cmFja2VyIDwNCj4gbm9yZXBseUBpZXRmLm9yZzxtYWlsdG86bm9yZXBseUBpZXRmLm9yZz4+ IHdyb3RlOg0KPg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAtLQ0KPiA+IENPTU1FTlQ6DQo+ ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPiAtLQ0KPiA+DQo+ID4gW3VwZGF0ZWQgdG8gbm90ZSB0aGF0LCBw ZXINCj4gPiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoL0xxdTE1 TUppa3laclhabzVxc1RQSzJvMA0KPiA+IGVhRS8gYW5kIHRoZSBKV1QgQkNQIChSRkMgODcyNSks IHNvbWUgZGlzY3Vzc2lvbiBvZiB3aHkgZXhwbGljaXQNCj4gPiB0eXBpbmcgaXMgbm90IHVzZWQg d291bGQgYmUgaW4gb3JkZXJdDQo+ID4NCj4gPg0KPg0KPiAtLQ0KPiBfQ09ORklERU5USUFMSVRZ IE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kDQo+IHByaXZp bGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 KHMpLiBBbnkNCj4gcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90 aGVycyBpcyBzdHJpY3RseQ0KPiBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2UNCj4gbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueQ0KPiBmaWxl IGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ll8NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlz dA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aA0KDQotLQ0KDQpWbGFkaW1pciBEemh1dmlub3YNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCg== --_000_DM6PR00MB0684908CEB778DED9943E0CDF5411DM6PR00MB0684namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIw NjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEyODc4NTM3ODk7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi05MzYxOTIzODA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Oi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2 MCI+QW5zd2VyaW5nIEZpbGlwIGFuZCBWbGFkaXJtaXLigJlzIHF1ZXN0aW9uIGFib3V0IGFkZGlu ZyBub3JtYXRpdmUgbGFuZ3VhZ2UgYXJvdW5kIOKAnHR5cOKAnSBhbmQg4oCcc3Vi4oCdOiZuYnNw OyBBbnl0aW1lIHlvdSBhZGQgYSBuZXcgcmVxdWlyZWQgZmVhdHVyZSwgeW91IGFyZSBicmVha2lu ZyBleGlzdGluZyBkZXBsb3ltZW50cy4mbmJzcDsgU3VwcG9zZSB3ZSBhZGRlZCB0aGUgbm9ybWF0 aXZlDQogcmVxdWlyZW1lbnQg4oCcSWYgYSDigJh0eXDigJkgaGVhZGVyIHBhcmFtZXRlciBpcyBw cmVzZW50LCBBU3MgTVVTVCByZWplY3QgdGhlIFJlcXVlc3Qgb2JqZWN0IGlmIGl0cyB2YWx1ZSBp cyBub3Qg4oCYb2F1dGguYXV0aHoucmVxK2p3dOKAmeKAnS4mbmJzcDsgT25lIGNvdWxkIHRoZW4g d3JpdGUgYSBjZXJ0aWZpY2F0aW9uIHRlc3Qgc2VuZGluZyB0aGUgQVMgYSBkaWZmZXJlbnQg4oCc dHlw4oCdIHZhbHVlIOKAkyB3aGljaCB0byBwYXNzLCBBU3Mgd291bGQgaGF2ZSB0byByZWplY3QN CiB0aGUgSldULiZuYnNwOyA8aT5FdmVyeSBleGlzdGluZyBkZXBsb3ltZW50IHdvdWxkIGZhaWwg dGhpcyB0ZXN0ITwvaT4mbmJzcDsgVGhhdOKAmXMgZXhhY3RseSB3aGF0IHdlIGRvbuKAmXQgd2Fu dCB0byBoYXZlIGhhcHBlbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkJy aWFuIGFza2VkIGZvciBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4mbmJzcDsgVGhlIElFU0cgYXNr ZWQgZm9yIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLiZuYnNwOyBJIGFkZGVkIHRoZW0gaW4gdGhl IFBSIOKAkyB3b3JraW5nIHdpdGggTmF0IGFuZCBKb2huLiZuYnNwOyBUaGV5IHBvaW50IHRoZSB3 YXkgdG8gdGhlIGZ1dHVyZSB3aXRob3V0IGJyZWFraW5nIGV4aXN0aW5nIGRlcGxveW1lbnRzLiZu YnNwOw0KIFRoYXTigJlzIGFzIGl0IHNob3VsZCBiZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBN aWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBPQXV0 aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCldh cnJlbiBQYXJhZDxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgQXVndXN0IDE1LCAyMDIwIDk6 MjcgQU08YnI+DQo8Yj5Ubzo8L2I+IFZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7dmxhZGltaXJAY29u bmVjdDJpZC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5BTF0gUmU6IFtPQVVUSC1XR10gQmVuamFt aW4gS2FkdWsncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjY6ICh3 aXRoIENPTU1FTlQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRo ZSBjYXNlIG9mPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPmlmIHRoZSBSZXF1ZXN0IE9iamVjdCBpbmNsdWRlcyBhIHN1YiBjbGFpbSB3aXRo IHRoZSB2YWx1ZSBvZiB0aGUgY2xpZW50X2lkIHRoZSBBUyBNVVNUIHJlamVjdCB0aGUgcmVxdWVz dDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V2hhdCB3b3VsZCB0aGUgZXhwZWN0YXRpb24gYmUgaW4gdGVybXMgb2YgYSBjbGllbnRf Y3JlZGVudGlhbHMgZ3JhbnQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkZyb20gZXhwZXJpZW5jZSwgdGhlIDxiPnN1YiA8L2I+aXMgZnJlcXVl bnRseSZuYnNwO3BvcHVsYXRlZCB3aXRoIHRoZSBjbGllbnRfaWQgdmFsdWUgYW5kIHRoZSBjbGll bnRfaWQgaXMgbm90IHVzZWQuIFdoaWNoIHdvdWxkIG1lYW4gYnJlYWtpbmcgZm9yIHRoYXQgdHlw ZSBvZiBncmFudCB3b3VsZG4ndCBpdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNl bGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpjb2xs YXBzZSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6c29s aWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo1 LjBwdCA1LjBwdCA1LjBwdCA1LjBwdCI+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJv cmRlci1kaXY7Ym9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGlu Ij4NCjxwIHN0eWxlPSJtYXJnaW46MGluO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj aztib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj48aW1nIHdpZHRoPSIx OTkiIGhlaWdodD0iMzQiIHN0eWxlPSJ3aWR0aDoyLjA3MjlpbjtoZWlnaHQ6LjM1NDFpbiIgaWQ9 Il94MDAwMF9pMTAyNSIgc3JjPSJodHRwczovL2xoNi5nb29nbGV1c2VyY29udGVudC5jb20vRE5p RHgxUUdJclNxTVBLRE4xb0tldnhZdXlWUlhzcWhYZGZaT3NXNTZSZjJBNzRtVUtiQVB0ckpTTnc0 cXlua1Nqb2x0V2tQWWRCaGFaSmcxQk80NVlPYzF4czZyOUtKMWZZc05Ib2dZLW5oNmhqdUltOUdD ZUJSUnpyU2M4a1djVVNOdHVBIj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvdGQ+ DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVy LWxlZnQ6bm9uZTtwYWRkaW5nOjUuMHB0IDUuMHB0IDUuMHB0IDUuMHB0O292ZXJmbG93OmhpZGRl biI+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOnNvbGlk IHdoaXRlIDEuMHB0O2JvcmRlci1ib3R0b206bm9uZTtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+ DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPldhcnJlbiBQ YXJhZDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1zby1l bGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLXRv cDpub25lO3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO2Jv cmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Gb3VuZGVyLCBDVE88L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+U2Vj dXJlIHlvdXIgdXNlciBkYXRhIGFuZCBjb21wbGV0ZSB5b3VyIGF1dGhvcml6YXRpb24gYXJjaGl0 ZWN0dXJlLiBJbXBsZW1lbnQmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9iaXQubHkvMzdT U08xcCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5BdXRo cmVzczwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gU2F0LCBBdWcgMTUsIDIwMjAgYXQgMTE6MDggQU0gVmxhZGltaXIgRHpodXZpbm92 ICZsdDs8YSBocmVmPSJtYWlsdG86dmxhZGltaXJAY29ubmVjdDJpZC5jb20iPnZsYWRpbWlyQGNv bm5lY3QyaWQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPHA+KzEgdG8gbWFrZSB0aGUgJnF1b3Q7dHlwJnF1b3Q7IGNoZWNrLCBh cyBGaWxpcCBzdWdnZXN0ZWQsIG5vcm1hdGl2ZSwgYXMgZXhpc3RpbmcgY2xpZW50IGFuZCBSUCBk ZXBsb3ltZW50cyB3aXRoIHVuZGVmaW5lZCAmcXVvdDt0eXAmcXVvdDsgd2lsbCBub3QgYmUgYWZm ZWN0ZWQuIE5ldyBkZXBsb3ltZW50cyBzaG91bGQgYmUgZW5jb3VyYWdlZCB0byB0eXBlIHRoZSBK V1QsIGFuZCB0aHVzIGJlIG1hZGUgc2FmZXIuPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwPlJlZ2FyZGluZyB0aGUgJnF1b3Q7c3ViICE9IGNsaWVudF9pZCZxdW90 OyBjaGVjayAtLSBjb3VsZCBhIHNpbXBsZSByZWplY3Rpb24gb2YgYWxsIEpXVHMgd2l0aCAmcXVv dDtzdWImcXVvdDsgcHJlc2VudCBzdWZmaWNlPzxvOnA+PC9vOnA+PC9wPg0KPHA+SSBmaW5kIGl0 IGRpZmZpY3VsdCB0byBpbWFnaW5lIHdoYXQgZWxzZSBhIGNsaWVudCBjb3VsZCBlbmQgdXAgc2V0 dGluZyB0aGUgJnF1b3Q7c3ViJnF1b3Q7IGNsYWltIHRvLCBpZiBpdCBkb2VzIGVuZCB1cCBwb3B1 bGF0aW5nIGl0IGZvciBzb21lIHJlYXNvbi48bzpwPjwvbzpwPjwvcD4NCjxwPlJlamVjdGluZyBK V1RzIHdpdGggJnF1b3Q7c3ViPWNsaWVudF9pZCZxdW90OyBvciAmcXVvdDtzdWImcXVvdDsgcHJl c2VudCB3aWxsIGJyZWFrIGRlcGxveW1lbnRzIHdoZXJlIGEgY2xpZW50IGZvciBzb21lIHJlYXNv biBzZXRzIHRoZSAmcXVvdDt0eXBpY2FsJnF1b3Q7IEpXVCBjbGFpbXMsIGFuZCAmcXVvdDtzdWIm cXVvdDsgaXMgYSB0eXBpY2FsIG9uZSwgYnV0IGlmIHRob3NlIGRlcGxveW1lbnRzIGhhcHBlbiB0 byBhY2NlcHQgY2xpZW50X3NlY3JldF9qd3Qgb3IgcHJpdmF0ZV9rZXlfand0IGNsaWVudCBhdXRo ZW50aWNhdGlvbiwNCiB0aGV5IGNvdWxkIHdlbGwgYmUgdnVsbmVyYWJsZSB0byBjcm9zcy1KV1Qg Y29uZnVzaW9uIGF0dGFja3MuPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwPlZsYWRpbWlyPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gMTQvMDgvMjAyMCAxMzo1OCwgRmlsaXAgU2tva2FuIHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTWlrZSwg TmF0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIHRob3VnaHQgd2Ugd291bGQgZ28gYXMgZmFyIGFzIG1ha2luZyB0aGVzZSBub3JtYXRpdmUg cmVxdWlyZW1lbnRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCmlm IHRoZSBSZXF1ZXN0IE9iamVjdCBpbmNsdWRlcyBhIHN1YiBjbGFpbSB3aXRoIHRoZSB2YWx1ZSBv ZiB0aGUgY2xpZW50X2lkIHRoZSBBUyBNVVNUIHJlamVjdCB0aGUgcmVxdWVzdDxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCmlm IHRoZSBSZXF1ZXN0IE9iamVjdCBpcyBleHBsaWNpdGx5IHR5cGVkICh0eXApIGl0cyB2YWx1ZSBN VVNUIGJlIC4uLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Rmlyc3QgcmVqZWN0cyBjbGllbnQgYXNzZXJ0aW9ucyB0byBiZSBwYXNzZWQg YXMgUmVxdWVzdCBPYmplY3RzLiBTZWNvbmQgcmVqZWN0cyBhbGwgZnV0dXJlIHR5cGVkIEpXVCBw cm9maWxlcyBmcm9tIGJlaW5nIHVzZWQgYXMgUmVxdWVzdCBPYmplY3RzIHdpdGhvdXQgd29ycnlp bmcgYWJvdXQgdGhlIGNsYWltcyB0aGV5IG1heSBvciBtYXkgbm90IGNvbnRhaW4uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9yIGlzIHRoYXQg YnJlYWtpbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5TIHBvemRyYXZlbSw8YnI+DQo8Yj5GaWxpcCBTa29rYW48L2I+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIDE0IEF1 ZyAyMDIwIGF0IDAwOjU5LCBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzPTxhIGhyZWY9Im1h aWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MG1p Y3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IE5hdCdzIHJlcXVl c3QsIEkndmUgY3JlYXRlZCBhIHB1bGwgcmVxdWVzdCBhZGRyZXNzaW5nIENyb3NzLUpXVCBDb25m dXNpb24gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuJm5ic3A7IEl0IGFkZHJlc3NlcyBib3RoIEJy aWFuJ3MgY29tbWVudCBhbmQgdGhlIElFU0cgY29tbWVudHMgYWJvdXQgZXhwbGljaXQgdHlwaW5n LiZuYnNwOyBTZWUgdGhlIGZ1bGwgUFIgYXQNCjxhIGhyZWY9Imh0dHBzOi8vYml0YnVja2V0Lm9y Zy9OYXQvb2F1dGgtandzcmVxL3B1bGwtcmVxdWVzdHMvMTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHBzOi8vYml0YnVja2V0Lm9yZy9OYXQvb2F1dGgtandzcmVxL3B1bGwtcmVxdWVzdHMvMTA8L2E+ LiZuYnNwOyBTZWUgdGhlIHNvdXJjZSBkaWZmcyBhdA0KPGEgaHJlZj0iaHR0cHM6Ly9iaXRidWNr ZXQub3JnL05hdC9vYXV0aC1qd3NyZXEvcHVsbC1yZXF1ZXN0cy8xMC9hZGRyZXNzLWllc2ctYW5k LXdvcmtpbmctZ3JvdXAtY29tbWVudHMvZGlmZiNjaGctZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEu eG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2JpdGJ1Y2tldC5vcmcvTmF0L29hdXRoLWp3 c3JlcS9wdWxsLXJlcXVlc3RzLzEwL2FkZHJlc3MtaWVzZy1hbmQtd29ya2luZy1ncm91cC1jb21t ZW50cy9kaWZmI2NoZy1kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS54bWw8L2E+LiZuYnNwOyBQbGVh c2UgcmV2aWV3ITxicj4NCjxicj4NClRoaXMgaXMgb25seSB0aGUgZmlyc3QgY29tbWl0LCBhbGJl aXQsIG9uZSB0aGF0IGFkZHJlc3NlcyBzb21lIG9mIHRoZSBtdXN0IHN1YnN0YW50aXZlIGlzc3Vl cy4mbmJzcDsgTW9yZSBjb21taXRzIHdpbGwgZm9sbG93IGFkZHJlc3NpbmcgYWRkaXRpb25hbCBJ RVNHIGNvbW1lbnRzLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtLSBNaWtlPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBPQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9h PiZndDsgT24gQmVoYWxmIE9mIEJlbmphbWluIEthZHVrPGJyPg0KU2VudDogVGh1cnNkYXksIEF1 Z3VzdCAxMywgMjAyMCAyOjU5IFBNPGJyPg0KVG86IEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVm PSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpk cmFmdC1pZXRmLW9hdXRoLWp3c3JlcUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LWll dGYtb2F1dGgtandzcmVxQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpvYXV0aC1jaGFp cnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1jaGFpcnNAaWV0Zi5vcmc8L2E+OyBU aGUgSUVTRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5pZXNnQGlldGYub3JnPC9hPiZndDs7IG9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gQmVuamFtaW4gS2FkdWsncyBObyBPYmplY3Rpb24gb24gZHJh ZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjY6ICh3aXRoIENPTU1FTlQpPGJyPg0KPGJyPg0KT29wcywg dGhhdCdzIG15IGJhZC4mbmJzcDsgVGhhbmtzIGZvciB0aGUgY29ycmVjdGlvbiAtLSBJJ3ZlIGxp bmtlZCB0byB5b3VyIG1lc3NhZ2UgaW4gdGhlIGRhdGF0cmFja2VyIChidXQgZGlkbid0IGJvdGhl ciB0byBoYXZlIHRoZSBkYXRhdHJhY2tlciBzZW5kIGEgdGhpcmQgY29weSBvZiBteSB1cGRhdGVk LWFnYWluIGJhbGxvdCBwb3NpdGlvbikuPGJyPg0KPGJyPg0KLUJlbjxicj4NCjxicj4NCk9uIFRo dSwgQXVnIDEzLCAyMDIwIGF0IDAzOjAwOjMzUE0gLTA2MDAsIEJyaWFuIENhbXBiZWxsIHdyb3Rl Ojxicj4NCiZndDsgV2hpbGUgc29tZSBkaXNjdXNzaW9uIG9mIHdoeSBleHBsaWNpdCB0eXBpbmcg d2FzIG5vdCB1c2VkIG1pZ2h0IGJlIDxicj4NCiZndDsgdXNlZnVsIHRvIGhhdmUsIHRoYXQgdGhy ZWFkIHN0YXJ0ZWQgd2l0aCBhIHJlcXVlc3QgZm9yIHNlY3VyaXR5IDxicj4NCiZndDsgY29uc2lk ZXJhdGlvbnMgcHJvaGliaXRpbmcgdXNlIG9mIHRoZSAmcXVvdDtzdWImcXVvdDsgd2l0aCBhIGNs aWVudCBJRCB2YWx1ZS4gPGJyPg0KJmd0OyBCZWNhdXNlIHN1Y2ggYSByZXF1ZXN0IEpXVCBjb3Vs ZCBiZSByZXB1cnBvc2VkIGZvciBKV1QgY2xpZW50IDxicj4NCiZndDsgYXV0aGVudGljYXRpb24u IEFuZCBleHBsaWNpdCB0eXBpbmcgd291bGRuJ3QgaGVscCBpbiB0aGF0IHNpdHVhdGlvbi48YnI+ DQomZ3Q7IDxicj4NCiZndDsgT24gVHVlLCBBdWcgMTEsIDIwMjAgYXQgMjo1MCBQTSBCZW5qYW1p biBLYWR1ayB2aWEgRGF0YXRyYWNrZXIgJmx0OyA8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpu b3JlcGx5QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bm9yZXBseUBpZXRmLm9yZzwvYT4mZ3Q7 IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPg0KJmd0OyAmZ3Q7IC0tPGJyPg0KJmd0OyAmZ3Q7IENPTU1FTlQ6PGJyPg0KJmd0OyAm Z3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IC0tPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IFt1cGRhdGVkIHRvIG5vdGUgdGhhdCwgcGVyPGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgvTHF1MTVNSmlreVpy WFpvNXFzVFBLMm8wIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL29hdXRoL0xxdTE1TUppa3laclhabzVxc1RQSzJvMDwvYT48YnI+DQomZ3Q7 ICZndDsgZWFFLyBhbmQgdGhlIEpXVCBCQ1AgKFJGQyA4NzI1KSwgc29tZSBkaXNjdXNzaW9uIG9m IHdoeSBleHBsaWNpdCA8YnI+DQomZ3Q7ICZndDsgdHlwaW5nIGlzIG5vdCB1c2VkIHdvdWxkIGJl IGluIG9yZGVyXTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgPGJyPg0K Jmd0OyAtLTxicj4NCiZndDsgX0NPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCA8YnI+DQomZ3Q7IHByaXZpbGVnZWQgbWF0ZXJpYWwg Zm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgPGJyPg0K Jmd0OyByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlz IHN0cmljdGx5IDxicj4NCiZndDsgcHJvaGliaXRlZC4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2UgPGJyPg0KJmd0OyBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBh bmQgYW55IDxicj4NCiZndDsgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRo YW5rIHlvdS5fPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv YT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxp c3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT4tLSA8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5WbGFkaW1pciBEemh1dmlub3Y8bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_DM6PR00MB0684908CEB778DED9943E0CDF5411DM6PR00MB0684namp_-- From nobody Mon Aug 17 08:36:42 2020 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 320E13A1113 for ; Mon, 17 Aug 2020 08:36:41 -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 W62jquCxx-o6 for ; Mon, 17 Aug 2020 08:36:40 -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 B414F3A10E4 for ; Mon, 17 Aug 2020 08:36:39 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id t23so17984801ljc.3 for ; Mon, 17 Aug 2020 08:36:39 -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=3uyM7wSjHi8V/i/M3H0/M02cd78tW8A/HrFtT7O7fv4=; b=Jw8HdccLgDDnOdjArvPFJYzZ4DNs/zDWvcaP5l6RLga2EUvkD/Uoi1uxu9LYOvW5PV LPaQFWD0oHfQEGQRmMovDmeIY5sczKdkyVnPudhnsqy6rHJ0OJ+t0PhwXm/BoJzU4Oxm wu+szJjIg/LBW1ldancGjt5Nezlx9ASeeXGTomQe3i0vzry0nDnumgF5fkLgcLA6tx3b u5EBd5bOsma72OyEiFisUpY6mdsycK5YiQvvLqqiCc6SOAMaPMaV7b7qn5yy/qK1pZIW zgLPSzsPUU66qDeXwk/PahGL2Iv1G9axyVyUQBgUp8JDj9MzML/XMY6B7ZPbBCQ+zPr5 Q1Bw== 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=3uyM7wSjHi8V/i/M3H0/M02cd78tW8A/HrFtT7O7fv4=; b=Fy4C9v2vZpGiQ4Hd7jI190xgBa7nSsJLj08TRxg+8e658yZ3UaAOnF9nLbp9DhRpjl 27bS/BD0e464DcGCmhxB1VKJ1MVJqICkvIVPWjE//Kii2AflRSftV3TeCijSXZpgmsQ2 olfJ8nDkz+pLFA7QCTZopJPrFbe9z762WuTwC2gO4PAs9E/K6il09huxSuVJiik7n5Vz 5fhemFClr8dtFQq3JvTqcOoOAqnOEEMO6/hvicfKIm7QxUgdSYftrdLhCI4LXa1JmWt3 yAvati42Zfy/W/kl7B6H8lQXP1xxisfrwwh96kGWA4QI/3oTVCt+GyiUZmGi+6oF38hn nMHw== X-Gm-Message-State: AOAM532yGe+FOoWCLkdwmlXLTWY5Zg//4XCZZ0wu+YhxPUJFmoNqYRYF UtJeiuKur68jaIH7vsRZyK2MwEeWqdT1K1AperzJSSNl1Gaq5RIfSwc3SdRHgKx2mUu83JGo/+g 4Nl3f1XOwww1brxwKVVqcdA== X-Google-Smtp-Source: ABdhPJwLlgAbghCMPtGCjAcHftxozEPt3Au1T4Jfa8BtmX7LuIcw3W5fo6vIFHRHSdV1E6gUK22Hjvnq8RGxHTyK3Uw= X-Received: by 2002:a2e:968c:: with SMTP id q12mr8190062lji.345.1597678597667; Mon, 17 Aug 2020 08:36:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Mon, 17 Aug 2020 09:36:11 -0600 Message-ID: To: Vladimir Dzhuvinov Cc: oauth Content-Type: multipart/alternative; boundary="000000000000479b6005ad14893e" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (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: Mon, 17 Aug 2020 15:36:41 -0000 --000000000000479b6005ad14893e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Aug 15, 2020 at 3:08 AM Vladimir Dzhuvinov wrote: > Regarding the "sub !=3D client_id" check -- could a simple rejection of a= ll > JWTs with "sub" present suffice? > Prohibiting the use of "sub" in request object JWTs would suffice, yes. I'd suggested the more narrow/specific prohibition with the aim of a smaller scoped change. But perhaps it'd be simpler to just say don't use "sub"? I can't think of any non-erroneous reason sub would be in a request object. --=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._ --000000000000479b6005ad14893e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Sat, Aug 15, 2020 at 3:08 AM Vladimir Dzhuvinov <vladimir@connect2id.com= > wrote:
=20 =20 =20
Regarding the "sub !=3D client_id" check -- could a simple rejection of all JWTs with "sub" present suffice?
=C2=A0
Prohibiting the use of "s= ub" in request object JWTs would suffice, yes. I'd suggested the m= ore narrow/specific prohibition with the aim of a smaller scoped change. Bu= t perhaps it'd be simpler to just say don't use "sub"? I = can't think of any non-erroneous reason sub would be in a request objec= t.

=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. --000000000000479b6005ad14893e-- From nobody Mon Aug 17 15:56:09 2020 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 B3A353A13FC for ; Mon, 17 Aug 2020 15:56:07 -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 28ZNgrEi8eaj for ; Mon, 17 Aug 2020 15:56:05 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 E22413A130F for ; Mon, 17 Aug 2020 15:56:04 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id h8so9210359lfp.9 for ; Mon, 17 Aug 2020 15:56:04 -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=rytfP3Oa8Bw5PmQV21BLw3KnwtpUN32DfSe5Q9nbxPs=; b=GyDzF3JqrYgckJhNEtFx/2lRiuB8GpJKXadwMO4f4U/inEpSOksBTpmgwzsE3By0CL iWu+BCVmN7kkr7UvWWb9Nzn6p1dFqaqLw3dkngC+TwstuRR6AoDJsg4Heqoda1WTWZMQ nKx1/YGNF8LPpqwVtd6De7WyhM1MPaadP53wiHAjXRVp+nVnorwB+QlO0mdnYgzlbnvl GRJPgB58CZCeEHgHWnDmREqha4r7HZ6lPXy3b07UD4eEHlBXa2yCMbZkZXxxeneEAigN WH2bo3xOgFj0eXq1pO3HdEOTeAUgvZvOhrqRHks8d5Pj9w0k4995DDQgHxIybtN6N4L9 Us/w== 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=rytfP3Oa8Bw5PmQV21BLw3KnwtpUN32DfSe5Q9nbxPs=; b=sUlE0XQoX5IlGPww2OreJYo+gbwTean+6QvFrYxVbA8wIWoSc6Ufk6PMTAcUdyb7nK 0kFGcofo8qO1rhrVLDUe3JdfzbRnyLu9UVMmvAfP7+wgjnNYgFlSEZmZ9kuxcbIjCo/d PG3dEE7QeLa8KH68NAf/SVWvfgCqYPP22lhAa8JSajaODtUOmm4JKc0C/EBLDhiak5bx Qv/Ui0bfw/66mQtaIF+GoNSNRvp9RU6aN3zkO9SnnpqNQeqvqFZ0+48xAzjPi7S9pDi3 r3j5JUi4MzYpuiHCc1Y0z6tMB2InZdRKtvBBF19wC/EwY1WWKpQVt8Rm5dSEbakKiXYD a2fg== X-Gm-Message-State: AOAM530m6bSCBD8mibiOPHJvSi3Voy69P0Z5ZrmZebaxeWl9rd5S1JRy b5EGqZtJ3ksenCguEVqmvo/ouX2FuvJqWqx2pJCQWpZDMmHXE7Ywbij4P8iCc60irRjyptOHc6A pAOm3LfXZBQIT+w== X-Google-Smtp-Source: ABdhPJycLYLcM+Jdq5Z/p3ng1b1eytzYR98GIZJT5N7U7gd6tJ59dV+VZrEPTua0sxDXA41Q28GC6EkTMfD+H7iZlVo= X-Received: by 2002:ac2:4ecf:: with SMTP id p15mr8346979lfr.11.1597704962644; Mon, 17 Aug 2020 15:56:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Mon, 17 Aug 2020 16:55:36 -0600 Message-ID: To: Mike Jones Cc: Vladimir Dzhuvinov , "panva.ip@gmail.com" , oauth Content-Type: multipart/alternative; boundary="000000000000c1454d05ad1aac40" Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (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: Mon, 17 Aug 2020 22:56:08 -0000 --000000000000c1454d05ad1aac40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I might suggest that thinking about it in the context of interoperability would be more meaningful than certification tests. Saying that an AS MUST reject the Request object if it has a typ header and the value of the header is not =E2=80=98oauth.authz.req+jwt=E2=80=99 [1] sh= ould allow for interoperability with respect to JWT typing between all combinations of existing and updated clients with existing and updated authorization servers. Saying that an AS MUST NOT include a sub with client id as the value would break for an updated authorization server when receiving such a request object JWT. But that's erroneous and potentially dangerous behaviour from the client so I don't know that we need to try and maintain interoperability there. [1] Unfortunately "typ":"JWT" would probably also need to be allowed. As best I understand it "typ":"JWT" basically says "this JWT is a JWT", which isn't useful for explicit typing and I think makes it effectively equivalent to an untyped JWT. I've honestly never understood why one would use "typ":"JWT" but it shows up in a lot of places including examples and explanations on sites like jwt.io so it seems very likely that it'd just get copied over and show up in some amount of real world request object JWTs. On Sat, Aug 15, 2020 at 10:41 AM Mike Jones wrote: > Answering Filip and Vladirmir=E2=80=99s question about adding normative l= anguage > around =E2=80=9Ctyp=E2=80=9D and =E2=80=9Csub=E2=80=9D: Anytime you add = a new required feature, you are > breaking existing deployments. Suppose we added the normative requiremen= t > =E2=80=9CIf a =E2=80=98typ=E2=80=99 header parameter is present, ASs MUST= reject the Request object > if its value is not =E2=80=98oauth.authz.req+jwt=E2=80=99=E2=80=9D. One = could then write a > certification test sending the AS a different =E2=80=9Ctyp=E2=80=9D value= =E2=80=93 which to pass, > ASs would have to reject the JWT. *Every existing deployment would fail > this test!* That=E2=80=99s exactly what we don=E2=80=99t want to have ha= ppen. > > > > Brian asked for security considerations. The IESG asked for security > considerations. I added them in the PR =E2=80=93 working with Nat and Jo= hn. They > point the way to the future without breaking existing deployments. That= =E2=80=99s > as it should be. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of * Warren Parad > *Sent:* Saturday, August 15, 2020 9:27 AM > *To:* Vladimir Dzhuvinov > *Cc:* oauth > *Subject:* [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's No Objection on > draft-ietf-oauth-jwsreq-26: (with COMMENT) > > > > In the case of > > if the Request Object includes a sub claim with the value of the client_i= d > the AS MUST reject the request > > > > What would the expectation be in terms of a client_credentials grant? > > > > From experience, the *sub *is frequently populated with the client_id > value and the client_id is not used. Which would mean breaking for that > type of grant wouldn't it? > > > > *Warren Parad* > > Founder, CTO > > Secure your user data and complete your authorization architecture. > Implement Authress . > > > > > > On Sat, Aug 15, 2020 at 11:08 AM Vladimir Dzhuvinov < > vladimir@connect2id.com> wrote: > > +1 to make the "typ" check, as Filip suggested, normative, as existing > client and RP deployments with undefined "typ" will not be affected. New > deployments should be encouraged to type the JWT, and thus be made safer. > > > > Regarding the "sub !=3D client_id" check -- could a simple rejection of a= ll > JWTs with "sub" present suffice? > > I find it difficult to imagine what else a client could end up setting th= e > "sub" claim to, if it does end up populating it for some reason. > > Rejecting JWTs with "sub=3Dclient_id" or "sub" present will break > deployments where a client for some reason sets the "typical" JWT claims, > and "sub" is a typical one, but if those deployments happen to accept > client_secret_jwt or private_key_jwt client authentication, they could we= ll > be vulnerable to cross-JWT confusion attacks. > > > > Vladimir > > On 14/08/2020 13:58, Filip Skokan wrote: > > Hi Mike, Nat, > > > > I thought we would go as far as making these normative requirements > > - if the Request Object includes a sub claim with the value of the > client_id the AS MUST reject the request > - if the Request Object is explicitly typed (typ) its value MUST be ..= . > > First rejects client assertions to be passed as Request Objects. Second > rejects all future typed JWT profiles from being used as Request Objects > without worrying about the claims they may or may not contain. > > > > Or is that breaking? > > > > S pozdravem, > *Filip Skokan* > > > > > > On Fri, 14 Aug 2020 at 00:59, Mike Jones 40microsoft.com@dmarc.ietf.org> wrote: > > At Nat's request, I've created a pull request addressing Cross-JWT > Confusion security considerations. It addresses both Brian's comment and > the IESG comments about explicit typing. See the full PR at > https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10. See the source > diffs at > https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-= working-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml. > Please review! > > This is only the first commit, albeit, one that addresses some of the mus= t > substantive issues. More commits will follow addressing additional IESG > comments. > > -- Mike > > -----Original Message----- > From: OAuth On Behalf Of Benjamin Kaduk > Sent: Thursday, August 13, 2020 2:59 PM > To: Brian Campbell > Cc: draft-ietf-oauth-jwsreq@ietf.org; oauth-chairs@ietf.org; The IESG < > iesg@ietf.org>; oauth > Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on > draft-ietf-oauth-jwsreq-26: (with COMMENT) > > Oops, that's my bad. Thanks for the correction -- I've linked to your > message in the datatracker (but didn't bother to have the datatracker sen= d > a third copy of my updated-again ballot position). > > -Ben > > On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote: > > While some discussion of why explicit typing was not used might be > > useful to have, that thread started with a request for security > > considerations prohibiting use of the "sub" with a client ID value. > > Because such a request JWT could be repurposed for JWT client > > authentication. And explicit typing wouldn't help in that situation. > > > > On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker < > > noreply@ietf.org> wrote: > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > [updated to note that, per > > > https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0 > > > eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit > > > typing is not used would be in order] > > > > > > > > > > -- > > _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 > > _______________________________________________ > 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 > > -- > > Vladimir Dzhuvinov > > _______________________________________________ > 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 > --=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._ --000000000000c1454d05ad1aac40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I might suggest that thinking about it in the context= of interoperability would be more meaningful than certification tests.

Saying that an AS MUST reject the Request object= if it has a typ header and the value of the header is not =E2=80=98oauth.a= uthz.req+jwt=E2=80=99 [1] should allow for interoperability with respect to= JWT typing between all combinations of existing and updated clients with e= xisting and updated authorization servers.

Sa= ying that an AS MUST NOT include a sub with client id as the value would br= eak for an updated authorization server when receiving such a request objec= t JWT. But that's erroneous and potentially dangerous behaviour from th= e client so I don't know that we need to try and maintain interoperabil= ity there.

[1] Unfortunately "typ":= "JWT" would probably also need to be allowed. As best I understan= d it "typ":"JWT" basically says "this JWT is a JW= T", which isn't useful for explicit typing and I think makes it ef= fectively equivalent to an untyped JWT. I've honestly never understood = why one would use "typ":"JWT" but it shows up in a lot= of places including examples and explanations on sites like jwt.io so it seems very likely that it'd just get copie= d over and show up in some amount of real world request object JWTs.


On Sat, Aug 15, 2020 at 10:41 AM Mike Jones <Michael= .Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

Answering Filip a= nd Vladirmir=E2=80=99s question about adding normative language around =E2= =80=9Ctyp=E2=80=9D and =E2=80=9Csub=E2=80=9D:=C2=A0 Anytime you add a new r= equired feature, you are breaking existing deployments.=C2=A0 Suppose we ad= ded the normative requirement =E2=80=9CIf a =E2=80=98typ=E2=80=99 header parameter is presen= t, ASs MUST reject the Request object if its value is not =E2=80=98oauth.au= thz.req+jwt=E2=80=99=E2=80=9D.=C2=A0 One could then write a certification t= est sending the AS a different =E2=80=9Ctyp=E2=80=9D value =E2=80=93 which = to pass, ASs would have to reject the JWT.=C2=A0 Every existing deployment would fail this test!=C2= =A0 That=E2=80=99s exactly what we don=E2=80=99t want to have happen.

=C2=A0<= /u>

Brian asked for s= ecurity considerations.=C2=A0 The IESG asked for security considerations.= =C2=A0 I added them in the PR =E2=80=93 working with Nat and John.=C2=A0 Th= ey point the way to the future without breaking existing deployments.=C2=A0 That=E2=80=99s as it should be.

=C2=A0<= /u>

=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=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=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 -- Mike

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Warren Parad
Sent: Saturday, August 15, 2020 9:27 AM
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
Cc: oauth <oa= uth@ietf.org>
Subject: [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's No Objection= on draft-ietf-oauth-jwsreq-26: (with COMMENT)

=C2=A0

In the case of

if the Request Object includes a sub claim with the = value of the client_id the AS MUST reject the request

=C2=A0

What would the expectation be in terms of a client_c= redentials grant?

=C2=A0

From experience, the sub is frequently=C2=A0p= opulated with the client_id value and the client_id is not used. Which woul= d mean breaking for that type of grant wouldn't it?

=C2=A0

Warren Parad

Founder, CTO<= /u>

Secure your user data= and complete your authorization architecture. Implement=C2=A0Authress.=

=C2=A0

=C2=A0

On Sat, Aug 15, 2020 at 11:08 AM Vladimir Dzhuvinov = <vladimir@c= onnect2id.com> wrote:

+1 to make the "typ" check, as Filip suggested, normative, as = existing client and RP deployments with undefined "typ" will not = be affected. New deployments should be encouraged to type the JWT, and thus= be made safer.

=C2=A0

Regarding the "sub !=3D client_id" check -- could a simple rej= ection of all JWTs with "sub" present suffice?

I find it difficult to imagine what else a client could end up setting t= he "sub" claim to, if it does end up populating it for some reaso= n.

Rejecting JWTs with "sub=3Dclient_id" or "sub" prese= nt will break deployments where a client for some reason sets the "typ= ical" JWT claims, and "sub" is a typical one, but if those d= eployments happen to accept client_secret_jwt or private_key_jwt client aut= hentication, they could well be vulnerable to cross-JWT confusion attacks.

=C2=A0

Vladimir

On 14/08/2020 13:58, Filip Skokan wrote:

Hi Mike, Nat,

=C2=A0

I thought we would go as far as making these normati= ve requirements

  • if the Request Object includes a sub claim with the value of the client_id = the AS MUST reject the request
  • if the Request Object is explicitly typed (typ) its value MUST be ...

First rejects client assertions to be passed as Requ= est Objects. Second rejects all future typed JWT profiles from being used a= s Request Objects without worrying about the claims they may or may not con= tain.

=C2=A0

Or is that breaking?

=C2=A0

S pozdravem,
Filip Skokan

=C2=A0

=C2=A0

On Fri, 14 Aug 2020 at 00:59, Mike Jones <Michael= .Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

At Nat's request, I've created a pull reques= t addressing Cross-JWT Confusion security considerations.=C2=A0 It addresse= s both Brian's comment and the IESG comments about explicit typing.=C2= =A0 See the full PR at https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10.=C2=A0 See the = source diffs at https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-wo= rking-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml.=C2=A0 Please= review!

This is only the first commit, albeit, one that addresses some of the must = substantive issues.=C2=A0 More commits will follow addressing additional IE= SG comments.

=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 -- Mike

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Benjamin Kaduk
Sent: Thursday, August 13, 2020 2:59 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: d= raft-ietf-oauth-jwsreq@ietf.org; oauth-chairs@iet= f.org; The IESG <= iesg@ietf.org>; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oau= th-jwsreq-26: (with COMMENT)

Oops, that's my bad.=C2=A0 Thanks for the correction -- I've linked= to your message in the datatracker (but didn't bother to have the data= tracker send a third copy of my updated-again ballot position).

-Ben

On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote:
> While some discussion of why explicit typing was not used might be > useful to have, that thread started with a request for security
> considerations prohibiting use of the "sub" with a client ID= value.
> Because such a request JWT could be repurposed for JWT client
> authentication. And explicit typing wouldn't help in that situatio= n.
>
> On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org= > wrote:
>
> >
> > -----------------------------------------------------------------= ---
> > --
> > COMMENT:
> > -----------------------------------------------------------------= ---
> > --
> >
> > [updated to note that, per
> > https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0 > > eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit =
> > typing is not used would be in order]
> >
> >
>
> --
> _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.=C2=A0 If you have received this communication in error, pl= ease
> 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
h= ttps://www.ietf.org/mailman/listinfo/oauth

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

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth
-- 
Vladimir Dzhuvinov

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

_______________________________________________
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. --000000000000c1454d05ad1aac40-- From nobody Tue Aug 18 14:18:54 2020 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 22FB53A0CD9 for ; Tue, 18 Aug 2020 14:18:52 -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 ocCH5PZDEuhe for ; Tue, 18 Aug 2020 14:18:50 -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 92CA93A0CDB for ; Tue, 18 Aug 2020 14:18:49 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id v9so23059978ljk.6 for ; Tue, 18 Aug 2020 14:18:49 -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=6t3K4dET7nbkuanZ56eSP1QRWuFBpkUCLU8xSPj6jiI=; b=CgWSilec0JFptqmNASCSaN3ii1QHvvwrktN+o4nPlZ/RHZcOFGxXX5U8lddqQvo/Gf NlDh122tXase6QuPbnZ5vORwls4vwzmumPAJKjgYdTQ3Y/ZoF6uK0JBOc7TvrekcPvG8 SdOIoSIbsK4J878VB0MDzBSoX9Rc/Jj1MNBFjNNY3WWTqUr9XArtSYf75KFZDhW7oQQg ghqIbZcZV1WENqEqc7KVKpsTYtOSMmEuuoDQjFL4l5AQ3Av9Tp9C9JKPDLjWrfcqb/rU 9ZLb5knZyFTQyev8qmZICpsEhw/u1hoKfYXta2QYnDnf0YrodzhNbjK902PABlDhXkg4 lIBA== 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=6t3K4dET7nbkuanZ56eSP1QRWuFBpkUCLU8xSPj6jiI=; b=Q5DeNR4bVZLxKwfNa5o5fUfcVHm/di0WOf8xSllkzpL4/SUQrQ8FkC2NgoyJNwiCng gQaNxK5hMpgyoqiatzK1SN0Dk71KQRPkcwbe+ITBi+1AiZoh7/LHLAqXANRnimFekLn7 Cm0RYO9NkSMSsblsBWYlXFcsvP1OhJJIJcQ38CivK91KdDp9UZdLkeJYCb3ukc0AiqR0 ZFjI0+oeX5EJNSZtYJ1yU7HJgWAOXiWcGe5UBReUKM8CNE4ohwKJhmwG+LtNQw/sLP5e m+wyNG0ZcydmQF0Hmy0/QnvGaqpZIxx6m3gliHlH/QKBzMoT5ElgubysXjh9nuRHU4v3 QUiQ== X-Gm-Message-State: AOAM531yJweeA9GrwdX51fVXXcxhefq6PneYxGGsPhfEPL744tQpqgEo +/AErUf6xsIT0sGlM+S1OzpcYcp0E2D9r7LnG/CJ6Plt1aeaTVd1sKxFsk/qIT25G1MA8iI5dDB xs/5kRZCUnoNhKsrgs5xcPQ== X-Google-Smtp-Source: ABdhPJxeC7aP6Rw8Kv0ykgtO9ZAawmbh7bRW/4vtnZbby/SzcXFq0oMSq9t1j7e1ayxkZ7V8pC4xyB3amg3LxK9TwEk= X-Received: by 2002:a2e:968c:: with SMTP id q12mr11329356lji.345.1597785527575; Tue, 18 Aug 2020 14:18:47 -0700 (PDT) MIME-Version: 1.0 References: <334EDEFB-AE33-4A19-9F2F-4C8158597C5C@authlete.com> In-Reply-To: <334EDEFB-AE33-4A19-9F2F-4C8158597C5C@authlete.com> From: Brian Campbell Date: Tue, 18 Aug 2020 15:18:21 -0600 Message-ID: To: Joseph Heenan Cc: oauth Content-Type: multipart/alternative; boundary="000000000000cc85bc05ad2d6ea9" Archived-At: Subject: Re: [OAUTH-WG] WGLC on Pushed Authorization Requests draft 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, 18 Aug 2020 21:18:52 -0000 --000000000000cc85bc05ad2d6ea9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Joseph. We'll get those niggles addressed. And it's great to hear the positive implementation and testing info. On Wed, Aug 12, 2020 at 6:08 PM Joseph Heenan wrote: > Thanks Rifaat, Hannes, and also thanks to all the authors. > > I=E2=80=99ve been through the latest spec and it basically looks great to= me; I > raised 3 minor niggles under > https://github.com/oauthstuff/draft-oauth-par/issues > > https://github.com/oauthstuff/draft-oauth-par/issues/59 - possible > ambiguity in the text around error responses from new endpoint > > https://github.com/oauthstuff/draft-oauth-par/issues/62 & > https://github.com/oauthstuff/draft-oauth-par/issues/63 - minor > typographical points > > > For info, Authlete has at least one deployed implementation of this spec. > > Authlete has also assisted in getting tests for PAR added to the Open ID > Foundation FAPI Certification test suite for Authorization Servers, and > (although there=E2=80=99s still a few niggles in the tests to work out) t= he tests > seem to interoperate with Authlete, Filip=E2=80=99s node-oidc-provider an= d a Ping > implementation fine. (Many thanks to Filip & Ping for testing them! If > anyone else would like to try them please let me know.) > > Thanks > > Joseph > > > On 11 Aug 2020, at 23:07, Rifaat Shekh-Yusef > wrote: > > All, > > This is a WGLC on the *Pushed Authorization Requests *document: > https://www.ietf.org/id/draft-ietf-oauth-par-03.html > > Please, take a look and provide feedback on the list by *August 25th.* > > Regards, > Rifaat & Hannes > > _______________________________________________ > 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 > --=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._ --000000000000cc85bc05ad2d6ea9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Joseph. We'll get those niggles addressed. And = it's great to hear the positive implementation and testing info.=C2=A0 =

On Wed, Aug 12, 2020 at 6:08 PM Joseph Heenan <joseph@authlete.com> wrote:
Thanks Rifaat, Hannes, and also thanks to all the authors.

I=E2=80=99ve been through the latest spec and it basically looks gre= at to me; I raised 3 minor niggles under=C2=A0https://github.com/oa= uthstuff/draft-oauth-par/issues

htt= ps://github.com/oauthstuff/draft-oauth-par/issues/59=C2=A0- possible am= biguity in the text around error responses from new endpoint

=


For info, Authlete has at least one deployed impleme= ntation of this spec.

Authlete has also assisted i= n getting tests for PAR added to the Open ID Foundation FAPI Certification = test suite for Authorization Servers, and (although there=E2=80=99s still a= few niggles in the tests to work out) the tests seem to interoperate with = Authlete, Filip=E2=80=99s node-oidc-provider and a Ping implementation fine= . (Many thanks to Filip & Ping for testing them! If anyone else would l= ike to try them please let me know.)

Thanks
<= div>
Joseph


=
On 11 Aug 2020, at 23:07, Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com&g= t; wrote:

All,

This is a = WGLC on the=C2=A0Pushed Authorization Requests document:
<= a href=3D"https://www.ietf.org/id/draft-ietf-oauth-par-03.html" target=3D"_= blank">https://www.ietf.org/id/draft-ietf-oauth-par-03.html

Please, take a look and provide feedback on the list by <= b>August 25th.

Regards,
=C2=A0Rifaat= & Hannes

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
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. --000000000000cc85bc05ad2d6ea9-- From nobody Tue Aug 18 15:25:42 2020 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 E587A3A0E47 for ; Tue, 18 Aug 2020 15:25:40 -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 0-vIBkgXObuy for ; Tue, 18 Aug 2020 15:25:39 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 135E33A0E41 for ; Tue, 18 Aug 2020 15:25:39 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id i10so23209539ljn.2 for ; Tue, 18 Aug 2020 15:25:38 -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=aamMDFzS9oqsGc96zWUN8qlXH61/nMjqajaV9c/IJGs=; b=M74BtbEA3rAwn6HzFZKLfeO7jMbn7kogwFqxdCB3yTnyrxqAOo+kflNo4GZiHvoUOQ iWsgLWeX3c7Jt24+A1ra5pSEtoqpgsZP7HLZMRd4lnA3qd/LT+AuvdeUo9JwJeKgvOPd 2gc3d/RjkAF4sBu4vv8KetkunMlKuE0m+6qX+HDx68RKNNgzP1iBguMWZDvG6elFn6LH Bk2WC4O751E3aggGZZqZ79sDzQPNxvlo6u3jW9Saii9RXPsr1Z6fC5BqOafRLytS2MDz zz+tsRJTGOJxyr/Kbtjof2pPVSNwwtFh+Z1OV2mDQ+uc8h8UgiG1ix0lqIDh9vQn76Ms DXAg== 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=aamMDFzS9oqsGc96zWUN8qlXH61/nMjqajaV9c/IJGs=; b=WQ57QJgk5hfzt2Qsg2a4TeO6eq7U2/JTbIiv1sr11I0D/aa5vutk6KQqYxufo2ak7+ he0KGpVtJ5zSBqXpC9vdgJtSozwTHJoSsxNNmo6qCdNdgwREYNkn6z4HJg08upnNjgui 90wKLXK32/PuAAODGHpEz01ReSIc/zb2CTQlSsgScJnd9NR+FK3T2aoOfRHOd0hXirDA p8s1ipsjGxYegDuDbjd8WwblEwqiuiP/ih0lVatjy4i+PqDaPPQvqLzpy4ptt/42XQps 5uX2/Zly9MAmulaUwAXkrodBdGuNyHjlTYjZ/0YmuBJhRjFgmvGyo8ar613suivCWaHo cSIQ== X-Gm-Message-State: AOAM532J5QMATBlxfQQ9ZSkJog7wEfmYjtpExeBixCmo9MjLkNI8GEFR o29m/E/pr2fFXfGtwbF2ihuGIdG1HzZhpP64ROSll7SW7MVvEnQFBwPiShMSZ1fGj3pbWG332xp 9VskrcwnZfUZACQ== X-Google-Smtp-Source: ABdhPJwBBiAPk6xZ72pjBhvF+WX2BFO4Ohv97EPtsB2GK+r1pxy2g3c4qZHSHxa00k7edPThJPu1vvoAmfhWMlaNr50= X-Received: by 2002:a2e:8642:: with SMTP id i2mr11388985ljj.368.1597789537108; Tue, 18 Aug 2020 15:25:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Tue, 18 Aug 2020 16:25:10 -0600 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="000000000000c920d705ad2e5dc4" Archived-At: Subject: Re: [OAUTH-WG] WGLC on Pushed Authorization Requests draft 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, 18 Aug 2020 22:25:41 -0000 --000000000000c920d705ad2e5dc4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A couple of WGLC comments from my sphere. I'd like to take the discussion of the first item in https://mailarchive.ietf.org/arch/msg/oauth/iD33QbZTj92LJ6M9wNUq9s3nLpA/ as a suggestion that the top part of section 2.1 be reworked or adjusted so as to (hopefully) avoid any confusion that the list there somehow conveys normative requirements. The definition of the client require_pushed_authorization_ requests metadata parameter needs to specify a default similar to how the AS metadata parameter of the same name does - i.e., "If omitted, the default value is false." On Tue, Aug 11, 2020 at 4:08 PM Rifaat Shekh-Yusef wrote: > All, > > This is a WGLC on the *Pushed Authorization Requests *document: > https://www.ietf.org/id/draft-ietf-oauth-par-03.html > > Please, take a look and provide feedback on the list by *August 25th.* > > Regards, > Rifaat & Hannes > > _______________________________________________ > 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._ --000000000000c920d705ad2e5dc4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A couple of WGLC comments from my sphere.
<= div>
I'd like to take the discussion of the first item in= https://mailarchive.ietf.org/arch/msg/oauth/iD= 33QbZTj92LJ6M9wNUq9s3nLpA/ as a suggestion that the top part of section 2.1 be reworked or adjusted so as to (hopefully) a= void any confusion that the list there somehow conveys normative requiremen= ts.

The definition of the client require_pushed_au= thorization_requests metadata parameter needs to specify a defa= ult similar to how the AS metadata parameter of the same name does = - i.e., "If omitted, the default value is false."=C2= =A0 =C2=A0

On Tue, Aug 11, 2020 at 4:08 PM Rifaat Shekh-Yusef <rifaat.s.ietf@gma= il.com> wrote:
All,

This is a WGLC on the=C2=A0<= b>Pushed Authorization Requests document:

= Please, take a look and provide feedback on the list by August 25th.=

Regards,
=C2=A0Rifaat & Hannes

_______________________________________________
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. --000000000000c920d705ad2e5dc4-- From nobody Wed Aug 19 02:41:29 2020 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 964AC3A16DF for ; Wed, 19 Aug 2020 02:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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=hackmanit-de.20150623.gappssmtp.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 rQ6CdSUALKUE for ; Wed, 19 Aug 2020 02:41:25 -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 902093A11C1 for ; Wed, 19 Aug 2020 02:41:25 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id c19so1278529wmd.1 for ; Wed, 19 Aug 2020 02:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackmanit-de.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=j/JXyOL/TBFAty+0gA48nNRZc3S/e6z0NKy9EhXdFaw=; b=ThjeZATyDqY19wcfps1BNNn4v7ctQYSU+MdAGTu7X6nQG2GBr5z57h6HkA+iroTZ1j wySS0y4V+Kc3uS1OVzEmb3xguPdzGU7Awj2dl2jzWEpkkFE/JFQmRXuI1dL9czOSoc/B qdDKnHbvvsGlEERV2toH+M20UY9uNxkkkQOsPGsWZ0YWXZ80lp8rAeM9cCoIRtA9qrRP mXByw5/LQXIlWFyEYeJTgx8ZS0AHrS1lH/8dl3ubnhpdSTeK3rrtmWO3DXtnun3INncR MHdI4Wd311ofRnMq4jR+ZZDe2W5Uu7MgHNXXPpqOyddxg3AVkRgZqHtZ3cj7gd6UeesY VKBA== 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:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=j/JXyOL/TBFAty+0gA48nNRZc3S/e6z0NKy9EhXdFaw=; b=uOKyRWyKY8dlELi9xEV4yo6RRM9+FFXiy/f7yMHH7jPPUHsxB12KkeglmWTuiITm3m DXQZCZHbCgyOyZCe+3p4mtYyCRLpbUFQtpkmcmu1bsid2aPzhxVwZLj1CTWIRDiSxyug y6cPtVHyQS8TyWYm3NZqOZNajhLbYXAw5cOXUTFm2Hmih38mmspDemVcUQCBi9iJNFZU DWCURkY718G++8p2PM9hr6XPGiznVRmYtiF7qbqIDrN2nNnjLmIjrV56h2/+mMRJVTYi CLkZzKvTBImPOeazn4KFbB1rYb/wIEpvfEy6/KGxK7sAxvRJMcyVFkIqpKtxog6Ks8PA SZpg== X-Gm-Message-State: AOAM5311sy54URdKKVj83mGveUyRiOOMP3zTFYL752EobqL35foDVZV5 7jn8SGG6np+E3+pN6kS7cIeV8sRDpnta4Q== X-Google-Smtp-Source: ABdhPJxLXni3x3w3US5TaBgwQ0N2FKzBnoKYFpeBmf7ciSUAcw13DTC3kzbjYKfQzzUAKPtRlFK73g== X-Received: by 2002:a1c:cc0c:: with SMTP id h12mr3842282wmb.57.1597830083406; Wed, 19 Aug 2020 02:41:23 -0700 (PDT) Received: from [192.168.178.22] (b2b-37-24-87-133.unitymedia.biz. [37.24.87.133]) by smtp.gmail.com with ESMTPSA id q5sm38452645wrp.60.2020.08.19.02.41.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Aug 2020 02:41:22 -0700 (PDT) To: oauth@ietf.org References: From: Karsten Meyer zu Selhausen Autocrypt: addr=karsten.meyerzuselhausen@hackmanit.de; keydata= mQINBFh1IBMBEADV73c10lB7zeFy6/ezLFzOBp8z6Zy1zUyIrf6RoBk1GQWREcGEGeaL90Pj F5plZeASVJdsEYnYXdgcIPE0tlBq6al6OYoWtH/VbFPWEPLVhA3rL1iXVJveD3J40OzSYP8N G7bla3zQ2+TXOB3iDPPsHZUdHCLASkIIWQK6+fE1C2epAdPtnsLsb++1d080jfXXwgyUUh4y bimcy9Jg5oZ4QMwnSq3Y+x38PNb+nTgjDi1X/89/WsNd7Bdh4Zvw3CAuc/W58CFaDjb7liUD YRoAp6ysnjPKEUSnAnMpgaiXJc1gFoL+ahdKJ3D9XTn28NTjUrvOkVidsuKbyxnXP9I6BO6i 2jzjrH6TEAfIYMjZlYTyPZTt271SW5iAHYwvPZWlqQTBT2P/d4gHl0To5b4e+UXxjQgxqUyi QIcxh3Ris21Kx4lKQKDXYWiwNTZzx8AdqrcxCWfK+MRpFyk0B+4uDMm7Apm5ZWwDKN/JnVsJ yokkkrrHs/elRCUGtN9NyhJQf3VnE87862Pej8PVvQJr3uVnoNX2yieTvJZftIOBG1b9ta6Z BcYyn3un1rSn7lBPg+RSnPemposVorQpjGwT+Dhg13Bpv5q0JfSc//js/nB6A4iq5YssdtQ7 35QBWLLaF1oCxalvrQVDD4Sh06eAUQsga9xeE0yv7sxqdsozdwARAQABtEJLYXJzdGVuIE1l eWVyIHp1IFNlbGhhdXNlbiA8a2Fyc3Rlbi5tZXllcnp1c2VsaGF1c2VuQGhhY2ttYW5pdC5k ZT6JAj8EEwEIACkFAlh1IBMCGyMFCQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAK CRBFNcDn2xbxSK7sEAC5hk0VQHo2+fMV3b4TgSt4qSPLz6EnWwoqcEzUGYHErQXy7tCENpqS rsZsFphpgvWo1tcQdpyQTFm0dry4ASJD78lEiYC/8Hedp0fIaJTGwxrSLpRxV/Wb+iqkbgz8 /Qydl3QyupSqznSHQMd0uhvzHLxoYvHAIKy52gCK0T9gmxcCIh7UEjDfm+kqHp+oU4sbNe+2 ZEtJLuCKW+amNyqnHXr7ehAIaYmTdKOEcUb2UM7Yzp9g4kSkg1GbPlAn6yjyAqJ96sobKFXX S3rkXksRTxkGKW278Nrs4UBO+OIu32kIXCM2m3fKaUK777jAQu1e8sdj2nL0sPWQvMikZRx6 0dy+wVuH8gGHZsd7rW201Sv5pAhSAK4l58GS3xSLId6smXCend9Vu+tcYA+Bb+45943LmoPA PrdIUeI+zC9pjGwm+x+jFiCxbChqAiJF7RyYv9crziEYnTQ70gHGNOTOTIS5t0ufc9D4wD4O IkkrPQYg3KcAqP2Kyj1uHcqdk7XEhV1fdTXdeEt1e7auWPh0d3Fo+BTtiGXfNMuORArE0El6 ky8eUOqZEJ8rYpEGDLt0JFkJM5AhX4PrQWekjaMhQ5yl/+M+Ss0V0JkImagSgWdvUn1+eAs0 zEuVxTc6ON69mIyMalQ5d4ofvPnKr3GNVmEiXAVDMGUZHoeabfgSBbkCDQRYdSATARAAsp2V mr3N7iNND8+M/OyA/OwcDQ6utZh+m4TnKsOVdiNLGpu2U3/2Qg3yrbjic2dWx1CsS6VH2/oO 1e/a4FlxA93wFv/OZjiUjHtEvdIJeHWlCvWOUlMsqyGDc3Q75fNjFw6DGKkiOu9lZaBs6naS BmkvAMGjV5bNKLyIL5j7Im1pCdZ2lCjD7eVwR3RQQKobTmu916htX8g1cB9yFmquu37X+ZBl A4GLJi63Kw0L2r8i8iO1NqDLOfT8IeNkOroEm3SDAuEApGAubKLSPBJ1khQ7kDhpdfzSYKUF tiIHpGWVOImDjqf4JIcF7OIdRPQfFPlwoPnsyBAS8znQJvmqbbMowgFZe3UMLAN78CETZHGM OLBPB873oWyZ07Ar4v/SL5/aD+FRj2VnYEcGwt0HMmMyaN6ed8Udj4OTNZ7ceZA1Tw8/lZuI KCamj0XfJIK6376RCGnqjsEfS65P1KWZXfWphCKWp2c7uWKtau1q8pgiVRoBSAmjvfXRrIvK LhhQyNOiCUDKrvEWpoeq9y5GTrY27ncLov8nSR/SUPOw5HwJmzdFjhOF9XAOtiND/QRH886O IohdlnUu668mwLCmL2ROe7XWcTkFQWLDg+5b0bC9dgfL+HHpWGUdQPG3CCyPG5LfDmnmuXkE eU1kSD27kFe1kM6pfqpCydJW66DuwoMAEQEAAYkCJQQYAQgADwUCWHUgEwIbDAUJCWYBgAAK CRBFNcDn2xbxSAAbEACeIsfrsq2tlyigZv+bwkiVP1oKtWfXN1e3K3lDOBqPJaPXWFOopq/1 9osk58PFtVEaDlYPlN/NP6Jq5nTTC8QyLG3swAdo4ZJXWEg1NTRu8ddYUvZWuRHWRghaq7qh eW5lVPqilCndSG7bkDPU/Vyd93nPKnKTKKs/Nd7ePneWA0JQohEg5gO/GU0v5SN3YfTxG1LV Cxu3HHHFodDLK4KITSYmt1+g0WCADeclwm5+L5lIvgKQvcIpjpMGNK1wj2E3exsLlgo/ZEyS AslOPXyQw2yfYLrcfGpvWa3e+AvU7eLVBgihskpibJg53yw31B0CXAJBbjg7AsxR8UE5pl6h 2gTjN2t++GvqefGtw/bPvx2RzFsorh1/RYaFgcaFyefghmpi55iiIhgEOiSIct0LoYl3cmH8 DGYKhSskpSDgfE41Esk/P2odeax9SmJuv4mnqkiGFPpTwCfUka2k0mCpBDpfTdECWUFhreGS qFbrvJDZRBiyaVyCjOvOc0v6Z0/iIRgHWTjITpqaQh69kqAtt9GQWV6i3THnpHFlIC2ecvdc YCagneZdoLEHCS8Nois/uDbp5qZwZcF5zKMI+T7u6Qf8EGdvxCB1fp0Sdlmeto0c6/gnFUix 4J/tozBwSXSg7JCxTrUdnJtcQAJzosOUZTVO/ZZR/n0+904kud6o3w== Message-ID: Date: Wed, 19 Aug 2020 11:41:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4C75E3DA72F393417BDDC041" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] WGLC on Pushed Authorization Requests draft 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, 19 Aug 2020 09:41:28 -0000 This is a multi-part message in MIME format. --------------4C75E3DA72F393417BDDC041 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I have two very small suggestions which I also raised as issues on Github= : 1. There are no hints in front of example requests/responses if extra line breaks are used for display purposes. I think hints such as "(with extra line breaks for display purposes only)" should be added to the examples. (#64 ) 2. In section 3 there is a typo in step 2. I think it should be "*Validate *the request object signature as specified in JAR [I-D.ietf-oauth-jwsreq], section 6.2." instead of "*Validates *the ...". The imperative is used in step 1, as well. (#65 ) Best regards; Karsten On 12.08.2020 00:07, Rifaat Shekh-Yusef wrote: > All, > > This is a WGLC on the=C2=A0*Pushed Authorization Requests *document: > https://www.ietf.org/id/draft-ietf-oauth-par-03.html > > Please, take a look and provide feedback on the list by *August 25th.* > > Regards, > =C2=A0Rifaat & Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Karsten Meyer zu Selhausen IT Security Consultant Phone: +49 (0)234 / 54456499 Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, = Security Training Unsere n=C3=A4chste Live Online-Schulung zur Sicherheit von OAuth und Ope= nID Connect am 24.09 + 25.09: https://hackmanit.de/de/schulungen/109-live-online-schulung-single-sign-o= n-sicherheit-oauth-openid-connect-am-24-und-25-09-2020 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 --------------4C75E3DA72F393417BDDC041 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi all,

I have two very small suggestions which I also raised as issues on Github:

  1. There are no hints in front of example requests/responses if extra line breaks are used for display purposes. I think hints such as "(with extra line breaks for display purposes only)" should be added to the examples. (#64)
  2. In section 3 there is a typo in step 2. I think it should be "Validate the request object signature as specified in JAR [I-D.ietf-oauth-jwsreq], section 6.2." instead of "Validates the ...". The imperative is used in step 1, as well. (#65)

Best regards;
Karsten

On 12.08.2020 00:07, Rifaat Shekh-Yusef wrote:
All,

This is a WGLC on the Pushed Authorization Requests document:

Please, take a look and provide feedback on the list by August 25th.

Regards,
 Rifaat & Hannes


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

-- 
Karsten Meyer zu Selhausen
IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training

Unsere nächste Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 24.09 + 25.09:
https://hackmanit.de/de/schulungen/109-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-24-und-25-09-2020

Hackmanit GmbH
Universitätsstraße 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
--------------4C75E3DA72F393417BDDC041-- From nobody Wed Aug 19 05:09:21 2020 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 ABBD03A08A6 for ; Wed, 19 Aug 2020 05:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=authlete-com.20150623.gappssmtp.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 NpnV5L0tseTu for ; Wed, 19 Aug 2020 05:09:16 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 7A9573A08AB for ; Wed, 19 Aug 2020 05:09:16 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id x5so1852641wmi.2 for ; Wed, 19 Aug 2020 05:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jx52W8/tMz8ycWNcdNMSwSIWy3uzicvJx8KT6Ue30a4=; b=Vlw58Yu+parCiyHwWc7yxhBYnufS/FdX+NRh6HxfGBQXFZL3b8HTsoFS10rR/Wl24r emDi2Ij42/tcGZvftE+8/2I/5ND+itBEnEWXnq7rsyldQ4OFADk2ih/ywIjEeRdE8v4R f3qxV/48dOzujGWM0I/DeZxVJ+WHJvpjHM+3IEXa/6X1/to80K/TsNHPWNpEIspalhGy ZdA9s8zhWfUkDiNs+DtyDLuz1Dw2Cm9lMtjvp4GRNh9ED98XY7QJda5qtPfk4t0cDy3O wjJ0dthcT6wxl3qd3eyUX71thnCaz2JB8bywkWzxPkVxCE5oxKrPowunbhNATAIMylVc A7yA== 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=jx52W8/tMz8ycWNcdNMSwSIWy3uzicvJx8KT6Ue30a4=; b=CBXIXYZvh8YKkKy9gIXnZrysnkyaDSaFioVB7MGPFtpNzbKqqYfTUrvNq2okmmKKjl dk0exPClEdoT++VMu76zLHlSVLRDEWFvKuEFz/41nJ1SeLYxQbEkq9+yJYDfys1V4nRf cVKAnDwe0ldvDJkIVVeAJguJcCN2hD8uSQId99t4pZZgwON/7V1XOCMkdVVXllKVVgVe b8mZsVd5EHf6d6lDmRJ97cR9QB7UZc+MeigB1y/qOJsJ0Pgp7ao9PYDkJuRvR7Vea+5J cUvag8//4+DE9RPZMuNAyc+e+jexVrlyKYGhIB6o2tWM1Dx5QhevBOegZRWvanHLOWeX i7NA== X-Gm-Message-State: AOAM532yTJAa8RND/WikXnVvUI4HPXerUlBz/4mRma07+EhPr4bcDUll P6hK1oN9+DoXEfvjz+N6sxmMGQVGPlUHTQ6m X-Google-Smtp-Source: ABdhPJxnaKHyqT84X04eCfnfIWuhl3BdOwvWb5a2uqNU1uimJa0yROpugqC87/tl1DWCY4l1pIs02Q== X-Received: by 2002:a1c:1b93:: with SMTP id b141mr4715592wmb.150.1597838954662; Wed, 19 Aug 2020 05:09:14 -0700 (PDT) Received: from [192.168.1.112] (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id c10sm39157806wrx.15.2020.08.19.05.09.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Aug 2020 05:09:14 -0700 (PDT) From: Joseph Heenan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8212231D-17BD-4FA1-9488-E0F6019A14EA" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 19 Aug 2020 13:09:13 +0100 In-Reply-To: Cc: Mike Jones , oauth To: Brian Campbell References: X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (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, 19 Aug 2020 12:09:21 -0000 --Apple-Mail=_8212231D-17BD-4FA1-9488-E0F6019A14EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with Brian here, I think =E2=80=9Ctyp=E2=80=9D:=E2=80=9DJWT=E2=80=9D= should be permitted as well as no typ and =E2=80=9Ctyp=E2=80=9D: = "oauth.authz.req+jwt". There are other tests we could write for JAR that an OIDC server will = fail (for example, one that tested the behaviour of passing a value only = outside the request object - which an OIDC server would process, but one = compliant with JAR [or FAPI-RW] would ignore the value outside). I = don=E2=80=99t see having one more case of this as an issue - some = servers will not be JAR compliant, and hence would fail tests that test = JAR-specific behaviour. I also agree with Brian about requiring AS to reject request objects = that have a sub that=E2=80=99s a client_id, this doesn=E2=80=99t seem to = cause significant interoperability concerns as it is hopefully unlikely = that any client is doing so. I could possibly see an argument for = weakening the requirement for an AS to reject a request object with = sub=3Dclient_id to a =E2=80=99should=E2=80=99 (rather than a must) given = there is a small chance it could end up breaking an ecosystem, but I=E2=80= =99m not entirely convinced. Joseph > On 17 Aug 2020, at 23:55, Brian Campbell = wrote: >=20 > I might suggest that thinking about it in the context of = interoperability would be more meaningful than certification tests.=20 >=20 > Saying that an AS MUST reject the Request object if it has a typ = header and the value of the header is not =E2=80=98oauth.authz.req+jwt=E2=80= =99 [1] should allow for interoperability with respect to JWT typing = between all combinations of existing and updated clients with existing = and updated authorization servers.=20 >=20 > Saying that an AS MUST NOT include a sub with client id as the value = would break for an updated authorization server when receiving such a = request object JWT. But that's erroneous and potentially dangerous = behaviour from the client so I don't know that we need to try and = maintain interoperability there.=20 >=20 > [1] Unfortunately "typ":"JWT" would probably also need to be allowed. = As best I understand it "typ":"JWT" basically says "this JWT is a JWT", = which isn't useful for explicit typing and I think makes it effectively = equivalent to an untyped JWT. I've honestly never understood why one = would use "typ":"JWT" but it shows up in a lot of places including = examples and explanations on sites like jwt.io so it = seems very likely that it'd just get copied over and show up in some = amount of real world request object JWTs.=20 >=20 >=20 > On Sat, Aug 15, 2020 at 10:41 AM Mike Jones = > wrote: > Answering Filip and Vladirmir=E2=80=99s question about adding = normative language around =E2=80=9Ctyp=E2=80=9D and =E2=80=9Csub=E2=80=9D:= Anytime you add a new required feature, you are breaking existing = deployments. Suppose we added the normative requirement =E2=80=9CIf a = =E2=80=98typ=E2=80=99 header parameter is present, ASs MUST reject the = Request object if its value is not =E2=80=98oauth.authz.req+jwt=E2=80=99=E2= =80=9D. One could then write a certification test sending the AS a = different =E2=80=9Ctyp=E2=80=9D value =E2=80=93 which to pass, ASs would = have to reject the JWT. Every existing deployment would fail this test! = That=E2=80=99s exactly what we don=E2=80=99t want to have happen. >=20 > =20 >=20 > Brian asked for security considerations. The IESG asked for security = considerations. I added them in the PR =E2=80=93 working with Nat and = John. They point the way to the future without breaking existing = deployments. That=E2=80=99s as it should be. >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 > From: OAuth > = On Behalf Of Warren Parad > Sent: Saturday, August 15, 2020 9:27 AM > To: Vladimir Dzhuvinov > > Cc: oauth > > Subject: [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's No Objection on = draft-ietf-oauth-jwsreq-26: (with COMMENT) >=20 > =20 >=20 > In the case of >=20 > if the Request Object includes a sub claim with the value of the = client_id the AS MUST reject the request >=20 > =20 >=20 > What would the expectation be in terms of a client_credentials grant? >=20 > =20 >=20 > =46rom experience, the sub is frequently populated with the client_id = value and the client_id is not used. Which would mean breaking for that = type of grant wouldn't it? >=20 > =20 >=20 >=20 > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. = Implement Authress . >=20 > =20 >=20 > =20 >=20 > On Sat, Aug 15, 2020 at 11:08 AM Vladimir Dzhuvinov = > wrote: >=20 > +1 to make the "typ" check, as Filip suggested, normative, as existing = client and RP deployments with undefined "typ" will not be affected. New = deployments should be encouraged to type the JWT, and thus be made = safer. >=20 > =20 >=20 > Regarding the "sub !=3D client_id" check -- could a simple rejection = of all JWTs with "sub" present suffice? >=20 > I find it difficult to imagine what else a client could end up setting = the "sub" claim to, if it does end up populating it for some reason. >=20 > Rejecting JWTs with "sub=3Dclient_id" or "sub" present will break = deployments where a client for some reason sets the "typical" JWT = claims, and "sub" is a typical one, but if those deployments happen to = accept client_secret_jwt or private_key_jwt client authentication, they = could well be vulnerable to cross-JWT confusion attacks. >=20 > =20 >=20 > Vladimir >=20 > On 14/08/2020 13:58, Filip Skokan wrote: >=20 > Hi Mike, Nat, >=20 > =20 >=20 > I thought we would go as far as making these normative requirements >=20 > if the Request Object includes a sub claim with the value of the = client_id the AS MUST reject the request > if the Request Object is explicitly typed (typ) its value MUST be ... > First rejects client assertions to be passed as Request Objects. = Second rejects all future typed JWT profiles from being used as Request = Objects without worrying about the claims they may or may not contain. >=20 > =20 >=20 > Or is that breaking? >=20 > =20 >=20 > S pozdravem, > Filip Skokan >=20 > =20 >=20 > =20 >=20 > On Fri, 14 Aug 2020 at 00:59, Mike Jones = > wrote: >=20 > At Nat's request, I've created a pull request addressing Cross-JWT = Confusion security considerations. It addresses both Brian's comment = and the IESG comments about explicit typing. See the full PR = athttps://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10 = . See the = source diffs at = https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-w= orking-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml = . Please = review! >=20 > This is only the first commit, albeit, one that addresses some of the = must substantive issues. More commits will follow addressing additional = IESG comments. >=20 > -- Mike >=20 > -----Original Message----- > From: OAuth > = On Behalf Of Benjamin Kaduk > Sent: Thursday, August 13, 2020 2:59 PM > To: Brian Campbell > > Cc: draft-ietf-oauth-jwsreq@ietf.org = ; oauth-chairs@ietf.org = ; The IESG >; oauth > > Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on = draft-ietf-oauth-jwsreq-26: (with COMMENT) >=20 > Oops, that's my bad. Thanks for the correction -- I've linked to your = message in the datatracker (but didn't bother to have the datatracker = send a third copy of my updated-again ballot position). >=20 > -Ben >=20 > On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote: > > While some discussion of why explicit typing was not used might be=20= > > useful to have, that thread started with a request for security=20 > > considerations prohibiting use of the "sub" with a client ID value.=20= > > Because such a request JWT could be repurposed for JWT client=20 > > authentication. And explicit typing wouldn't help in that situation. > >=20 > > On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker <=20 > > noreply@ietf.org > wrote: > >=20 > > > > > > = -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > = -------------------------------------------------------------------- > > > -- > > > > > > [updated to note that, per > > > = https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0 = > > > eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit=20= > > > typing is not used would be in order] > > > > > > > >=20 > > -- > > _CONFIDENTIALITY NOTICE: This email may contain confidential and=20 > > privileged material for the sole use of the intended recipient(s). = Any=20 > > review, use, distribution or disclosure by others is strictly=20 > > prohibited. If you have received this communication in error, = please=20 > > notify the sender immediately by e-mail and delete the message and = any=20 > > file attachments from your computer. Thank you._ >=20 > _______________________________________________ > 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 = > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > --=20 > Vladimir Dzhuvinov > _______________________________________________ > 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 = >=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.ietf.org/mailman/listinfo/oauth --Apple-Mail=_8212231D-17BD-4FA1-9488-E0F6019A14EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree with Brian here, I think =E2=80=9Ctyp=E2=80=9D:=E2=80=9DJWT=E2=80=9D= should be permitted as well as no typ and =E2=80=9Ctyp=E2=80=9D: = "oauth.authz.req+jwt".

There are other tests we could write for JAR that an OIDC = server will fail (for example, one that tested the behaviour of passing = a value only outside the request object - which an OIDC server would = process, but one compliant with JAR [or FAPI-RW] would ignore the value = outside). I don=E2=80=99t see having one more case of this as an issue - = some servers will not be JAR compliant, and hence would fail tests that = test JAR-specific behaviour.

I also agree with Brian about requiring = AS to reject request objects that have a sub that=E2=80=99s a client_id, = this doesn=E2=80=99t seem to cause significant interoperability concerns = as it is hopefully unlikely that any client is doing so. I could = possibly see an argument for weakening the requirement for an AS to = reject a request object with sub=3Dclient_id to a =E2=80=99should=E2=80=99= (rather than a must) given there is a small chance it could end up = breaking an ecosystem, but I=E2=80=99m not entirely convinced.

Joseph


On 17 Aug 2020, at 23:55, Brian Campbell = <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

I might suggest that thinking = about it in the context of interoperability would be more meaningful = than certification tests.

Saying that an AS MUST reject the = Request object if it has a typ header and the value of the header is not = =E2=80=98oauth.authz.req+jwt=E2=80=99 [1] should allow for = interoperability with respect to JWT typing between all combinations of = existing and updated clients with existing and updated authorization = servers.

Saying that an AS MUST NOT include a sub with client id as = the value would break for an updated authorization server when receiving = such a request object JWT. But that's erroneous and potentially = dangerous behaviour from the client so I don't know that we need to try = and maintain interoperability there.

[1] Unfortunately = "typ":"JWT" would probably also need to be allowed. As best I understand = it "typ":"JWT" basically says "this JWT is a JWT", which isn't useful = for explicit typing and I think makes it effectively equivalent to an = untyped JWT. I've honestly never understood why one would use = "typ":"JWT" but it shows up in a lot of places including examples and = explanations on sites like jwt.io so it seems very likely that it'd just get copied = over and show up in some amount of real world request object JWTs.


On Sat, Aug 15, 2020 at 10:41 AM Mike Jones = <Michael..Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:

Answering Filip and Vladirmir=E2=80=99s question about adding = normative language around =E2=80=9Ctyp=E2=80=9D and =E2=80=9Csub=E2=80=9D:=   Anytime you add a new required feature, you are breaking existing = deployments.  Suppose we added the normative requirement =E2=80=9CIf a =E2=80=98typ=E2=80=99 header parameter is = present, ASs MUST reject the Request object if its value is not = =E2=80=98oauth.authz.req+jwt=E2=80=99=E2=80=9D.  One could then = write a certification test sending the AS a different =E2=80=9Ctyp=E2=80=9D= value =E2=80=93 which to pass, ASs would have to reject the JWT.  Every existing deployment would fail this = test!  That=E2=80=99s exactly what we don=E2=80=99t want to = have happen.

 

Brian = asked for security considerations.  The IESG asked for security = considerations.  I added them in the PR =E2=80=93 working with Nat = and John.  They point the way to the future without breaking = existing deployments.  That=E2=80=99s as it should be.

 

          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Warren Parad
Sent: Saturday, August 15, 2020 9:27 AM
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
Cc: oauth <oauth@ietf.org>
Subject: [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's No = Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

 

In the case of

if the Request Object includes a sub claim with the = value of the client_id the AS MUST reject the request

 

What would the expectation be in = terms of a client_credentials grant?

 

=46rom experience, the sub is frequently populated with the client_id value = and the client_id is not used. Which would mean breaking for that type = of grant wouldn't it?

 
Warren Parad
Founder, CTO

Secure your user data and complete your authorization = architecture. Implement Authress.

 

 

On Sat, Aug 15, 2020 at 11:08 AM = Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

+1 to make the "typ" check, as Filip = suggested, normative, as existing client and RP deployments with = undefined "typ" will not be affected. New deployments should be = encouraged to type the JWT, and thus be made safer.

 

Regarding the "sub !=3D client_id" = check -- could a simple rejection of all JWTs with "sub" present = suffice?

I find it = difficult to imagine what else a client could end up setting the "sub" = claim to, if it does end up populating it for some reason.

Rejecting JWTs with = "sub=3Dclient_id" or "sub" present will break deployments where a client = for some reason sets the "typical" JWT claims, and "sub" is a typical = one, but if those deployments happen to accept client_secret_jwt or = private_key_jwt client authentication, they could well be vulnerable to cross-JWT confusion attacks.

 

Vladimir

On 14/08/2020 13:58, Filip Skokan = wrote:

Hi Mike, Nat,

 

I thought we would go as far as = making these normative requirements

  • if the Request Object includes a sub claim with the value of the = client_id the AS MUST reject the request
  • if the Request Object is explicitly typed (typ) its value MUST be ...

First rejects client assertions = to be passed as Request Objects. Second rejects all future typed JWT = profiles from being used as Request Objects without worrying about the = claims they may or may not contain.

 

Or is that breaking?

 

S pozdravem,
Filip Skokan

 

 

On Fri, 14 Aug 2020 at 00:59, = Mike Jones <Michael..Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

At Nat's request, I've created a pull request = addressing Cross-JWT Confusion security considerations.  It = addresses both Brian's comment and the IESG comments about explicit = typing.  See the full PR at https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10.  See = the source diffs at = https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-w= orking-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml.  = Please review!

This is only the first commit, albeit, one that addresses some of the = must substantive issues.  More commits will follow addressing = additional IESG comments.

                    =             -- Mike

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of = Benjamin Kaduk
Sent: Thursday, August 13, 2020 2:59 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: draft-ietf-oauth-jwsreq@ietf.org; oauth-chairs@ietf.org; The IESG <iesg@ietf.org>; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on = draft-ietf-oauth-jwsreq-26: (with COMMENT)

Oops, that's my bad.  Thanks for the correction -- I've linked to = your message in the datatracker (but didn't bother to have the = datatracker send a third copy of my updated-again ballot position).

-Ben

On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote:
> While some discussion of why explicit typing was not used might be =
> useful to have, that thread started with a request for security
> considerations prohibiting use of the "sub" with a client ID value. =
> Because such a request JWT could be repurposed for JWT client
> authentication. And explicit typing wouldn't help in that = situation.
>
> On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker < =
> noreply@ietf.org> wrote:
>
> >
> > = --------------------------------------------------------------------
> > --
> > COMMENT:
> > = --------------------------------------------------------------------
> > --
> >
> > [updated to note that, per
> > = https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0 > > eaE/ and the JWT BCP (RFC 8725), some discussion of why = explicit
> > typing is not used would be in order]
> >
> >
>
> --
> _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

_______________________________________________
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
-- 
Vladimir Dzhuvinov

_______________________________________________
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

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

= --Apple-Mail=_8212231D-17BD-4FA1-9488-E0F6019A14EA-- From nobody Wed Aug 19 10:17:59 2020 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 D744E3A08E6 for ; Wed, 19 Aug 2020 10:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 j33ofXRAfLVg for ; Wed, 19 Aug 2020 10:17:52 -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 4F19B3A08C3 for ; Wed, 19 Aug 2020 10:17:31 -0700 (PDT) Received: from [192.168.1.11] (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 07JHHT3M016017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 19 Aug 2020 13:17:29 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_FC59BE4D-50DE-4D9C-9F59-3C29AB906B53" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: Date: Wed, 19 Aug 2020 13:17:29 -0400 To: oauth X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [OAUTH-WG] OAuth v.2.1 Readthrough 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, 19 Aug 2020 17:17:57 -0000 --Apple-Mail=_FC59BE4D-50DE-4D9C-9F59-3C29AB906B53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As promised on the WG call, I=E2=80=99ve gone through the 2.1 document = and I=E2=80=99ve made some notes and suggestions on my way through. A = big thanks to the editors for putting this together, and particularly = for Aaron who did the early heavy lifting on getting a reasonable start = on this important work! But first, a note: I realize that many portions of this are simply = copied from 6749 or related specifications, and I do not fault the = editors for that. Even so, there are some places where the old language = should be updated in this draft, since we have an opportunity to fix = things and make them more readable on our way through. There are also a = number of places that are redundant with each other as they clearly come = from different source documents. A major goal of this work is to = coalesce these differences into a single and easily understandable = framework. =C2=A7Abstract I think we should update =E2=80=9Cinteraction between the RO and the = HTTP Service=E2=80=9D to be =E2=80=9Cthe RO and an authorization = service=E2=80=9D or something like that instead, since =E2=80=9Cthe HTTP = service=E2=80=9D referenced elsewhere in this paragraph is more = precisely the RS and not the AS, yet the interaction and approval = happens at the AS. OAuth 2.0 allowed the AS and RS to be separate, and = 2.1 should go further to admit that in a lot of cases today, they are = separate.=20 There=E2=80=99s been debate on the =E2=80=9Creplaces and obsoletes=E2=80=9D= language already, and I think there=E2=80=99s a lot of IETF process = that we=E2=80=99ll need to sort out to get that language right. =C2=A71: We should add a note on password use to this list: - Often the resource owner=E2=80=99s password is used with other = unrelated services, and the additional exposure of sharing the password = among components in one domain lowers the possible security in other = domains where the password is shared. =C2=B63/4 can probably be collapsed to read better, and some of the = language cleaned up. Recommend: OAuth addresses these issues by introducing an authorization layer and = separating the role of the client from that of the resource owner. In = OAuth, the client requests access to resources controlled by the = resource owner and hosted by the resource server. Instead of using the = resource owner's credentials to access protected resources, the client = obtains an access token - a credential representing a specific set of = access attributes such as scope and lifetime. Access tokens are issued = to clients by an authorization server with the approval of the resource = owner. The client uses the access token to access the protected = resources hosted by the resource server. =C2=B66: (and throughout document) avoid use of gendered pronouns in = favor of singular =E2=80=9Cthey=E2=80=9D unless needed for clearer = reading (such as an Alice and Bob scenario) =C2=A71.2: This diagram could use an update to not show the client = talking directly to the RO in the first step, especially because the = ROPC grant has been removed here. The way it=E2=80=99s written now makes = it look like the user gives something to the client which it then trades = for a token directly, which doesn=E2=80=99t happen quite like that = anywhere. =C2=A71.3: Having taught many OAuth 2 classes to hundreds of people over = the years, I can say with confidence that this definition of =E2=80=9Cgran= t=E2=80=9D as a credential has historically been problematic and = confusing to most people. And in particular, it doesn=E2=80=99t even = really apply to the client credentials flow listed here: there is not a = separate "credential representing authorization", just the client=E2=80=99= s own authentication. Suggest new text to more accurately reflect what a = =E2=80=9Cgrant=E2=80=9D is in the OAuth reality: An authorization grant is a process by which a client obtains = authorization from a resource owner to obtain an access token to act on = that resource owner=E2=80=99s behalf. This specification defines... Changing this would require a consensus call=20 =C2=A71.3.X: I don=E2=80=99t see why we shouldn=E2=80=99t list the = Device Flow here in this spec. It=E2=80=99s mentioned as an extension = later, but we might as well list it here as a known and accepted grant = type.=20 =C2=A71.4: This section should mention introspection explicitly. = Recommend rewriting the intro to =C2=B63: The token make be used by the RS to retrieve the authorization = information, or the token may self-contain the authorization information = in a verifiable manner (i.e., a token string consisting of a signed data = payload). One example of a token retrieval mechanism is Token = Introspection [RFC7662], in which the RS calls an endpoint on the AS to = validate the token presented by the client. One example of a structured = token =E2=80=A6 We may also want to mention CWT (RFC8392) here in passing.=20 =C2=A71.5: =E2=80=9CThe string is usually opaque=E2=80=9D should be = =E2=80=9Cthe string is opaque" =C2=A71.6: this should probably refer to the TLS BCP195 here instead of = the RFC and version. =C2=A71.8: This should have explicit links to introspection (RFC7662), = registration (RFC7591, RFC7592), and discovery (RFC8414) inline as = they=E2=80=99re given as examples, instead of putting them all in the = appendix. Perhaps also bring up JWTs for token formats here as well. =C2=A71.X: Suggest adding a section on compatibility with OAuth 2.0, = either as part of =C2=A71.8 or in a new section injected right after it. = Some suggested starter text: OAuth 2.1 is compatible with OAuth 2.0 with the extensions and = restrictions from known best current practices applied. Specifically, = features not available in OAuth 2.0 core, such as PKCE, are required in = OAuth 2.1. Additionally, features available in OAuth 2.0, such as the = implicit or resource owner credentials grant types, are not available in = OAuth 2.1. Furthermore, some behaviors allowed in OAuth 2.0 are = restricted in OAuth 2.1, such as the strict string matching of redirect = URIs required by OAuth 2.1. =C2=A72: the client needs only provide redirect URIs if it uses them =E2=80= =94 this registration requirement is meaningless for device flow and = client credentials grants, suggest changing second bullet to something = like: - provide client details needed by the grant type in use, such = as redirect URIs as described in section 3.1.2, and =C2=A72.1: The first sentence on client IDs seems out of place here, and = it should probably be in 2.2 or 2 itself. It might read better to move = =C2=A72.1 after =C2=A72.3 to allow getting away from that problem =C2=A72.2: While it=E2=80=99s usually the case that the AS issues the = client_id, it=E2=80=99s increasingly common in profiles of OAuth 2 for = that to no longer be true. Ultimately, the AS needs to be able to = :recognize: the client software identified by the client ID, and issuing = an ID associated with some known set of policies (like which redirect = URIs are allowed) is just one way to do it. We should be more precise in = the definition and allow for the more general use cases that we already = know are in the wild. Additionally, fixed client IDs are a thing, and so = the restriction of it being unique to the AS is also untrue. Now = allowing client_id choice is important mostly for registration-based = clients, where the AS does issue the ID, and not for other cases where = the AS =E2=80=9Crecognizes=E2=80=9D and processes the client ID, like in = OIDC=E2=80=99s Federation profile and some other specs. =C2=A72.3.1: Can we excise the term =E2=80=9Cclient password=E2=80=9D = since nobody in the wild uses it, in my experience at least?=20 =C2=A72.3.X: We should mention other common client authentication = methods here in the core, including private_key_jwt and MTLS. Both have = stable implementations and are registered, we should call them out = directly. =C2=A72.4: We need to define what exactly an =E2=80=9Cunregistered = client=E2=80=9D is if we=E2=80=99re going to refer to it here. I think = rewriting of =C2=A72.2 could help address a lot of this. =C2=A73.1: Since the =E2=80=9Cresources=E2=80=9D parameter spec = (RFC8707) breaks the =E2=80=9Cnot more than once=E2=80=9D requirement, = can we change that here? Or at least put in an escape valve like = =E2=80=9Cextensions to this specification MAY define parameters that can = be included more than once=E2=80=9D. =C2=A73.1.2: Comparing =E2=80=9Ctwo URIs=E2=80=9D is talked about here, = but only one is explicitly mentioned. I assume it means comparing the = registered redirect URI vs. any specified in the request, but that=E2=80=99= s not mentioned. This is misplaced =E2=80=94 maybe move to =C2=A73.1.2.3 = or the information needs to be inlined up here. =C2=A73.1.2.5: If we=E2=80=99re going to mention this kind of attack = here (and we should), then we should also talk about exposure of the = auth code in referrer headers, especially to elements loaded within the = page (such as images and other non-script data).=20 =C2=A73.2: Again the use of =E2=80=9Cgrant=E2=80=9D as a noun here = largely leads to confusion. This could be changed to just =E2=80=9CThe = token endpoint is used by the client to obtain an access token using a = grant, such as those described in =C2=A74 and =C2=A76 of this = specification.=E2=80=9D =C2=B63: The client shouldn=E2=80=99t ever be adding query parameters = to the token endpoint, so this requirement is not meaningful. =C2=B65: We should specify form encoding as the input body here. We should be explicitly recommending CORS support on the token = endpoint here, especially if we expect SPA=E2=80=99s to use the auth = code flow going forward. =C2=A73.3: Can we start to mandate or at least recommend that scope is = always returned and not just when it differs? Yes this is a breaking = change for the AS but it doesn=E2=80=99t affect clients negatively, and = it=E2=80=99s similar in requirement to doing exact redirect URI matching = which is already done in this spec that OAuth 2.0 didn=E2=80=99t do. =C2=A74: As above, stating that the authorization is =E2=80=9Cin the = form of a grant=E2=80=9D is confusing as the authorization might be just = the existence of the client itself. =C2=A74.1: We should remove the =E2=80=9Cflow=E2=80=9D based language = throughout the document. This seems to have never quite gotten cleaned = up previously.=20 =C2=A74.1: The requests aren=E2=80=99t coming =E2=80=9C=46rom the = authorization server=E2=80=9D, suggest reword: =E2=80=A6 capable of = receiving incoming requests (via redirection from the authorization = server). =C2=A74.1.1.1: The first code-block callout is unhelpful here, suggest = inlining it to the preceding paragraph, or remove it. The content is = largely already covered by the ABNF and the NOTE. =C2=A74.1.1.2: Reverse the order of the plain and S256 examples to imply = preference to S256. Remove line about =E2=80=9Cexisting deployments=E2=80=9D= , but constrained environments is still a potentially reasonable reason = to keep =E2=80=9Cplain=E2=80=9D so add that to the preceding paragraph = (though you=E2=80=99d be hard pressed to find an embedded system that = can=E2=80=99t do that these days).=20 =C2=A74.1.2: the last few paragraphs on storing code_challenge are = awkward to read, suggest reordering to clarify: The authorization server MUST associate the code_challenge and = code_challenge_method values with the issued authorization code so the = code challenge can be verified later.=20 The exact method that the server uses to associate the code_challenge = with the issued code is out of scope for this specification. The code = challenge could be stored on the server and associated with the code = there. The code_challenge and code_challenge_method values may be stored = in encrypted form in the code itself, but the server MUST NOT include = the code_challenge value in a response parameter in a form that other = entities can extract. =C2=A74.1.2.1: We should state here, or somewhere in =C2=A74.1, that a = client might send a request and never get a response back on the front = channel, and they have to be prepared for that.=20 =C2=B63: This should be folded into the error definition below = instead of its own paragraph. Should we state in here the =E2=80=9Cunsupported_response_mode=E2=80=9D= error or other now-registered errors from the registry? =C2=A74.2.1: This section should be dropped, it doesn=E2=80=99t add = anything to the conversation. It was meant to keep things parallel to = the other three grants listed, but now that there=E2=80=99s only one it = is just superfluous.=20 =C2=A74.X: Again I think we might want to list the device flow here as = more than an example. If this is meant to be one-stop-shopping then we = should have everything reasonable in the list. =C2=A75.1: Move the content type to the opening sentence instead of = below, but keep the discussion of serialization and structure down where = it is in =C2=B63_ The JSON reference should be updated to RFC8259 =C2=A76: I wonder if now we should move this back to a =E2=80=9Cgrant=E2=80= =9D type in =C2=A74. It originally was but the editor moved it out to = its own section, but I have found that it confuses developers who are = looking for it to have it on its own. Semantically it=E2=80=99s a grant = (process to get an access token), but it feels like something = =E2=80=9Cspecial=E2=80=9D where it isn=E2=80=99t really. I don=E2=80=99t understand the allowance for allowing clients to = refresh a token with alternate grant types here. In particular, the = example of a long-lived authorization code being used again is illegal = since an auth code is one-time-use as per =C2=A79.8 and elsewhere. If = the client is just getting another access token by doing a new grant = process, this isn=E2=80=99t =E2=80=9Crefreshing=E2=80=9D the access = token, it=E2=80=99s getting a new one from scratch. What is this new = allowance trying to say or enable? =C2=A76.1: I=E2=80=99m not sure of the value of including the = =E2=80=9Cimplementation note=E2=80=9D listed here, especially because = =E2=80=9Cgrant=E2=80=9D is now being used as an ongoing entity and not = as currently defined in the document nor as I=E2=80=99m proposing we = more-accurately define it here. This seems like general advice for not = trusting values in tokens unless you can validate the integrity of the = token, and should go in another section.=20 =C2=A77.2.2: some leftover language from this being standalone: =E2=80=9CA= ll challenges defined by this specification MUST use the auth-scheme = value Bearer=E2=80=9D. Change to =E2=80=9Call challenges for this token = type=E2=80=A6=E2=80=9D =C2=A77.3: This section should probably discuss the fact that a given = API can have its own error codes and responses and doesn=E2=80=99t have = to use the OAuth responses. This isn=E2=80=99t clear by the text, and if = the intention of the original text was to have everyone return the same = JSON error, that=E2=80=99s violating design principles of OAuth as a = security layer on top of an API (and we should fix that). Either way we = should be clear about the place of OAuth=E2=80=99s error messages. =C2=A77.X I would like to see some discussion on other forms of tokens, = especially sender-constrained token methods such as OAuth PoP, Token = Binding, MTLS, and DPoP.=20 =C2=A77.4: This section feels like it should be its own top level, or = integrated into =C2=A79, and not under =E2=80=9Caccessing protected = resources=E2=80=9D. =C2=A77.4.2: The beginning should explicitly reference introspection and = JWT as possible solutions. The TLS recommendation should point to the BCP195. I=E2=80=99d rather see these recommendations listed out instead of = mashed together in =C2=A77.4.2 and listed again in =C2=A77.4.3 =E2=80=94 = it=E2=80=99s hard to read this way. The recommendations here are listed for bearer tokens but largely = apply to sender constrained tokens as well. =C2=A78.3: The pointer to registering new parameters should point to = =C2=A78.2 internally instead of directly to RFC6749 =C2=A79: There are several broken/missing links throughout this section, = evidenced by surviving text like (#pop_tokens) and (#mix_up).=20 =C2=A79.1: This probably means =E2=80=9Cshould require clients to = authenticate=E2=80=9D not =E2=80=9Cuse client authentication=E2=80=9D =C2=B63 is confusing, suggested rewording: The process of = issuance/registration and distribution of the underlying credentials = MUST ensures the confidentiality of the credentials for an authorization = server to rely on authentication with those credentials. =C2=B64: This advice should apply even when clients can = authenticate, it=E2=80=99s only especially applicable when the client = hasn=E2=80=99t authenticated. =C2=B66: Should back away from value-judgment language like =E2=80=9Cm= ore sensible services=E2=80=9D. Also, realize that client instances can = be strongly associated even when using dynamic registration, so this = advice falls flat in many cases in the wild. =C2=A79.1.1 and =C2=A79.2 feel like they=E2=80=99re more closely related = than their relative positions in the text would indicate. Should they be = =C2=A79.2.1/9.2 or =C2=A79.2/9.3 respectively instead? I can=E2=80=99t = tell what the intent is. =C2=A79.2: This discussion on redirect URIs for native apps should be = its own section (=C2=A710.3 has this kind of detail), and it should also = include captured remote URLs (registering an https URL on the app = developer=E2=80=99s site that the app listens for) (this is in =C2=A710.3.= 2 but not mentioned here) =C2=A79.4: Not all access token attributes should be shared with the = client. In many cases, the user=E2=80=99s identity or, say, medical = record number might be unknown to the client but known to the RS to look = up information when a call is made. It might also be necessary to hide = some attributes from some RS=E2=80=99s when a token is used for multiple = RS=E2=80=99s in a system. =C2=A79.4.2: The first paragraph isn=E2=80=99t about replay and seems to = belong in =C2=A79.4.1 instead I think we should have more detail on sender constrained tokens, and = that the token value vs. the keys used to present the token can be = handled differently by clients. Also discussion of an attack where the = RS replays the access token would fit under such an umbrella. =C2=A79.5: I believe =E2=80=9C...guessed to produce valid refresh = tokens=E2=80=9D in the last paragraph is supposed to be =E2=80=9C=E2=80=A6= guessed to prevent valid refresh tokens=E2=80=9D, or something similar.=20= =C2=A79.6: The advice here should also indicate that an AS can (should?) = record other details with the token, including which grant type the = token was issued under. The AS can also limit which scopes are available = to which grant types and circumstances. =C2=A79.7: While PAR doesn=E2=80=99t seem to be in scope (should it = be?), it does seem that the use of PAR allows an AS to do something = other than direct string matching for the redirect URI, since the client = can present a redirect URI in an authenticated state in the back channel = first, and the AS can make a more robust decision on those grounds. I = think we might want to consider that here. =C2=B64: The =E2=80=9Csame user agent=E2=80=9D advice only applies = to web-based applications, and this should be made more clear. Otherwise = the user isn=E2=80=99t interacting with the client via an agent, and the = launch/return can be separated. =C2=A79.9: The advice for state and scope also applies to anything sent = in the front channel, and that should be called out more specifically = here with these as key examples. =C2=A79.11: What=E2=80=99s the goal with the =E2=80=9Cother means=E2=80=9D= requirement, and what means are intended here (and how do they = differ?)? =C2=A79.14: We should be more clear that this isn=E2=80=99t the same as = registering to handle a :single: https URI, which is now a common and = accepted pattern. =C2=A79.16: There=E2=80=99s a formatting error on the example here (if I = had to guess, someone used ``` instead of ~~~ in the markdown source) =C2=A79.18.1: We probably want to discuss clients putting target URIs = (ie, where to redirect to after processing the code) into the = =E2=80=9Cstate=E2=80=9D value in a way that someone can manipulate = before the callback occurs.=20 =C2=A79.19: This uniqueness requirement is stronger than the suggestion = earlier in the document. I think it should still be guidance, not a = requirement, as there are other methods of preventing the mixup attack = (like properly using PKCE/state together).=20 =C2=A79.20: Some of this seems to be a repeat of previous sections, = maybe combine them all into a larger discussion on user agents? This section should probably explicitly discuss secure browser tabs. = (They are mentioned in passing in =C2=A710.2) =C2=A710: Much of the content of this section is covered in =C2=A79, and = these need to be shuffled together appropriately. (I get that they come = from different specs, and the plan is for this spec should combine them = intelligently into a navigable set of risks and requirements and not = just paste them back to back.) =C2=B65: This is specifically talking about =E2=80=9CThe system = browser=E2=80=9D, and not just any external browser. This is further = muddied by the fact that the user might not have all their sessions in = the default/normal browser on the platform, a topic which should be = discussed somewhere in here. =C2=A710.3: I don=E2=80=99t understand the MUST on the three different = options. Are there any teeth to this requirement? If a platform = restricts one or more of these options is it not in compliance with = OAuth 2.1? =C2=A711: This section would be a good place for the discussion on the = need for CORS support on the token endpoint. =C2=A712: The discussion on compatibility expectations can be expanded = into this section here. =C2=A713: It=E2=80=99s not exactly traditional to do so, but it might be = worthwhile to list out the various OAuth registries here with = explanations for what they provide. In particular, the client metadata = registry gives a client model, the AS discovery registry gives a server = model, introspection and JWT give a token model, etc.=20 =C2=A7B: The claims in the intro are no longer true as of 2014: it=E2=80=99= s been registered in = https://www.iana.org/assignments/media-types/media-types.xhtml = and = links to the WHATWG spec for it. --Apple-Mail=_FC59BE4D-50DE-4D9C-9F59-3C29AB906B53 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = promised on the WG call, I=E2=80=99ve gone through the 2.1 document and = I=E2=80=99ve made some notes and suggestions on my way through. A big = thanks to the editors for putting this together, and particularly for = Aaron who did the early heavy lifting on getting a reasonable start on = this important work!

But first, a note: I realize that many portions of this are = simply copied from 6749 or related specifications, and I do not fault = the editors for that. Even so, there are some places where the old = language should be updated in this draft, since we have an opportunity = to fix things and make them more readable on our way through. There are = also a number of places that are redundant with each other as they = clearly come from different source documents. A major goal of this work = is to coalesce these differences into a single and easily understandable = framework.



=C2=A7Abstract

I think we should update =E2=80=9Cinteraction between the RO = and the HTTP Service=E2=80=9D to be =E2=80=9Cthe RO and an authorization = service=E2=80=9D or something like that instead, since =E2=80=9Cthe HTTP = service=E2=80=9D referenced elsewhere in this paragraph is more = precisely the RS and not the AS, yet the interaction and approval = happens at the AS. OAuth 2.0 allowed the AS and RS to be separate, and = 2.1 should go further to admit that in a lot of cases today, they are = separate. 

There=E2=80=99s been debate on the =E2=80=9Creplaces and = obsoletes=E2=80=9D language already, and I think there=E2=80=99s a lot = of IETF process that we=E2=80=99ll need to sort out to get that language = right.


=C2=A71: We should add a note on = password use to this list:

 - Often the resource owner=E2=80=99s password is used = with other unrelated services, and the additional exposure of sharing = the password among components in one domain lowers the possible security = in other domains where the password is shared.


  =C2=B63/4 can probably be collapsed to read better, = and some of the language cleaned up. Recommend:

OAuth addresses these issues = by introducing an authorization layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server. Instead of = using the resource owner's credentials to access protected resources, the client obtains an access token - a credential = representing a specific set of access attributes such as scope and lifetime. Access = tokens are issued to clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource = server.

  =C2=B66: (and throughout document) avoid use of = gendered pronouns in favor of singular =E2=80=9Cthey=E2=80=9D unless = needed for clearer reading (such as an Alice and Bob scenario)

=C2=A71.2: This diagram = could use an update to not show the client talking directly to the RO in = the first step, especially because the ROPC grant has been removed here. = The way it=E2=80=99s written now makes it look like the user gives = something to the client which it then trades for a token directly, which = doesn=E2=80=99t happen quite like that anywhere.

=C2=A71.3: Having taught many OAuth 2 = classes to hundreds of people over the years, I can say with confidence = that this definition of =E2=80=9Cgrant=E2=80=9D as a credential has = historically been problematic and confusing to most people. And in = particular, it doesn=E2=80=99t even really apply to the client = credentials flow listed here: there is not a separate "credential = representing authorization", just the client=E2=80=99s own = authentication. Suggest new text to more accurately reflect what a = =E2=80=9Cgrant=E2=80=9D is in the OAuth reality:

An authorization grant is a = process by which a client obtains authorization from a resource owner to = obtain an access token to act on that resource owner=E2=80=99s behalf. = This specification defines...

Changing this would require a consensus = call 

=C2=A71.3.X: I don=E2=80=99t see why we shouldn=E2=80=99t = list the Device Flow here in this spec. It=E2=80=99s mentioned as an = extension later, but we might as well list it here as a known and = accepted grant type. 

=C2=A71.4: This section should mention introspection = explicitly. Recommend rewriting the intro to =C2=B63:

The token make = be used by the RS to retrieve the authorization information, or the = token may self-contain the authorization information in a verifiable = manner (i.e., a token string consisting of a signed data payload). One = example of a token retrieval mechanism is Token Introspection [RFC7662], = in which the RS calls an endpoint on the AS to validate the token = presented by the client. One example of a structured token =E2=80=A6
=

We may = also want to mention CWT (RFC8392) here in passing. 

=C2=A71.5: =E2=80=9CThe = string is usually opaque=E2=80=9D should be =E2=80=9Cthe string is = opaque"

=C2=A71.= 6: this should probably refer to the TLS BCP195 here instead of the RFC = and version.

=C2=A71.8: This should have explicit links to introspection = (RFC7662), registration (RFC7591, RFC7592), and discovery (RFC8414) = inline as they=E2=80=99re given as examples, instead of putting them all = in the appendix. Perhaps also bring up JWTs for token formats here as = well.

=C2=A71.X:= Suggest adding a section on compatibility with OAuth 2.0, either as = part of =C2=A71.8 or in a new section injected right after it. Some = suggested starter text:

OAuth 2.1 is compatible with = OAuth 2.0 with the extensions and restrictions from known best current = practices applied. Specifically, features not available in OAuth 2.0 = core, such as PKCE, are required in OAuth 2.1. Additionally, features = available in OAuth 2.0, such as the implicit or resource owner = credentials grant types, are not available in OAuth 2.1. Furthermore, = some behaviors allowed in OAuth 2.0 are restricted in OAuth 2.1, such as = the strict string matching of redirect URIs required by OAuth = 2.1.

=C2=A72: the client needs only provide redirect URIs if it = uses them =E2=80=94 this registration requirement is meaningless for = device flow and client credentials grants, suggest changing second = bullet to something like:

= - provide client details needed by the grant type in use, such as = redirect URIs as described in section 3.1.2, and

=C2=A72.1: The first sentence on client = IDs seems out of place here, and it should probably be in 2.2 or 2 = itself. It might read better to move =C2=A72.1 after =C2=A72.3 to allow = getting away from that problem

=C2=A72.2: While it=E2=80=99s usually = the case that the AS issues the client_id, it=E2=80=99s increasingly = common in profiles of OAuth 2 for that to no longer be true. Ultimately, = the AS needs to be able to :recognize: the client software identified by = the client ID, and issuing an ID associated with some known set of = policies (like which redirect URIs are allowed) is just one way to do = it. We should be more precise in the definition and allow for the more = general use cases that we already know are in the wild. Additionally, = fixed client IDs are a thing, and so the restriction of it being unique = to the AS is also untrue. Now allowing client_id choice is important = mostly for registration-based clients, where the AS does issue the ID, = and not for other cases where the AS =E2=80=9Crecognizes=E2=80=9D and = processes the client ID, like in OIDC=E2=80=99s Federation profile and = some other specs.

=C2=A72.3.1: Can we excise the term =E2=80=9Cclient = password=E2=80=9D since nobody in the wild uses it, in my experience at = least? 

=C2=A72.3.X: We should mention other common client = authentication methods here in the core, including private_key_jwt and = MTLS. Both have stable implementations and are registered, we should = call them out directly.

=C2=A72.4: We need to define what exactly an =E2=80=9Cunregiste= red client=E2=80=9D is if we=E2=80=99re going to refer to it here. I = think rewriting of =C2=A72.2 could help address a lot of this.

=C2=A73.1: Since the = =E2=80=9Cresources=E2=80=9D parameter spec (RFC8707) breaks the =E2=80=9Cn= ot more than once=E2=80=9D requirement, can we change that here? Or at = least put in an escape valve like =E2=80=9Cextensions to this = specification MAY define parameters that can be included more than = once=E2=80=9D.

=C2=A73.1.2: Comparing =E2=80=9Ctwo URIs=E2=80=9D is talked = about here, but only one is explicitly mentioned. I assume it means = comparing the registered redirect URI vs. any specified in the request, = but that=E2=80=99s not mentioned. This is misplaced =E2=80=94 maybe move = to =C2=A73.1.2.3 or the information needs to be inlined up = here.

=C2=A73.1.= 2.5: If we=E2=80=99re going to mention this kind of attack here (and we = should), then we should also talk about exposure of the auth code in = referrer headers, especially to elements loaded within the page (such as = images and other non-script data). 

=C2=A73.2: Again the use of =E2=80=9Cgran= t=E2=80=9D as a noun here largely leads to confusion. This could be = changed to just =E2=80=9CThe token endpoint is used by the client to = obtain an access token using a grant, such as those described in =C2=A74 = and =C2=A76 of this specification.=E2=80=9D

  =C2=B63: The client shouldn=E2=80=99= t ever be adding query parameters to the token endpoint, so this = requirement is not meaningful.

  =C2=B65: We should specify form = encoding as the input body here.

  We should be explicitly = recommending CORS support on the token endpoint here, especially if we = expect SPA=E2=80=99s to use the auth code flow going forward.

=C2=A73.3: Can we start = to mandate or at least recommend that scope is always returned and not = just when it differs? Yes this is a breaking change for the AS but it = doesn=E2=80=99t affect clients negatively, and it=E2=80=99s similar in = requirement to doing exact redirect URI matching which is already done = in this spec that OAuth 2.0 didn=E2=80=99t do.

=C2=A74: As above, stating that the = authorization is =E2=80=9Cin the form of a grant=E2=80=9D is confusing = as the authorization might be just the existence of the client = itself.

=C2=A74.= 1: We should remove the =E2=80=9Cflow=E2=80=9D based language throughout = the document. This seems to have never quite gotten cleaned up = previously. 

=C2=A74.1: The requests aren=E2=80=99t coming =E2=80=9C=46rom = the authorization server=E2=80=9D, suggest reword: =E2=80=A6 capable of = receiving incoming requests (via redirection from the authorization = server).

=C2=A74.1.1.1: The first code-block callout is unhelpful = here, suggest inlining it to the preceding paragraph, or remove it. The = content is largely already covered by the ABNF and the NOTE.

=C2=A74.1.1.2: Reverse = the order of the plain and S256 examples to imply preference to S256. = Remove line about =E2=80=9Cexisting deployments=E2=80=9D, but = constrained environments is still a potentially reasonable reason to = keep =E2=80=9Cplain=E2=80=9D so add that to the preceding paragraph = (though you=E2=80=99d be hard pressed to find an embedded system that = can=E2=80=99t do that these days). 

=C2=A74.1.2: the last few paragraphs on = storing code_challenge are awkward to read, suggest reordering to = clarify:

The authorization server MUST associate the code_challenge and code_challenge_method values with the issued = authorization code so the code challenge can be verified later. 
The exact method that the server uses to = associate the code_challenge with the = issued code is out of scope for this = specification. The code challenge could be stored on the server and = associated with the code there. The code_challenge= and code_challenge_method values may be stored in encrypted form in the code = itself, but the server MUST NOT include the code_challenge value in a response parameter in a = form that other entities can extract.

=C2=A74.1.2.1: We should state here, or = somewhere in =C2=A74.1, that a client might send a request and never get = a response back on the front channel, and they have to be prepared for = that. 

    =C2=B63: This should be folded into the error = definition below instead of its own paragraph.

   Should we state in here = the =E2=80=9Cunsupported_response_mode=E2=80=9D error or other = now-registered errors from the registry?

=C2=A74.2.1: This section should be = dropped, it doesn=E2=80=99t add anything to the conversation. It was = meant to keep things parallel to the other three grants listed, but now = that there=E2=80=99s only one it is just superfluous. 

=C2=A74.X: Again I think = we might want to list the device flow here as more than an example. If = this is meant to be one-stop-shopping then we should have everything = reasonable in the list.

=C2=A75.1: Move the content type to the opening sentence = instead of below, but keep the discussion of serialization and structure = down where it is in =C2=B63_

    The JSON reference should = be updated to RFC8259

=C2=A76: I wonder if now we should move this back to a = =E2=80=9Cgrant=E2=80=9D type in =C2=A74. It originally was but the = editor moved it out to its own section, but I have found that it = confuses developers who are looking for it to have it on its own. = Semantically it=E2=80=99s a grant (process to get an access token), but = it feels like something =E2=80=9Cspecial=E2=80=9D where it isn=E2=80=99t = really.

  =   I don=E2=80=99t understand the allowance for allowing clients to = refresh a token with alternate grant types here. In particular, the = example of a long-lived authorization code being used again is illegal = since an auth code is one-time-use as per =C2=A79.8 and elsewhere. If = the client is just getting another access token by doing a new grant = process, this isn=E2=80=99t =E2=80=9Crefreshing=E2=80=9D the access = token, it=E2=80=99s getting a new one from scratch. What is this new = allowance trying to say or enable?

=C2=A76.1: I=E2=80=99m not sure of the = value of including the =E2=80=9Cimplementation note=E2=80=9D listed = here, especially because =E2=80=9Cgrant=E2=80=9D is now being used as an = ongoing entity and not as currently defined in the document nor as I=E2=80= =99m proposing we more-accurately define it here. This seems like = general advice for not trusting values in tokens unless you can validate = the integrity of the token, and should go in another = section. 

=C2=A77.2.2: some leftover language from this being = standalone: =E2=80=9CAll challenges defined by this specification MUST = use the auth-scheme value Bearer=E2=80=9D. Change to =E2=80=9Cal= l challenges for this token type=E2=80=A6=E2=80=9D

=C2=A77.3: This section = should probably discuss the fact that a given API can have its own error = codes and responses and doesn=E2=80=99t have to use the OAuth responses. = This isn=E2=80=99t clear by the text, and if the intention of the = original text was to have everyone return the same JSON error, that=E2=80=99= s violating design principles of OAuth as a security layer on top of an = API (and we should fix that). Either way we should be clear about the = place of OAuth=E2=80=99s error messages.

=C2=A77.X I would like to see some = discussion on other forms of tokens, especially sender-constrained token = methods such as OAuth PoP, Token Binding, MTLS, and = DPoP. 

=C2=A77.4: This section feels like it should be its own top = level, or integrated into =C2=A79, and not under =E2=80=9Caccessing = protected resources=E2=80=9D.

=C2=A77.4.2: The beginning should = explicitly reference introspection and JWT as possible = solutions.

    The TLS recommendation should point to the = BCP195.

  =   I=E2=80=99d rather see these recommendations listed out instead = of mashed together in =C2=A77.4.2 and listed again in =C2=A77.4.3 =E2=80=94= it=E2=80=99s hard to read this way.

    The recommendations here = are listed for bearer tokens but largely apply to sender constrained = tokens as well.

=C2=A78.3: The pointer to registering new parameters should = point to =C2=A78.2 internally instead of directly to RFC6749

=C2=A79: There are = several broken/missing links throughout this section, evidenced by = surviving text like (#pop_tokens) and (#mix_up). 

=C2=A79.1: This probably = means =E2=80=9Cshould require clients to authenticate=E2=80=9D not = =E2=80=9Cuse client authentication=E2=80=9D

    =C2=B63 is confusing, = suggested rewording: The process of issuance/registration and distribution of the underlying credentials MUST ensures the confidentiality of the credentials for an = authorization server to rely on authentication with those = credentials.

    =C2=B64: This advice should apply even when = clients can authenticate, it=E2=80=99s only especially applicable when = the client hasn=E2=80=99t authenticated.

    =C2=B66: Should back away = from value-judgment language like =E2=80=9Cmore sensible services=E2=80=9D= . Also, realize that client instances can be strongly associated even = when using dynamic registration, so this advice falls flat in many cases = in the wild.

=C2=A79.1.1 and =C2=A79.2 feel like they=E2=80=99re more = closely related than their relative positions in the text would = indicate. Should they be =C2=A79.2.1/9.2 or =C2=A79.2/9.3 respectively = instead? I can=E2=80=99t tell what the intent is.
=C2=A79.2: This discussion on redirect = URIs for native apps should be its own section (=C2=A710.3 has this kind = of detail), and it should also include captured remote URLs (registering = an https URL on the app developer=E2=80=99s site that the app listens = for) (this is in =C2=A710.3.2 but not mentioned here)

=C2=A79.4: Not all = access token attributes should be shared with the client. In many cases, = the user=E2=80=99s identity or, say, medical record number might be = unknown to the client but known to the RS to look up information when a = call is made. It might also be necessary to hide some attributes from = some RS=E2=80=99s when a token is used for multiple RS=E2=80=99s in a = system.

=C2=A79.= 4.2: The first paragraph isn=E2=80=99t about replay and seems to belong = in =C2=A79.4.1 instead

    I think we should have more detail on sender = constrained tokens, and that the token value vs. the keys used to = present the token can be handled differently by clients. Also discussion = of an attack where the RS replays the access token would fit under such = an umbrella.

=C2=A79.5: I believe =E2=80=9C...guessed to produce valid = refresh tokens=E2=80=9D in the last paragraph is supposed to be = =E2=80=9C=E2=80=A6guessed to prevent valid refresh tokens=E2=80=9D, or = something similar. 

=C2=A79.6: The advice here should also indicate that an AS = can (should?) record other details with the token, including which grant = type the token was issued under. The AS can also limit which scopes are = available to which grant types and circumstances.
=C2=A79.7: While PAR doesn=E2=80=99t = seem to be in scope (should it be?), it does seem that the use of PAR = allows an AS to do something other than direct string matching for the = redirect URI, since the client can present a redirect URI in an = authenticated state in the back channel first, and the AS can make a = more robust decision on those grounds. I think we might want to consider = that here.

    =C2=B64: The =E2=80=9Csame user agent=E2=80=9D = advice only applies to web-based applications, and this should be made = more clear. Otherwise the user isn=E2=80=99t interacting with the client = via an agent, and the launch/return can be separated.

=C2=A79.9: The advice = for state and scope also applies to anything sent in the front channel, = and that should be called out more specifically here with these as key = examples.

=C2=A79.11: What=E2=80=99s the goal with the =E2=80=9Cother = means=E2=80=9D requirement, and what means are intended here (and how do = they differ?)?

=C2=A79.14: We should be more clear that this isn=E2=80=99t = the same as registering to handle a :single: https URI, which is now a = common and accepted pattern.

=C2=A79.16: There=E2=80=99s a = formatting error on the example here (if I had to guess, someone used = ``` instead of ~~~ in the markdown source)

=C2=A79.18.1: We probably want to = discuss clients putting target URIs (ie, where to redirect to after = processing the code) into the =E2=80=9Cstate=E2=80=9D value in a way = that someone can manipulate before the callback occurs. 

=C2=A79.19: This = uniqueness requirement is stronger than the suggestion earlier in the = document. I think it should still be guidance, not a requirement, as = there are other methods of preventing the mixup attack (like properly = using PKCE/state together). 

=C2=A79.20: Some of this seems to be a = repeat of previous sections, maybe combine them all into a larger = discussion on user agents?

    This section should probably explicitly discuss = secure browser tabs. (They are mentioned in passing in =C2=A710.2)

=C2=A710: Much of the = content of this section is covered in =C2=A79, and these need to be = shuffled together appropriately. (I get that they come from different = specs, and the plan is for this spec should combine them intelligently = into a navigable set of risks and requirements and not just paste them = back to back.)

     =C2=B65: This is specifically talking = about =E2=80=9CThe system browser=E2=80=9D, and not just any external = browser. This is further muddied by the fact that the user might not = have all their sessions in the default/normal browser on the platform, a = topic which should be discussed somewhere in here.

=C2=A710.3: I don=E2=80=99= t understand the MUST on the three different options. Are there any = teeth to this requirement? If a platform restricts one or more of these = options is it not in compliance with OAuth 2.1?

=C2=A711: This section would be a good = place for the discussion on the need for CORS support on the token = endpoint.

=C2=A7= 12: The discussion on compatibility expectations can be expanded into = this section here.

=C2=A713: It=E2=80=99s not exactly traditional to do so, but = it might be worthwhile to list out the various OAuth registries here = with explanations for what they provide. In particular, the client = metadata registry gives a client model, the AS discovery registry gives = a server model, introspection and JWT give a token model, = etc. 

=C2=A7= B: The claims in the intro are no longer true as of 2014: it=E2=80=99s = been registered in https://www.iana.org/assignments/media-types/media-types.xhtml<= /a> and links to the WHATWG spec for it.


= --Apple-Mail=_FC59BE4D-50DE-4D9C-9F59-3C29AB906B53-- From nobody Wed Aug 19 12:23:31 2020 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 4D42D3A0D7B for ; Wed, 19 Aug 2020 12:23:30 -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 4fcKnq7ybhbV for ; Wed, 19 Aug 2020 12:23:28 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 03D533A0D79 for ; Wed, 19 Aug 2020 12:23:27 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id m22so26623800ljj.5 for ; Wed, 19 Aug 2020 12:23:27 -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=PouhgA6tY5JVGQcwOEl8IlLL1OGSdpezsuGIHVa771s=; b=UKWOvd3NQW5c6YgrAqLxfvJpB7wIUO+OjxO5sAkGeS1eHWBcSPw0JKNmzv8i6iQiQ3 91Ohlmo/2h7urQbK+heTeyOoAwr31ekxdGBIb+nTT0WgA5iWRQb4bPgqKMQjsrzGUZvt cMYi0cI2znrTxGCon2SS4dvX5VZMgiawR8fxBH355mMGrbz2O5MVa6mkTIdQeq0gok0f SYvDmSEcj0FNr+LoO6SvLQNpfxR6odXiVU+8DIcAbG53W2znAzFz4ulgnlhIma15jXuP RGEfJORLbA2jz4pqH7y9Onws08Mb5n39TcmBitLNsLDNdoE788ozoBKwubkWYTvvMrx+ pZRg== 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=PouhgA6tY5JVGQcwOEl8IlLL1OGSdpezsuGIHVa771s=; b=JQ3aI4fOR8WY6EWj1ADW6hXnNw/zuW04xzEFZAYTXXdZALO3P9kK8lqsIg0I/MJJqS lZHFDXLagUwmXT7k6wyHjFajiLqHPJcVG7i4s7YxaXV6utoNLqgjjccUZT7oIGVty7yY H+qVnuDnbuXJFTAPRmmpq18Eny0o0yv1S/wftk8JkqGUPLwQo4Lcxj39RXvnymOf8hfw GGoda4sD1QcfdIEJk5C2j5wRWrYASmHwtFjBClCetyaIr80Jxcs5FSBYlQy3OPthelVt Kq1fc8BALCgpa6n4gCdzg317p9sjsWF+RJAYng4r3KNWxCQsT6+NxAaYPm5G42bnJqKU GK+Q== X-Gm-Message-State: AOAM532xXQfSps9J9gi5QNRZpIBTCPXaLQ/YQsQGXeWrIXCtvUFpvRnm OqYDvrIe+8eaecjQsyON9ZTuReKXziLmfTklXDd7Kxqh/hMMWIAykyVz29/nKn3qgjhgiO5i5sx IcR3RHqKUA+6SAg== X-Google-Smtp-Source: ABdhPJyjQGeNfkhxOsct6HAoX/kqXTOnYoG4eDUZW3DZ5bT94mA0sBYAzbkrxEs8cxKyZWMnqMkp5bggzB9VVrUpPgA= X-Received: by 2002:a05:651c:1291:: with SMTP id 17mr13644575ljc.366.1597865005915; Wed, 19 Aug 2020 12:23:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Wed, 19 Aug 2020 13:22:58 -0600 Message-ID: To: Karsten Meyer zu Selhausen Cc: oauth Content-Type: multipart/alternative; boundary="00000000000013c1e505ad3ff05d" Archived-At: Subject: Re: [OAUTH-WG] WGLC on Pushed Authorization Requests draft 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, 19 Aug 2020 19:23:30 -0000 --00000000000013c1e505ad3ff05d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review, Karsten. We'll incorporate your suggestions into the next revision of the draft. On Wed, Aug 19, 2020 at 3:41 AM Karsten Meyer zu Selhausen < karsten.meyerzuselhausen@hackmanit.de> wrote: > Hi all, > > I have two very small suggestions which I also raised as issues on Github= : > > 1. There are no hints in front of example requests/responses if extra > line breaks are used for display purposes. I think hints such as "(wit= h > extra line breaks for display purposes only)" should be added to the > examples. (#64 > ) > 2. In section 3 there is a typo in step 2. I think it should be "*Vali= date > *the request object signature as specified in JAR > [I-D.ietf-oauth-jwsreq], section 6.2." instead of "*Validates *the > ...". The imperative is used in step 1, as well. (#65 > ) > > Best regards; > Karsten > On 12.08.2020 00:07, Rifaat Shekh-Yusef wrote: > > All, > > This is a WGLC on the *Pushed Authorization Requests *document: > https://www.ietf.org/id/draft-ietf-oauth-par-03.html > > Please, take a look and provide feedback on the list by *August 25th.* > > Regards, > Rifaat & Hannes > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > -- > Karsten Meyer zu Selhausen > IT Security Consultant > Phone: +49 (0)234 / 54456499 > Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, = Security Training > > Unsere n=C3=A4chste Live Online-Schulung zur Sicherheit von OAuth und Ope= nID Connect am 24.09 + 25.09:https://hackmanit.de/de/schulungen/109-live-on= line-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-24-und-25-0= 9-2020 > > 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 > > _______________________________________________ > 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._ --00000000000013c1e505ad3ff05d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review, Karsten. We'll incorporate you= r suggestions into the next revision of the draft.

On Wed, Aug 19, 2020= at 3:41 AM Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de> wrot= e:
=20 =20 =20

Hi all,

I have two very small suggestions which I also raised as issues on Github:

  1. There are no hints i= n front of example requests/responses if extra line breaks are used for display purposes. I think hints such as "<= /font>(with extra line breaks = for display purposes only)" should be added to the examples. (= #64)
  2. In section 3 there i= s a typo in step 2. I think it should be "Validate th= e request object signature as specified in JAR [I-D.ietf-oauth-jwsreq], section 6.2." instead of "Validates the ...". The imperative is used in step 1, as well. (#65)=

Best regards;
Karsten

On 12.08.2020 00:07, Rifaat Shekh-Yusef wrote:
=20 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth

--=20
Karsten Meyer zu Selhausen
IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	https://hackmanit.d=
e | IT Security Consulting, Penetration Testing, Security Training

Unsere n=C3=A4chste Live Online-Schulung zur Sicherheit von OAuth und OpenI=
D Connect am 24.09 + 25.09:
https://hackmanit.de/de/schulungen/109-live-online-schulung-single-=
sign-on-sicherheit-oauth-openid-connect-am-24-und-25-09-2020

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 Som=
orovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
_______________________________________________
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. --00000000000013c1e505ad3ff05d-- From nobody Wed Aug 19 13:06:48 2020 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 6550D3A0DB9 for ; Wed, 19 Aug 2020 13:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 9BAxT-6qM16r for ; Wed, 19 Aug 2020 13:06:44 -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 67E853A0DB7 for ; Wed, 19 Aug 2020 13:06:44 -0700 (PDT) Received: from [192.168.1.11] (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 07JK6gGN026049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 19 Aug 2020 16:06:43 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_C7416B1D-7557-45E6-ABA0-3268A74C7DBB" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <7C0FD285-F677-4501-B2FB-9431A59855F6@mit.edu> Date: Wed, 19 Aug 2020 16:06:42 -0400 To: oauth X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [OAUTH-WG] WGLC Review of PAR 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, 19 Aug 2020 20:06:46 -0000 --Apple-Mail=_C7416B1D-7557-45E6-ABA0-3268A74C7DBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ve done a full read through of the PAR specification, and here = are my notes on it. For additional context, I=E2=80=99ve implemented this specification for = both a client and a server in a couple of languages. Overall, I think = it=E2=80=99s in good shape and it makes sense from a developer=E2=80=99s = perspective. I=E2=80=99ve got a few comments, some small and some that = might need more conversation within the WG, Throughout: Suggest using =E2=80=9Ccredentialed=E2=80=9D instead of = =E2=80=9Cconfidential=E2=80=9D client, as introduced in OAuth 2.1 draft. =C2=A71: Suggest the problems list start with changing scopes or = swapping client IDs as scenarios in the first bullet, ACR is an esoteric = use case for many and not in OAuth 2 core, either remove it or put it at = the end of the bullet. Suggest the second bullet note who the information needs to be = protected from, at least in passing. It=E2=80=99s not clear from this = setup why the parameters should be confidential, and this is a major = motivation for this work. Avoid use of phrase =E2=80=9Cso-called=E2=80=9D and just give the = name =E2=80=9CRequest Object=E2=80=9D. =C2=B64: Perhaps overly pedantic but I suggest extending: =E2=80=9Cin = exchange for a request_uri value usable at the authorization server=E2=80=9D= .=20 =C2=B64/5: Alternatively, suggest combining these paragraphs: =E2=80=9C= This document complements JAR by providing an interoperable way for the = client to push its authorization request parameters to the authorization = server in exchange for a request_uri usable at the authorization server. = The document further allows the client to push request objects as = specified in JAR in exchange for a request_uri usable at the = authorization server.=E2=80=9D =C2=B612: =E2=80=9CThis is directly utilized=E2=80=9D is a little = ambiguous into what it=E2=80=99s referring to. Would suggest rewording = the start as: =E2=80=9CThis early stage client authentication is used by = this draft to allow confidential clients=E2=80=A6=E2=80=9D or something = of that sort. =C2=B613: Not only is POST much harder to use, it=E2=80=99s also = optional for the AS to implement so it can=E2=80=99t be counted on by a = client to be available generally. (To be honest in retrospect we = shouldn=E2=80=99t have included it in OAuth 2.) =C2=A72: Please provide a reference to JWT client assertion auth here = (either the assertion RFC or OIDC=E2=80=99s definition of the client = auth methods mentioned). I would also phrase this as direct guidance = instead of a note/aside. =C2=A72.1: There=E2=80=99s some potential weirdness about client_id = here. Since the authz request was designed around not having client = authentication, that request requires client_id. However, here the = client is authenticating, and the client_id might be included elsewhere = like the Basic header. A developer might be curious about whether they = need to include them twice. =C2=B62: Of necessity, this spec mixes parameters in the = authorization endpoint and token endpoint registries into a single = request. Is there any danger of conflict between them? The registry = holds them in one list but they could possibly have different semantics = in both places. =C2=B66: Does the AS really have "the ability to authenticate and = authorize clients=E2=80=9D? I think what we mean here is "the ability to = authenticate clients and validate client requests=E2=80=9D, but I=E2=80=99= m not positive of the intent.=20 =C2=B67: I=E2=80=99m not sure I buy this example. Even if the = clientID is managed externally, the association with a set or pattern of = allowed redirect URIs is still important, and the AS will need to know = what that is. I think this example could lead an AS developer to = (erroneously and dangerously) conclude that they don=E2=80=99t have to = check any other values in a request, including scope and redirect URI. = It=E2=80=99s important that DynReg doesn=E2=80=99t alleviate that issue, = but removal of DynReg doesn=E2=80=99t really change things in that = regard. Suggest removing example or reworking paragraph. =C2=A72.2: Is =E2=80=9Cexpires_in=E2=80=9D required? If so, can an AS = decide that a request URI doesn=E2=80=99t expire after a certain amount = of time? Related, what does a =E2=80=9C0=E2=80=9D or negative value = mean, if anything?=20 I don=E2=80=99t see why a request URI with unguessable values = isn=E2=80=99t a MUST for one-time-use, is there a reason? =C2=A72.3: Are the HTTP status codes a normative MAY or just an = informative =E2=80=9Ccan=E2=80=9D as written? =C2=A73: This bit should be normative as follows: "he authorization = server MUST take the following steps beyond the processing rules=E2=80=A6"= Clean up the tenses and voice of the numbered list, which are = currently inconsistent. =C2=A77.2: The AS should also make sure that the new redirect URI is = applicable within that client=E2=80=99s domain or policies. So you = wouldn=E2=80=99t want a legit-but-rogue client registering for someone = else=E2=80=99s redirect URI in order to start an attack, for example. I = think overall we might need better guidance around the redirect URI = variability feature (which, to be clear, I=E2=80=99m hugely in favor of = =E2=80=94 but OAuth=E2=80=99s assumptions in the client model make this = trickier to talk about and implement safely, so we need to be extra = careful). =C2=A77.3: As above, is there a reason that this isn=E2=80=99t a MUST? = It=E2=80=99s a temporary credential representing a request, much like an = authorization code in many ways. I don=E2=80=99t see why a legitimate = client would use it more than once, or why a server would want to allow = it for AS-generated values. For client-supplied request URIs, sure, but = not here. =C2=A7X: Missing privacy considerations section. If anything this spec = helps alleviate some privacy concerns by trading values for a reference, = but the section is still needed. --Apple-Mail=_C7416B1D-7557-45E6-ABA0-3268A74C7DBB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99ve done a full read through of the PAR = specification, and here are my notes on it.

For additional context, I=E2=80=99ve = implemented this specification for both a client and a server in a = couple of languages. Overall, I think it=E2=80=99s in good shape and it = makes sense from a developer=E2=80=99s perspective. I=E2=80=99ve got a = few comments, some small and some that might need more conversation = within the WG,



Throughout: Suggest using =E2=80=9Ccredentialed=E2=80=9D = instead of =E2=80=9Cconfidential=E2=80=9D client, as introduced in OAuth = 2.1 draft.

=C2=A7= 1: Suggest the problems list start with changing scopes or swapping = client IDs as scenarios in the first bullet, ACR is an esoteric use case = for many and not in OAuth 2 core, either remove it or put it at the end = of the bullet.

   Suggest the second bullet note who the = information needs to be protected from, at least in passing. It=E2=80=99s = not clear from this setup why the parameters should be confidential, and = this is a major motivation for this work.

   Avoid use of phrase = =E2=80=9Cso-called=E2=80=9D and just give the name =E2=80=9CRequest = Object=E2=80=9D.

   =C2=B64: Perhaps overly pedantic but I suggest = extending: =E2=80=9Cin exchange for a request_uri value usable at the = authorization server=E2=80=9D. 

   =C2=B64/5: Alternatively, = suggest combining these paragraphs: =E2=80=9CThis document complements = JAR by providing an interoperable way for the client to push its = authorization request parameters to the authorization server in exchange = for a request_uri usable at the authorization server. The document = further allows the client to push request objects as specified in JAR in = exchange for a request_uri usable at the authorization = server.=E2=80=9D

    =C2=B612: =E2=80=9CThis is directly utilized=E2=80= =9D is a little ambiguous into what it=E2=80=99s referring to. Would = suggest rewording the start as: =E2=80=9CThis early stage client = authentication is used by this draft to allow confidential clients=E2=80=A6= =E2=80=9D or something of that sort.

    =C2=B613: Not only is = POST much harder to use, it=E2=80=99s also optional for the AS to = implement so it can=E2=80=99t be counted on by a client to be available = generally. (To be honest in retrospect we shouldn=E2=80=99t have = included it in OAuth 2.)

=C2=A72: Please provide a reference to JWT client assertion = auth here (either the assertion RFC or OIDC=E2=80=99s definition of the = client auth methods mentioned). I would also phrase this as direct = guidance instead of a note/aside.

=C2=A72.1: There=E2=80=99s some = potential weirdness about client_id here. Since the authz request was = designed around not having client authentication, that request requires = client_id. However, here the client is authenticating, and the client_id = might be included elsewhere like the Basic header. A developer might be = curious about whether they need to include them twice.

    =C2=B62: = Of necessity, this spec mixes parameters in the authorization endpoint = and token endpoint registries into a single request. Is there any danger = of conflict between them? The registry holds them in one list but they = could possibly have different semantics in both places.

    =C2=B66: = Does the AS really have "the ability to authenticate and authorize clients=E2=80=9D? I think what we mean here is = "the ability to authenticate clients and validate client requests=E2=80=9D= , but I=E2=80=99m not positive of the intent. 

    =C2=B67: = I=E2=80=99m not sure I buy this example. Even if the clientID is managed = externally, the association with a set or pattern of allowed redirect = URIs is still important, and the AS will need to know what that is. I = think this example could lead an AS developer to (erroneously and = dangerously) conclude that they don=E2=80=99t have to check any other = values in a request, including scope and redirect URI. It=E2=80=99s = important that DynReg doesn=E2=80=99t alleviate that issue, but removal = of DynReg doesn=E2=80=99t really change things in that regard. Suggest = removing example or reworking paragraph.

=C2=A72.2: Is =E2=80=9Cexpires_in=E2=80=9D= required? If so, can an AS decide that a request URI doesn=E2=80=99t = expire after a certain amount of time? Related, what does a =E2=80=9C0=E2=80= =9D or negative value mean, if anything? 

    I don=E2=80=99t see why a = request URI with unguessable values isn=E2=80=99t a MUST for = one-time-use, is there a reason?

=C2=A72.3: Are the HTTP status codes a = normative MAY or just an informative =E2=80=9Ccan=E2=80=9D as = written?

=C2=A73= : This bit should be normative as follows: "he authorization server MUST = take the following steps beyond the processing rules=E2=80=A6"

    Clean up = the tenses and voice of the numbered list, which are currently = inconsistent.

=C2=A77.2: The AS should also make sure that the new redirect = URI is applicable within that client=E2=80=99s domain or policies. So = you wouldn=E2=80=99t want a legit-but-rogue client registering for = someone else=E2=80=99s redirect URI in order to start an attack, for = example. I think overall we might need better guidance around the = redirect URI variability feature (which, to be clear, I=E2=80=99m hugely = in favor of =E2=80=94 but OAuth=E2=80=99s assumptions in the client = model make this trickier to talk about and implement safely, so we need = to be extra careful).

=C2=A77.3: As above, is there a reason that this isn=E2=80=99t = a MUST? It=E2=80=99s a temporary credential representing a request, much = like an authorization code in many ways. I don=E2=80=99t see why a = legitimate client would use it more than once, or why a server would = want to allow it for AS-generated values. For client-supplied request = URIs, sure, but not here.

=C2=A7X: Missing privacy considerations section. If anything = this spec helps alleviate some privacy concerns by trading values for a = reference, but the section is still needed.






= --Apple-Mail=_C7416B1D-7557-45E6-ABA0-3268A74C7DBB-- From nobody Wed Aug 19 18:54:55 2020 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 7135F3A1018; Wed, 19 Aug 2020 18:54:50 -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.14.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <159788849031.3863.18028590353036937346@ietfa.amsl.com> Date: Wed, 19 Aug 2020 18:54:50 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-27.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: Thu, 20 Aug 2020 01:54:50 -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 : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) Authors : Nat Sakimura John Bradley Michael B. Jones Filename : draft-ietf-oauth-jwsreq-27.txt Pages : 35 Date : 2020-08-19 Abstract: The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents is not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-27 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-27 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 20 02:02:27 2020 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 604A33A0A40 for ; Thu, 20 Aug 2020 02:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 ypThZVtIKTDa for ; Thu, 20 Aug 2020 02:02:24 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 2D1B03A0A3E for ; Thu, 20 Aug 2020 02:02:24 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id n128so1284297oif.0 for ; Thu, 20 Aug 2020 02:02: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=Y3iI0vl26QYYGrkooGit465v2dZ13CCdZbpfY69ZD44=; b=jtAmMnV7qVsMi77jU3InLvzOj4M6zFhcQZaNA82rHan2OCA+NDGG1psAHjuOXu+UaN 6jdRZXCq/sacuD/pZLvgXC+R5NxH30pcQKinc9ko3MxBwsypk6mNhCvI03N4QE4HwreH uH5snpviETN+B9Z19AzXgQgE36WoWeNNLKuFecdGCnU61uWtG8IjG51wLy3A4Uad8khs 1uUovW1yW54m13zR5rsQWgYDPbaqLRqoE+MtNCZh06Xc+NdQWc/Fa40bXhopbh/GGNK8 LYEKcluC8izduYweFuwLTk+/4ZAhPd9CGCw/xM8iAB7fQ7ZIJZ6I6KtC1yk7p9tgF3u0 lapQ== 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=Y3iI0vl26QYYGrkooGit465v2dZ13CCdZbpfY69ZD44=; b=av+vKb4jPJGzvEqp6UtL6t2Q0e6DIT9HAZpJlT6YrBfB6DBhX3vFbSuYTFNOIBBsSd AifIrTXzDzpc0iMc7P7yicv7QGCViWMcu8ooCTnrplypw81jzftEWSZfI8OzlFc1N3Lv SmQvh6sBUsT0Coqy4KY6i86OIoim2YT6F0vq/UBVGsZZJSdTtzzdeQDUw7STL7rUlWcP v93EMqqvlk6hLn4sI9GQctEgeJWUD3/IyRaa19orV8F4i3dXWQIXALNtRfL57pm5aT2F +a6JE5auv1peZensSH9v4uXWs4IYB/5S36ivpy5YKinF5QV50X3w8SPWIIRpSHtRsN2B IuHw== X-Gm-Message-State: AOAM5322IoSnq+zFxv1Af+3tfhF+PpGoBxolcn3EuYhxNigDZVZ7LmAH KJFCqRvXM65YlBc54Btq9LIaFjWN2LYxVmbsqiKDH4ZuGP4= X-Google-Smtp-Source: ABdhPJy+rAwUT4sis5Ij4b1Z65Em3Ijuy7riiYAU5dVBo1ZuWQQ0NshyJUSiTesB6dqgv5Ho+k2Zf6gzXFrbCdVVqHo= X-Received: by 2002:a54:4588:: with SMTP id z8mr1163320oib.86.1597914143064; Thu, 20 Aug 2020 02:02:23 -0700 (PDT) MIME-Version: 1.0 From: Emond Papegaaij Date: Thu, 20 Aug 2020 11:02:12 +0200 Message-ID: To: oauth Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OAUTH-WG] Client authentication on token revocation 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, 20 Aug 2020 09:02:25 -0000 Hi all, We are currently implementing the token revocation endpoint (RFC 7009) on our authorization server and do not understand why it requires client authentication. When a party (a valid client or not) gets hold of a valid access token in whatever way, the least damaging it could do with it, is to revoke it. The current spec allows an attacker to misuse this token for access to the resource server, but forbids it to revoke it. This seems strange to me. Section 5 of RFC 7009 does not help in this either. It starts to explain that this authentication is needed to prevent malicious clients from guessing tokens, but ends with the fact that if this were possible, much worse damage could be done by using the guessed token on the resource server. We plan to skip the authentication all together and simply revoke any valid token presented. How would you recommend we deal with this? Best regards, Emond Papegaaij Topicus KeyHub From nobody Thu Aug 20 03:52:26 2020 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 AFF713A08AF for ; Thu, 20 Aug 2020 03:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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 NIwLXIyUZ1s4 for ; Thu, 20 Aug 2020 03:52:23 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 DFA773A08AB for ; Thu, 20 Aug 2020 03:52:22 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id m20so1236400eds.2 for ; Thu, 20 Aug 2020 03:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rnfkrc/JOvVAvAN+se3gIShJ0+sSffA7RTq11LcJQSY=; b=jnDLGC80yUZwWt0qhK9GmDOXKyWG/nGIuY2aq33FApPRtN1teZ4gjG1yx5gIQOWiNn 7cTHtijk74+g6ItyHLJKv8RZn1+bjNl1w1ejUxR5zfApa1VmZZFuz35UrCyziUoPKTnL jcI01p2jBp51+AP9+Lo7OzW5tV+z/M1m8Z/vSLOh81gFDQjCzY2gLmUwNdGetAjQYKRU INdjX3v5mrbAUxvOn+mBgYBn+a+jH4sq2PofzJGJhXzGpnMkIuNWEFk+bfsJowjxt2zO J525OnNY6eALa2zXvngCI1PzDyAwlduOiFDMFmEGGsaKuyFwZMpdtg3/urWO06i0HjIq 6MxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rnfkrc/JOvVAvAN+se3gIShJ0+sSffA7RTq11LcJQSY=; b=V8dMpJru7Es1TZHIP+5gQP9eHbVfcygiCsN4L8mzPsPTNHd8xjA+XkZiugKIRR15zX LlOInFJ1grvoVGZLEAMG6/waIPgDBwrM1oh8yj3jVeAOzIhWI2wXHN6dlWUAHtGKvGL+ 8XyrzU3VwLIVPfbkes58PgpDWNBtlEnMC0HlUPTXCl/ncmJuxbNMsxPAWGIcxvHUiMbW qLdu4nOwGBgG2kjqtyxMdqPXbC53jErcA3NTUl/zepQe8nXhQctI0vM/y3VqNcokYX6S TFofHlOi7m0gLyvbLOVdIxLP84lkWOvQhEe8BGqWBOGQ71OpZNXwO0JuySF2qHKHj5S/ luJw== X-Gm-Message-State: AOAM532LLckYvTw19xMWYKzzAJAur0rVOTiisCg+Dst4iyQ692xhXS82 mk9WgIdKfa+2KrQ2/3gGWyYKTA== X-Google-Smtp-Source: ABdhPJwfPJLrmh1X8rSvn5yDRkHZ+sne/Xv5Qv6ravW0Fv7iEyzN6SJDzCHYAiYFyQHhwlHstqe8vg== X-Received: by 2002:a05:6402:145a:: with SMTP id d26mr1248524edx.283.1597920741092; Thu, 20 Aug 2020 03:52:21 -0700 (PDT) Received: from p200300eb8f1e2aeb4ce42ed7e308c687.dip0.t-ipconnect.de (p200300eb8f1e2aeb4ce42ed7e308c687.dip0.t-ipconnect.de. [2003:eb:8f1e:2aeb:4ce4:2ed7:e308:c687]) by smtp.gmail.com with ESMTPSA id u6sm1220651ejf.98.2020.08.20.03.52.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Aug 2020 03:52:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Torsten Lodderstedt In-Reply-To: Date: Thu, 20 Aug 2020 12:52:19 +0200 Cc: oauth Content-Transfer-Encoding: quoted-printable Message-Id: <46A7D36F-C999-4CA5-AA7F-F955316C4855@lodderstedt.net> References: To: Emond Papegaaij X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] Client authentication on token revocation 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, 20 Aug 2020 10:52:25 -0000 Hi Emond,=20 I tend to agree with your assessment. Revoking bearer tokens without = client authentication seems to be better than leaving the attacker the = option to use them to invoke resources.=20 However, if the attacker cannot use the access tokens (e.g. because they = are sender constrained), the attacker could revoke tokens issued to a = confidential client as a kind of DoS attack.=20 best regards, Torsten.=20 > On 20. Aug 2020, at 11:02, Emond Papegaaij = wrote: >=20 > Hi all, >=20 > We are currently implementing the token revocation endpoint (RFC 7009) > on our authorization server and do not understand why it requires > client authentication. When a party (a valid client or not) gets hold > of a valid access token in whatever way, the least damaging it could > do with it, is to revoke it. The current spec allows an attacker to > misuse this token for access to the resource server, but forbids it to > revoke it. This seems strange to me. >=20 > Section 5 of RFC 7009 does not help in this either. It starts to > explain that this authentication is needed to prevent malicious > clients from guessing tokens, but ends with the fact that if this were > possible, much worse damage could be done by using the guessed token > on the resource server. We plan to skip the authentication all > together and simply revoke any valid token presented. How would you > recommend we deal with this? >=20 > Best regards, > Emond Papegaaij > Topicus KeyHub >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Aug 20 04:30:39 2020 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 5C5CE3A082D for ; Thu, 20 Aug 2020 04:30:37 -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 (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 evze9uoNk7Tg for ; Thu, 20 Aug 2020 04:30:34 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 409FC3A0805 for ; Thu, 20 Aug 2020 04:30:33 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id f1so1690768wro.2 for ; Thu, 20 Aug 2020 04:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=S4CJleXtHmUV6VL62ZsP6BxpLtD5FY6L/iLp2KqP1ho=; b=dv6oYsb1hqZdKogyiJl2hrY3PPDiG8rE0hoaaDavFLem2uG95En1Ixms8bcPEEsPhw NRL8O9e7eZDCkzVtwmZ/JkRd9jwzWbHYatwWNWGOvVd1EweIp5k5v8e019Uq7Cl+JDQY HxvGJaoEyg33J7VbKm8kUkM7v1jQ8YO1gZBDs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=S4CJleXtHmUV6VL62ZsP6BxpLtD5FY6L/iLp2KqP1ho=; b=QJDtSPhLX0L2OUteO6Ivspf403eKsd508qa0hGAHZsmCZArfPsVOAdewtMhcJ2ASNA jD4wEE1Qmz25lY7stu9nxqSymRyv89TIWRAMJuN5E26aI+djtZ8YKbqfSIHJulqHJ9z1 94ozFbLPBnw3+cGOkwAPzmRSEawWFwzsFQBpmt7s8Txx0ssb8vV1CWcBaxWxH/uQI2sT mQH+4DzwwjsencZer+JS7Q5jWKqYwEy+IWDc/O89dFALygqp+OYOOtUi3Kw4/ntg2LkU IN0xy5jJoHWK3gm9e5LxaBh9ixJGbxi6Xpsu7ybY4ZUWGe6YFD7lCLpk8I0xo1fjE+NT HkMg== X-Gm-Message-State: AOAM531/twXMyKNMaJtOoBj6TQa22YEyCktzsqtllpzvNmp2vrXr+p4+ 1KQOBTi9OcDXH1kQMO7bjvlg0vofZptYZ1UuZ7Cnjn6jAXALEdWBZFEjSAPOV2SvtnJitIOFXVM iB0gHqLOMRd61fv8ECQSkgAaHl+Sf9NGfQ725ncXX4dWEtIyjJxYfJ6tdkjDVsqe8tQ== X-Google-Smtp-Source: ABdhPJwLNBf/0Bl2kvYGbFjoEA1iMiEjbTEIhOf/obZVrK9nAOUxVskbCFuoaIUDbUrwlSoEF+IKxQ== X-Received: by 2002:adf:a3d0:: with SMTP id m16mr2667466wrb.232.1597923029518; Thu, 20 Aug 2020 04:30:29 -0700 (PDT) Received: from [10.0.0.6] (38.227.143.150.dyn.plus.net. [150.143.227.38]) by smtp.gmail.com with ESMTPSA id i7sm3846678wrs.25.2020.08.20.04.30.28 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Aug 2020 04:30:28 -0700 (PDT) From: Neil Madden Content-Type: multipart/alternative; boundary="Apple-Mail=_B22A644F-8ECA-4284-8370-666C425FD534" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: Date: Thu, 20 Aug 2020 12:30:28 +0100 To: oauth X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [OAUTH-WG] WGLC review of PAR 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, 20 Aug 2020 11:30:37 -0000 --Apple-Mail=_B22A644F-8ECA-4284-8370-666C425FD534 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As promised in the last interim meeting, I=E2=80=99ve reviewed the = current (03) draft-ietf-oauth-par document. Overall it looks close to = ready to me, with mostly minor comments and one security-relevant = comment on section 2.1 that should be discussed further, and one = additional proposed security consideration: Abstract: The wording here could be improved - =E2=80=9Callows clients to push an = authorization request [=E2=80=A6] used as a reference to the data in a = subsequent authorization request.=E2=80=9D Both the pushed data and the = call to the authorization endpoint are referred to as an = =E2=80=9Cauthorization request=E2=80=9D. Maybe change the second usage = to =E2=80=9Cin a subsequent call to the authorization endpoint=E2=80=9D. Section 1: The introductory part here is quite long. Maybe adding a new sub-heading = before the example would make it flow better. The end of the introduction uses the acronym =E2=80=9CPAR=E2=80=9D for = the first time, but never explicitly defines it. I agree with Justin that ACR is not the best example to lead with. If it = stays there should be a reference to OIDC to explain what this means. The paragraph that begins =E2=80=9CIt also allows clients to push the = form encoded =E2=80=A6=E2=80=9D is confusing because the use of = =E2=80=9Calso=E2=80=9D suggests this is different from the previous = paragraph, but it seems to actually be saying the same thing? =E2=80=9C[=E2=80=A6] but it also allows clients requiring an even higher security level, especially cryptographically confirmed non-repudiation, to explicitly adopt JWT-based request objects=E2=80=9D= The =E2=80=9Cbut=E2=80=9D should be an =E2=80=9Cand=E2=80=9D in this = paragraph. It=E2=80=99s also not clear what is being said here - isn=E2=80= =99t JAR what provides JWT-based request objects?=20 The paragraph beginning =E2=80=9CAs a further benefit, =E2=80=A6=E2=80=9D = is a little bit of a Columbo moment (=E2=80=9CJust one more thing=E2=80=A6= =E2=80=9D) at the end of the introduction. Maybe move this as another = bullet point at the start of the section. The following paragraph can = then be rewritten as =E2=80=9CThe increased confidence in the identity = of the client during the authorization process allows confidential = clients to provide a different redirect_uri on every request. [=E2=80=A6]=E2= =80=9D Section 2: The 3rd paragraph contains statements like=20 The endpoint also supports sending all authorization request parameters as request object according to [I-D.ietf-oauth-jwsreq = ]. presumably this is not a normative requirement that any PAR = implementation has to also support JAR, or is it? Maybe change the = wording to =E2=80=9CMAY also support =E2=80=A6=E2=80=9D. The first mention of =E2=80=9Ctoken_endpoint_auth_method=E2=80=9D and = client metadata should have a reference to RFC 7591 - currently it=E2=80=99= s only referenced later in section 2.1. 2.1: I=E2=80=99m a little bit wary of the relaxing of the redirect_uri = processing rules, because this removes a layer of defence in depth. With = the current requirement for pre-registered URIs an attacker needs to = compromise the redirect endpoint *and* the client credentials in order = to steal an authorization code and use it. With this change, = compromising the client credentials alone would be enough. If the = use-case is specifically in a PKI environment, could the redirect_uri be = baked into the cert? Maybe this use-case could be better addressed in a = separate draft. 2.2: The definition of =E2=80=9Cexpires_in=E2=80=9D as a "JSON number" = suggests that fractional/floating-point values are allowed. Presumably = this is intended to be an integer? Is there a recommended = minimum/maximum? Suggested wording: =3D=3D=3D * "expires_in" : A JSON number that represents the lifetime of the request URI in seconds as a positive integer. The lifetime SHOULD=20= be at least 5 seconds and at most 600 seconds, but other values = are permitted at the discretion of the authorization server. =3D=3D=3D Those values are fairly arbitrary - 5 seconds seems a reasonable lower = bound for a client with a bad network connection, and 10 minutes seems = more than adequate upper bound for the typical uses. 3: I confirmed that the request JWT verifies with the given JWK using our = internal JWT library :-) 5: =E2=80=9Crequire_pushed_authorization_requests=E2=80=9D might be better = named =E2=80=9Crequires_pushed_authorization_requests=E2=80=9D given = that it is describing the server=E2=80=99s policy rather than telling = the client to require them, but this is a really pedantic point. Same = for the client metadata in section 6. 7: I would like to propose an additional security consideration, with the = following wording: =3D=3D=3D 7.5. Request URI swapping An attacker could capture the request URI from one request and then = substitute it into a different authorization request. For example, in = the context of OpenID Connect, an attacker could replace a request URI = asking for a high level of authentication assurance with one that = requires a lower level of assurance. Clients SHOULD make use of PKCE, a = unique =E2=80=9Cstate" parameter, or the OIDC =E2=80=9Cnonce=E2=80=9D = parameter in the pushed request object to prevent this attack. =3D=3D=3D =E2=80=94 Neil --Apple-Mail=_B22A644F-8ECA-4284-8370-666C425FD534 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = promised in the last interim meeting, I=E2=80=99ve reviewed the current = (03) draft-ietf-oauth-par document. Overall it looks close to ready to = me, with mostly minor comments and one security-relevant comment on = section 2.1 that should be discussed further, and one additional = proposed security consideration:

Abstract:
The wording here could be = improved - =E2=80=9Callows clients to push an authorization request = [=E2=80=A6] used as a reference to the data in a subsequent = authorization request.=E2=80=9D Both the pushed data and the call to the = authorization endpoint are referred to as an =E2=80=9Cauthorization = request=E2=80=9D. Maybe change the second usage to =E2=80=9Cin a = subsequent call to the authorization endpoint=E2=80=9D.

Section 1:
The introductory part here is quite long. Maybe adding a new = sub-heading before the example would make it flow better.

The end of the = introduction uses the acronym =E2=80=9CPAR=E2=80=9D for the first time, = but never explicitly defines it.

I agree with Justin that ACR is not the = best example to lead with. If it stays there should be a reference to = OIDC to explain what this means.

The paragraph that begins =E2=80=9CIt = also allows clients to push the form encoded =E2=80=A6=E2=80=9D is = confusing because the use of =E2=80=9Calso=E2=80=9D suggests this is = different from the previous paragraph, but it seems to actually be = saying the same thing?

=E2=80=9C[=E2=80=A6] but it also = allows clients requiring
   an even higher security level, =
especially cryptographically confirmed
   non-repudiation, to explicitly adopt JWT-based request =
objects=E2=80=9D

The =E2=80=9Cbut=E2=80=9D should be an =
=E2=80=9Cand=E2=80=9D in this paragraph. It=E2=80=99s also not clear =
what is being said here - isn=E2=80=99t JAR what provides JWT-based =
request objects? 

The paragraph beginning =E2=80=9CAs a =
further benefit, =E2=80=A6=E2=80=9D is a little bit of a Columbo moment =
(=E2=80=9CJust one more thing=E2=80=A6=E2=80=9D) at the end of the =
introduction. Maybe move this as another bullet point at the start of =
the section. The following paragraph can then be rewritten as =E2=80=9CThe=
 increased confidence in the identity of the client during the =
authorization process allows confidential clients to provide a different =
redirect_uri on every request. [=E2=80=A6]=E2=80=9D

Section =
2:
The 3rd paragraph contains statements =
like 
The endpoint also supports sending all =
authorization
   request parameters as request object according to
   [I-D.ietf-oauth-jwsreq].
presumably = this is not a normative requirement that any PAR implementation has to = also support JAR, or is it? Maybe change the wording to =E2=80=9CMAY = also support =E2=80=A6=E2=80=9D.

The first mention of = =E2=80=9Ctoken_endpoint_auth_method=E2=80=9D and client metadata should = have a reference to RFC 7591 - currently it=E2=80=99s only referenced = later in section 2.1.

2.1:
I=E2=80=99m a little bit wary of = the relaxing of the redirect_uri processing rules, because this removes = a layer of defence in depth. With the current requirement for = pre-registered URIs an attacker needs to compromise the redirect = endpoint *and* the client credentials in order to steal an authorization = code and use it. With this change, compromising the client credentials = alone would be enough. If the use-case is specifically in a PKI = environment, could the redirect_uri be baked into the cert? Maybe this = use-case could be better addressed in a separate draft.

2.2:
The definition of =E2=80=9Cexpires_in=E2=80=9D as a "JSON = number" suggests that fractional/floating-point values are allowed. = Presumably this is intended to be an integer? Is there a recommended = minimum/maximum? Suggested wording:

=3D=3D=3D
   *  "expires_in" : A =
JSON number that represents the lifetime of the
      request URI in seconds as a positive integer. The lifetime =
SHOULD 
      be at least 5 seconds and at most 600 seconds, but other =
values are
      permitted at the discretion of the authorization =
server.
=3D=3D=3D

Those values are fairly arbitrary - 5 = seconds seems a reasonable lower bound for a client with a bad network = connection, and 10 minutes seems more than adequate upper bound for the = typical uses.

3:
I confirmed that the request JWT = verifies with the given JWK using our internal JWT library :-)

5:
=E2=80=9Crequire_pushed_authorization_requests=E2=80=9D might = be better named =E2=80=9Crequires_pushed_authorization_requests=E2=80= =9D given that it is describing the server=E2=80=99s policy rather than = telling the client to require them, but this is a really pedantic point. = Same for the client metadata in section 6.

7:
I would like to = propose an additional security consideration, with the following = wording:

=3D=3D=3D
7.5. Request URI = swapping

An = attacker could capture the request URI from one request and then = substitute it into a different authorization request. For example, in = the context of OpenID Connect, an attacker could replace a request URI = asking for a high level of authentication assurance with one that = requires a lower level of assurance. Clients SHOULD make use of PKCE, a = unique =E2=80=9Cstate" parameter, or the OIDC =E2=80=9Cnonce=E2=80=9D = parameter in the pushed request object to prevent this attack.
=3D=3D=3D

=E2=80=94 Neil

= --Apple-Mail=_B22A644F-8ECA-4284-8370-666C425FD534-- From nobody Thu Aug 20 05:18:26 2020 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 D4C543A08AA for ; Thu, 20 Aug 2020 05:18:24 -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, 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 JEGJem9EhM3k for ; Thu, 20 Aug 2020 05:18:23 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 22E6E3A08A9 for ; Thu, 20 Aug 2020 05:18:23 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id h16so1264061oti.7 for ; Thu, 20 Aug 2020 05:18:23 -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; bh=PTYIm6qNhRfgTjU3ek0/blfx/ieqcK6oRCF/9+A0s98=; b=PVUMp31CZtVsKukRan6l3ML5SHkP7AAktXBSiOTIW8Gv2j/XIncW1tjfmO4RI5eB2K 3/NxW1ZmsQ6x9enUr503spceAOc5oVEKU0qZI7Hzh1slQL6CsuTj5S04moHT36PVMx5r E3mgYA2R14pzPRRA3guo7EEHrlcZWUkuIdgx6Vwb9gMW7OO4mpoAIzCj9ZiiHYmKfSZJ 7Vhi+cF7PoIokgUCSEjtHtAFgypK+aPYyvoGEmMOwHwCO3/6PEuJHpkERETMzM9k2HDW w9culVAyE1k6tSS66S3GUuO5iGKjCVhh4i0JHqIUWQS1yMBBoPryfjiZHv7fGFk+/iWl 2r+Q== 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; bh=PTYIm6qNhRfgTjU3ek0/blfx/ieqcK6oRCF/9+A0s98=; b=uM9pfvl2YKFwUQhydCyDR4cBszqXo9LrHPsCgx/DCOFkKsftdobyOpLPQGITobseU+ BLFs1RhOHlgrs5UYBfDXZB+VU/Oqdo21DJdxfUo4nlKa3C2JBxqVOEgKKWV2gthgqiY2 kpzStddkceQY8KUO9scLiDnKSehdpK98dfsNnav827G3KDzx4S0ACT2XG33u6nes8W+O gu/HoIi5XS9X8qTrBioBpUQPiYOJTior6PYo/39l0Ye39y8PV4jRFF28jupyvaxohJHb idyyq6PNKpkIuott+A7PRMQq+R9Nw+mCkrJ9gtwhcQUUh12T9X7RVHbAZfYDOkqoH8Gs ZtpA== X-Gm-Message-State: AOAM5339cYlWNGCdSt+HPW6WrlDB5inmdXfVAM4ii3Zk7qgfgZzenv8y JsF46xYtV0Y9UfXFjKUsfoDEdTSrmVPxr7O3uoE+P76je3bn4g== X-Google-Smtp-Source: ABdhPJz0Zfd9ObhmqvXIE/5ye8NTrlLimXQtYMpQB4Q7p7miaY8/kcMFcXjy1bcx5Ef8WLLHR1ykAQQf+4Z76ZWheIE= X-Received: by 2002:a9d:3da1:: with SMTP id l30mr2049343otc.233.1597925902016; Thu, 20 Aug 2020 05:18:22 -0700 (PDT) MIME-Version: 1.0 References: <46A7D36F-C999-4CA5-AA7F-F955316C4855@lodderstedt.net> In-Reply-To: <46A7D36F-C999-4CA5-AA7F-F955316C4855@lodderstedt.net> From: Emond Papegaaij Date: Thu, 20 Aug 2020 14:18:11 +0200 Message-ID: To: oauth Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] Client authentication on token revocation 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, 20 Aug 2020 12:18:25 -0000 Hi Torsten, Thanks for your insight. I agree, a sender constraint token, such as when using certificate bound tokens from RFC 8705, cannot be used by an attacker. It makes sense to only allow the owner to revoke them, probably using the same mechanism as by which they are bound to the client. For bearer tokens, we will simply skip the validation of the client credentials. Best regards, Emond Papegaaij On Thu, Aug 20, 2020 at 12:52 PM Torsten Lodderstedt wrote: > > Hi Emond, > > I tend to agree with your assessment. Revoking bearer tokens without client authentication seems to be better than leaving the attacker the option to use them to invoke resources. > > However, if the attacker cannot use the access tokens (e.g. because they are sender constrained), the attacker could revoke tokens issued to a confidential client as a kind of DoS attack. > > best regards, > Torsten. > > > On 20. Aug 2020, at 11:02, Emond Papegaaij wrote: > > > > Hi all, > > > > We are currently implementing the token revocation endpoint (RFC 7009) > > on our authorization server and do not understand why it requires > > client authentication. When a party (a valid client or not) gets hold > > of a valid access token in whatever way, the least damaging it could > > do with it, is to revoke it. The current spec allows an attacker to > > misuse this token for access to the resource server, but forbids it to > > revoke it. This seems strange to me. > > > > Section 5 of RFC 7009 does not help in this either. It starts to > > explain that this authentication is needed to prevent malicious > > clients from guessing tokens, but ends with the fact that if this were > > possible, much worse damage could be done by using the guessed token > > on the resource server. We plan to skip the authentication all > > together and simply revoke any valid token presented. How would you > > recommend we deal with this? > > > > Best regards, > > Emond Papegaaij > > Topicus KeyHub > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > From nobody Thu Aug 20 14:07:47 2020 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 868393A1412; Thu, 20 Aug 2020 14:07:41 -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.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <159795766141.25901.11737239140865725646@ietfa.amsl.com> Date: Thu, 20 Aug 2020 14:07:41 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-28.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: Thu, 20 Aug 2020 21:07:42 -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 : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) Authors : Nat Sakimura John Bradley Michael B. Jones Filename : draft-ietf-oauth-jwsreq-28.txt Pages : 35 Date : 2020-08-20 Abstract: The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents is not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-28 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-28 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-28 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 21 07:16:58 2020 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 B49F83A086A; Fri, 21 Aug 2020 07:16:52 -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.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <159801941265.8491.9738321133065361247@ietfa.amsl.com> Date: Fri, 21 Aug 2020 07:16:52 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-02.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: Fri, 21 Aug 2020 14:16:53 -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 Rich Authorization Requests Authors : Torsten Lodderstedt Justin Richer Brian Campbell Filename : draft-ietf-oauth-rar-02.txt Pages : 31 Date : 2020-08-21 Abstract: This document specifies a new parameter "authorization_details" that is used to carry fine grained authorization data in the OAuth authorization request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-rar-02 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-rar-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 21 07:20:16 2020 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 D761D3A08B1 for ; Fri, 21 Aug 2020 07:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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 EO0gvH3Gr5gm for ; Fri, 21 Aug 2020 07:20:13 -0700 (PDT) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 5CE7D3A02BD for ; Fri, 21 Aug 2020 07:20:13 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id kq25so2494456ejb.3 for ; Fri, 21 Aug 2020 07:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=uEeF2PBdIvMVsS1ZxLsYiHIarvDztU8JvWVbq1IXPyk=; b=SLHFetku3fId3askYRqocb8P8qjnY46j3DEcRYL0ADpGtR6ezGX1DAt+7Kw6vCFl9J RoH35swTLxYp2aBDv6PZjdl+cD2SKkxVkKPi1viS/T0yZth5mM6zr298GzxQAAOF5Trm N57Z1qL7FOmYXsIoiHrdfx/yyy/qTj6FjwjJAyRExPyaDirSu1sZ15Q3vP30HcBmnC37 Vqa6mEmWV7Gapis89bSFm3y98xQGbuO3BnQ5smz2+A3n12RaovjEJ6IQQA5Qh7aLVVvH rd4IJpdB/t5ul5Eu6xVfxpJJ4USyRKo374BEQHA8lCMMITyyIxpH/6I2ptq7z0LjUwOX Ipig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=uEeF2PBdIvMVsS1ZxLsYiHIarvDztU8JvWVbq1IXPyk=; b=VKHH/vsfwviszN842nRB1zcaHtRiyHxao/MVXVBwfcnAdA48rmEBHQv9B7qfUg/aI+ Nteien5qf0Krs5hiEMZy3AZhRfodxcb9Dhe5mohtKX7CbWCMFXgKEjMi//QgFm8O06H8 mEgPFfu8bVuMPQSns0fRds3PaSCtUsA5n06fSBCfbW/j6dJsghF7PeQB2awD2/a33Apn zEfh0OqJNdt94VJWL9sw45NnANJ9vI5ZTyNoVdTCnGRaGj7wXqxAEFVCe0zmhEdrgSnU kChkd6QDQhCf0tEdnmQ+r+ulS63Xxuo2F2Y4BaCXaC1bp0ds4KRTYGdXYfCwZ1xb/qbQ hJjg== X-Gm-Message-State: AOAM532CNO3SAd4fGYWq1w2xw8AkdDLxuPREwq7S84diA6QiqBla3jlD 46nuEpBeFDOhPLfOtJMhvrrq2cyWwU3tKNrh X-Google-Smtp-Source: ABdhPJw3Q+LEUOrHBnr5NvYQlxzp/0m6k2pUrBU5is5lcQ1O72A/xKFR0ADv0ZyJd1mNgHtn58Gnyg== X-Received: by 2002:a17:906:ce59:: with SMTP id se25mr3149127ejb.359.1598019611222; Fri, 21 Aug 2020 07:20:11 -0700 (PDT) Received: from p200300eb8f1e2ab8659d323df35a38b8.dip0.t-ipconnect.de (p200300eb8f1e2ab8659d323df35a38b8.dip0.t-ipconnect.de. [2003:eb:8f1e:2ab8:659d:323d:f35a:38b8]) by smtp.gmail.com with ESMTPSA id os4sm1377984ejb.117.2020.08.21.07.20.10 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Aug 2020 07:20:10 -0700 (PDT) From: Torsten Lodderstedt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 21 Aug 2020 16:20:09 +0200 References: <159801941265.8491.9738321133065361247@ietfa.amsl.com> To: oauth@ietf.org In-Reply-To: <159801941265.8491.9738321133065361247@ietfa.amsl.com> Message-Id: <69B941CD-BDEF-44F5-AC28-D0CB66A7B116@lodderstedt.net> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-02.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: Fri, 21 Aug 2020 14:20:15 -0000 Hi all,=20 the new RAR revision clarifies the =E2=80=9Ctype=E2=80=9D parameter = processing.=20 best regards, Torsten.=20 > On 21. Aug 2020, at 16:16, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : OAuth 2.0 Rich Authorization Requests > Authors : Torsten Lodderstedt > Justin Richer > Brian Campbell > Filename : draft-ietf-oauth-rar-02.txt > Pages : 31 > Date : 2020-08-21 >=20 > Abstract: > This document specifies a new parameter "authorization_details" that > is used to carry fine grained authorization data in the OAuth > authorization request. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-rar-02 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-rar-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Aug 21 07:43:47 2020 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 DD8B73A098C for ; Fri, 21 Aug 2020 07:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=cert.org 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 zMzp--BhE99v for ; Fri, 21 Aug 2020 07:43:44 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 810973A097C for ; Fri, 21 Aug 2020 07:43:44 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 07LEhhtd002665 for ; Fri, 21 Aug 2020 10:43:43 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 07LEhhtd002665 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1598021023; bh=VAcP/ZnUkQSZFhIe3eYYlQ/KuOzOpCgEMEyhWV+sB7c=; h=From:To:Subject:Date:From; b=W8L2QmrGSdj/dgwWxF40DtIStAr7uTpR7TQX+Kr60yn5fIRCkRV0tiOTFjEyWZsWh d7traYt7CWoXQZ6iEAfm0wOobNUCPNJEXfLlp2c2gv2Iv5oW347Egm5ivdyEk5d+CU RmWHx8N1SXishFebw8sxBPeWEPFeq0NuwriXkrTY= Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 07LEhf8c037413 for ; Fri, 21 Aug 2020 10:43:41 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Fri, 21 Aug 2020 10:43:41 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Fri, 21 Aug 2020 10:43:41 -0400 From: Roman Danyliw To: "oauth@ietf.org" Thread-Topic: AD Review of draft-ietf-oauth-jwt-introspection-response-09 Thread-Index: AdZ3yNCMMi3AzHwFQQyw6c2oHNRUWA== Date: Fri, 21 Aug 2020 14:43:39 +0000 Message-ID: <8a42a78a8a3645f793b0991e4dd5bb34@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.178] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-introspection-response-09 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, 21 Aug 2020 14:43:46 -0000 Hi! I conducted an another AD review of draft-ietf-oauth-jwt-introspection-resp= onse-09. As background, -07 of this document went to IESG Review and the d= ocument was brought back to the WG to address the DISCUSS points. =20 Below is my feedback which can be addressed concurrently with IETF LC. ** Section 5. I want to clarify what are the permissible members of token_= introspection. The two relevant text snippets seem to be: (a) "token_introspection A JSON object containing the members of the token introspection response, as specified in the "OAuth Token Introspection Response" registry established by [RFC7662] as well as other members." (b) "Claims from the "JSON Web Token Claims" registry that are commonly used in [OpenID.Core] and can be applied to the resource owner MAY be included as members in the "token_introspection" claim." -- Per (a), Recommend citing the IANA sub-registry directly -- https://www.= iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspe= ction-response (and not the "as specified in the "OAuth Token Introspection= Response" registry established by [RFC7662]") -- Per (a), "... as well as other members", what members is this referencin= g? Is that (b)? Recommend being clear upfront on which exact registries a= re the sources of valid members. -- Per (b), "... commonly used in [OpenId.Core]", what are those specifical= ly? Is that claims registered in https://www.iana.org/assignments/jwt/jwt.= xhtml#claims whose reference is [OpenID Connect Core 1.0]? Recommend being= unambiguous in which claims are permitted by pointing the IANA registry. -- If I'm understanding right that the source comes either from oauth-param= eters.xhtml#token-introspection-response or jwt.xhtml#claims, what happens = if it isn't one of those? ** Section 5. Per " The AS MUST ensure the release of any privacy-sensitiv= e data is legally based", recommend also including a forward reference to S= ection 9 Regards, Roman From nobody Fri Aug 21 08:14:43 2020 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 0AC0D3A09DB; Fri, 21 Aug 2020 08:14:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk CC: oauth-chairs@ietf.org, draft-ietf-oauth-jwt-introspection-response@ietf.org, rifaat.s.ietf@gmail.com, oauth@ietf.org, rdd@cert.org, Rifaat Shekh-Yusef Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159802288149.12737.11570006487802113668@ietfa.amsl.com> Date: Fri, 21 Aug 2020 08:14:41 -0700 Archived-At: Subject: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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: Fri, 21 Aug 2020 15:14:42 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'JWT Response for OAuth Token Introspection' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-09-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification proposes an additional JSON Web Token (JWT) secured response for OAuth 2.0 Token Introspection. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Aug 21 08:23:17 2020 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 A6D2E3A0B3D for ; Fri, 21 Aug 2020 08:23:15 -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 osYx-xEddAp9 for ; Fri, 21 Aug 2020 08:23:13 -0700 (PDT) Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (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 2F1253A0A5E for ; Fri, 21 Aug 2020 08:23:13 -0700 (PDT) Received: by mail-wm1-x341.google.com with SMTP id 9so2279035wmj.5 for ; Fri, 21 Aug 2020 08:23:13 -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=MPJXc/QoyCQN1YDNj3xu+7xmjp2+AkrdJWI06O34Uqc=; b=j07cwhI7M7j7b1/aLucPi+UtTkIuNwnPTReL/bGfJTy0QIxkvmkyIyLas2I4jDHB1l VS+369D5WC/GDQhgnUpVrbwaRjNi91bQRlMWy+2hMvgvj9ZUXwweKLmOigVpe7Sov3yp 9SxE9HACV4q5gae51Tg0w9UjSTkliXKoYSYONMp1zOiI9nJkPgSb6LDhGXWNysN6OO6f W0Buytp4velmE5mz6ADUg5hSAR3JSHPwXyx0onAOaXIX4qPM5eMWnpwOtmIEB7TGzKEa LuIFC61pImLV0zx3ny+Ap7la9Gsl7IN1KpKBRXsZdBMNuKL55xRzn5WiVjZtPbxDSt6g k+0g== 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=MPJXc/QoyCQN1YDNj3xu+7xmjp2+AkrdJWI06O34Uqc=; b=DLfGFqQFKcaskMmWpQe7jTdecpW7K1NY0Oj0+ehgVwPz1um8mSrvLaDi7CVWZFKEWn q8YCb/xWMeft2ejnapE3pySLwltNC2wD/rDnxbPx7d7K4tpEozmPMqWmeYLazaa7Tbad GrLx1UrzRmdzWdxWjG01gz4d3zISZqd9ML9IOraT5pjSuGb65vUaGlSCNTh816g2dTz6 tsZZ4euEWaH9HGIu5Nt734g8sRsVzOqYPwbyl+s7mdUBz+awraIAdOmUdMbxl/obUBdA Hqv88BRTdn5kAI5SaXgy8KLA4LRdeNiBx/IwdAASmEySiscad7hWaMXASbaeJreCFMTW dL3Q== X-Gm-Message-State: AOAM53319IoBRLlYih/5nOyS9gPwMoNKvtbtDV2BXEaV8SwsFOHR//P1 aMjprq6LAtP3Yh+GfhpR7UJl0i2cFT8rd++I6Lk= X-Google-Smtp-Source: ABdhPJxPnzw0eScU+CJicduAZBtje0Rx+3XOloghZuQWQDhHA+vAlyCkFbR3+P8JWBygjI4QrqJLEzsMLBzbzt21V24= X-Received: by 2002:a7b:c40b:: with SMTP id k11mr3691643wmi.107.1598023391469; Fri, 21 Aug 2020 08:23:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Thibault Normand Date: Fri, 21 Aug 2020 17:23:00 +0200 Message-ID: To: Mike Jones Cc: Dick Hardt , Filip Skokan , oauth Content-Type: multipart/alternative; boundary="00000000000097644405ad64d056" Archived-At: Subject: Re: [OAUTH-WG] ECDH-1PU encryption algorithm 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, 21 Aug 2020 15:23:16 -0000 --00000000000097644405ad64d056 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Id' like to add that I've made a Gist with a one file implementation in Go to try to make it simple to understand. https://gist.github.com/Zenithar/cf58b003fcf341a3b1593c30b50b0820 I hope it helps new users Regards, Le lun. 10 ao=C3=BBt 2020 =C3=A0 19:34, Mike Jones a =C3=A9crit : > I=E2=80=99m likewise supportive of the work. Note that COSE working grou= p is > currently open whereas JOSE is closed, so if you want working group revie= w, > I=E2=80=99d submit specs to COSE soon. > > > > As background, I worked the spec > https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-08 in > COSE which also performs JOSE registrations. So that=E2=80=99s definitel= y a viable > path forward. (This document is currently in AUTH48 status, and so is > about to become an RFC.) > > > > Filip, the JOSE working group closed after RFCs 7515-7518 and 7520 were > completed. Note that it=E2=80=99s possible to register algorithms, etc. = in the > IANA JOSE registries https://www.iana.org/assignments/jose/jose.xhtml > without the spec coming from a working group =E2=80=93 and indeed, withou= t coming > from a working group at all. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of * Dick Hardt > *Sent:* Monday, August 10, 2020 10:27 AM > *To:* Filip Skokan > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] ECDH-1PU encryption algorithm > > > > I'm supportive of this work. > > > > It is not clear that it is in the charter of the OAuth WG. > > > > > > On Mon, Aug 10, 2020 at 9:01 AM Filip Skokan wrote: > > Hi Neil, > > > > I'm interested in seeing both AES SIV and ECDH-1PU for JOSE. Not sure how > to go about it tho since JOSE is a concluded WG. > > > > Out of curiosity, why is it a concluded WG? Did IETF/JOSE WG not consider > the need to further maintain/expand the JOSE algorithms as time goes on? > > > S pozdravem, > *Filip Skokan* > > > > > > On Mon, 10 Aug 2020 at 10:29, Neil Madden > wrote: > > Thanks Vladimir, > > Responses below > > > On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov > wrote: > > > > =EF=BB=BFHi Neil, > > > > I definitely like the elegance of the proposed alg for JOSE, it provide= s > > something that isn't currently available in the various classes of algs > > made standard in JOSE. > > > > I also wanted to ask what's happening with AES SIV for JOSE, if there's > > traction / feedback / support there as well? > > > > https://tools.ietf.org/html/draft-madden-jose-siv-mode-02 > > Thanks for bringing this up. I=E2=80=99ve not received much feedback abou= t this > one, and I haven=E2=80=99t been very good at pushing it. If there is inte= rest then > I=E2=80=99d certainly be interested in bringing this forward too. > > That draft might be a better fit for eg the COSE WG though, which could > then also register identifiers for JOSE. What do you think? > > > > > Vladimir > > > > > >>> On 05/08/2020 13:01, Neil Madden wrote: > >> Hi all, > >> You may remember me from such I-Ds > >> as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which > >> proposes adding a new encryption algorithm to JOSE. I=E2=80=99d like t= o > >> reserve a bit of time to discuss it at one of the upcoming interim > >> meetings. > >> The basic idea is that in many cases in OAuth and OIDC you want to > >> ensure both confidentiality and authenticity of some token - for > >> example when transferring an ID token containing PII to the client > >> through the front channel, or for access tokens intended to be handled > >> by a specific RS without online token introspection (such as the JWT > >> access token draft). If you have a shared secret key between the AS > >> and the client/RS then you can use symmetric authenticated encryption > >> (alg=3Ddir or alg=3DA128KW etc). But if you need to use public key > >> cryptography then currently you are limited to a nested > >> signed-then-encrypted JOSE structure, which produces much larger token > >> sizes. > >> The draft adds a new =E2=80=9Cpublic key authenticated encryption=E2= =80=9D mode based > >> on ECDH in the NIST standard =E2=80=9Cone-pass unified=E2=80=9D model.= The primary > >> advantage for OAuth usage is that the tokens produced are more compact > >> compared to signing+encryption (~30% smaller for typical access/ID > >> token sizes in compact serialization). Performance-wise, it=E2=80=99s = roughly > >> equivalent. I know that size concerns are often a limiting factor in > >> choosing whether to encrypt tokens, so this should help. > >> In terms of implementation, it=E2=80=99s essentially just a few extra = lines of > >> code compared to an ECDH-ES implementation. (Some JOSE library APIs > >> might need an adjustment to accommodate the extra private key needed > >> for encryption/public key for decryption). > >> I=E2=80=99ve received a few emails off-list from people interested in = using it > >> for non-OAuth use-cases such as secure messaging applications. I think > >> these use-cases can be accommodated without significant changes, so I > >> think the OAuth WG would be a good venue for advancing this. > >> I=E2=80=99d be interested to hear thoughts and discussion on the list = prior to > >> any discussion at an interim meeting. > >> =E2=80=94 Neil > > _______________________________________________ > 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Thibault Normand "Il existe moins bien mais c'est plus cher !" http://www.zenithar.org --00000000000097644405ad64d056 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Id' like to add t= hat I've made a Gist with a one file implementation in Go to try to mak= e it simple to understand.

I hope it helps= new users
Regards,

Le=C2=A0lun. 10 ao=C3=BBt 2020 =C3= =A0=C2=A019:34, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> a =C3=A9crit= =C2=A0:

I=E2=80=99m likew= ise supportive of the work.=C2=A0 Note that COSE working group is currently= open whereas JOSE is closed, so if you want working group review, I=E2=80= =99d submit specs to COSE soon.

=C2=A0<= /u>

As background, I = worked the spec https://tools.ietf.org/html/draft-ietf-cose-we= bauthn-algorithms-08 in COSE which also performs JOSE registrations.=C2= =A0 So that=E2=80=99s definitely a viable path forward.=C2=A0 (This documen= t is currently in AUTH48 status, and so is about to become an RFC.)

=C2=A0

Filip, the JOSE working group closed after RFCs 7515= -7518 and 7520 were completed.=C2=A0 Note that it=E2=80=99s possible to reg= ister algorithms, etc. in the IANA JOSE registries https://www.iana.org/assignments/jose/jose.xhtml without the spec c= oming from a working group =E2=80=93 and indeed, without coming from a work= ing group at all.

=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=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=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=A0 -- Mike<= span style=3D"color:rgb(0,32,96)">

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Dick Hardt
Sent: Monday, August 10, 2020 10:27 AM
To: Filip Skokan <panva.ip@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] ECDH-1PU encryption algorithm<= /p>

=C2=A0

I'm supportive of this work.

=C2=A0

It is not clear that it is in the charter of the OAu= th WG.

=C2=A0

=C2=A0

On Mon, Aug 10, 2020 at 9:01 AM Filip Skokan <panva.ip@gmail.com= > wrote:

Hi Neil,

=C2=A0

I'm interested in seeing both AES SIV and=C2=A0E= CDH-1PU for JOSE. Not sure how to go about it tho since JOSE is a concluded= WG.=C2=A0

=C2=A0

Out of curiosity, why is it a concluded WG? Did IETF= /JOSE WG not consider the need to further maintain/expand the JOSE algorith= ms as time goes on?


S pozdravem,
Filip Skokan

=C2=A0

=C2=A0

On Mon, 10 Aug 2020 at 10:29, Neil Madden <neil.madden@forger= ock.com> wrote:

Thanks Vladimir,

Responses below

> On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov <vladimir@connect2id.com> wrot= e:
>
> =EF=BB=BFHi Neil,
>
> I definitely like the elegance of the proposed alg for JOSE, it provid= es
> something that isn't currently available in the various classes of= algs
> made standard in JOSE.
>
> I also wanted to ask what's happening with AES SIV for JOSE, if th= ere's
> traction / feedback / support there as well?
>
> https://tools.ietf.org/html/draft-madden-jose-siv-mode-02

Thanks for bringing this up. I=E2=80=99ve not received much feedback about = this one, and I haven=E2=80=99t been very good at pushing it. If there is i= nterest then I=E2=80=99d certainly be interested in bringing this forward t= oo.

That draft might be a better fit for eg the COSE WG though, which could the= n also register identifiers for JOSE. What do you think?

>
> Vladimir
>
>
>>> On 05/08/2020 13:01, Neil Madden wrote:
>> Hi all,
>> You may remember me from such I-Ds
>> as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which
>> proposes adding a new encryption algorithm to JOSE. I=E2=80=99d li= ke to
>> reserve a bit of time to discuss it at one of the upcoming interim=
>> meetings.
>> The basic idea is that in many cases in OAuth and OIDC you want to=
>> ensure both confidentiality and authenticity of some token - for >> example when transferring an ID token containing PII to the client=
>> through the front channel, or for access tokens intended to be han= dled
>> by a specific RS without online token introspection (such as the J= WT
>> access token draft). If you have a shared secret key between the A= S
>> and the client/RS then you can use symmetric authenticated encrypt= ion
>> (alg=3Ddir or alg=3DA128KW etc). But if you need to use public key=
>> cryptography then currently you are limited to a nested
>> signed-then-encrypted JOSE structure, which produces much larger t= oken
>> sizes.
>> The draft adds a new =E2=80=9Cpublic key authenticated encryption= =E2=80=9D mode based
>> on ECDH in the NIST standard =E2=80=9Cone-pass unified=E2=80=9D mo= del. The primary
>> advantage for OAuth usage is that the tokens produced are more com= pact
>> compared to signing+encryption (~30% smaller for typical access/ID=
>> token sizes in compact serialization). Performance-wise, it=E2=80= =99s roughly
>> equivalent. I know that size concerns are often a limiting factor = in
>> choosing whether to encrypt tokens, so this should help.
>> In terms of implementation, it=E2=80=99s essentially just a few ex= tra lines of
>> code compared to an ECDH-ES implementation. (Some JOSE library API= s
>> might need an adjustment to accommodate the extra private key need= ed
>> for encryption/public key for decryption).
>> I=E2=80=99ve received a few emails off-list from people interested= in using it
>> for non-OAuth use-cases such as secure messaging applications. I t= hink
>> these use-cases can be accommodated without significant changes, s= o I
>> think the OAuth WG would be a good venue for advancing this.
>> I=E2=80=99d be interested to hear thoughts and discussion on the l= ist prior to
>> any discussion at an interim meeting.
>> =E2=80=94 Neil

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

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

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


--
Thibault Normand
"Il existe moins bien mais c'e= st plus cher !"
http://www.zenithar.org
--00000000000097644405ad64d056-- From nobody Fri Aug 21 08:29:29 2020 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 E7CB83A09F4; Fri, 21 Aug 2020 08:29:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Cc: draft-ietf-oauth-jwsreq@ietf.org, The IESG , rdd@cert.org, oauth-chairs@ietf.org, Hannes.Tschofenig@gmx.net, rfc-editor@rfc-editor.org, oauth@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159802376386.19450.4075512098724539190@ietfa.amsl.com> Date: Fri, 21 Aug 2020 08:29:23 -0700 Archived-At: Subject: [OAUTH-WG] Protocol Action: 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)' to Proposed Standard (draft-ietf-oauth-jwsreq-28.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: Fri, 21 Aug 2020 15:29:24 -0000 The IESG has approved the following document: - 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)' (draft-ietf-oauth-jwsreq-28.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ Technical Summary The authorization request in OAuth 2.0 [RFC6749] utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be JWS signed and/or JWE encrypted so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. Working Group Summary The document changes the encoding of the parameters in the authorization request to a JSON-based encoding. Document Quality There are a number of implementations, both vendor and open source and there was good support in the working group. Personnel Hannes Tschofenig is the document shepherd and the responsible area director is Roman Danyliw. From nobody Sun Aug 23 14:49:03 2020 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 BA1353A0E8A for ; Sun, 23 Aug 2020 14:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.595 X-Spam-Level: * X-Spam-Status: No, score=1.595 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_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_08=1.781, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 uiuKFtyXy8yP for ; Sun, 23 Aug 2020 14:49:00 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 E214A3A0E89 for ; Sun, 23 Aug 2020 14:48:59 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id 145so556333lfi.8 for ; Sun, 23 Aug 2020 14:48:59 -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=ySvN6OHp2RzdnIxqtObMSSaQQ4qESSBeZW02Fq+0IQU=; b=Bm9upGbDZb505TcqrOfiuPX6eCfyHZQF9ghscA+7Y9x2wUHUZh5sNBlCldNXNAMDoP Lf9eT5oBvH0CZpIsRxe48KiB8k7u144pcyBjAMvZK7XMeuPJF6gDc2ny+gLf9WwNIOuQ NgAvHz5Lcfc0EZpKCIbNi2mcLGd/JkZIHUdlJ4w6jWvm2SyrjFznW3GXfFITZzoWJDoL Rbueelttmqoq2ffy+Dg2q9rbwqd2sIJaeXnJUeHk44QqwPoYD2zl9agD/RTn5kk9DGqe YGlTx6WXbOB+k2uI406dGUXmDHEFxr1Q6sPCrYO95Ii7KQlAKqxlnEcLR4S1ySCz3n6l F4iA== 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=ySvN6OHp2RzdnIxqtObMSSaQQ4qESSBeZW02Fq+0IQU=; b=JUQyj60b0k9XxLQ58fAKo3UFUm2UcND2TknMSQk3OxofoRiNA4rwRkfktBK7RUzF8B k57Cq+xljkMGZG+ZZBIZ1WqP13kLiZ+grsXIp6hOAnbDa/e8SCTRaZz0OJ8ipU7KvV+k X+e7agm3qBF+XHdI3/zKuu/UBVk4d+CESLpPH9F7B9cZQgXyFBqXi1qdQ4s0YWhFAg1/ AnrhybDAofj8ksRM0cfBv7yD3SrLPB+ikArBcwEWg76ewOZGmbj7QMWVgUew93K5iO0A UCAr8JOenqCJNWXVgXiyvV5S+0dEE7A93SCxxJdv6sjT5KsGNfomqBK1Bn2dPMWrn2Z8 aa0A== X-Gm-Message-State: AOAM531IIQsN9Zdh32dDsjcuzR9r9cg7hdyLiPUrh4vsMuOr3tEdneko xH0LwcvYWxIJanYFodZE5VHTUe2KzB+Nx4vmts4Zp+Ha3P0= X-Google-Smtp-Source: ABdhPJyizttsbR/bhRKTEOg5GVLT0YIszTNzgjzBSj/LEKOh0SEReonEKrwJMebn/i7jSA8qAPJwt7mIN4LXGHRo66M= X-Received: by 2002:ac2:5f48:: with SMTP id 8mr1164762lfz.157.1598219337448; Sun, 23 Aug 2020 14:48:57 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Sun, 23 Aug 2020 14:48:21 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000e1c3df05ad926f18" Archived-At: Subject: [OAUTH-WG] office hours / meeting this week? 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, 23 Aug 2020 21:49:02 -0000 --000000000000e1c3df05ad926f18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Are either of these happening tomorrow? If so, what is the WebEx link? Thanks! =E1=90=A7 --000000000000e1c3df05ad926f18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Are either of these happening tomorrow? If so, what is the= WebEx link?

Thanks!
3D""=E1=90=A7
--000000000000e1c3df05ad926f18-- From nobody Mon Aug 24 04:03:20 2020 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 7BA3F3A0CB4 for ; Mon, 24 Aug 2020 04:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 7oI17FWgJXsr for ; Mon, 24 Aug 2020 04:03:17 -0700 (PDT) Received: from sjmda09.webex.com (sjmda09.webex.com [64.68.122.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F973A0CB1 for ; Mon, 24 Aug 2020 04:03:17 -0700 (PDT) Received: from rva2rmd101.webex.com (sjc02-wxpd-lb03-v140.webex.com [10.252.16.111]) by sjmda09.webex.com (Postfix) with ESMTP id 2B46B300D8DD for ; Mon, 24 Aug 2020 11:03:16 +0000 (GMT) Received: from rva2rmd101.webex.com (localhost [127.0.0.1]) by rva2rmd101.webex.com (Postfix) with ESMTP id A02A6100CEB8 for ; Mon, 24 Aug 2020 11:03:15 +0000 (GMT) Date: Mon, 24 Aug 2020 11:03:15 +0000 (GMT) From: Web Authorization Protocol Working Group Reply-To: oauth-chairs@ietf.org To: oauth@ietf.org Message-ID: <1654833594.14042431598266995654.JavaMail.nobody@rva2rmd101.webex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2808444_1998331008.1598266995653" X-Priority: 3 Importance: normal X-WBX-INFO: X-WBX-SID=456680, X-WBX-CID=169207479596494431, X-WBX-TID=2gwwnoapye3peo5qvu9lfx2hfhzehgkk8zmzz6blu2vc38ljamidrk8g, X-WBX-RID=461802b20b824c96a8aa8e5aebf40fa8, X-WBX-SVC:Meeting Center, X-WBX-TT:Meeting Invitation, Date:Mon Aug 24 11:03:15 GMT 2020 reminder-40.8.0-3226 Archived-At: Subject: [OAUTH-WG] Webex meeting invitation: OAuth WG Virtual Office Hours 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, 24 Aug 2020 11:03:18 -0000 ------=_Part_2808444_1998331008.1598266995653 Content-Type: multipart/Alternative; boundary="----=_Part_2808445_220495408.1598266995653" ------=_Part_2808445_220495408.1598266995653 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhpLCBvYXV0aEBpZXRmLm9yZywKCldlYiBBdXRob3JpemF0aW9uIFByb3RvY29sIFdvcmtpbmcg R3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYmV4IG1lZXRpbmcuCgoKT0F1dGggV0cg VmlydHVhbCBPZmZpY2UgSG91cnMKT2NjdXJzIGV2ZXJ5IDIgd2VlayhzKSBvbiBNb25kYXkgZWZm ZWN0aXZlIE1vbmRheSwgQXVndXN0IDI0LCAyMDIwIGZyb20gNjowMCBQTSB0byA2OjMwIFBNLCAo VVRDKzAyOjAwKSBBbXN0ZXJkYW0sIEJlcmxpbiwgQmVybiwgUm9tZSwgU3RvY2tob2xtLCBWaWVu bmEKNjowMCBwbSAgfCAgKFVUQyswMjowMCkgQW1zdGVyZGFtLCBCZXJsaW4sIEJlcm4sIFJvbWUs IFN0b2NraG9sbSwgVmllbm5hICB8ICAzMCBtaW5zCk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29k ZSk6IDY0MyAxNDggNTQ4IApNZWV0aW5nIHBhc3N3b3JkOiBCV3NBRjlyVAoKCgpXaGVuIGl0J3Mg dGltZSwgam9pbiB0aGUgbWVldGluZy4KaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhw P01USUQ9bThiYjkwODUxMzI4YzQ4ZmY4NWU2NTA3ZjFjNmNkZWIzCgpBZGQgdG8gQ2FsZW5kYXIK aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bThiNDc4M2UyZjljZDFlZDc1 OThjNDU4NzVmZWVkODIwDQoNCgoKDQpUQVAgVE8gSk9JTiBGUk9NIEEgTU9CSUxFIERFVklDRSAo QVRURU5ERUVTIE9OTFkpDQorMS02NTAtNDc5LTMyMDgsLDY0MzE0ODU0OCMjIHRlbDolMkIxLTY1 MC00NzktMzIwOCwsKjAxKjY0MzE0ODU0OCUyMyUyMyowMSogQ2FsbC1pbiB0b2xsIG51bWJlciAo VVMvQ2FuYWRhKQoNCg0KSk9JTiBCWSBQSE9ORQ0KMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xs IG51bWJlciAoVVMvQ2FuYWRhKQoNCg0KCgoKCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/Cmh0dHBz Oi8vY29sbGFib3JhdGlvbmhlbHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1CgoKSU1Q T1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dz IGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBi ZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4g Qnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3Vj aCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRp c2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNz aW9uLgo= ------=_Part_2808445_220495408.1598266995653 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KdGFibGUgewoJYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0 ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNpbmc6IDA7fQoKdHIgewoJbGlu ZS1oZWlnaHQ6IDE4cHg7fQoKYSwgdGQgewoJZm9udC1zaXplOiAxNHB4Owlmb250LWZhbWlseTog QXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7CXdvcmQtYnJlYWs6IG5v cm1hbDsJcGFkZGluZzogMDt9CgoudGl0bGUgewoJZm9udC1zaXplOiAyOHB4O30KCi5pbWFnZSB7 Cgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBhdXRvO30KCi5mb290ZXIgewoJd2lkdGg6IDYwNHB4 O30KCi5tYWluIHsKCn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4LWRldmljZS13aWR0aDogODAwcHgp IHsKCS50aXRsZSB7CgkJZm9udC1zaXplOiAyMnB4ICFpbXBvcnRhbnQ7CX0KCS5pbWFnZSB7CgkJ d2lkdGg6IGF1dG8gIWltcG9ydGFudDsJCW1heC13aWR0aDogMTAwJSAhaW1wb3J0YW50Owl9Cgku Zm9vdGVyIHsKCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1w b3J0YW50Cgl9CgkubWFpbiB7CgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDog NjA0cHggIWltcG9ydGFudAoJfQp9Cjwvc3R5bGU+Cgo8dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIg c3R5bGU9InBhZGRpbmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFs aWduPSJsZWZ0Ij4KCTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3Ry PgoJPHRyPgoJCTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2lu OiAwIj4KCQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7 IHdpZHRoOiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBh bGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPgoJCQkJPHRyPgoJCQkJCTx0ZCBhbGlnbj0iY2VudGVy IiB2YWxpZ249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD4KCQkJCTwvdHI+CgkJCTwvdGFibGU+LS0+ CgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgIDx0ZCBzdHlsZT0iaGVpZ2h0OiAyMnB4 O2NvbG9yOiAjMDAwMDAwO2ZvbnQtZmFtaWx5OiBBcmlhbDsJZm9udC1zaXplOiAxNnB4O2ZvbnQt d2VpZ2h0OiBib2xkO2xpbmUtaGVpZ2h0OiAyMnB4OyI+CiAgICAgICAgICAgICAgICBXZWIgQXV0 aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpvaW4gdGhp cyBXZWJleCBtZWV0aW5nLgogICAgICAgICAgICAgICAgCSAgICAgICAgICAgPC90ZD4KICAgICAg PC90cj4KPC90YWJsZT4KCgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0 ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoKICAgIDx0YWJs ZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQ7Ij4KICAgICAgICA8dHI+ CiAgICAgICAgICAgIDx0ZCBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogIzAwMDAw MDsgZm9udC1zaXplOiAxNnB4OyBsaW5lLWhlaWdodDogMjJweDsiPgogICAgICAgICAgICAgICAg TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQzIDE0OCA1NDgKICAgICAgICAgICAgPC90 ZD4KICAgICAgICA8L3RyPgogICAgPC90YWJsZT4KICAgIDx0YWJsZSBzdHlsZT0id2lkdGg6YXV0 bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQiPgogICAgICAgIDx0ciA+CiAgICAgICAgICAgIDx0ZCBz dHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogIzAwMDAwMDsgZm9udC1zaXplOiAxNnB4 OyBsaW5lLWhlaWdodDogMjJweDsiPk1lZXRpbmcgcGFzc3dvcmQ6IEJXc0FGOXJUPC90ZD4KICAg ICAgICA8L3RyPgogICAgPC90YWJsZT4KPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIw cHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCiAg ICA8dGFibGUgIHdpZHRoPSIxMDAlIj4KICAgICAgICA8dHIgc3R5bGU9Im1hcmdpbjowcHg7Y29s b3I6ICM2NjY2NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdo dDogMjJweDsiPgogICAgICAgICAgICA8dGQgc3R5bGU9Im1hcmdpbjowcHg7Y29sb3I6ICM2NjY2 NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjJweDsi Pk9jY3VycyBldmVyeSAyIHdlZWsocykgb24gTW9uZGF5IGVmZmVjdGl2ZSBNb25kYXksIEF1Z3Vz dCAyNCwgMjAyMCBmcm9tIDY6MDAgUE0gdG8gNjozMCBQTSwgKFVUQyswMjowMCkgQW1zdGVyZGFt LCBCZXJsaW4sIEJlcm4sIFJvbWUsIFN0b2NraG9sbSwgVmllbm5hCiAgICAgICAgICAgIDwvdGQ+ CiAgICAgICAgPC90cj4KICAgICAgICA8dHIgc3R5bGU9Im1hcmdpbjowcHg7Y29sb3I6ICM2NjY2 NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjJweDsi PgogICAgICAgICAgICA8dGQgc3R5bGU9Im1hcmdpbjowcHg7Y29sb3I6ICM2NjY2NjY7Zm9udC1m YW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjJweDsiPjY6MDAgcG0m bmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7KFVUQyswMjowMCkgQW1zdGVyZGFtLCBCZXJsaW4sIEJl cm4sIFJvbWUsIFN0b2NraG9sbSwgVmllbm5hJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzMwIG1p bnMKICAgICAgICAgICAgPC90ZD4KICAgICAgICA8L3RyPgogICAgPC90YWJsZT4KCiA8Rk9OVCBz aXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9O VD4KCiAgICAKCgkJCTx0YWJsZSBzdHlsZT0icGFkZGluZy1ib3R0b206IDRweDtmb250LWZhbWls eTogQXJpYWw7Ij48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdo dDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJPHRhYmxlIHN0eWxlPSd3aWR0aDph dXRvO3dpZHRoOmF1dG8haW1wb3J0YW50Oyc+PHRyPjx0ZCBzdHlsZT0nd2lkdGg6YXV0byFpbXBv cnRhbnQ7ICc+PHRhYmxlIGJvcmRlcj0nMCcgY2VsbHBhZGRpbmc9JzAnIGNlbGxzcGFjaW5nPScw JyBzdHlsZT0nd2lkdGg6YXV0bzt3aWR0aDphdXRvIWltcG9ydGFudDsgYmFja2dyb3VuZC1jb2xv cjojNDNBOTQyOyBib3JkZXI6MHB4IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjBweDsg bWluLXdpZHRoOjE2MHB4IWltcG9ydGFudDsnPjx0Ym9keT48dHI+PHRkIGFsaWduPSdjZW50ZXIn IHN0eWxlPSdwYWRkaW5nOjEwcHggMzZweDtmb250LWZhbWlseTogQXJpYWw7Jz48YSBocmVmPSdo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tOGJiOTA4NTEzMjhjNDhmZjg1 ZTY1MDdmMWM2Y2RlYjMnIHN0eWxlPSdjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4 dC1kZWNvcmF0aW9uOm5vbmU7Jz5Kb2luIG1lZXRpbmc8L2E+PC90ZD48L3RyPjwvdGJvZHk+PC90 YWJsZT48L3RkPjwvdHI+PC90YWJsZT4KCQkJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6 IDQ4cHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjQ4cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoK Cgk8dGFibGU+PHRyPjx0ZCBzdHlsZT0iY29sb3I6ICMwMDAwMDA7Zm9udC1mYW1pbHk6IEFyaWFs OyBmb250LXNpemU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRweDsi PjxiPlRhcCB0byBqb2luIGZyb20gYSBtb2JpbGUgZGV2aWNlIChhdHRlbmRlZXMgb25seSk8L2I+ PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJmb250LWZhbWlseTog QXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4OyI+PGEgaHJlZj0ndGVsOiUy QjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQzMTQ4NTQ4JTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMw MEFGRjk7ICB0ZXh0LWRlY29yYXRpb246bm9uZTsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6 ZTogMTRweDtsaW5lLWhlaWdodDogMjRweDsnPisxLTY1MC00NzktMzIwOCwsNjQzMTQ4NTQ4IyM8 L2E+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJs aW5lLWhlaWdodDogMjRweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjRweCI+Jm5ic3A7PC90ZD48L3Ry PjwvdGFibGU+PHRhYmxlPjx0Ym9keT48dHI+PHRkIHN0eWxlPSJjb2xvcjogIzAwMDAwMDtmb250 LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUt aGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiBieSBwaG9uZTwvYj48L3RkPjwvdHI+PHRyIHN0eWxlPSJt YXJnaW46MHB4Ij48dGQgc3R5bGU9ImNvbG9yOiAjMzMzMzMzO2ZvbnQtZmFtaWx5OiBBcmlhbDtm b250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7Ij4xLTY1MC00NzktMzIwOCZuYnNwOzxz cGFuIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsiPkNhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFk YSk8L3NwYW4+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJmb250 LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4OyI+PC90ZD48 L3RyPjwvdGJvZHk+PC90YWJsZT48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIw Ij48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyOHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjhweCI+ Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkKICAgIAoKCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUt aGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90 YWJsZT4KCQoKCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDogMTAwJTsiIGFsaWduPSJsZWZ0IiBjbGFz cz0ibWFpbiI+CiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNzJweCI+PHRkPiZu YnNwOzwvdGQ+PC90cj4KCQkJCTx0cj4KCQkJCQk8dGQgc3R5bGU9ImhlaWdodDogMjRweDsgY29s b3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OkFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVp Z2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBHbyB0byA8YSBocmVmPSJodHRwOi8vaGVscC53ZWJleC5j b20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPmh0dHA6Ly9o ZWxwLndlYmV4LmNvbTwvYT4KCQkJCQk8L3RkPgoJCQkJPC90cj4KICAgICAgICAgICAgICAgIDx0 ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPgoJCQk8L3RhYmxlPgoJ CTwvdGQ+Cgk8L3RyPgo8L3RhYmxlPgo= ------=_Part_2808445_220495408.1598266995653 Content-Type: text/calendar;method=REQUEST;charset=utf-8; Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkV1cm9wZS9CZXJsaW4NClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9uZWlu Zm8tb3V0bG9vay9FdXJvcGUvQmVybGluDQpYLUxJQy1MT0NBVElPTjpFdXJvcGUvQmVybGluDQpC RUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9GRlNFVFRPOiswMjAwDQpUWk5B TUU6Q0VTVA0KRFRTVEFSVDoxOTcwMDMyOVQwMjAwMDANClJSVUxFOkZSRVE9WUVBUkxZO0JZTU9O VEg9MztCWURBWT0tMVNVDQpFTkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpUWk9GRlNFVEZS T006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClRaTkFNRTpDRVQNCkRUU1RBUlQ6MTk3MDEwMjVU MDMwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTEwO0JZREFZPS0xU1UNCkVORDpTVEFO REFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwODI0VDExMDMx NVoNCkFUVEVOREVFO0NOPSJvYXV0aEBpZXRmLm9yZyI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNW UD1UUlVFOk1BSUxUTzpvYXV0aEBpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJXZWIgQXV0aG9yaXph dGlvbiBQcm90b2NvbCBXb3JraW5nIEdyb3VwIjpNQUlMVE86b2F1dGgtY2hhaXJzQGlldGYub3Jn DQpEVFNUQVJUO1RaSUQ9RXVyb3BlL0JlcmxpbjoyMDIwMDgyNFQxODAwMDANCkRURU5EO1RaSUQ9 RXVyb3BlL0JlcmxpbjoyMDIwMDgyNFQxODMwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9qLnBocD9NVElEPW04YmI5MDg1MTMyOGM0OGZmODVlNjUwN2YxYzZjZGViMw0K VFJBTlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MTU5ODI2Njk5NQ0KVUlEOjIwNDVkMzU3LWZlNzgtNDkw YS1iOTA0LTU2MGRjN2FlMzYwMg0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJ Tkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW04YmI5MDg1MTMyOGM0 OGZmODVlNjUwN2YxYzZjZGViM1xuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQzIDE0 OCA1NDhcblxuTWVldGluZyBwYXNzd29yZDogQldzQUY5clRcblxuXG5cblRBUCBUTyBKT0lOIEZS T00gQSBNT0JJTEUgREVWSUNFIChBVFRFTkRFRVMgT05MWSlcbisxLTY1MC00NzktMzIwOCwsNjQz MTQ4NTQ4IyMgdGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQzMTQ4NTQ4JTIzJTIzKjAxKiBD YWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAt NDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuXG5cblxuXG5cblxuQ2Fu J3Qgam9pbiB0aGUgbWVldGluZz9cbmh0dHBzOi8vY29sbGFib3JhdGlvbmhlbHAuY2lzY28uY29t L2FydGljbGUvV0JYMDAwMDI5MDU1XG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUg dGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlv biBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRp c2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlv dSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90 IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRo ZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuDQpYLUFMVC1ERVNDO0ZNVFRZUEU9 dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+XG50YWJsZSB7XG4JYm9yZGVyLWNvbGxh cHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNpbmc6IDA7 fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9udC1zaXplOiAx NHB4Owlmb250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5cbi50aXRsZSB7XG4JZm9udC1z aXplOiAyOHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBhdXRvO31c blxuLmZvb3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4ge1xuXG59QG1lZGlhIHNjcmVl biBhbmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJZm9udC1zaXpl OiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0aDogYXV0byAhaW1wb3J0YW50 OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJd2lkdGg6IDEw MCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbgkubWFpbiB7 XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRc bgl9XG59XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9InBhZGRp bmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFsaWduPSJsZWZ0Ij5c bgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgk8dHI+XG4J CTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2luOiAwIj5cbgkJ CTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4OyB3aWR0aDog MTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIgYWxpZ249Imxl ZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiB2YWxp Z249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT4tLT5cblxu XG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpF PSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1lLCBqb2luIHRo ZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQkJ PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZu YnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjIi IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2Rl KTogNjQzIDE0OCA1NDg8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+ XG4JCQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkJXc0FGOXJUPC9GT05UPjwvdGQ+PC90cj48L3Rh YmxlPlxuXG4gICAgICAgIDx0YWJsZT5cbiAgICAgICAgCTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6 IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8dHI+ XG4JCQkJPHRkIHN0eWxlPSJ3aWR0aDphdXRvIWltcG9ydGFudDsgIj5cbgkJCQkJPHRhYmxlIGJv cmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiBzdHlsZT0id2lkdGg6YXV0 bzt3aWR0aDphdXRvIWltcG9ydGFudDtiYWNrZ3JvdW5kLWNvbG9yOiM0M0E5NDI7IGJvcmRlcjow cHggc29saWQgIzQzQTk0MjsgYm9yZGVyLXJhZGl1czoyNXB4OyBtaW4td2lkdGg6MTYwcHghaW1w b3J0YW50OyI+XG4JCQkJCQk8dHI+XG4JCQkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJw YWRkaW5nOjEwcHggMzZweDsiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW04YmI5MDg1MTMyOGM0OGZmODVlNjUwN2YxYzZjZGViMyIgc3R5bGU9ImNvbG9y OiNGRkZGRkY7IGZvbnQtc2l6ZToyMHB4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPkpvaW4gbWVl dGluZzwvYT48L3RkPlxuCQkJCQkJPC90cj5cbgkJCQkJPC90YWJsZT5cbgkJCQk8L3RkPlxuCQkJ PC90cj5cbgkJPC90YWJsZT5cblxuIDxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIiBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsOyI+PC9GT05UPlxuPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJ QUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPlxuXG4mbmJzcDsgPEJSPjxGT05UIFNJWkU9 IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPlRhcCB0byBqb2luIGZyb20gYSBtb2JpbGUgZGV2aWNlIChhdHRlbmRlZXMgb25seSk8L0ZP TlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij48YSBocmVmPSd0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDMxNDg1NDglMjMlMjMqMDEq JyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3JhdGlvbjpub25lOyBmb250LWZhbWls eTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4Oyc+KzEtNjUwLTQ3OS0z MjA4LCw2NDMxNDg1NDgjIzwvYT4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9O VD4mbmJzcDsgPEJSPjxCUj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0i MyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiAmbmJz cDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+MS02NTAt NDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4gJm5ic3A7IDxC Uj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjwvRk9OVD4mbmJz cDsgPEJSPjxCUj48QlI+XG5cbjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+ PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+XG5cblxuXG5c blxuCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdo dDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT5cbglcblxuCQkJPHRhYmxlIHN0eWxlPSJ3 aWR0aDogMTAwJTsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFpbiI+XG4gICAgICAgICAgICAgICAg PHRyIHN0eWxlPSJoZWlnaHQ6IDcycHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxu CQkJCQk8dGQgc3R5bGU9ImhlaWdodDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5 OkFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBH byB0byA8YSBocmVmPSJodHRwOi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5 OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJCQkJ PC90ZD5cbgkJCQk8L3RyPlxuICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4 Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxuPC90 YWJsZT5cbg0KU1VNTUFSWTpPQXV0aCBXRyBWaXJ0dWFsIE9mZmljZSBIb3Vycw0KUFJJT1JJVFk6 NQ0KQ0xBU1M6UFVCTElDDQpSUlVMRTpGUkVRPVdFRUtMWTtXS1NUPVNVO0lOVEVSVkFMPTI7QllE QVk9TU8NCkJFR0lOOlZBTEFSTQ0KVFJJR0dFUjotUFQ1TQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NS SVBUSU9OOlJlbWluZGVyDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= ------=_Part_2808445_220495408.1598266995653-- ------=_Part_2808444_1998331008.1598266995653 Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkV1cm9wZS9CZXJsaW4NClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9uZWlu Zm8tb3V0bG9vay9FdXJvcGUvQmVybGluDQpYLUxJQy1MT0NBVElPTjpFdXJvcGUvQmVybGluDQpC RUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9GRlNFVFRPOiswMjAwDQpUWk5B TUU6Q0VTVA0KRFRTVEFSVDoxOTcwMDMyOVQwMjAwMDANClJSVUxFOkZSRVE9WUVBUkxZO0JZTU9O VEg9MztCWURBWT0tMVNVDQpFTkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpUWk9GRlNFVEZS T006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClRaTkFNRTpDRVQNCkRUU1RBUlQ6MTk3MDEwMjVU MDMwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTEwO0JZREFZPS0xU1UNCkVORDpTVEFO REFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwODI0VDExMDMx NVoNCkFUVEVOREVFO0NOPSJvYXV0aEBpZXRmLm9yZyI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNW UD1UUlVFOk1BSUxUTzpvYXV0aEBpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJXZWIgQXV0aG9yaXph dGlvbiBQcm90b2NvbCBXb3JraW5nIEdyb3VwIjpNQUlMVE86b2F1dGgtY2hhaXJzQGlldGYub3Jn DQpEVFNUQVJUO1RaSUQ9RXVyb3BlL0JlcmxpbjoyMDIwMDgyNFQxODAwMDANCkRURU5EO1RaSUQ9 RXVyb3BlL0JlcmxpbjoyMDIwMDgyNFQxODMwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9qLnBocD9NVElEPW04YmI5MDg1MTMyOGM0OGZmODVlNjUwN2YxYzZjZGViMw0K VFJBTlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MTU5ODI2Njk5NQ0KVUlEOjIwNDVkMzU3LWZlNzgtNDkw YS1iOTA0LTU2MGRjN2FlMzYwMg0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJ Tkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW04YmI5MDg1MTMyOGM0 OGZmODVlNjUwN2YxYzZjZGViM1xuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQzIDE0 OCA1NDhcblxuTWVldGluZyBwYXNzd29yZDogQldzQUY5clRcblxuXG5cblRBUCBUTyBKT0lOIEZS T00gQSBNT0JJTEUgREVWSUNFIChBVFRFTkRFRVMgT05MWSlcbisxLTY1MC00NzktMzIwOCwsNjQz MTQ4NTQ4IyMgdGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQzMTQ4NTQ4JTIzJTIzKjAxKiBD YWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAt NDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuXG5cblxuXG5cblxuQ2Fu J3Qgam9pbiB0aGUgbWVldGluZz9cbmh0dHBzOi8vY29sbGFib3JhdGlvbmhlbHAuY2lzY28uY29t L2FydGljbGUvV0JYMDAwMDI5MDU1XG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUg dGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlv biBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRp c2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlv dSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90 IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRo ZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuDQpYLUFMVC1ERVNDO0ZNVFRZUEU9 dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+XG50YWJsZSB7XG4JYm9yZGVyLWNvbGxh cHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNpbmc6IDA7 fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9udC1zaXplOiAx NHB4Owlmb250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5cbi50aXRsZSB7XG4JZm9udC1z aXplOiAyOHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBhdXRvO31c blxuLmZvb3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4ge1xuXG59QG1lZGlhIHNjcmVl biBhbmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJZm9udC1zaXpl OiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0aDogYXV0byAhaW1wb3J0YW50 OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJd2lkdGg6IDEw MCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbgkubWFpbiB7 XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRc bgl9XG59XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9InBhZGRp bmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFsaWduPSJsZWZ0Ij5c bgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgk8dHI+XG4J CTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2luOiAwIj5cbgkJ CTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4OyB3aWR0aDog MTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIgYWxpZ249Imxl ZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiB2YWxp Z249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT4tLT5cblxu XG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpF PSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1lLCBqb2luIHRo ZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQkJ PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZu YnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjIi IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2Rl KTogNjQzIDE0OCA1NDg8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+ XG4JCQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkJXc0FGOXJUPC9GT05UPjwvdGQ+PC90cj48L3Rh YmxlPlxuXG4gICAgICAgIDx0YWJsZT5cbiAgICAgICAgCTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6 IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8dHI+ XG4JCQkJPHRkIHN0eWxlPSJ3aWR0aDphdXRvIWltcG9ydGFudDsgIj5cbgkJCQkJPHRhYmxlIGJv cmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiBzdHlsZT0id2lkdGg6YXV0 bzt3aWR0aDphdXRvIWltcG9ydGFudDtiYWNrZ3JvdW5kLWNvbG9yOiM0M0E5NDI7IGJvcmRlcjow cHggc29saWQgIzQzQTk0MjsgYm9yZGVyLXJhZGl1czoyNXB4OyBtaW4td2lkdGg6MTYwcHghaW1w b3J0YW50OyI+XG4JCQkJCQk8dHI+XG4JCQkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJw YWRkaW5nOjEwcHggMzZweDsiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW04YmI5MDg1MTMyOGM0OGZmODVlNjUwN2YxYzZjZGViMyIgc3R5bGU9ImNvbG9y OiNGRkZGRkY7IGZvbnQtc2l6ZToyMHB4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPkpvaW4gbWVl dGluZzwvYT48L3RkPlxuCQkJCQkJPC90cj5cbgkJCQkJPC90YWJsZT5cbgkJCQk8L3RkPlxuCQkJ PC90cj5cbgkJPC90YWJsZT5cblxuIDxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIiBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsOyI+PC9GT05UPlxuPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJ QUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPlxuXG4mbmJzcDsgPEJSPjxGT05UIFNJWkU9 IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPlRhcCB0byBqb2luIGZyb20gYSBtb2JpbGUgZGV2aWNlIChhdHRlbmRlZXMgb25seSk8L0ZP TlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij48YSBocmVmPSd0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDMxNDg1NDglMjMlMjMqMDEq JyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3JhdGlvbjpub25lOyBmb250LWZhbWls eTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4Oyc+KzEtNjUwLTQ3OS0z MjA4LCw2NDMxNDg1NDgjIzwvYT4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9O VD4mbmJzcDsgPEJSPjxCUj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0i MyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiAmbmJz cDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+MS02NTAt NDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4gJm5ic3A7IDxC Uj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjwvRk9OVD4mbmJz cDsgPEJSPjxCUj48QlI+XG5cbjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+ PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+XG5cblxuXG5c blxuCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdo dDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT5cbglcblxuCQkJPHRhYmxlIHN0eWxlPSJ3 aWR0aDogMTAwJTsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFpbiI+XG4gICAgICAgICAgICAgICAg PHRyIHN0eWxlPSJoZWlnaHQ6IDcycHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxu CQkJCQk8dGQgc3R5bGU9ImhlaWdodDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5 OkFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBH byB0byA8YSBocmVmPSJodHRwOi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5 OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJCQkJ PC90ZD5cbgkJCQk8L3RyPlxuICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4 Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxuPC90 YWJsZT5cbg0KU1VNTUFSWTpPQXV0aCBXRyBWaXJ0dWFsIE9mZmljZSBIb3Vycw0KUFJJT1JJVFk6 NQ0KQ0xBU1M6UFVCTElDDQpSUlVMRTpGUkVRPVdFRUtMWTtXS1NUPVNVO0lOVEVSVkFMPTI7QllE QVk9TU8NCkJFR0lOOlZBTEFSTQ0KVFJJR0dFUjotUFQ1TQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NS SVBUSU9OOlJlbWluZGVyDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= ------=_Part_2808444_1998331008.1598266995653-- From nobody Mon Aug 24 04:05:25 2020 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 467063A0CBA for ; Mon, 24 Aug 2020 04:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.443 X-Spam-Level: * X-Spam-Status: No, score=1.443 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_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_12=1.629, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 AF5ZgWWFQ5bi for ; Mon, 24 Aug 2020 04:05:23 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 C32383A0CB7 for ; Mon, 24 Aug 2020 04:05:22 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id h15so1483413wrt.12 for ; Mon, 24 Aug 2020 04:05:22 -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=mbxXTswuFlTYc3BBwNvq07oW/zC/3y4QZKimiNns1+I=; b=YboChxoarowiMc+c6NbMQ5XJ0fPfF15G3XGb2CRz1LbnhA/sQIcdg5LYbyp9LqhAaC a7E2Cd+j5FgaJrg9eaSJYUdvD3SIPNXwaVIk0zS2rmJO5CGMmSF9hwJS7RcGT2kt0yVd uCVIuXcCs4U+rHY76PRp2QVLQU0blytuj45Oie4ZIaH030Og3FXjzUaeO/qMGIzsAffx AwTd9586xpo93HF8k7/njORlEBgN75Ox0Ldbm8IMPROiOwX5l72HpTQQ+qU3P+57ZvIv JnxA/jTHDJNGGWdTNU1/QLcTMnlQNfg0hHqp4KgFsWQBMNT0Pa3HxDAHi8bn/BprsvN/ 3zig== 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=mbxXTswuFlTYc3BBwNvq07oW/zC/3y4QZKimiNns1+I=; b=GjiDaXkzvhMup9U8syrBV2LbwfrxutusMnoCJzkSccitPTYXzN0WqE1UhddUIT6pzp 0fFnLAkbA/X4fG2tC2NeV7eg0ADWQdZpvLzf/prbnEYUpMjTmz9rZXIE8d86W2yuDqN4 PmPoJt0mxTW7SDP7ywOyv/R+kV7Dp58J0LAyi2eylQF+v5R1WMnIteOddhK6MuUdsR6U 9Ewnzv1muL25j0+pzsO++ZcXkvp/pRunyMzPOKmIn4Zxg0F/JhlP2hgMu0qlajSDMlnI Ds4cdje49aazFof2EKFS7QEo6300r41NX3koh6dJspAe0+q4yCoS6edQmgvMjKHooXQf sCkg== X-Gm-Message-State: AOAM532DCt3hE0avVKY+yxhZZIWaFMqo5KxOuc4jJm/I1qR3dgw2z79a uU10Vqms5j0bn4Pv8NkYrhAIPqE+U9TBzZ+106s= X-Google-Smtp-Source: ABdhPJyBxou6IF4ItWTok2Bas1lTDh9QOzjoanxNQeVe0Z5/HcA4NOaFczlQYQoGxzzWwGdrTdpeaCKeqzdDkG8qNZw= X-Received: by 2002:adf:e60a:: with SMTP id p10mr5301388wrm.295.1598267121166; Mon, 24 Aug 2020 04:05:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Mon, 24 Aug 2020 07:05:10 -0400 Message-ID: To: Dick Hardt Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000036b6505ad9d90ae" Archived-At: Subject: Re: [OAUTH-WG] office hours / meeting this week? 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, 24 Aug 2020 11:05:24 -0000 --000000000000036b6505ad9d90ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We have office hours today. I have just sent the meeting invite to the list. Regards, Rifaat On Sunday, August 23, 2020, Dick Hardt wrote: > Are either of these happening tomorrow? If so, what is the WebEx link? > > Thanks! > =E1=90=A7 > --000000000000036b6505ad9d90ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We have office hours today.
I have just sent the meeti= ng invite to the list.

Regards,
=C2=A0Rifa= at

On Sunday, August 23, 2020, Dick Hardt <dick.hardt@gmail.com> wrote:
=
Are either of these happeni= ng tomorrow? If so, what is the WebEx link?

Thanks!
3D"==E1=90=A7
--000000000000036b6505ad9d90ae-- From nobody Tue Aug 25 06:28:30 2020 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 686D13A0D32 for ; Tue, 25 Aug 2020 06:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-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 bhOnHIpnr3xd for ; Tue, 25 Aug 2020 06:28:28 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B074C3A0D2C for ; Tue, 25 Aug 2020 06:28:27 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d84 with ME id KpUQ230032bcEcA03pUQiK; Tue, 25 Aug 2020 15:28:25 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 25 Aug 2020 15:28:25 +0200 X-ME-IP: 90.79.51.120 To: oauth@ietf.org References: From: Denis Message-ID: <8b35cd47-4bae-af9c-0ebb-da7c71b2a597@free.fr> Date: Tue, 25 Aug 2020 15:28:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2F7F947BC1A4794C0A36F539" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] WGLC on Pushed Authorization Requests draft 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, 25 Aug 2020 13:28:29 -0000 This is a multi-part message in MIME format. --------------2F7F947BC1A4794C0A36F539 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This document does not include a "Privacy considerations" section, but it should. Denis > All, > > This is a WGLC on the *Pushed Authorization Requests *document: > https://www.ietf.org/id/draft-ietf-oauth-par-03.html > > Please, take a look and provide feedback on the list by *August 25th.* > > Regards, >  Rifaat & Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------2F7F947BC1A4794C0A36F539 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
This document does not include a "Privacy considerations" section, but it should.

Denis

All,

This is a WGLC on the Pushed Authorization Requests document:

Please, take a look and provide feedback on the list by August 25th.

Regards,
 Rifaat & Hannes


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


--------------2F7F947BC1A4794C0A36F539-- From nobody Tue Aug 25 07:56:07 2020 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 0034C3A0DD7 for ; Tue, 25 Aug 2020 07:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 GhZrnQF3VjlZ for ; Tue, 25 Aug 2020 07:56:00 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA9F3A0DDC for ; Tue, 25 Aug 2020 07:55:59 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d50 with ME id Kqvu2300E2bcEcA03qvvpC; Tue, 25 Aug 2020 16:55:57 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 25 Aug 2020 16:55:57 +0200 X-ME-IP: 90.79.51.120 To: last-call@ietf.org References: <159802288149.12737.11570006487802113668@ietfa.amsl.com> From: Denis Cc: oauth@ietf.org Message-ID: <87dbd1ed-e03d-a00d-e3a2-6f53500ef725@free.fr> Date: Tue, 25 Aug 2020 16:55:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <159802288149.12737.11570006487802113668@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------A69E85CBE657632DD095C38F" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 25 Aug 2020 14:56:03 -0000 This is a multi-part message in MIME format. --------------A69E85CBE657632DD095C38F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This draft contains a "Privacy considerations" section (Section 9). . The content of this section is as follows:    The token introspection response can be used to transfer personal    identifiable information from the AS to the RS.  The AS MUST ensure a    legal basis exists for the data transfer before any data is released    to a particular RS.  The way the legal basis is established might    vary among jurisdictions and MUST consider the legal entities    involved.    For example, the classical way to establish the legal basis is by    explicit user consent gathered from the resource owner by the AS    during the authorization flow.    It is also possible that the legal basis is established out of band,    e.g. in an explicit contract or by the client gathering the resource    owner’s consent.    If the AS and the RS belong to the same legal entity (1st party    scenario), there is potentially no need for an explicit user consent    but the terms of service and policy of the respective service    provider MUST be enforced at all times.    In any case, the AS MUST ensure that the scope of the legal basis is    enforced throughout the whole process.  The AS MUST retain the scope    of the legal basis with the access token, e.g. in the scope value,    and the AS MUST determine the data a resource server is allowed to    receive based on the resource server’s identity and suitable token    data, e.g. the scope value. It is not believed that these explanations are useful, nor sufficient. Talking a "legal basis" without translating legal constraints into technical constraints is not useful. Since sensitive information may be returned, the text should say that AS should/must make sure that the requesting RS is indeed authenticated and allowed to perform this operation. However, section 4 is only using the verb "SHOULD" whereas it should use the verb "SHALL" : The AS SHOULD authenticate the caller at the token introspection endpoint. Talking of "an explicit user consent gathered from the resource owner by the AS" does not make sense. Either the operation is allowed or is not allowed by the RO, but there is no "RO consent". *About **RFC 7662 (OAuth 2.0 Token Introspection)* One might think that the important considerations have already been provided when issuing RFC 7662 (OAuth 2.0 Token Introspection) which contains a Privacy considerations section (section 5). The third sentence states: One method is to transmit user identifiers as opaque service-specific strings, potentially returning different identifiers to each protected resource. This would mean that the response would not reflect the content of the token. Furthermore, the RS would not even be informed of such a transformation. The last sentence even states: Omitting privacy-sensitive information from an introspection response is the simplest way of minimizing privacy issues. In such a case, the introspection query becomes more or less useless. What should have been said in RFC 7662 (OAuth 2.0 Token Introspection) ? The fact that using an introspection call can be avoided and should be avoided for privacy reasons. While "in OAuth 2.0 [RFC6749], the contents of tokens are opaque to clients", it is not opaque to RSs. As soon as the RS knows the format of the access token and is able to validate its security features, this call should be avoided. So what should be mentioned in section 9 ? The fact that the AS will know exactly when the introspection call has been made and thus be able to make sure which client has attempted perform an access to that RS and at which instant of time. The use of this call allows an AS to track where and when its clients have indeed presented an issued access token. Denis > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: - 'JWT Response for OAuth Token > Introspection' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2020-09-04. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > This specification proposes an additional JSON Web Token (JWT) > secured response for OAuth 2.0 Token Introspection. > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ > > > No IPR declarations have been submitted directly on this I-D. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------A69E85CBE657632DD095C38F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

This draft contains a "Privacy considerations" section (Section 9).
.
The content of this section is as follows:

   The token introspection response can be used to transfer personal
   identifiable information from the AS to the RS.  The AS MUST ensure a
   legal basis exists for the data transfer before any data is released
   to a particular RS.  The way the legal basis is established might
   vary among jurisdictions and MUST consider the legal entities
   involved.

   For example, the classical way to establish the legal basis is by
   explicit user consent gathered from the resource owner by the AS
   during the authorization flow.

   It is also possible that the legal basis is established out of band,
   e.g. in an explicit contract or by the client gathering the resource
   owner’s consent.

   If the AS and the RS belong to the same legal entity (1st party
   scenario), there is potentially no need for an explicit user consent
   but the terms of service and policy of the respective service
   provider MUST be enforced at all times.

   In any case, the AS MUST ensure that the scope of the legal basis is
   enforced throughout the whole process.  The AS MUST retain the scope
   of the legal basis with the access token, e.g. in the scope value,
   and the AS MUST determine the data a resource server is allowed to
   receive based on the resource server’s identity and suitable token
   data, e.g. the scope value.

It is not believed that these explanations are useful, nor sufficient.

Talking a "legal basis" without translating legal constraints into technical constraints is not useful.
Since sensitive information may be returned, the text should say that AS should/must make sure that the requesting RS is indeed
authenticated and allowed to perform this operation.

However, section 4 is only using the verb "SHOULD" whereas it should use the verb "SHALL" :
The AS SHOULD authenticate the caller at the token introspection endpoint.
Talking of "an explicit user consent gathered from the resource owner by the AS" does not make sense.
Either the operation is allowed or is not allowed by the RO, but there is no "RO consent".

About RFC 7662 (OAuth 2.0 Token Introspection)

One might think that the important considerations have already been provided when issuing RFC 7662 (OAuth 2.0 Token Introspection)
which contains a Privacy considerations section (section 5).

The third sentence states:
One method is to transmit user identifiers as opaque service-specific strings, potentially returning different identifiers to each protected resource.
This would mean that the response would not reflect the content of the token. Furthermore, the RS would not even be informed of such a transformation.

The last sentence even states:
Omitting privacy-sensitive information from an introspection response is the simplest way of minimizing privacy issues.
In such a case, the introspection query becomes more or less useless.

What should have been said in RFC 7662 (OAuth 2.0 Token Introspection) ?

The fact that using an introspection call can be avoided and should be avoided for privacy reasons. While "in OAuth 2.0 [RFC6749],
the contents of tokens are opaque to clients", it is not opaque to RSs. As soon as the RS knows the format of the access token and is able
to validate its security features, this call should be avoided.

So what should be mentioned in section 9 ?

The fact that the AS will know exactly when the introspection call has been made and thus be able to make sure which client
has attempted perform an access to that RS and at which instant of time. The use of this call allows an AS to track where and when
its clients have indeed presented an issued access token.

Denis

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'JWT Response for OAuth Token
Introspection'
  <draft-ietf-oauth-jwt-introspection-response-09.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-09-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   This specification proposes an additional JSON Web Token (JWT)
   secured response for OAuth 2.0 Token Introspection.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/


No IPR declarations have been submitted directly on this I-D.

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


--------------A69E85CBE657632DD095C38F-- From nobody Tue Aug 25 09:26:55 2020 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 01C543A0F46 for ; Tue, 25 Aug 2020 09:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-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 FyyJdVtmnSfW for ; Tue, 25 Aug 2020 09:26:51 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014163A0F32 for ; Tue, 25 Aug 2020 09:26:50 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d22 with ME id KsSp230012bcEcA03sSpHH; Tue, 25 Aug 2020 18:26:49 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 25 Aug 2020 18:26:49 +0200 X-ME-IP: 90.79.51.120 To: last-call@ietf.org References: <159802288149.12737.11570006487802113668@ietfa.amsl.com> <87dbd1ed-e03d-a00d-e3a2-6f53500ef725@free.fr> From: Denis Cc: oauth@ietf.org Message-ID: Date: Tue, 25 Aug 2020 18:26:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <87dbd1ed-e03d-a00d-e3a2-6f53500ef725@free.fr> Content-Type: multipart/alternative; boundary="------------43C05610DF15704654E67A2C" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 25 Aug 2020 16:26:54 -0000 This is a multi-part message in MIME format. --------------43C05610DF15704654E67A2C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Here is an additional comment: The text mentions in the Introduction:    In example is a resource server using verified person data    to create certificates, which in turn are used to create qualified    electronic signatures. The problem is the following: the AS has no way to verify that the User has effectively authorized the RS to use the JWT Response for such a purpose. A "User Consent" phase for such a usage has not been addressed. This concern is identified in RFC 6973 as: 5.2.3.  Secondary Use    Secondary use is the use of collected information about an individual    without the individual’s consent for a purpose different from that    for which the information was collected.  Secondary use may violate    people’s expectations or desires.  The potential for secondary use    can generate uncertainty as to how one’s information will be used in    the future, potentially discouraging information exchange in the    first place.  Secondary use encompasses any use of data, including    disclosure. The progression of this draft is really questionable. The User has currently no way to allow or to disallow this protocol which is between a RS and an AS.  It would not be reasonable to say that this concern is outside the scope of this draft. Denis > This draft contains a "Privacy considerations" section (Section 9). > . > The content of this section is as follows: > >    The token introspection response can be used to transfer personal >    identifiable information from the AS to the RS.  The AS MUST ensure a >    legal basis exists for the data transfer before any data is released >    to a particular RS.  The way the legal basis is established might >    vary among jurisdictions and MUST consider the legal entities >    involved. > >    For example, the classical way to establish the legal basis is by >    explicit user consent gathered from the resource owner by the AS >    during the authorization flow. > >    It is also possible that the legal basis is established out of band, >    e.g. in an explicit contract or by the client gathering the resource >    owner’s consent. > >    If the AS and the RS belong to the same legal entity (1st party >    scenario), there is potentially no need for an explicit user consent >    but the terms of service and policy of the respective service >    provider MUST be enforced at all times. > >    In any case, the AS MUST ensure that the scope of the legal basis is >    enforced throughout the whole process.  The AS MUST retain the scope >    of the legal basis with the access token, e.g. in the scope value, >    and the AS MUST determine the data a resource server is allowed to >    receive based on the resource server’s identity and suitable token >    data, e.g. the scope value. > > It is not believed that these explanations are useful, nor sufficient. > > Talking a "legal basis" without translating legal constraints into > technical constraints is not useful. > Since sensitive information may be returned, the text should say that > AS should/must make sure that the requesting RS is indeed > authenticated and allowed to perform this operation. > > However, section 4 is only using the verb "SHOULD" whereas it should > use the verb "SHALL" : > > The AS SHOULD authenticate the caller at the token introspection > endpoint. > > Talking of "an explicit user consent gathered from the resource owner > by the AS" does not make sense. > Either the operation is allowed or is not allowed by the RO, but there > is no "RO consent". > > *About **RFC 7662 (OAuth 2.0 Token Introspection)* > > One might think that the important considerations have already been > provided when issuing RFC 7662 (OAuth 2.0 Token Introspection) > which contains a Privacy considerations section (section 5). > > The third sentence states: > > One method is to transmit user identifiers as opaque > service-specific strings, potentially returning different > identifiers to each protected resource. > > This would mean that the response would not reflect the content of the > token. Furthermore, the RS would not even be informed of such a > transformation. > > The last sentence even states: > > Omitting privacy-sensitive information from an introspection > response is the simplest way of minimizing privacy issues. > > In such a case, the introspection query becomes more or less useless. > > What should have been said in RFC 7662 (OAuth 2.0 Token Introspection) ? > > The fact that using an introspection call can be avoided and should be > avoided for privacy reasons. While "in OAuth 2.0 [RFC6749], > the contents of tokens are opaque to clients", it is not opaque to > RSs. As soon as the RS knows the format of the access token and is able > to validate its security features, this call should be avoided. > > So what should be mentioned in section 9 ? > > The fact that the AS will know exactly when the introspection call has > been made and thus be able to make sure which client > has attempted perform an access to that RS and at which instant of > time. The use of this call allows an AS to track where and when > its clients have indeed presented an issued access token. > > Denis > >> The IESG has received a request from the Web Authorization Protocol WG >> (oauth) to consider the following document: - 'JWT Response for OAuth Token >> Introspection' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits final >> comments on this action. Please send substantive comments to the >> last-call@ietf.org mailing lists by 2020-09-04. Exceptionally, comments may >> be sent toiesg@ietf.org instead. In either case, please retain the beginning >> of the Subject line to allow automated sorting. >> >> Abstract >> >> This specification proposes an additional JSON Web Token (JWT) >> secured response for OAuth 2.0 Token Introspection. >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> _______________________________________________ >> 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 --------------43C05610DF15704654E67A2C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Here is an additional comment:

The text mentions in the Introduction:

   In example is a resource server using verified person data
   to create certificates, which in turn are used to create qualified
   electronic signatures.

The problem is the following: the AS has no way to verify that the User has effectively authorized the RS
to use the JWT Response for such a purpose. A "User Consent" phase for such a usage has not been addressed. 

This concern is identified in RFC 6973 as:

5.2.3.  Secondary Use

   Secondary use is the use of collected information about an individual
   without the individual’s consent for a purpose different from that
   for which the information was collected.  Secondary use may violate
   people’s expectations or desires.  The potential for secondary use
   can generate uncertainty as to how one’s information will be used in
   the future, potentially discouraging information exchange in the
   first place.  Secondary use encompasses any use of data, including
   disclosure.

The progression of this draft is really questionable. The User has currently no way to allow or to disallow this protocol
which is between a RS and an AS.  It would not be reasonable to say that this concern is outside the scope of this draft.

Denis


This draft contains a "Privacy considerations" section (Section 9).
.
The content of this section is as follows:

   The token introspection response can be used to transfer personal
   identifiable information from the AS to the RS.  The AS MUST ensure a
   legal basis exists for the data transfer before any data is released
   to a particular RS.  The way the legal basis is established might
   vary among jurisdictions and MUST consider the legal entities
   involved.

   For example, the classical way to establish the legal basis is by
   explicit user consent gathered from the resource owner by the AS
   during the authorization flow.

   It is also possible that the legal basis is established out of band,
   e.g. in an explicit contract or by the client gathering the resource
   owner’s consent.

   If the AS and the RS belong to the same legal entity (1st party
   scenario), there is potentially no need for an explicit user consent
   but the terms of service and policy of the respective service
   provider MUST be enforced at all times.

   In any case, the AS MUST ensure that the scope of the legal basis is
   enforced throughout the whole process.  The AS MUST retain the scope
   of the legal basis with the access token, e.g. in the scope value,
   and the AS MUST determine the data a resource server is allowed to
   receive based on the resource server’s identity and suitable token
   data, e.g. the scope value.

It is not believed that these explanations are useful, nor sufficient.

Talking a "legal basis" without translating legal constraints into technical constraints is not useful.
Since sensitive information may be returned, the text should say that AS should/must make sure that the requesting RS is indeed
authenticated and allowed to perform this operation.

However, section 4 is only using the verb "SHOULD" whereas it should use the verb "SHALL" :
The AS SHOULD authenticate the caller at the token introspection endpoint.
Talking of "an explicit user consent gathered from the resource owner by the AS" does not make sense.
Either the operation is allowed or is not allowed by the RO, but there is no "RO consent".

About RFC 7662 (OAuth 2.0 Token Introspection)

One might think that the important considerations have already been provided when issuing RFC 7662 (OAuth 2.0 Token Introspection)
which contains a Privacy considerations section (section 5).

The third sentence states:
One method is to transmit user identifiers as opaque service-specific strings, potentially returning different identifiers to each protected resource.
This would mean that the response would not reflect the content of the token. Furthermore, the RS would not even be informed of such a transformation.

The last sentence even states:
Omitting privacy-sensitive information from an introspection response is the simplest way of minimizing privacy issues.
In such a case, the introspection query becomes more or less useless.

What should have been said in RFC 7662 (OAuth 2.0 Token Introspection) ?

The fact that using an introspection call can be avoided and should be avoided for privacy reasons. While "in OAuth 2.0 [RFC6749],
the contents of tokens are opaque to clients", it is not opaque to RSs. As soon as the RS knows the format of the access token and is able
to validate its security features, this call should be avoided.

So what should be mentioned in section 9 ?

The fact that the AS will know exactly when the introspection call has been made and thus be able to make sure which client
has attempted perform an access to that RS and at which instant of time. The use of this call allows an AS to track where and when
its clients have indeed presented an issued access token.

Denis

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'JWT Response for OAuth Token
Introspection'
  <draft-ietf-oauth-jwt-introspection-response-09.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-09-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   This specification proposes an additional JSON Web Token (JWT)
   secured response for OAuth 2.0 Token Introspection.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/


No IPR declarations have been submitted directly on this I-D.

_______________________________________________
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


--------------43C05610DF15704654E67A2C-- From nobody Tue Aug 25 15:01:36 2020 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 97CBA3A0C41 for ; Tue, 25 Aug 2020 15:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 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, 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 jsDGW5DtK-WJ for ; Tue, 25 Aug 2020 15:01:32 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 BC6243A0C40 for ; Tue, 25 Aug 2020 15:01:31 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id v4so56066ljd.0 for ; Tue, 25 Aug 2020 15:01:31 -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=lcgbv7inWdpSKzgNLIZI0kcztvgoQ995AbOE5iod8CY=; b=IFO/jTN/aUZUH0mmIq6zlU50mTzuXMhXgwkscObf56S2pqvUPixrYytU25iky+JM+P gh1K4QU8DZvpBV/vcuOPWplNPqJizUaN/clITkXWC5vYwXEx9ONAWWLNVbcoxcXVdoev vQUwM03bOMyflKoDjLcyQjnuwTIyCarpjvMpKaEX2DhAWIIpNyhPBgAm+7Yw33AY0zBq CNVRHmguEID4T1A9Xrw8EtBZf2UvKYTCaDPXmIQh9W9S7nQYuwRvZU8SzuAiROw2P09A VJUfJkvBF7lSJ4L6fqekH1PfUdLhoHY89V4lU+25hzf3673KQLfzKW1wQpcB2LWf9Opr AaCw== 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=lcgbv7inWdpSKzgNLIZI0kcztvgoQ995AbOE5iod8CY=; b=pyiMkBbSW9/rE7+5R0tCeE86HTFvd2roa7uHVK6ZO6W2i+rChotZkN6B6LdIzhHbKj jA0lQ2Z9r3mnCm7GdfPhTBxURErdL4pmL0oFi2VjkrOT9LsJpaDJRvFJs5Zs8vFCgS1P mB4kv8sOrMU8GaRdvkkpandOiQ7yEWMJUxpVtxODy5RACjJOEvYB8SE8ZkYeHhgoUzwn SjWCaCZXO2IgZO2KJAE3VzlFUQA6ke71IbOMhWTBoSZeiM4i9pehPndA0rEjEFUARWxe m3kmQvsfIEAxOiuxZmM1ZvJu8PPWbfGiBYsDZ+sSIjz5w0zluyJucB58qRbVjY2vk22Q OPPw== X-Gm-Message-State: AOAM530/9LGlLemcVS1QZG9heBl8n0MQOZGkaHr7Usg2ujErrXxTRzhF weFjgI++e0ppU25rARLjU6bwWW0JqYFW2tjMZcGrdihQ15Awx1s4Vge/pc9EIXVQybtL91FQ5Pg g5GdrawEkocmylg== X-Google-Smtp-Source: ABdhPJx26QSLRWFU76Fvzx5gxo5mZBjGrp47tmKLeXEM4dwve7F3TdGxM/7GFh66TWGiAMIpOsDYbC3SOlQ2+iwd8iU= X-Received: by 2002:a05:651c:1291:: with SMTP id 17mr6191252ljc.366.1598392889629; Tue, 25 Aug 2020 15:01:29 -0700 (PDT) MIME-Version: 1.0 References: <7C0FD285-F677-4501-B2FB-9431A59855F6@mit.edu> In-Reply-To: <7C0FD285-F677-4501-B2FB-9431A59855F6@mit.edu> From: Brian Campbell Date: Tue, 25 Aug 2020 16:01:02 -0600 Message-ID: To: Justin Richer Cc: oauth Content-Type: multipart/alternative; boundary="00000000000065f34b05adbad8f6" Archived-At: Subject: Re: [OAUTH-WG] WGLC Review of PAR 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, 25 Aug 2020 22:01:35 -0000 --00000000000065f34b05adbad8f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review and comments Justin. Replies (or attempts thereat) are inline below. On Wed, Aug 19, 2020 at 2:06 PM Justin Richer wrote: > I=E2=80=99ve done a full read through of the PAR specification, and here = are my > notes on it. > > For additional context, I=E2=80=99ve implemented this specification for b= oth a > client and a server in a couple of languages. Overall, I think it=E2=80= =99s in good > shape and it makes sense from a developer=E2=80=99s perspective. I=E2=80= =99ve got a few > comments, some small and some that might need more conversation within th= e > WG, > Always nice to get feedback from implementation experience. Especially when the overall is that it's "in good shape". Throughout: Suggest using =E2=80=9Ccredentialed=E2=80=9D instead of =E2=80= =9Cconfidential=E2=80=9D client, > as introduced in OAuth 2.1 draft. > I'm hesitant to use *new* terminology from the 2.1 draft, which was just recently adopted by the WG, in this document that is written as an extension of OAuth 2.0 and is further along in the process going through WGLC. There's a temporal dependency problem including potential risk of change after the fact. Perhaps this draft could avoid use of the terms and be more explicit and wordy with something like "clients having established authentication credentials with the AS"? > =C2=A71: Suggest the problems list start with changing scopes or swapping > client IDs as scenarios in the first bullet, ACR is an esoteric use case > for many and not in OAuth 2 core, either remove it or put it at the end o= f > the bullet. > Fair suggestion. Will look at reworking it a bit. Suggest the second bullet note who the information needs to be protected > from, at least in passing. It=E2=80=99s not clear from this setup why the > parameters should be confidential, and this is a major motivation for thi= s > work. > Also a fair suggestion. Although there are some subtleties and complexities that I think make this a little tricky to write. Will try though. > Avoid use of phrase =E2=80=9Cso-called=E2=80=9D and just give the name= =E2=80=9CRequest Object=E2=80=9D. > Okay, yeah. I think a moment of terminology frustration slipped into the text there. > =C2=B64: Perhaps overly pedantic but I suggest extending: =E2=80=9Cin = exchange for a > request_uri value usable at the authorization server=E2=80=9D. > I like the pedanticness. > > =C2=B64/5: Alternatively, suggest combining these paragraphs: =E2=80= =9CThis document > complements JAR by providing an interoperable way for the client to push > its authorization request parameters to the authorization server in > exchange for a request_uri usable at the authorization server. The docume= nt > further allows the client to push request objects as specified in JAR in > exchange for a request_uri usable at the authorization server.=E2=80=9D > Yeah, I think that working works better. > =C2=B612: =E2=80=9CThis is directly utilized=E2=80=9D is a little amb= iguous into what it=E2=80=99s > referring to. Would suggest rewording the start as: =E2=80=9CThis early s= tage > client authentication is used by this draft to allow confidential clients= =E2=80=A6=E2=80=9D > or something of that sort. > Makes sense to be less ambiguous there. > > =C2=B613: Not only is POST much harder to use, it=E2=80=99s also opti= onal for the > AS to implement so it can=E2=80=99t be counted on by a client to be avail= able > generally. (To be honest in retrospect we shouldn=E2=80=99t have included= it in > OAuth 2.) > Connect says the AS/OP must support both get and post. But your point on optionality stands with respect to pure OAuth only ASs. Will add something about that to the paragraph. > > =C2=A72: Please provide a reference to JWT client assertion auth here (ei= ther > the assertion RFC or OIDC=E2=80=99s definition of the client auth methods > mentioned). I would also phrase this as direct guidance instead of a > note/aside. > Will do. > > =C2=A72.1: There=E2=80=99s some potential weirdness about client_id here.= Since the > authz request was designed around not having client authentication, that > request requires client_id. However, here the client is authenticating, a= nd > the client_id might be included elsewhere like the Basic header. A > developer might be curious about whether they need to include them twice. > Fair point about the weirdness. Suggestions on some text to preempt curiosity or confusion? My thinking is that the client_id parameter should always be sent so as to conform to the syntax of a regular authz request. But I'll admit that, due to reusing client auth logic, my server implementation won't strictly require client_id when it's included elsewhere like the Basic header. > > =C2=B62: Of necessity, this spec mixes parameters in the authorizatio= n > endpoint and token endpoint registries into a single request. Is there an= y > danger of conflict between them? The registry holds them in one list but > they could possibly have different semantics in both places. > I think that technically such danger does exist but that it's highly unlikely in practice. Especially because the only token endpoint parameters that are relevant to PAR are those that deal with client authentication (currently client_secret, client_assertion, and client_assertion_type). I'm also not sure what can reasonably be done about it given the way the registries are. I guess PAR could update the registration for those three (client_secret, client_assertion, and client_assertion_type) to also indicate authorization request as a usage location with some commentary that it's only for avoiding name collisions. And offer some guidance about doing the same for any future client auth methods being defined. But honestly I'm not sure what, if anything, to do here? And yes it is super unfortunate that client auth and protocol parameters got mixed together in the HTTP body. I didn't cause that situation but I've certainly contributed to it and for that I apologize. > =C2=B66: Does the AS really have "the ability to authenticate and > *authorize* clients=E2=80=9D? I think what we mean here is "the ability t= o > authenticate clients and validate client requests=E2=80=9D, but I=E2=80= =99m not positive of > the intent. > I think the intent is that the AS can check whether a client is authorized to make a particular authorization request (specific scopes, response type, etc.). But checking authorization to request authorization is confusing wording. I think your working is less confusing and still allows for the intent. I'll let Torsten interject if he feels differently as I think he originally wrote the text in question. > > =C2=B67: I=E2=80=99m not sure I buy this example. Even if the clientI= D is managed > externally, the association with a set or pattern of allowed redirect URI= s > is still important, and the AS will need to know what that is. I think th= is > example could lead an AS developer to (erroneously and dangerously) > conclude that they don=E2=80=99t have to check any other values in a requ= est, > including scope and redirect URI. It=E2=80=99s important that DynReg does= n=E2=80=99t > alleviate that issue, but removal of DynReg doesn=E2=80=99t really change= things in > that regard. Suggest removing example or reworking paragraph. > I'm going to have to defer to Torsten on this because, to be honest, I'm not too sure about it myself. I tend to lean towards thinking the draft would be better off without it. > > =C2=A72.2: Is =E2=80=9Cexpires_in=E2=80=9D required? If so, can an AS dec= ide that a request URI > doesn=E2=80=99t expire after a certain amount of time? Related, what does= a =E2=80=9C0=E2=80=9D or > negative value mean, if anything? > Yes, no, and that it's already expired, respectively. I guess anyway. But maybe better to say that it has to be there and is a positive integer value. Will clarify all that. > > I don=E2=80=99t see why a request URI with unguessable values isn=E2= =80=99t a MUST for > one-time-use, is there a reason? > The reason AFAIK was to not be overly prescriptive and allow for eventually consistent or not atomic storage of the data by not strictly requiring the AS to enforce one-time-use. Do you think that's too loose or could be worded/explained differently or better? > > =C2=A72.3: Are the HTTP status codes a normative MAY or just an informati= ve > =E2=80=9Ccan=E2=80=9D as written? > It's meant to be more of an informative =E2=80=9Ccan=E2=80=9D or even just = a "does". It's supposed to just say that the error response looks the same as a token endpoint error response - same JSON and same status code, which is a 400 unless otherwise stated. There have been other similar WGLC comments on this particular text so it's already on the list to reword for clarity. > > =C2=A73: This bit should be normative as follows: "he authorization serve= r MUST > take the following steps beyond the processing rules=E2=80=A6" > > Clean up the tenses and voice of the numbered list, which are > currently inconsistent. > Yep and yep, respectively. > > =C2=A77.2: The AS should also make sure that the new redirect URI is appl= icable > within that client=E2=80=99s domain or policies. So you wouldn=E2=80=99t = want a > legit-but-rogue client registering for someone else=E2=80=99s redirect UR= I in order > to start an attack, for example. I think overall we might need better > guidance around the redirect URI variability feature (which, to be clear, > I=E2=80=99m hugely in favor of =E2=80=94 but OAuth=E2=80=99s assumptions = in the client model make > this trickier to talk about and implement safely, so we need to be extra > careful). > Yeah, I think I follow and agree with you here. I'll try and add some more coverage/guidance on the topic. But if you have any concrete suggestions or text, I'd welcome it. > > =C2=A77.3: As above, is there a reason that this isn=E2=80=99t a MUST? It= =E2=80=99s a temporary > credential representing a request, much like an authorization code in man= y > ways. I don=E2=80=99t see why a legitimate client would use it more than = once, or > why a server would want to allow it for AS-generated values. For > client-supplied request URIs, sure, but not here. > The intent wasn't to allow it to be used more than once. But rather to avoid putting a strict requirement on the AS to enforce one-time-use (and the eventual certification tests that send the same URI twice within milliseconds). If that distinction makes any sense. It is much like an authorization code in many ways including the one-time-use text on code in RFC 6749 being subject to different interpretations :/ I would like to avoid different interpretations here. For better or worse, that's some of the reasoning behind what's there now. But I'm open to changing the normative strength of the statement, if you and other folks in the WG feel it should be more MUSTy. And I'm certainly open to suggestions on better wording/explanation. > > =C2=A7X: Missing privacy considerations section. If anything this spec he= lps > alleviate some privacy concerns by trading values for a reference, but th= e > section is still needed. > Because of that and because it's already discussed to some extent in the body of the document, a separate privacy considerations section didn't seem needed. But we can look at adding a short section that says as much. --=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._ --00000000000065f34b05adbad8f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review and comments J= ustin. Replies (or attempts thereat) are inline below.


On Wed, Aug 19, 2020 at 2:06 PM Justin Richer <jricher@mit.edu> wrote:
<= /div>
I=E2=80=99ve do= ne a full read through of the PAR specification, and here are my notes on i= t.

For additional context, I=E2=80=99ve implemented this= specification for both a client and a server in a couple of languages. Ove= rall, I think it=E2=80=99s in good shape and it makes sense from a develope= r=E2=80=99s perspective. I=E2=80=99ve got a few comments, some small and so= me that might need more conversation within the WG,

Always nice to get feedback from implementation experi= ence. Especially when the overall is that it's "in good shape"= ;.


Throughout: Suggest using =E2=80=9Ccredentialed=E2= =80=9D instead of =E2=80=9Cconfidential=E2=80=9D client, as introduced in O= Auth 2.1 draft.

I'm hesitan= t to use *new* terminology from the 2.1 draft, which was just recently adop= ted by the WG, in this document that is written as an extension of OAuth 2.= 0 and is further along in the process going through WGLC. There's a te= mporal dependency problem including potential risk of change after the fact= .

Perhaps this draft could avoid use of the t= erms and be more explicit and wordy with something like "clients havin= g established authentication credentials with the AS"?
=
=C2=A0
=C2=A0 = =C2=A0Suggest the second bullet note who the information needs to be protec= ted from, at least in passing. It=E2=80=99s not clear from this setup why t= he parameters should be confidential, and this is a major motivation for th= is work.

Also a fair suggestion= . Although there are some subtleties and complexities that I think make thi= s a little tricky to write. Will try though.

= =C2=A0
=C2=A0 =C2=A0Avoid use of phrase =E2=80=9Cso-called=E2=80=9D and ju= st give the name =E2=80=9CRequest Object=E2=80=9D.
=

Okay, yeah. I think a moment of terminology frustration= slipped into the text there.
=C2=A0


=C2= =A0 =C2=A0=C2=B64: Perhaps overly pedantic but I suggest extending: =E2=80= =9Cin exchange for a request_uri value usable at the authorization server= =E2=80=9D.=C2=A0

I like the ped= anticness.
=C2=A0

=C2=A0 =C2=A0=C2=B64/5: Alternatively= , suggest combining these paragraphs: =E2=80=9CThis document complements JA= R by providing an interoperable way for the client to push its authorizatio= n request parameters to the authorization server in exchange for a request_= uri usable at the authorization server. The document further allows the cli= ent to push request objects as specified in JAR in exchange for a request_u= ri usable at the authorization server.=E2=80=9D

=C2=A0Yeah, I think that working works better.
<= div>
=C2=A0
=C2=A0 =C2=A0 =C2=B612: =E2=80=9CThis is directl= y utilized=E2=80=9D is a little ambiguous into what it=E2=80=99s referring = to. Would suggest rewording the start as: =E2=80=9CThis early stage client = authentication is used by this draft to allow confidential clients=E2=80=A6= =E2=80=9D or something of that sort.

Makes sense to be less ambiguous there.
=C2=A0

= =C2=A0 =C2=A0 =C2=B613: Not only is POST much harder to use, it=E2=80=99s a= lso optional for the AS to implement so it can=E2=80=99t be counted on by a= client to be available generally. (To be honest in retrospect we shouldn= =E2=80=99t have included it in OAuth 2.)

<= /div>
Connect says the AS/OP must support both get and post. But your p= oint on optionality stands with respect to pure OAuth only ASs. Will add so= mething about that to the paragraph.
=C2=A0

=C2=A72: Pl= ease provide a reference to JWT client assertion auth here (either the asse= rtion RFC or OIDC=E2=80=99s definition of the client auth methods mentioned= ). I would also phrase this as direct guidance instead of a note/aside.

Will do.
=C2=A0

=C2=A72.1: There=E2=80=99s some potential weirdness about client_id here.= Since the authz request was designed around not having client authenticati= on, that request requires client_id. However, here the client is authentica= ting, and the client_id might be included elsewhere like the Basic header. = A developer might be curious about whether they need to include them twice.=

Fair point about the weirdness= . Suggestions on some text to preempt curiosity or confusion? My thinking i= s that the client_id parameter should always be sent so as to conform to th= e syntax of a regular authz request. But I'll admit that, due to reusin= g client auth logic, my server implementation won't strictly require cl= ient_id when it's included elsewhere like the Basic header.
<= div>=C2=A0

=C2=A0 =C2=A0 =C2=B62: Of necessity, this spec mixes parame= ters in the authorization endpoint and token endpoint registries into a sin= gle request. Is there any danger of conflict between them? The registry hol= ds them in one list but they could possibly have different semantics in bot= h places.

I think that technica= lly such danger does exist but that it's highly unlikely in practice. E= specially because the only token endpoint parameters that are relevant to P= AR are those that deal with client authentication (currently client_secret,= client_assertion, and client_assertion_type). I'm also not sure what c= an reasonably be done about it given the way the registries are. I guess PA= R could update the registration for those three (client_secret, client_asse= rtion, and client_assertion_type) to also indicate authorization request as= a usage location with some commentary that it's only for avoiding name= collisions. And offer some guidance about doing the same for any future cl= ient auth methods being defined. But honestly I'm not sure what, if any= thing, to do here?=C2=A0

And yes i= t is super unfortunate that client auth and protocol parameters got mixed t= ogether in the HTTP body. I didn't cause that situation but I've ce= rtainly contributed to it and for that I apologize.


=C2=A0 =C2=A0 =C2=B66: Does the AS really have "the ability to authe= nticate and authorize clients=E2=80=9D? I think what we mean here is= "the ability to authenticate clients and validate client requests=E2= =80=9D, but I=E2=80=99m not positive of the intent.=C2=A0

I think the intent is that the AS can check whet= her a client is authorized to make a particular authorization request (spec= ific scopes, response type, etc.). But checking authorization to request au= thorization is confusing wording. I think your working is less confusing an= d still allows for the intent.

I'll let T= orsten interject if he feels differently as I think he originally wrote the= text in question.

=C2=A0

=C2=A0 =C2=A0 = =C2=B67: I=E2=80=99m not sure I buy this example. Even if the clientID is m= anaged externally, the association with a set or pattern of allowed redirec= t URIs is still important, and the AS will need to know what that is. I thi= nk this example could lead an AS developer to (erroneously and dangerously)= conclude that they don=E2=80=99t have to check any other values in a reque= st, including scope and redirect URI. It=E2=80=99s important that DynReg do= esn=E2=80=99t alleviate that issue, but removal of DynReg doesn=E2=80=99t r= eally change things in that regard. Suggest removing example or reworking p= aragraph.

I'm going to have= to defer to Torsten on this because, to be honest, I'm not too sure ab= out it myself. I tend to lean towards thinking the draft would be better of= f without it.

=C2=A0

=C2=A72.2: Is =E2= =80=9Cexpires_in=E2=80=9D required? If so, can an AS decide that a request = URI doesn=E2=80=99t expire after a certain amount of time? Related, what do= es a =E2=80=9C0=E2=80=9D or negative value mean, if anything?=C2=A0

Yes, no, and that it's already exp= ired, respectively. I guess anyway. But maybe better to say that it has to = be there and is a positive integer value. Will clarify all that. =C2=A0
=C2=A0
<= div>

=C2=A0 =C2=A0 I don=E2=80=99t see why a request URI= with unguessable values isn=E2=80=99t a MUST for one-time-use, is there a = reason?

The reason AFAIK was to= not be overly prescriptive and allow for eventually consistent or not atom= ic storage of the data by not strictly requiring the AS to enforce one-time= -use. Do you think that's too loose or could be worded/explained differ= ently or better?=C2=A0
=C2=A0

=C2=A72.3: Are the HTTP statu= s codes a normative MAY or just an informative =E2=80=9Ccan=E2=80=9D as wri= tten?

It's meant to be more= of an informative =E2=80=9Ccan=E2=80=9D or even just a "does". I= t's supposed to just say that the error response looks the same as a to= ken endpoint error response - same JSON and same status code, which is a 40= 0 unless otherwise stated. There have been other similar WGLC comments on t= his particular text so it's already on the list to reword for clarity. =
=C2=A0

=C2=A77.2: The AS should also make sure that th= e new redirect URI is applicable within that client=E2=80=99s domain or pol= icies. So you wouldn=E2=80=99t want a legit-but-rogue client registering fo= r someone else=E2=80=99s redirect URI in order to start an attack, for exam= ple. I think overall we might need better guidance around the redirect URI = variability feature (which, to be clear, I=E2=80=99m hugely in favor of =E2= =80=94 but OAuth=E2=80=99s assumptions in the client model make this tricki= er to talk about and implement safely, so we need to be extra careful).

Yeah, I think I follow and agree w= ith you here. I'll try and add some more coverage/guidance on the topic= . But if you have any concrete suggestions or text, I'd welcome it.
=C2=A0
<= div>

=C2=A77.3: As above, is there a reason that this is= n=E2=80=99t a MUST? It=E2=80=99s a temporary credential representing a requ= est, much like an authorization code in many ways. I don=E2=80=99t see why = a legitimate client would use it more than once, or why a server would want= to allow it for AS-generated values. For client-supplied request URIs, sur= e, but not here.

The intent was= n't to allow it to be used more than once. But rather to avoid putting = a strict requirement on the AS to enforce one-time-use (and the eventual ce= rtification tests that send the same URI twice within milliseconds). If tha= t distinction makes any sense. It is much like an authorization code in man= y ways including the one-time-use text on code in RFC 6749 being subject to= different interpretations :/ I would like to avoid different interpretatio= ns here.

For better or worse, that's some = of the reasoning behind what's there now. But I'm open to changing= the normative strength of the statement, if you and other folks in the WG = feel it should be more MUSTy. And I'm certainly open to suggestions on = better wording/explanation.
=C2=A0

=C2=A7X: Missing pri= vacy considerations section. If anything this spec helps alleviate some pri= vacy concerns by trading values for a reference, but the section is still n= eeded.

Because of that and because i= t's already discussed to some extent in the body of the document, a sep= arate privacy considerations section didn't seem needed. But we can loo= k at adding a short section that says as much.

<= 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. --00000000000065f34b05adbad8f6-- From nobody Tue Aug 25 15:57:30 2020 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 D0ECA3A0828 for ; Tue, 25 Aug 2020 15:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 ANsk61tdZTsK for ; Tue, 25 Aug 2020 15:57:26 -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 ABCE93A0822 for ; Tue, 25 Aug 2020 15:57:25 -0700 (PDT) Received: from [192.168.1.11] (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 07PMvNi3021304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Aug 2020 18:57:24 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A3ABFCE7-E476-45A5-912F-656BEBE3AB50" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 25 Aug 2020 18:57:23 -0400 In-Reply-To: Cc: oauth To: Brian Campbell References: <7C0FD285-F677-4501-B2FB-9431A59855F6@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] WGLC Review of PAR 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, 25 Aug 2020 22:57:29 -0000 --Apple-Mail=_A3ABFCE7-E476-45A5-912F-656BEBE3AB50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Brian, just a couple responses inline where it seemed fitting. Thanks = for going through everything! =E2=80=94 Justin > On Aug 25, 2020, at 6:01 PM, Brian Campbell = wrote: >=20 > Thanks for the review and comments Justin. Replies (or attempts = thereat) are inline below. >=20 >=20 > On Wed, Aug 19, 2020 at 2:06 PM Justin Richer > wrote: > I=E2=80=99ve done a full read through of the PAR specification, and = here are my notes on it. >=20 > For additional context, I=E2=80=99ve implemented this specification = for both a client and a server in a couple of languages. Overall, I = think it=E2=80=99s in good shape and it makes sense from a developer=E2=80= =99s perspective. I=E2=80=99ve got a few comments, some small and some = that might need more conversation within the WG, >=20 > Always nice to get feedback from implementation experience. Especially = when the overall is that it's "in good shape". >=20 >=20 > Throughout: Suggest using =E2=80=9Ccredentialed=E2=80=9D instead of = =E2=80=9Cconfidential=E2=80=9D client, as introduced in OAuth 2.1 draft. >=20 > I'm hesitant to use *new* terminology from the 2.1 draft, which was = just recently adopted by the WG, in this document that is written as an = extension of OAuth 2.0 and is further along in the process going through = WGLC. There's a temporal dependency problem including potential risk of = change after the fact.=20 >=20 > Perhaps this draft could avoid use of the terms and be more explicit = and wordy with something like "clients having established authentication = credentials with the AS"?=20 Fair point about the terminology, and while it=E2=80=99s verbose I think = the more precise wording might be warranted here so as not to extend the = problems and confusion with =E2=80=9Cconfidential=E2=80=9D clients as a = term. >=20 > =20 > =C2=A71: Suggest the problems list start with changing scopes or = swapping client IDs as scenarios in the first bullet, ACR is an esoteric = use case for many and not in OAuth 2 core, either remove it or put it at = the end of the bullet. >=20 > Fair suggestion. Will look at reworking it a bit.=20 > =20 >=20 > Suggest the second bullet note who the information needs to be = protected from, at least in passing. It=E2=80=99s not clear from this = setup why the parameters should be confidential, and this is a major = motivation for this work. >=20 > Also a fair suggestion. Although there are some subtleties and = complexities that I think make this a little tricky to write. Will try = though.=20 >=20 > =20 > Avoid use of phrase =E2=80=9Cso-called=E2=80=9D and just give the = name =E2=80=9CRequest Object=E2=80=9D. >=20 > Okay, yeah. I think a moment of terminology frustration slipped into = the text there.=20 > =20 >=20 >=20 > =C2=B64: Perhaps overly pedantic but I suggest extending: =E2=80=9Cin= exchange for a request_uri value usable at the authorization server=E2=80= =9D.=20 >=20 > I like the pedanticness.=20 > =20 >=20 > =C2=B64/5: Alternatively, suggest combining these paragraphs: = =E2=80=9CThis document complements JAR by providing an interoperable way = for the client to push its authorization request parameters to the = authorization server in exchange for a request_uri usable at the = authorization server. The document further allows the client to push = request objects as specified in JAR in exchange for a request_uri usable = at the authorization server.=E2=80=9D >=20 > Yeah, I think that working works better.=20 >=20 > =20 > =C2=B612: =E2=80=9CThis is directly utilized=E2=80=9D is a little = ambiguous into what it=E2=80=99s referring to. Would suggest rewording = the start as: =E2=80=9CThis early stage client authentication is used by = this draft to allow confidential clients=E2=80=A6=E2=80=9D or something = of that sort. >=20 > Makes sense to be less ambiguous there.=20 > =20 >=20 > =C2=B613: Not only is POST much harder to use, it=E2=80=99s also = optional for the AS to implement so it can=E2=80=99t be counted on by a = client to be available generally. (To be honest in retrospect we = shouldn=E2=80=99t have included it in OAuth 2.) >=20 > Connect says the AS/OP must support both get and post. But your point = on optionality stands with respect to pure OAuth only ASs. Will add = something about that to the paragraph.=20 > =20 >=20 > =C2=A72: Please provide a reference to JWT client assertion auth here = (either the assertion RFC or OIDC=E2=80=99s definition of the client = auth methods mentioned). I would also phrase this as direct guidance = instead of a note/aside. >=20 > Will do.=20 > =20 >=20 > =C2=A72.1: There=E2=80=99s some potential weirdness about client_id = here. Since the authz request was designed around not having client = authentication, that request requires client_id. However, here the = client is authenticating, and the client_id might be included elsewhere = like the Basic header. A developer might be curious about whether they = need to include them twice. >=20 > Fair point about the weirdness. Suggestions on some text to preempt = curiosity or confusion? My thinking is that the client_id parameter = should always be sent so as to conform to the syntax of a regular authz = request. But I'll admit that, due to reusing client auth logic, my = server implementation won't strictly require client_id when it's = included elsewhere like the Basic header.=20 > =20 >=20 > =C2=B62: Of necessity, this spec mixes parameters in the = authorization endpoint and token endpoint registries into a single = request. Is there any danger of conflict between them? The registry = holds them in one list but they could possibly have different semantics = in both places. >=20 > I think that technically such danger does exist but that it's highly = unlikely in practice. Especially because the only token endpoint = parameters that are relevant to PAR are those that deal with client = authentication (currently client_secret, client_assertion, and = client_assertion_type). I'm also not sure what can reasonably be done = about it given the way the registries are. I guess PAR could update the = registration for those three (client_secret, client_assertion, and = client_assertion_type) to also indicate authorization request as a usage = location with some commentary that it's only for avoiding name = collisions. And offer some guidance about doing the same for any future = client auth methods being defined. But honestly I'm not sure what, if = anything, to do here? =20 >=20 > And yes it is super unfortunate that client auth and protocol = parameters got mixed together in the HTTP body. I didn't cause that = situation but I've certainly contributed to it and for that I apologize.=20= I think the only perfect solution is to go back in time and fix the = registries with based on the last decade of knowledge in using them. :P=20= For this, I think maybe being very prescriptive about the fact that the = only parameters from the token endpoint that are allowed here are those = used for client authentication and that when they show up, they=E2=80=99re= interpreted as in the token endpoint request not the authorization = endpoint request. Does that work? >=20 >=20 > =C2=B66: Does the AS really have "the ability to authenticate and = authorize clients=E2=80=9D? I think what we mean here is "the ability to = authenticate clients and validate client requests=E2=80=9D, but I=E2=80=99= m not positive of the intent.=20 >=20 > I think the intent is that the AS can check whether a client is = authorized to make a particular authorization request (specific scopes, = response type, etc.). But checking authorization to request = authorization is confusing wording. I think your working is less = confusing and still allows for the intent.=20 >=20 > I'll let Torsten interject if he feels differently as I think he = originally wrote the text in question.=20 >=20 > =20 >=20 > =C2=B67: I=E2=80=99m not sure I buy this example. Even if the = clientID is managed externally, the association with a set or pattern of = allowed redirect URIs is still important, and the AS will need to know = what that is. I think this example could lead an AS developer to = (erroneously and dangerously) conclude that they don=E2=80=99t have to = check any other values in a request, including scope and redirect URI. = It=E2=80=99s important that DynReg doesn=E2=80=99t alleviate that issue, = but removal of DynReg doesn=E2=80=99t really change things in that = regard. Suggest removing example or reworking paragraph. >=20 > I'm going to have to defer to Torsten on this because, to be honest, = I'm not too sure about it myself. I tend to lean towards thinking the = draft would be better off without it.=20 >=20 > =20 >=20 > =C2=A72.2: Is =E2=80=9Cexpires_in=E2=80=9D required? If so, can an AS = decide that a request URI doesn=E2=80=99t expire after a certain amount = of time? Related, what does a =E2=80=9C0=E2=80=9D or negative value = mean, if anything?=20 >=20 > Yes, no, and that it's already expired, respectively. I guess anyway. = But maybe better to say that it has to be there and is a positive = integer value. Will clarify all that. =20 > =20 >=20 > I don=E2=80=99t see why a request URI with unguessable values = isn=E2=80=99t a MUST for one-time-use, is there a reason? >=20 > The reason AFAIK was to not be overly prescriptive and allow for = eventually consistent or not atomic storage of the data by not strictly = requiring the AS to enforce one-time-use. Do you think that's too loose = or could be worded/explained differently or better?=20 I do think it=E2=80=99s too loose and it should be a MUST, and the = methods for enforcing that =E2=80=9CMUST=E2=80=9D are going to vary = based on the deployments and implementations out there.=20 > =20 >=20 > =C2=A72.3: Are the HTTP status codes a normative MAY or just an = informative =E2=80=9Ccan=E2=80=9D as written? >=20 > It's meant to be more of an informative =E2=80=9Ccan=E2=80=9D or even = just a "does". It's supposed to just say that the error response looks = the same as a token endpoint error response - same JSON and same status = code, which is a 400 unless otherwise stated. There have been other = similar WGLC comments on this particular text so it's already on the = list to reword for clarity.=20 > =20 >=20 > =C2=A73: This bit should be normative as follows: "he authorization = server MUST take the following steps beyond the processing rules=E2=80=A6"= >=20 > Clean up the tenses and voice of the numbered list, which are = currently inconsistent. >=20 > Yep and yep, respectively.=20 > =20 >=20 > =C2=A77.2: The AS should also make sure that the new redirect URI is = applicable within that client=E2=80=99s domain or policies. So you = wouldn=E2=80=99t want a legit-but-rogue client registering for someone = else=E2=80=99s redirect URI in order to start an attack, for example. I = think overall we might need better guidance around the redirect URI = variability feature (which, to be clear, I=E2=80=99m hugely in favor of = =E2=80=94 but OAuth=E2=80=99s assumptions in the client model make this = trickier to talk about and implement safely, so we need to be extra = careful). >=20 > Yeah, I think I follow and agree with you here. I'll try and add some = more coverage/guidance on the topic. But if you have any concrete = suggestions or text, I'd welcome it.=20 I=E2=80=99ll see if I can suggest something to help with this.=20 > =20 >=20 > =C2=A77.3: As above, is there a reason that this isn=E2=80=99t a MUST? = It=E2=80=99s a temporary credential representing a request, much like an = authorization code in many ways. I don=E2=80=99t see why a legitimate = client would use it more than once, or why a server would want to allow = it for AS-generated values. For client-supplied request URIs, sure, but = not here. >=20 > The intent wasn't to allow it to be used more than once. But rather to = avoid putting a strict requirement on the AS to enforce one-time-use = (and the eventual certification tests that send the same URI twice = within milliseconds). If that distinction makes any sense. It is much = like an authorization code in many ways including the one-time-use text = on code in RFC 6749 being subject to different interpretations :/ I = would like to avoid different interpretations here. >=20 > For better or worse, that's some of the reasoning behind what's there = now. But I'm open to changing the normative strength of the statement, = if you and other folks in the WG feel it should be more MUSTy. And I'm = certainly open to suggestions on better wording/explanation.=20 Same comment as above.=20 > =20 >=20 > =C2=A7X: Missing privacy considerations section. If anything this spec = helps alleviate some privacy concerns by trading values for a reference, = but the section is still needed. >=20 > Because of that and because it's already discussed to some extent in = the body of the document, a separate privacy considerations section = didn't seem needed. But we can look at adding a short section that says = as much.=20 I think having a specific section for privacy is important and should be = added, even if it=E2=80=99s short. In this case I don=E2=80=99t think it = would actually be all that short since you=E2=80=99re now hiding a lot = of potentially privacy-leaking parameters from the browser. =E2=80=94 Justin >=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. --Apple-Mail=_A3ABFCE7-E476-45A5-912F-656BEBE3AB50 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Brian, just a couple responses inline where it seemed fitting. Thanks = for going through everything!
 =E2=80=94 Justin

On Aug 25, 2020, at 6:01 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks for the review and comments Justin. Replies (or = attempts thereat) are inline below.


On Wed, Aug = 19, 2020 at 2:06 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99ve done a = full read through of the PAR specification, and here are my notes on = it.

For additional = context, I=E2=80=99ve implemented this specification for both a client = and a server in a couple of languages. Overall, I think it=E2=80=99s in = good shape and it makes sense from a developer=E2=80=99s perspective. = I=E2=80=99ve got a few comments, some small and some that might need = more conversation within the WG,

Always nice to get = feedback from implementation experience. Especially when the overall is = that it's "in good shape".


Throughout: Suggest using =E2=80=9Ccredentialed=E2=80=9D = instead of =E2=80=9Cconfidential=E2=80=9D client, as introduced in OAuth = 2.1 draft.

I'm hesitant to use *new* terminology = from the 2.1 draft, which was just recently adopted by the WG, in this = document that is written as an extension of OAuth 2.0 and is further = along in the process going through WGLC. There's a temporal dependency = problem including potential risk of change after the fact.

Perhaps this draft could avoid use of the terms and be more = explicit and wordy with something like "clients having established = authentication credentials with the AS"?

Fair point about the terminology, and while it=E2=80= =99s verbose I think the more precise wording might be warranted here so = as not to extend the problems and confusion with =E2=80=9Cconfidential=E2=80= =9D clients as a term.


 
=C2=A71= : Suggest the problems list start with changing scopes or swapping = client IDs as scenarios in the first bullet, ACR is an esoteric use case = for many and not in OAuth 2 core, either remove it or put it at the end = of the bullet.

Fair suggestion. Will look at reworking = it a bit.
 

  =  Suggest the second bullet note who the information needs to be = protected from, at least in passing. It=E2=80=99s not clear from this = setup why the parameters should be confidential, and this is a major = motivation for this work.

Also a fair suggestion. Although there = are some subtleties and complexities that I think make this a little = tricky to write. Will try though.
 
   Avoid use of phrase = =E2=80=9Cso-called=E2=80=9D and just give the name =E2=80=9CRequest = Object=E2=80=9D.

Okay, yeah. I think a moment of = terminology frustration slipped into the text there.
 


   =C2=B64: Perhaps overly = pedantic but I suggest extending: =E2=80=9Cin exchange for a request_uri = value usable at the authorization = server=E2=80=9D. 

I like the pedanticness.
 

   =C2=B64/5: = Alternatively, suggest combining these paragraphs: =E2=80=9CThis = document complements JAR by providing an interoperable way for the = client to push its authorization request parameters to the authorization = server in exchange for a request_uri usable at the authorization server. = The document further allows the client to push request objects as = specified in JAR in exchange for a request_uri usable at the = authorization server.=E2=80=9D
 Yeah, I think that working works = better.

 
    =C2=B612: =E2=80=9CThis = is directly utilized=E2=80=9D is a little ambiguous into what it=E2=80=99s= referring to. Would suggest rewording the start as: =E2=80=9CThis early = stage client authentication is used by this draft to allow confidential = clients=E2=80=A6=E2=80=9D or something of that = sort.

Makes sense to be less ambiguous there.
 

    =C2=B613: = Not only is POST much harder to use, it=E2=80=99s also optional for the = AS to implement so it can=E2=80=99t be counted on by a client to be = available generally. (To be honest in retrospect we shouldn=E2=80=99t = have included it in OAuth 2.)

Connect says the AS/OP must support = both get and post. But your point on optionality stands with respect to = pure OAuth only ASs. Will add something about that to the paragraph.
 

=C2=A72: Please provide = a reference to JWT client assertion auth here (either the assertion RFC = or OIDC=E2=80=99s definition of the client auth methods mentioned). I = would also phrase this as direct guidance instead of a = note/aside.

Will do.
 

=C2=A72.1: There=E2=80=99s some = potential weirdness about client_id here. Since the authz request was = designed around not having client authentication, that request requires = client_id. However, here the client is authenticating, and the client_id = might be included elsewhere like the Basic header. A developer might be = curious about whether they need to include them = twice.

Fair point about the weirdness. Suggestions on some text to = preempt curiosity or confusion? My thinking is that the client_id = parameter should always be sent so as to conform to the syntax of a = regular authz request. But I'll admit that, due to reusing client auth = logic, my server implementation won't strictly require client_id when = it's included elsewhere like the Basic header.
 

    =C2=B62: Of necessity, = this spec mixes parameters in the authorization endpoint and token = endpoint registries into a single request. Is there any danger of = conflict between them? The registry holds them in one list but they = could possibly have different semantics in both = places.

I think that technically such danger does exist but that it's = highly unlikely in practice. Especially because the only token endpoint = parameters that are relevant to PAR are those that deal with client = authentication (currently client_secret, client_assertion, and = client_assertion_type). I'm also not sure what can reasonably be done = about it given the way the registries are. I guess PAR could update the = registration for those three (client_secret, client_assertion, and = client_assertion_type) to also indicate authorization request as a usage = location with some commentary that it's only for avoiding name = collisions. And offer some guidance about doing the same for any future = client auth methods being defined. But honestly I'm not sure what, if = anything, to do here? 

And yes it is = super unfortunate that client auth and protocol parameters got mixed = together in the HTTP body. I didn't cause that situation but I've = certainly contributed to it and for that I apologize.

I think the only perfect solution is to go back in = time and fix the registries with based on the last decade of knowledge = in using them. :P 

For this, I = think maybe being very prescriptive about the fact that the only = parameters from the token endpoint that are allowed here are those used = for client authentication and that when they show up, they=E2=80=99re = interpreted as in the token endpoint request not the authorization = endpoint request. Does that work?



    =C2=B66: = Does the AS really have "the ability to authenticate and authorize clients=E2=80=9D? I think what we mean here is = "the ability to authenticate clients and validate client requests=E2=80=9D= , but I=E2=80=99m not positive of the = intent. 

I think the intent is that the AS can = check whether a client is authorized to make a particular authorization = request (specific scopes, response type, etc.). But checking = authorization to request authorization is confusing wording. I think = your working is less confusing and still allows for the intent.

I'll= let Torsten interject if he feels differently as I think he originally = wrote the text in question.

 

    =C2=B67: = I=E2=80=99m not sure I buy this example. Even if the clientID is managed = externally, the association with a set or pattern of allowed redirect = URIs is still important, and the AS will need to know what that is. I = think this example could lead an AS developer to (erroneously and = dangerously) conclude that they don=E2=80=99t have to check any other = values in a request, including scope and redirect URI. It=E2=80=99s = important that DynReg doesn=E2=80=99t alleviate that issue, but removal = of DynReg doesn=E2=80=99t really change things in that regard. Suggest = removing example or reworking paragraph.

I'm going to have to = defer to Torsten on this because, to be honest, I'm not too sure about = it myself. I tend to lean towards thinking the draft would be better off = without it.

 

=C2=A72.2: Is =E2=80=9Cexpires_in=E2=80=9D= required? If so, can an AS decide that a request URI doesn=E2=80=99t = expire after a certain amount of time? Related, what does a =E2=80=9C0=E2=80= =9D or negative value mean, if = anything? 

Yes, no, and that it's already expired, = respectively. I guess anyway. But maybe better to say that it has to be = there and is a positive integer value. Will clarify all that.  
 

    I don=E2=80=99= t see why a request URI with unguessable values isn=E2=80=99t a MUST for = one-time-use, is there a reason?

The reason AFAIK was to = not be overly prescriptive and allow for eventually consistent or not = atomic storage of the data by not strictly requiring the AS to enforce = one-time-use. Do you think that's too loose or could be worded/explained = differently or better?  =

I do = think it=E2=80=99s too loose and it should be a MUST, and the methods = for enforcing that =E2=80=9CMUST=E2=80=9D are going to vary based on the = deployments and implementations out there. 

 

=C2=A72.3: Are the HTTP status codes a = normative MAY or just an informative =E2=80=9Ccan=E2=80=9D as = written?

It's meant to be more of an informative =E2=80=9Ccan=E2=80=9D = or even just a "does". It's supposed to just say that the error response = looks the same as a token endpoint error response - same JSON and same = status code, which is a 400 unless otherwise stated. There have been = other similar WGLC comments on this particular text so it's already on = the list to reword for clarity.
 

=C2=A73: This bit should be normative = as follows: "he authorization server MUST take the following steps = beyond the processing rules=E2=80=A6"

    Clean up the tenses and = voice of the numbered list, which are currently = inconsistent.

Yep and yep, respectively.
 

=C2=A77.2: The AS should = also make sure that the new redirect URI is applicable within that = client=E2=80=99s domain or policies. So you wouldn=E2=80=99t want a = legit-but-rogue client registering for someone else=E2=80=99s redirect = URI in order to start an attack, for example. I think overall we might = need better guidance around the redirect URI variability feature (which, = to be clear, I=E2=80=99m hugely in favor of =E2=80=94 but OAuth=E2=80=99s = assumptions in the client model make this trickier to talk about and = implement safely, so we need to be extra = careful).

Yeah, I think I follow and agree with = you here. I'll try and add some more coverage/guidance on the topic. But = if you have any concrete suggestions or text, I'd welcome it.

I=E2=80=99ll see if I can suggest something to = help with this. 

 

=C2=A77.3: As above, is = there a reason that this isn=E2=80=99t a MUST? It=E2=80=99s a temporary = credential representing a request, much like an authorization code in = many ways. I don=E2=80=99t see why a legitimate client would use it more = than once, or why a server would want to allow it for AS-generated = values. For client-supplied request URIs, sure, but not = here.

The intent wasn't to allow it to be used more than once. But = rather to avoid putting a strict requirement on the AS to enforce = one-time-use (and the eventual certification tests that send the same = URI twice within milliseconds). If that distinction makes any sense. It = is much like an authorization code in many ways including the = one-time-use text on code in RFC 6749 being subject to different = interpretations :/ I would like to avoid different interpretations = here.

For better or worse, that's some of the reasoning behind = what's there now. But I'm open to changing the normative strength of = the statement, if you and other folks in the WG feel it should be more = MUSTy. And I'm certainly open to suggestions on better = wording/explanation.

Same comment as above. 

 

=C2=A7X: Missing privacy considerations = section. If anything this spec helps alleviate some privacy concerns by = trading values for a reference, but the section is still = needed.

Because of that and because it's already discussed to = some extent in the body of the document, a separate privacy = considerations section didn't seem needed. But we can look at adding a = short section that says as much.

I= think having a specific section for privacy is important and should be = added, even if it=E2=80=99s short. In this case I don=E2=80=99t think it = would actually be all that short since you=E2=80=99re now hiding a lot = of potentially privacy-leaking parameters from the = browser.

 =E2=80=94 = Justin


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.

= --Apple-Mail=_A3ABFCE7-E476-45A5-912F-656BEBE3AB50-- From nobody Wed Aug 26 04:35:51 2020 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 B7A6F3A1053 for ; Wed, 26 Aug 2020 04:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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 jvsg3TkuRMgy for ; Wed, 26 Aug 2020 04:35:43 -0700 (PDT) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 D6C503A1050 for ; Wed, 26 Aug 2020 04:35:42 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id e23so1593588ejb.4 for ; Wed, 26 Aug 2020 04:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hFqPKaGSsuvKI55VPZBL8+WVw0IlxfxWBQI6bODV++I=; b=55/3JGya8KyLUH1GgjV+0yvDkXSfUqWiaTd3c6hfux80Wash4Rt2CxE954txsYgAEa PdvxelzLFRc+xfZOsYTpuyrdNZJZ1ReZ06pksVMEsrwbyqwWs5YVtkdWSUrEp/Fq9Iuu A2BMm9BD0GnlogylDCXOs5RxC6AVrEvrTX3TcO66W1V0OT2wXjlze3NwLP+9n7BNnAKX WJBApLzSeAMAT5soRp4EBCEQJ957005Vinl9zpUxyEaLH3BUqR26VPSm3xNC4nSFK3iW JoTHXXHTxfmZb9JDNvQ7XX3Oge72ww/W8KOzDYQvrku1MOcTmCoBbqPHxfS5rlwRAfXT Tifg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hFqPKaGSsuvKI55VPZBL8+WVw0IlxfxWBQI6bODV++I=; b=pgTiAAikerUXD4C2K3ofFsIQ7qLfMR2ukQPi4SJWrrydFXDenLI4qrtE+ISfjVJujv uV7pwG/wv5XY7STI2jgw9OGoZs9TtS/hTPrPA1Q+9iZqFP/GUlTax6181W6CweScxbbx cqIj1POR9js4+zgU8Zs+KMNJUjU3y7RW/dZnhZXnd2fmSPlZYPm30UnfNFbHYPTJR9FN a/PHI/Y4dlBMW1wb0HN7aWjWYSuSjaMimQlrnrA0H9XFJZg2iZQfyI3KI2tuMSsEtYBF zWULrZbmMv32h/Ty8/EAuCQuLCXOdxbYA1QvEG4mdwxjlLtSZ2F8//egx6TQ6buRoOlN 9U0Q== X-Gm-Message-State: AOAM531En4xAVHH9OdqlNI37OGH6MZLvvRwHTOx6fiieXyw0df0foiDP 2+Dr3NHdExXoSLHruDUHhxa145YrqPvHYIGN X-Google-Smtp-Source: ABdhPJwZ1oBLldABYW/dbyWUpXkWa4MYgmGz5K7AJEREpf0FMmshSvQxyRCzFkbEpGU0K02gXELurQ== X-Received: by 2002:a17:906:f1d4:: with SMTP id gx20mr15210843ejb.132.1598441741081; Wed, 26 Aug 2020 04:35:41 -0700 (PDT) Received: from p200300eb8f1e2a050c334d31fc069d53.dip0.t-ipconnect.de (p200300eb8f1e2a050c334d31fc069d53.dip0.t-ipconnect.de. [2003:eb:8f1e:2a05:c33:4d31:fc06:9d53]) by smtp.gmail.com with ESMTPSA id q15sm1820366edc.74.2020.08.26.04.35.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Aug 2020 04:35:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Torsten Lodderstedt In-Reply-To: <87dbd1ed-e03d-a00d-e3a2-6f53500ef725@free.fr> Date: Wed, 26 Aug 2020 13:35:38 +0200 Cc: last-call@ietf.org, oauth Content-Transfer-Encoding: quoted-printable Message-Id: References: <159802288149.12737.11570006487802113668@ietfa.amsl.com> <87dbd1ed-e03d-a00d-e3a2-6f53500ef725@free.fr> To: Denis X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 26 Aug 2020 11:35:45 -0000 Hi Denis, > On 25. Aug 2020, at 16:55, Denis wrote: thanks for the review and your feedback.=20 >=20 >=20 > This draft contains a "Privacy considerations" section (Section 9). > . > The content of this section is as follows: >=20 > The token introspection response can be used to transfer personal > identifiable information from the AS to the RS. The AS MUST ensure = a > legal basis exists for the data transfer before any data is = released > to a particular RS. The way the legal basis is established might > vary among jurisdictions and MUST consider the legal entities > involved. >=20 > For example, the classical way to establish the legal basis is by > explicit user consent gathered from the resource owner by the AS > during the authorization flow. >=20 > It is also possible that the legal basis is established out of = band, > e.g. in an explicit contract or by the client gathering the = resource > owner=E2=80=99s consent. >=20 > If the AS and the RS belong to the same legal entity (1st party > scenario), there is potentially no need for an explicit user = consent > but the terms of service and policy of the respective service > provider MUST be enforced at all times. >=20 > In any case, the AS MUST ensure that the scope of the legal basis = is > enforced throughout the whole process. The AS MUST retain the = scope > of the legal basis with the access token, e.g. in the scope value, > and the AS MUST determine the data a resource server is allowed to > receive based on the resource server=E2=80=99s identity and = suitable token > data, e.g. the scope value. >=20 > It is not believed that these explanations are useful, nor sufficient. >=20 > Talking a "legal basis" without translating legal constraints into = technical constraints is not useful. > Since sensitive information may be returned, the text should say that = AS should/must make sure that the requesting RS is indeed=20 > authenticated and allowed to perform this operation. >=20 > However, section 4 is only using the verb "SHOULD" whereas it should = use the verb "SHALL" : > The AS SHOULD authenticate the caller at the token introspection = endpoint. Good point. I added the requirement to authenticate the RS if privacy = sensitive data is released to section 9. I=E2=80=99m reluctant to make = it a general requirement since RFC 7662 also does not require all RSs to = authenticate.=20 > Talking of "an explicit user consent gathered from the resource owner = by the AS" does not make sense. > Either the operation is allowed or is not allowed by the RO, but there = is no "RO consent". I don=E2=80=99t understand your argument. The OAuth authorization flow = is conducted with the resource owner and it is the resource owner who = gives consent to the requested scopes to the AS. What do you mean by = there is no "RO consent=E2=80=9D? >=20 > About RFC 7662 (OAuth 2.0 Token Introspection) >=20 > One might think that the important considerations have already been = provided when issuing RFC 7662 (OAuth 2.0 Token Introspection)=20 > which contains a Privacy considerations section (section 5). >=20 > The third sentence states: > One method is to transmit user identifiers as opaque service-specific = strings, potentially returning different identifiers to each protected = resource. > This would mean that the response would not reflect the content of the = token. Furthermore, the RS would not even be informed of such a = transformation. >=20 > The last sentence even states: > Omitting privacy-sensitive information from an introspection response = is the simplest way of minimizing privacy issues. > In such a case, the introspection query becomes more or less useless. >=20 > What should have been said in RFC 7662 (OAuth 2.0 Token Introspection) = ? >=20 > The fact that using an introspection call can be avoided and should be = avoided for privacy reasons. While "in OAuth 2.0 [RFC6749],=20 > the contents of tokens are opaque to clients", it is not opaque to = RSs. As soon as the RS knows the format of the access token and is able=20= > to validate its security features, this call should be avoided. >=20 > So what should be mentioned in section 9 ? >=20 > The fact that the AS will know exactly when the introspection call has = been made and thus be able to make sure which client=20 > has attempted perform an access to that RS and at which instant of = time. The use of this call allows an AS to track where and when=20 > its clients have indeed presented an issued access token. That is a fact. I don=E2=80=99t think it is an issue per se. Please = explain the privacy implications.=20 Token introspection has several advantages over structured access = tokens, also when it comes to privacy. If one uses a structured access = token in conjunction with different services, then this access token = needs to contain ALL data required to call ALL these services. This = effectively means the services learn more data than required. One could = try to mitigate this by carrying encrypted compartments in the same = token, each of them encrypted with for a certain service. That would be = complex and is not covered by current technical standards. = Introspection, however, allows the AS issue a minimal access token (even = without any id) and mint specific response for the different RSs.=20 best regards, Torsten.=20 >=20 > Denis >=20 >> The IESG has received a request from the Web Authorization Protocol = WG >> (oauth) to consider the following document: - 'JWT Response for OAuth = Token >> Introspection' >> as Proposed = Standard >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits = final >> comments on this action. Please send substantive comments to the >>=20 >> last-call@ietf.org >> mailing lists by 2020-09-04. Exceptionally, comments may >> be sent to=20 >> iesg@ietf.org >> instead. In either case, please retain the beginning >> of the Subject line to allow automated sorting. >>=20 >> Abstract >>=20 >> This specification proposes an additional JSON Web Token (JWT) >> secured response for OAuth 2.0 Token Introspection. >>=20 >> The file can be obtained via >>=20 >> = https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respon= se/ >>=20 >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >> _______________________________________________ >> OAuth mailing list >>=20 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Aug 26 04:38:03 2020 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 D4EEC3A0C3D for ; Wed, 26 Aug 2020 04:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=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 V-kEg_7XibTN for ; Wed, 26 Aug 2020 04:37:55 -0700 (PDT) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 2AC543A0C3B for ; Wed, 26 Aug 2020 04:37:55 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id md23so2369239ejb.6 for ; Wed, 26 Aug 2020 04:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yjltArgugF0P5pcCCisLKkTe4qTmiUzaUMriy8HPlwI=; b=nP/rKyBXc/5J28/VZdRYMJDvXZdrhPSr2cBEyghJimOTFVviV24EH+/XbCk6EofJRy 5cxqiA3i6mD0q7TRhMZfsJEEBTg1aENhhZ1f0oBZdNS5I7gNqQJgBb4cDJOlLGM/7jWm ADuclgnMtADdKJgWfgAnlssRUv1KdXsMRC5yMSlO2+auYXEJc6Z8sFfPYPRB44LlAPlx 8EYJp6GvC1m5Nd8c8F2k6J9r1OXvJ6HKddjyPheoMVoP1BD4YxiNEjz/0mqycmQHcEXm Hvz6xCdvPWZX/DDjaD2IQCR/wsSCpb5oFTw/5KP8xWmsZVvP0KxaTdtaWSyNcCLrg7Df 1aFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yjltArgugF0P5pcCCisLKkTe4qTmiUzaUMriy8HPlwI=; b=sZTWrBXgMQhN7i409hIR3/5LmIa1ndcbZrOWdhQ9AyBvQdvBZMhv5WAo609iZyGd8F UU+tbJy9h25f+2mZwSFQ+jbRIN19e39vUZUukDcQGvZyoUgqbKW1DvKuUbepfpiZ9vTC fRvUooTJwGIr+xrIm7Fb4sPmT69Sj/jUK4PWYv8ivsF7T94kNun7Lxuo0ILNuGLBgLRv UXsgDoXQAR3+A8OWt/f0S6Qu99LVFvHVnTNDsf+yFIK5+cVq5tqeturZueQZy1NOv1v/ lE9Cec/RAoQ6t1D8SKfaltLY50fkzzMfCHN3jHYJ95wetSJ6RPdwSJXXtc2SP7hgy3BD 2sWQ== X-Gm-Message-State: AOAM533SmqTSMA+dSdwxQeu3P5Z8yMa8MollZmIaLwsTUzGjLSYk9HNV dt5K4Rcj0ieJJMW/hHoZxS46xXzBpDTMXW17 X-Google-Smtp-Source: ABdhPJx629zTOuRkPW472OGSg3SWnjpP2dn4qMID6nUGcMvdVfGQ6GQ5yDII9BKB+RsqfmgaVC6c/A== X-Received: by 2002:a17:907:693:: with SMTP id wn19mr5988880ejb.121.1598441873379; Wed, 26 Aug 2020 04:37:53 -0700 (PDT) Received: from p200300eb8f1e2a050c334d31fc069d53.dip0.t-ipconnect.de (p200300eb8f1e2a050c334d31fc069d53.dip0.t-ipconnect.de. [2003:eb:8f1e:2a05:c33:4d31:fc06:9d53]) by smtp.gmail.com with ESMTPSA id r26sm1835614eds.79.2020.08.26.04.37.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Aug 2020 04:37:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Torsten Lodderstedt In-Reply-To: Date: Wed, 26 Aug 2020 13:37:51 +0200 Cc: last-call@ietf.org, oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <159802288149.12737.11570006487802113668@ietfa.amsl.com> <87dbd1ed-e03d-a00d-e3a2-6f53500ef725@free.fr> To: Denis X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 26 Aug 2020 11:37:58 -0000 > On 25. Aug 2020, at 18:26, Denis wrote: >=20 > Here is an additional comment: >=20 > The text mentions in the Introduction:=20 >=20 > In example is a resource server using verified person data > to create certificates, which in turn are used to create qualified > electronic signatures. >=20 > The problem is the following: the AS has no way to verify that the = User has effectively authorized the RS=20 > to use the JWT Response for such a purpose. A "User Consent" phase for = such a usage has not been addressed. =20 Why not? The AS can easily ask the resource owner/user in the = authorization process for consent to transfer certain end user claims to = the RS. As a pre-requisite, the AS needs to determine what data is = transmitted to an RS for a certain scope.=20 >=20 > This concern is identified in RFC 6973 as: >=20 > 5.2.3. Secondary Use >=20 > Secondary use is the use of collected information about an = individual > without the individual=E2=80=99s consent for a purpose different = from that > for which the information was collected. Secondary use may violate > people=E2=80=99s expectations or desires. The potential for = secondary use > can generate uncertainty as to how one=E2=80=99s information will = be used in > the future, potentially discouraging information exchange in the > first place. Secondary use encompasses any use of data, including > disclosure. >=20 > The progression of this draft is really questionable. The User has = currently no way to allow or to disallow this protocol=20 > which is between a RS and an AS. It would not be reasonable to say = that this concern is outside the scope of this draft. > Denis This is no secondary use, it=E2=80=99s the primary use the user = consented with.=20 >=20 >=20 >=20 >> This draft contains a "Privacy considerations" section (Section 9). >> . >> The content of this section is as follows: >>=20 >> The token introspection response can be used to transfer personal >> identifiable information from the AS to the RS. The AS MUST = ensure a >> legal basis exists for the data transfer before any data is = released >> to a particular RS. The way the legal basis is established might >> vary among jurisdictions and MUST consider the legal entities >> involved. >>=20 >> For example, the classical way to establish the legal basis is by >> explicit user consent gathered from the resource owner by the AS >> during the authorization flow. >>=20 >> It is also possible that the legal basis is established out of = band, >> e.g. in an explicit contract or by the client gathering the = resource >> owner=E2=80=99s consent. >>=20 >> If the AS and the RS belong to the same legal entity (1st party >> scenario), there is potentially no need for an explicit user = consent >> but the terms of service and policy of the respective service >> provider MUST be enforced at all times. >>=20 >> In any case, the AS MUST ensure that the scope of the legal basis = is >> enforced throughout the whole process. The AS MUST retain the = scope >> of the legal basis with the access token, e.g. in the scope value, >> and the AS MUST determine the data a resource server is allowed to >> receive based on the resource server=E2=80=99s identity and = suitable token >> data, e.g. the scope value. >>=20 >> It is not believed that these explanations are useful, nor = sufficient. >>=20 >> Talking a "legal basis" without translating legal constraints into = technical constraints is not useful. >> Since sensitive information may be returned, the text should say that = AS should/must make sure that the requesting RS is indeed=20 >> authenticated and allowed to perform this operation. >>=20 >> However, section 4 is only using the verb "SHOULD" whereas it should = use the verb "SHALL" : >> The AS SHOULD authenticate the caller at the token introspection = endpoint. >> Talking of "an explicit user consent gathered from the resource owner = by the AS" does not make sense. >> Either the operation is allowed or is not allowed by the RO, but = there is no "RO consent". >>=20 >> About RFC 7662 (OAuth 2.0 Token Introspection) >>=20 >> One might think that the important considerations have already been = provided when issuing RFC 7662 (OAuth 2.0 Token Introspection)=20 >> which contains a Privacy considerations section (section 5). >>=20 >> The third sentence states: >> One method is to transmit user identifiers as opaque service-specific = strings, potentially returning different identifiers to each protected = resource. >> This would mean that the response would not reflect the content of = the token. Furthermore, the RS would not even be informed of such a = transformation. >>=20 >> The last sentence even states: >> Omitting privacy-sensitive information from an introspection response = is the simplest way of minimizing privacy issues. >> In such a case, the introspection query becomes more or less useless. >>=20 >> What should have been said in RFC 7662 (OAuth 2.0 Token = Introspection) ? >>=20 >> The fact that using an introspection call can be avoided and should = be avoided for privacy reasons. While "in OAuth 2.0 [RFC6749],=20 >> the contents of tokens are opaque to clients", it is not opaque to = RSs. As soon as the RS knows the format of the access token and is able=20= >> to validate its security features, this call should be avoided. >>=20 >> So what should be mentioned in section 9 ? >>=20 >> The fact that the AS will know exactly when the introspection call = has been made and thus be able to make sure which client=20 >> has attempted perform an access to that RS and at which instant of = time. The use of this call allows an AS to track where and when=20 >> its clients have indeed presented an issued access token. >>=20 >> Denis >>=20 >>> The IESG has received a request from the Web Authorization Protocol = WG >>> (oauth) to consider the following document: - 'JWT Response for = OAuth Token >>> Introspection' >>> as Proposed = Standard >>>=20 >>> The IESG plans to make a decision in the next few weeks, and = solicits final >>> comments on this action. Please send substantive comments to the >>>=20 >>> last-call@ietf.org >>> mailing lists by 2020-09-04. Exceptionally, comments may >>> be sent to=20 >>> iesg@ietf.org >>> instead. In either case, please retain the beginning >>> of the Subject line to allow automated sorting. >>>=20 >>> Abstract >>>=20 >>> This specification proposes an additional JSON Web Token (JWT) >>> secured response for OAuth 2.0 Token Introspection. >>>=20 >>> The file can be obtained via >>>=20 >>> = https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respon= se/ >>>=20 >>>=20 >>>=20 >>> No IPR declarations have been submitted directly on this I-D. >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>>=20 >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >>=20 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Aug 26 05:26:32 2020 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 E41E83A124E for ; Wed, 26 Aug 2020 05:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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 YcW6hWLF9a6h for ; Wed, 26 Aug 2020 05:26:29 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 3E7E73A124B for ; Wed, 26 Aug 2020 05:26:29 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id c8so1547562edn.8 for ; Wed, 26 Aug 2020 05:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2tlZrXmf2yyXsRglOEC9N0qFCH7Q6XKUV9KdQNFyFgU=; b=dp3mO9fU6N1fl0WvEklpbamsBu90TxBKABjy9HefRLJWB1Mxtuv7iSO1+DfaqZtKQw J81m5wddOeDbthuc46De9nTveV+0heCTnc0eEees2GbBZqDeMhSEqWPZSxpCopG7Bo3R FfvmBAXlKGtKacuDnAbKolZ823B3SzZJzM74GNqF/R6iAcnLMZnZb0FSxIHaCj0j5NoJ 9ZHXPkiZYJlPWkHRpq6JjQru7RwIPXIJ6AI96913JXryZ64oZtat2c4lKfbq/dLJQhnD h+lV+tAIwrQwAkpUTisFrcYcHFaoVWHH4QzFX70yCx39w4P+bB2ezkcZUPuz1Y7ytmnQ AZ0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2tlZrXmf2yyXsRglOEC9N0qFCH7Q6XKUV9KdQNFyFgU=; b=TB3J8wLYBUFL3MLmMDZqZDrRO/aGO1bxykI/vJ6jrJ+KmvLWOCqjR4tCKCoM5q7FxM WDda2ks+0GN9SsQBWA+4U63kH7oZrejeZGvBy8rF93GNXwD85Vo4FJWLw+KMPTb4AUQq lGK6FWVlpSMOGcs8es7puToXJ3juflM1tezr24qBuAG+bxwCwp9DFa1SJpDiRwWVNP16 GYu8gdp5YT7J4jrSG1J0VslwkTq1VxeP80+7SEap8FXL4eRkzFahyS+dUe7gYW9mQ8ju kId/4FlHN9dU9QsojRqqJlBTItxW9hM1xKvrKdMSSniIItEHV5DiGWbf5FPGBSmGrrpc QH2w== X-Gm-Message-State: AOAM530Y/uZw6khECZF9ZqOSkgGcs2FvyI54r3XX0eHzRt3rlGgs5/rO y9u2j74i4zMzZd4W7MgfYf9oBA== X-Google-Smtp-Source: ABdhPJwVb11BqO28qb4v89aDo2vaFqZpJ4C3OaVwwL3SYNlBrB07+y3KPFCv0DyzQZ55m7V9OvvEOw== X-Received: by 2002:aa7:cc14:: with SMTP id q20mr1505809edt.309.1598444787463; Wed, 26 Aug 2020 05:26:27 -0700 (PDT) Received: from p200300eb8f1e2a050c334d31fc069d53.dip0.t-ipconnect.de (p200300eb8f1e2a050c334d31fc069d53.dip0.t-ipconnect.de. [2003:eb:8f1e:2a05:c33:4d31:fc06:9d53]) by smtp.gmail.com with ESMTPSA id p9sm1778230ejg.120.2020.08.26.05.26.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Aug 2020 05:26:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Torsten Lodderstedt In-Reply-To: <8a42a78a8a3645f793b0991e4dd5bb34@cert.org> Date: Wed, 26 Aug 2020 14:26:25 +0200 Cc: "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <428325A0-611A-4E3B-943A-4D848F7BB038@lodderstedt.net> References: <8a42a78a8a3645f793b0991e4dd5bb34@cert.org> To: Roman Danyliw X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-introspection-response-09 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, 26 Aug 2020 12:26:31 -0000 Hi Roman,=20 thanks for your review feedback.=20 > On 21. Aug 2020, at 16:43, Roman Danyliw wrote: >=20 > Hi! >=20 > I conducted an another AD review of = draft-ietf-oauth-jwt-introspection-response-09. As background, -07 of = this document went to IESG Review and the document was brought back to = the WG to address the DISCUSS points. =20 >=20 > Below is my feedback which can be addressed concurrently with IETF LC. >=20 > ** Section 5. I want to clarify what are the permissible members of = token_introspection. The two relevant text snippets seem to be: >=20 > (a) "token_introspection A JSON object containing the members of the > token introspection response, as specified in the "OAuth > Token Introspection Response" registry established by > [RFC7662] as well as other members." >=20 > (b) "Claims from the "JSON Web Token Claims" registry that are > commonly used in [OpenID.Core] and can be applied to the > resource owner MAY be included as members in the > "token_introspection" claim." >=20 > -- Per (a), Recommend citing the IANA sub-registry directly -- = https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#t= oken-introspection-response (and not the "as specified in the "OAuth = Token Introspection Response" registry established by [RFC7662]") done=20 >=20 > -- Per (a), "... as well as other members", what members is this = referencing? Is that (b)? Recommend being clear upfront on which exact = registries are the sources of valid members. I reworked the whole paragraph (hrefs for registries not shown).=20 As specified in section 2.2. of [RFC7662], specific implementations MAY = extend the token introspection response with service-specific claims. In = the context of this specification, such claims will be added as = top-level members of the token_introspection claim. Response names = intended to be used across domains MUST be registered in the OAuth Token = Introspection Response registry defined by [RFC7662]. In addition, = claims from the JSON Web Token Claims registry established by [RFC7519] = MAY be included as members in the token_introspection claim. They can = serve to convey the privileges delegated to the client, to identify the = resource owner or to provide a required contact detail, such as an = e-Mail address or phone number. When transmitting such claims the AS = acts as an identity provider in regard to the RS. The AS determines = based on its RS-specific policy what claims about the resource owner to = return in the token introspection response. Does this work for you? >=20 > -- Per (b), "... commonly used in [OpenId.Core]", what are those = specifically? Is that claims registered in = https://www.iana.org/assignments/jwt/jwt.xhtml#claims whose reference is = [OpenID Connect Core 1.0]? Recommend being unambiguous in which claims = are permitted by pointing the IANA registry. >=20 > -- If I'm understanding right that the source comes either from = oauth-parameters.xhtml#token-introspection-response or jwt.xhtml#claims, = what happens if it isn't one of those? Every implementation is also free to use their own specific claims. This = is defined in section 2.2. of RFC=20 >=20 > ** Section 5. Per " The AS MUST ensure the release of any = privacy-sensitive data is legally based", recommend also including a = forward reference to Section 9 done best regards, Torsten.=20 >=20 > Regards, > Roman >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Aug 26 09:52:42 2020 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 EC6033A16C6; Wed, 26 Aug 2020 09:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 aMYA7ZIR1uDX; Wed, 26 Aug 2020 09:52:39 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 3FEF83A16C3; Wed, 26 Aug 2020 09:52:39 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id t23so3178663ljc.3; Wed, 26 Aug 2020 09:52: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=nwjWryur4YNGdhTBRFDZ+5JibJos55qQFd7EsDn8WTQ=; b=RiUWg4LoSNe9Ikb5WBSSH1E0ALd50BxXL0XaIe0T2XzGYjq49S0Zpm/swxjC0BCVe7 uw7opx2Qpybobm+Wu7R2EFCj79Ej/3k277DKKbXT8mNDprmVOvW4wSBvAjYLH5tpYzOv h2ujZaVQdDrhrVpXOsO3pcaVOW3U0K6luKgojBxaE+RkmwhnPjO1YDTAwHLAr4Fpm0oH UwzYTKJmi10D9f7GN1MFMspxa/NmuJ8AVK/UvfryPSSf7KfXW53o8rJShQjc8lcnl/Yy vIEtf6rVNvdz6ff602biCZYwRwKwy9m+zXrqcK/ecOif6AMLS1eukfGG48bqy/QfyGJr Ra4Q== 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=nwjWryur4YNGdhTBRFDZ+5JibJos55qQFd7EsDn8WTQ=; b=kNGTZAIcNaH6PHSRKOsjbP/UyOknAQSHdR3CclnpjItMjiSSczrzX+IQ9gLGjDtOPm GJVvSmV1D8nYnU7Y0pvGCKKDSXsrUjO04JW5REFb4uAgN7KqnXZqXxUXORFt6VeP2Ryu XTRkwAzXgyCq+wMBBNVnrzdceIBbJmb2ImLhMwR3r1i/LhlxGw5hW7zr4Q/UjR0eXhc5 MrKf5SGxbA5F4fu54d1afqxHQy+w07BiLWU0vVS3n61SjPtkToJ7qn0E+OjjQXq96vvp 0iKfvlJq0RRmdjcDWBJN7xbkXMQ0hd0g3WFgG7BuybsnNQFLKhuLf01d8JohHAGa3zxu Ur+w== X-Gm-Message-State: AOAM5305JM12B0FlyZjJ98EWWoFvvsZ/W5XGS4lM3CV95lAvCsj19YPl nXfntqWC97feOSasgKswJrff2El+LvlyGaeJnik= X-Google-Smtp-Source: ABdhPJxi+yYaCCrtel5BBqhWKdAx9WJeEU7eJzghDbyLalXl3UtuV9AAxXMshzxckK/FefARepkID0Th9WPfFm1rFX4= X-Received: by 2002:a2e:b0db:: with SMTP id g27mr8073692ljl.69.1598460757035; Wed, 26 Aug 2020 09:52:37 -0700 (PDT) MIME-Version: 1.0 References: <159802288149.12737.11570006487802113668@ietfa.amsl.com> <87dbd1ed-e03d-a00d-e3a2-6f53500ef725@free.fr> In-Reply-To: From: Dick Hardt Date: Wed, 26 Aug 2020 09:52:00 -0700 Message-ID: To: Torsten Lodderstedt Cc: Denis , last-call@ietf.org, oauth Content-Type: multipart/alternative; boundary="0000000000009c521505adcaa520" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 26 Aug 2020 16:52:41 -0000 --0000000000009c521505adcaa520 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt wrote: > Hi Denis, > > > On 25. Aug 2020, at 16:55, Denis wrote: > > > The fact that the AS will know exactly when the introspection call has > been made and thus be able to make sure which client > > has attempted perform an access to that RS and at which instant of time= . > The use of this call allows an AS to track where and when > > its clients have indeed presented an issued access token. > > That is a fact. I don=E2=80=99t think it is an issue per se. Please expla= in the > privacy implications. > As I see it, the privacy implication is that the AS knows *when* the client (and potentially the user) is accessing the RS, which is also an indication of *when* the user is using the client. I think including this implication would be important to have in a Privacy Considerations section. /Dick =E1=90=A7 --0000000000009c521505adcaa520 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
3D""= =E1=90=A7
--0000000000009c521505adcaa520-- From nobody Wed Aug 26 12:06:38 2020 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 08F153A0763; Wed, 26 Aug 2020 12:06:29 -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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 AjKK-0K6Hfcm; Wed, 26 Aug 2020 12:06:27 -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 6D93E3A0766; Wed, 26 Aug 2020 12:06:27 -0700 (PDT) Received: from [192.168.1.11] (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 07QJ6OEu027978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 Aug 2020 15:06:24 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_212EF0BE-FC34-4AAF-835A-5E90539B21CA" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 26 Aug 2020 15:06:23 -0400 In-Reply-To: Cc: Torsten Lodderstedt , last-call@ietf.org, oauth To: Dick Hardt References: <159802288149.12737.11570006487802113668@ietfa.amsl.com> <87dbd1ed-e03d-a00d-e3a2-6f53500ef725@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 26 Aug 2020 19:06:29 -0000 --Apple-Mail=_212EF0BE-FC34-4AAF-835A-5E90539B21CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would argue that by the nature of OAuth tokens not being bound to user = presence or sessions, it=E2=80=99s not an indication that the user is = present necessarily, unless you know something additional about the = nature of the client. But it does tell the AS when the client is active = for a particular AS, which in some cases is a privacy concern and in = others it=E2=80=99s a signal into the AS for keeping an eye out for = aberrant behavior that a single RS couldn=E2=80=99t detect. This is all a general implication of the introspection process, and not = unique to this draft. That said, it=E2=80=99s an aspect of privacy that = we did not cover in the considerations for RFC7662, but I don=E2=80=99t = know if it=E2=80=99s appropriate to add such a general consideration = here. =E2=80=94 Justin > On Aug 26, 2020, at 12:52 PM, Dick Hardt wrote: >=20 >=20 >=20 > On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt = > wrote: > Hi Denis, >=20 > > On 25. Aug 2020, at 16:55, Denis > wrote: >=20 > > The fact that the AS will know exactly when the introspection call = has been made and thus be able to make sure which client=20 > > has attempted perform an access to that RS and at which instant of = time. The use of this call allows an AS to track where and when=20 > > its clients have indeed presented an issued access token. >=20 > That is a fact. I don=E2=80=99t think it is an issue per se. Please = explain the privacy implications.=20 >=20 > As I see it, the privacy implication is that the AS knows when the = client (and potentially the user) is accessing the RS, which is also an = indication of when the user is using the client. >=20 > I think including this implication would be important to have in a = Privacy Considerations section. >=20 > /Dick > =E1=90=A7 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_212EF0BE-FC34-4AAF-835A-5E90539B21CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = would argue that by the nature of OAuth tokens not being bound to user = presence or sessions, it=E2=80=99s not an indication that the user is = present necessarily, unless you know something additional about the = nature of the client. But it does tell the AS when the client is active = for a particular AS, which in some cases is a privacy concern and in = others it=E2=80=99s a signal into the AS for keeping an eye out for = aberrant behavior that a single RS couldn=E2=80=99t detect.

This is all a general = implication of the introspection process, and not unique to this draft. = That said, it=E2=80=99s an aspect of privacy that we did not cover in = the considerations for RFC7662, but I don=E2=80=99t know if it=E2=80=99s = appropriate to add such a general consideration here.

 =E2=80=94 Justin

On Aug 26, 2020, at 12:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Wed, Aug 26, 2020 at 4:37 AM Torsten = Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
Hi Denis,

> On 25. Aug 2020, at 16:55, Denis <denis.ietf@free.fr> wrote:

= > The fact that the AS will know exactly when the introspection call = has been made and thus be able to make sure which client
> has attempted perform an access to that RS and at which instant of = time. The use of this call allows an AS to track where and when
> its clients have indeed presented an issued access token.

That is a fact. I don=E2=80=99t think it is an issue per se. Please = explain the privacy implications.

As I see it, the privacy = implication is that the AS knows when the client (and = potentially the user) is accessing the RS, which is also an indication = of when the user is using the client.

I think including this = implication would be important to have in a Privacy Considerations = section.

/Dick
3D""=E1=90=A7
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_212EF0BE-FC34-4AAF-835A-5E90539B21CA-- From nobody Wed Aug 26 13:05:20 2020 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 8BC203A0AE5 for ; Wed, 26 Aug 2020 13:05:19 -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 G11Z869JevvN for ; Wed, 26 Aug 2020 13:05:16 -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 50D6D3A0ABB for ; Wed, 26 Aug 2020 13:05:16 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id r13so393189ljm.0 for ; Wed, 26 Aug 2020 13:05:16 -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=Ctr/Ei5zZWU4HOKyR10CmFCA2dH+cBqJJbpLwzq5bYQ=; b=dVzdCC/6U5nbfLtie2owsrXH2poQvNX5Y9WX5ZxlpztS7WqXDbu+up8fa+j/l7WWts 2+TtgdD35rKXP17ENO1WR3jeJBNxNtF9B1fWQ7CWxf64SQ+cP5Js5emRAC2smVx37rBt o41AuUiWejscr3bXEOoPzcB/JtECQozw9K7q4/ri5s2aDGOFS9fMwHbEl1qYoBWyy5jy dQpNS46XfjYYdJEEhG9duGIHpaOM58vQ3B3bLV1ioMRgkYBXn4I7sA+qo2FlSIl9+Tdu BhB3l8KFRH3Hc6m2ATWseCCZuWlFoqqbquUK/DynQ4b8KJlwjpX1oZU66iutXMXqbhjE 06Lg== 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=Ctr/Ei5zZWU4HOKyR10CmFCA2dH+cBqJJbpLwzq5bYQ=; b=kf3Vb7FmI+JkhaLDHLsGod79Gp7vKxmKa8Uei6TB9j3wI7v1M4EjPOPcAMxKOIg3Vk OdI8eDp/KklLycEDRsfmM5uA9L90Hhj58J2LhYHmJghYsF1mld904PbQ5pZcyTeP0ekJ a80o148tgmFJHrGFpqMTK/tKMyKN/+tL+m7FNv0D0pp/VxP0PXPGCUkLJ3HR7BwICpd9 X7jSd0YuUGujG8t/Or47sS7vKeFHdmSVFs5a8BMMAUgtJilYhC1+fS/RLy+w9CefE2/s TbI7UHK8qgnI85qZ6f1NAJUieCTTrBo3alG6ASCCvYUVslJPQjEUKguAOKnpEW/9utuW 3YrA== X-Gm-Message-State: AOAM531IVNzLZQdAHNXwm1I0hWoHC1FUaF3lB/8b/Oh56Z6bmDivAVdt v8urFAZ+yzt04v1IGOrPrypx50Bv40+0TcbkW29/9cMeMu3BhVmmnBHuxjkSZcNR1sAMkgcXndW 9ob+HQyUaD91waQ== X-Google-Smtp-Source: ABdhPJzeng9Op0SPGwC0wv0+qLUUd0MQu6IwAXcyK2hsKIx71jaP29VVf+uGfbbF4gKb0r4vdilwSDemNF3mYZN6csk= X-Received: by 2002:a2e:390f:: with SMTP id g15mr7236203lja.280.1598472314043; Wed, 26 Aug 2020 13:05:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Wed, 26 Aug 2020 14:04:47 -0600 Message-ID: To: Neil Madden Cc: oauth Content-Type: multipart/alternative; boundary="000000000000766cf305adcd5691" Archived-At: Subject: Re: [OAUTH-WG] WGLC review of PAR 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, 26 Aug 2020 20:05:20 -0000 --000000000000766cf305adcd5691 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Neil. Appreciate the review and feedback. My attempts at responses are inline below. On Thu, Aug 20, 2020 at 5:30 AM Neil Madden wrote: > As promised in the last interim meeting, I=E2=80=99ve reviewed the curren= t (03) > draft-ietf-oauth-par document. Overall it looks close to ready to me, wit= h > mostly minor comments and one security-relevant comment on section 2.1 th= at > should be discussed further, and one additional proposed security > consideration: > > Abstract: > The wording here could be improved - =E2=80=9Callows clients to push an > authorization request [=E2=80=A6] used as a reference to the data in a su= bsequent > authorization request.=E2=80=9D Both the pushed data and the call to the > authorization endpoint are referred to as an =E2=80=9Cauthorization reque= st=E2=80=9D. Maybe > change the second usage to =E2=80=9Cin a subsequent call to the authoriza= tion > endpoint=E2=80=9D. > Makes sense. > > Section 1: > The introductory part here is quite long. Maybe adding a new sub-heading > before the example would make it flow better. > Will look at breaking it up. > > The end of the introduction uses the acronym =E2=80=9CPAR=E2=80=9D for th= e first time, but > never explicitly defines it. > Will fix. > > I agree with Justin that ACR is not the best example to lead with. If it > stays there should be a reference to OIDC to explain what this means. > Yup. > > The paragraph that begins =E2=80=9CIt also allows clients to push the for= m encoded > =E2=80=A6=E2=80=9D is confusing because the use of =E2=80=9Calso=E2=80=9D= suggests this is different from > the previous paragraph, but it seems to actually be saying the same thing= ? > Yeah, that is rather awkward because it is the same thing. Will fix. > > =E2=80=9C[=E2=80=A6] but it also allows clients requiring > > an even higher security level, especially cryptographically confirmed > non-repudiation, to explicitly adopt JWT-based request objects=E2=80= =9D > > > The =E2=80=9Cbut=E2=80=9D should be an =E2=80=9Cand=E2=80=9D in this para= graph. It=E2=80=99s also not clear what is being said here - isn=E2=80=99t = JAR what provides JWT-based request objects? > > Yeah, JAR defines JWT-based request objects and PAR allows for their use by sending the 'request' parameter to the PAR endpoint. Will try and make that more clear. > > The paragraph beginning =E2=80=9CAs a further benefit, =E2=80=A6=E2=80=9D= is a little bit of a Columbo moment (=E2=80=9CJust one more thing=E2=80=A6= =E2=80=9D) at the end of the introduction. Maybe move this as another bulle= t point at the start of the section. The following paragraph can then be re= written as =E2=80=9CThe increased confidence in the identity of the client = during the authorization process allows confidential clients to provide a d= ifferent redirect_uri on every request. [=E2=80=A6]=E2=80=9D > > Agree with the sentiment here and will endeavor to rework things along the lines of the suggestion. > Section 2: > > The 3rd paragraph contains statements like > > The endpoint also supports sending all authorization > > request parameters as request object according to > [I-D.ietf-oauth-jwsreq ]. > > presumably this is not a normative requirement that any PAR implementatio= n > has to also support JAR, or is it? Maybe change the wording to =E2=80=9CM= AY also > support =E2=80=A6=E2=80=9D. > Interesting question. PAR has a normative reference to JAR for the request_uri parameter at the authz endpoint. But does that necessitate that every PAR implementation also has to support all of JAR? I'm thinking probably not. I mean, different but related, an AS PAR implementation might legitimately support the request_uri parameter with URI values that it creates but not support the more general retrieval of arbitrary URIs. In the same vein, it seems legit and still useful to support PAR without also supporting request object JWTs. So yeah, I think changing this to MAY or something similar would be appropriate. > > The first mention of =E2=80=9Ctoken_endpoint_auth_method=E2=80=9D and cli= ent metadata > should have a reference to RFC 7591 - currently it=E2=80=99s only referen= ced later > in section 2.1. > Will fix. 2.1: > I=E2=80=99m a little bit wary of the relaxing of the redirect_uri process= ing > rules, because this removes a layer of defence in depth. With the current > requirement for pre-registered URIs an attacker needs to compromise the > redirect endpoint *and* the client credentials in order to steal an > authorization code and use it. With this change, compromising the client > credentials alone would be enough. If the use-case is specifically in a P= KI > environment, could the redirect_uri be baked into the cert? Maybe this > use-case could be better addressed in a separate draft. > I agree that the specifics of a PKI type environment use-case would be better in a separate draft or profile somewhere. And do plan to add some more considerations around the possibility of relaxed redirect_uri validation. 2.2: > The definition of =E2=80=9Cexpires_in=E2=80=9D as a "JSON number" suggest= s that > fractional/floating-point values are allowed. Presumably this is intended > to be an integer? > Yes and I need to clarify that it's a positive integer. > Is there a recommended minimum/maximum? Suggested wording: > > =3D=3D=3D > > * "expires_in" : A JSON number that represents the lifetime of the > request URI in seconds as a positive integer. The lifetime SHOULD > > be at least 5 seconds and at most 600 seconds, but other values are > > permitted at the discretion of the authorization server. > > =3D=3D=3D > > Those values are fairly arbitrary - 5 seconds seems a reasonable lower > bound for a client with a bad network connection, and 10 minutes seems mo= re > than adequate upper bound for the typical uses. > Arbitrary, yes. But also pretty reasonable. I'm not too keen on using arbitrary values with normative language, however, even if reasonable. I think we could work them in with slightly different language something like, "for example, at least 5 seconds but at most 600". > > 3: > I confirmed that the request JWT verifies with the given JWK using our > internal JWT library :-) > Yay for interoperability! I produced those using a different JWT library :) 5: > =E2=80=9Crequire_pushed_authorization_requests=E2=80=9D might be better > named =E2=80=9Crequires_pushed_authorization_requests=E2=80=9D given that= it is describing > the server=E2=80=99s policy rather than telling the client to require the= m, but > this is a really pedantic point. Same for the client metadata in section = 6. > Fair point but I don't think sufficient to warrant a change to a protocol parameter name at this point. 7: > I would like to propose an additional security consideration, with the > following wording: > > =3D=3D=3D > 7.5. Request URI swapping > > An attacker could capture the request URI from one request and then > substitute it into a different authorization request. For example, in the > context of OpenID Connect, an attacker could replace a request URI asking > for a high level of authentication assurance with one that requires a low= er > level of assurance. Clients SHOULD make use of PKCE, a unique =E2=80=9Cst= ate" > parameter, or the OIDC =E2=80=9Cnonce=E2=80=9D parameter in the pushed re= quest object to > prevent this attack. > =3D=3D=3D > Thanks. Will incorporate (with added refs and minor tweaks). I'm wondering if there's a good example that isn't OpenID Connect though? Just thinking something OAuth only might be more accessible to most readers (similar to what you and Justin pointed out that the ACR example earlier in the draft may not be the best). --=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._ --000000000000766cf305adcd5691 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Neil. Appreciate the review and feedback. My a= ttempts at responses are inline below.


On Thu, Aug 20, 2= 020 at 5:30 AM Neil Madden <neil.madden@forgerock.com> wrote:
As promised in the last in= terim meeting, I=E2=80=99ve reviewed the current (03) draft-ietf-oauth-par = document. Overall it looks close to ready to me, with mostly minor comments= and one security-relevant comment on section 2.1 that should be discussed = further, and one additional proposed security consideration:

=
Abstract:
The wording here could be improved - =E2=80=9Callo= ws clients to push an authorization request [=E2=80=A6] used as a reference= to the data in a subsequent authorization request.=E2=80=9D Both the pushe= d data and the call to the authorization endpoint are referred to as an =E2= =80=9Cauthorization request=E2=80=9D. Maybe change the second usage to =E2= =80=9Cin a subsequent call to the authorization endpoint=E2=80=9D.

Makes sense.
=C2=A0

Section 1:
The introductory part here is quite long. Maybe addin= g a new sub-heading before the example would make it flow better.

Will look at breaking it up.
<= div>=C2=A0

The end of the introduction uses the acronym =E2=80=9CPAR= =E2=80=9D for the first time, but never explicitly defines it.
<= /blockquote>

Will fix.
=C2=A0

I agre= e with Justin that ACR is not the best example to lead with. If it stays th= ere should be a reference to OIDC to explain what this means.

Yup.
=C2=A0

The paragrap= h that begins =E2=80=9CIt also allows clients to push the form encoded =E2= =80=A6=E2=80=9D is confusing because the use of =E2=80=9Calso=E2=80=9D sugg= ests this is different from the previous paragraph, but it seems to actuall= y be saying the same thing?

Yea= h, that is rather awkward because it is the same thing. Will fix.
=C2=A0

=E2=80=9C[=E2=80=A6] but it also allows clients requiring
   an even higher security level, especially cryptog=
raphically confirmed
   non-repudiation, to explicitly adopt JWT-based request objects=E2=80=9D<=
/font>

The =
=E2=80=9Cbut=E2=80=9D should be an =E2=80=9Cand=E2=80=9D in this paragraph.=
 It=E2=80=99s also not clear what is being said here - isn=E2=80=99t JAR wh=
at provides JWT-based request objects?

Yeah, JAR defines JWT-based request objects and PAR allows = for their use by sending the 'request' parameter to the PAR endpoin= t.=C2=A0 Will try and make that more clear.
=C2=A0

<=
/font>
The paragraph beginning =E2=80=9CAs a furth=
er benefit, =E2=80=A6=E2=80=9D is a little bit of a Columbo moment (=E2=80=
=9CJust one more thing=E2=80=A6=E2=80=9D) at the end of the introduction. M=
aybe move this as another bullet point at the start of the section. The fol=
lowing paragraph can then be rewritten as =E2=80=9CThe increased confidence=
 in the identity of the client during the authorization process allows conf=
idential clients to provide a different redirect_uri on every request. [=E2=
=80=A6]=E2=80=9D

=C2=A0A= gree with the sentiment here and will endeavor to rework things along the l= ines of the suggestion.

=C2=A0
Section 2:
The 3rd paragraph contains statements like=C2=A0<= /pre>
The endpoint also supports sending all auth=
orization
   request parameters as request object ac=
cording to
   [I-D.ietf-oau=
th-jwsreq].
presumably this is not a normative requirement th= at any PAR implementation has to also support JAR, or is it? Maybe change t= he wording to =E2=80=9CMAY also support =E2=80=A6=E2=80=9D.

Interesting question. PAR has a normative refe= rence to JAR for the request_uri parameter at the authz endpoint. But does = that necessitate that every PAR implementation also has to support all of J= AR? I'm thinking probably not. I mean, different but related, an AS PAR= implementation might legitimately support the request_uri parameter with U= RI values that it creates but not support the more general retrieval of arb= itrary URIs. In the same vein, it seems legit and still useful to support P= AR without also supporting request object JWTs. So yeah, I think changing t= his to MAY or something similar would be appropriate.
=C2=A0=

The first mention of =E2=80=9Ctoken_endpoint_auth_method=E2=80=9D and= client metadata should have a reference to RFC 7591 - currently it=E2=80= =99s only referenced later in section 2.1.
Will fix.

2.1:
I=E2=80=99m a little bit war= y of the relaxing of the redirect_uri processing rules, because this remove= s a layer of defence in depth. With the current requirement for pre-registe= red URIs an attacker needs to compromise the redirect endpoint *and* the cl= ient credentials in order to steal an authorization code and use it. With t= his change, compromising the client credentials alone would be enough. If t= he use-case is specifically in a PKI environment, could the redirect_uri be= baked into the cert? Maybe this use-case could be better addressed in a se= parate draft.

=C2=A0I agree tha= t the specifics of a PKI type environment use-case would be better in a sep= arate draft or profile somewhere. And do plan to add some more consideratio= ns around the possibility of relaxed redirect_uri validation.


Is there a recommended minimum/m= aximum? Suggested wording:

=3D=3D=3D
* "expires_in" : A JSON number that represents the li= fetime of the request URI in seconds as a positive integer. The lifetime SHOULD=C2= =A0
      be at least 5 seconds and at most 600 seconds, bu=
t other values are
      permitted at the discretion of the=
 authorization server.
=3D=3D=3D

T= hose values are fairly arbitrary - 5 seconds seems a reasonable lower bound= for a client with a bad network connection, and 10 minutes seems more than= adequate upper bound for the typical uses.
Arbitrary, yes. But also pretty reasonable. I'm not too ke= en on using arbitrary values with normative language, however, even if reas= onable. I think we could work them in with slightly different language some= thing like, "for example, at least 5 seconds but at most 600".
=C2=A0
=

3:
I confirmed that the request JWT veri= fies with the given JWK using our internal JWT library :-)

Yay for interoperability!=C2=A0 I produced thos= e using a different JWT library :)

5:
=E2=80=9Crequire_= pushed_authorization_requests=E2=80=9D might be better named=C2=A0=E2=80=9C= requires_pushed_authorization_requests=E2=80=9D given that it is describing= the server=E2=80=99s policy rather than telling the client to require them= , but this is a really pedantic point. Same for the client metadata in sect= ion 6.

Fair point but I don'= ;t think sufficient to warrant a change to a protocol parameter name at thi= s point.
=C2=A0

7:
I would like to propose an= additional security consideration, with the following wording:
<= br>
=3D=3D=3D
7.5. Request URI swapping

<= /div>
An attacker could capture the request URI from one request and th= en substitute it into a different authorization request. For example, in th= e context of OpenID Connect, an attacker could replace a request URI asking= for a high level of authentication assurance with one that requires a lowe= r level of assurance. Clients SHOULD make use of PKCE, a unique =E2=80=9Cst= ate" parameter, or the OIDC =E2=80=9Cnonce=E2=80=9D parameter in the p= ushed request object to prevent this attack.
=3D=3D=3D

Thanks. Will incorporate (with added refs= and minor tweaks). I'm wondering if there's a good example that is= n't OpenID Connect though? Just thinking something OAuth only might be = more accessible to most readers (similar to what you and Justin pointed out= that the ACR example earlier in the draft may not be the best). =C2=A0

=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. --000000000000766cf305adcd5691-- From nobody Wed Aug 26 13:44:53 2020 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 0BF4F3A0B75 for ; Wed, 26 Aug 2020 13:44:52 -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=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 4JeNah3zlkE1 for ; Wed, 26 Aug 2020 13:44:50 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 EC0453A0B63 for ; Wed, 26 Aug 2020 13:44:49 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id t23so3945123ljc.3 for ; Wed, 26 Aug 2020 13:44:49 -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=4LQtn6+lr45IpS7SuoSwMQC+tDneFYeVl9i1mdHQeE0=; b=Ab/QtLQJ+DDvurQ9yPB83RuRCS1r6npOkVesJX8uqC1c+8wN5kdxwxk0u51QPmKTu9 m3voZ0xwpNoAnc3XeUA9Y+IFR51PZ/3IQu8fjOUD16O2TANl4qHT3htXhhV6d0t5KI7S rJ0Q0rYb8GpkQHWc2dVAX4tkIMAnZ8OqJjqrOoi5EmvCdrN/Erlk24U5LPSSMGgZLcy/ SHKhkleqorJbyQu9vEshVlsYxWMZ7X/DxYnXeqAYhGxVAbHv1Y4eM4+JVKPd8b45Ltk6 fqqgkwmGT3W2sO+1fje4nijk5KpYJwt7eSPUosD7zFdlOybyJjogRb7Ex/F5VCQDYjkQ qsNg== 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=4LQtn6+lr45IpS7SuoSwMQC+tDneFYeVl9i1mdHQeE0=; b=I9Bsif20WWmMqwugqPkkuXNGCEn7LV4CEWurWVWpp3iDOVv/h1SxjUIYg1K+1fOyWd xn1ZYdD0qdelQ2RIlBtALp6gN4wivy31iTtStpHvAIwO3KqqF6GDmzuG94654WZ1JgRk k/9RPXf4tIja3bplY+r3jCWFGw8Y1HmsxsldqJcVix6x8BhBXBloytqE98EVE4MB6uhi qjKDpgHTM1Fjq8icO//rWt7hSQzoWo+2WOg6i+FCuiKNgqPHk4U4QI6vbTNehwd4VbWo mBD7hlEGtUb+R6wk8T/decwQ6+NioCWTVjq7VZ3onUp7T7QTjpw9AKIMZlsVeCFu2Nkr vYpA== X-Gm-Message-State: AOAM532wlRmKj87SlUW680sOV/y8l1ZkxbEPuoO2a/x/Vdl6K7T9FTi1 fjoIz53GpvvcQi0t2nhxz9RzVqpJso75np0ntG75kQrH9o4C1E0WWKB2fHkYsPOY0OBaKpZarmc Fb7Nhrw7Yt4lQ47eKZdrABA== X-Google-Smtp-Source: ABdhPJzRGParRqpHYuAD8gqMveXauXxQtyihP5PWYGVAXqp5dvcJG1shZmlPmd23kd7dcm6K0iE9v76pDln0Y2vdvAw= X-Received: by 2002:a05:651c:1136:: with SMTP id e22mr7956062ljo.422.1598474687771; Wed, 26 Aug 2020 13:44:47 -0700 (PDT) MIME-Version: 1.0 References: <7C0FD285-F677-4501-B2FB-9431A59855F6@mit.edu> In-Reply-To: From: Brian Campbell Date: Wed, 26 Aug 2020 14:44:21 -0600 Message-ID: To: Justin Richer Cc: oauth Content-Type: multipart/alternative; boundary="000000000000f295ac05adcde370" Archived-At: Subject: Re: [OAUTH-WG] WGLC Review of PAR 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, 26 Aug 2020 20:44:52 -0000 --000000000000f295ac05adcde370 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Justin. Just a couple more responses to responses inline below (but with lots of content that needs no further discussion removed). A TL;DR for the WG is that I'd like to get some wider feedback on the question of changing the one-time-use condition on the request_uri from a SHOULD to a MUST. On Tue, Aug 25, 2020 at 4:57 PM Justin Richer wrote: > Hi Brian, just a couple responses inline where it seemed fitting. Thanks > for going through everything! > =E2=80=94 Justin > > On Aug 25, 2020, at 6:01 PM, Brian Campbell > wrote: > > Thanks for the review and comments Justin. Replies (or attempts thereat) > are inline below. > > > On Wed, Aug 19, 2020 at 2:06 PM Justin Richer wrote: > >> I=E2=80=99ve done a full read through of the PAR specification, and here= are my >> notes on it. >> >> >>> =C2=B62: Of necessity, this spec mixes parameters in the authorizat= ion >>> endpoint and token endpoint registries into a single request. Is there = any >>> danger of conflict between them? The registry holds them in one list bu= t >>> they could possibly have different semantics in both places. >>> >> >> I think that technically such danger does exist but that it's highly >> unlikely in practice. Especially because the only token endpoint paramet= ers >> that are relevant to PAR are those that deal with client authentication >> (currently client_secret, client_assertion, and client_assertion_type). = I'm >> also not sure what can reasonably be done about it given the way the >> registries are. I guess PAR could update the registration for those thre= e >> (client_secret, client_assertion, and client_assertion_type) to also >> indicate authorization request as a usage location with some commentary >> that it's only for avoiding name collisions. And offer some guidance abo= ut >> doing the same for any future client auth methods being defined. But >> honestly I'm not sure what, if anything, to do here? >> >> And yes it is super unfortunate that client auth and protocol parameters >> got mixed together in the HTTP body. I didn't cause that situation but I= 've >> certainly contributed to it and for that I apologize. >> > > I think the only perfect solution is to go back in time and fix the > registries with based on the last decade of knowledge in using them. :P > > For this, I think maybe being very prescriptive about the fact that the > only parameters from the token endpoint that are allowed here are those > used for client authentication and that when they show up, they=E2=80=99r= e > interpreted as in the token endpoint request not the authorization endpoi= nt > request. Does that work? > I think so, yes. And will work on incorporating some text towards that end. > I don=E2=80=99t see why a request URI with unguessable values isn=E2= =80=99t a MUST for >> one-time-use, is there a reason? >> > > The reason AFAIK was to not be overly prescriptive and allow for > eventually consistent or not atomic storage of the data by not strictly > requiring the AS to enforce one-time-use. Do you think that's too loose o= r > could be worded/explained differently or better? > > > I do think it=E2=80=99s too loose and it should be a MUST, and the method= s for > enforcing that =E2=80=9CMUST=E2=80=9D are going to vary based on the depl= oyments and > implementations out there. > > I'd be okay with making it a MUST but think maybe it'd be good to hear from a few more people in the WG before committing to that change. Can I ask some folks to weigh in on this one? I'm leaning towards making the change barring objections. --=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._ --000000000000f295ac05adcde370 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0Justin. Just a couple more re= sponses to responses inline below (but with lots of content that needs no f= urther discussion removed).

A TL;= DR for the WG is that I'd like to get some wider feedback on the questi= on of changing the one-time-use condition on the request_uri from a SHOULD = to a MUST.

On Tue, Aug 25, 2020 at 4:57 PM Justin Richer <jricher@mit.edu> wrote:
Hi Brian, just a couple responses inline where it seemed fitting.= Thanks for going through everything!
=C2=A0=E2=80=94 Justin
On Aug 25, 2020, at 6:01 PM, Brian Campbel= l <bcamp= bell@pingidentity.com> wrote:

Thanks for the review and comments Justin. Replies (or attem= pts thereat) are inline below.


On Wed, Aug = 19, 2020 at 2:06 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99ve do= ne a full read through of the PAR specification, and here are my notes on i= t.


=C2=A0 =C2=A0 =C2=B62: Of necessity, this spec mixes param= eters in the authorization endpoint and token endpoint registries into a si= ngle request. Is there any danger of conflict between them? The registry ho= lds them in one list but they could possibly have different semantics in bo= th places.

I think that technic= ally such danger does exist but that it's highly unlikely in practice. = Especially because the only token endpoint parameters that are relevant to = PAR are those that deal with client authentication (currently client_secret= , client_assertion, and client_assertion_type). I'm also not sure what = can reasonably be done about it given the way the registries are. I guess P= AR could update the registration for those three (client_secret, client_ass= ertion, and client_assertion_type) to also indicate authorization request a= s a usage location with some commentary that it's only for avoiding nam= e collisions. And offer some guidance about doing the same for any future c= lient auth methods being defined. But honestly I'm not sure what, if an= ything, to do here?=C2=A0

And yes it is super= unfortunate that client auth and protocol parameters got mixed together in= the HTTP body. I didn't cause that situation but I've certainly co= ntributed to it and for that I apologize.

I think the only perfect sol= ution is to go back in time and fix the registries with based on the last d= ecade of knowledge in using them. :P=C2=A0

For thi= s, I think maybe being very prescriptive about the fact that the only param= eters from the token endpoint that are allowed here are those used for clie= nt authentication and that when they show up, they=E2=80=99re interpreted a= s in the token endpoint request not the authorization endpoint request. Doe= s that work?

I thin= k so, yes. And will work on incorporating some text towards that end.
<= /div>


=C2=A0
<= div>
=C2=A0 =C2= =A0 I don=E2=80=99t see why a request URI with unguessable values isn=E2=80= =99t a MUST for one-time-use, is there a reason?

The reason AFAIK was to not be overly prescriptive and al= low for eventually consistent or not atomic storage of the data by not stri= ctly requiring the AS to enforce one-time-use. Do you think that's too = loose or could be worded/explained differently or better?=C2=A0

I do think it=E2=80=99s too l= oose and it should be a MUST, and the methods for enforcing that =E2=80=9CM= UST=E2=80=9D are going to vary based on the deployments and implementations= out there.=C2=A0


I'd be okay with making it a MUST but think maybe it'd be good t= o hear from a few more people in the WG before committing to that change. <= br>

Can I ask some folks to weigh in on this one? = I'm leaning towards making the change barring objections.


<= 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. --000000000000f295ac05adcde370-- From nobody Wed Aug 26 14:13:09 2020 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 630A83A0C69; Wed, 26 Aug 2020 14:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=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=microsoft.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 3WALl6PsaafJ; Wed, 26 Aug 2020 14:12:55 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650135.outbound.protection.outlook.com [40.107.65.135]) (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 A804C3A0C6B; Wed, 26 Aug 2020 14:12:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jMg3bhSWvc2J52pHVk34twYMFjrPiFxsfxm2QAB4Vbhh702JMJFwdX5FlhLepF52hzwRXLJo7CKpYrhS8F0UVLz0dsdn7IFI0ZZPhcUyAvZ+IU+xz+2CLmyebuP9ISYloIExn0UbR50secjXIw4564iVHguYUgcWN8nasCf6XxYrnwAJ5pcez4ASeA6GSeon7z9vWht3Oq/g1+FVM+1u5eu8X8ZJsK2w/cX6uoEYIF7Pq0QRmMmywA6e80YZNGP9zsg4Ba/tuU638wxRb0J8RXpqJ+5vka0vRG2GXp+Qn3Qw1CJ/RB6NGaVWBzw7ic1et7e8Mc6gWLk/f+sn/K5Njw== 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=eZk88HOWZaHhJXHMcocH1aSyFE/4awUdZ6gMw5GjFNg=; b=mNl2QnZrkjPBvZCsi3nLUksIFUfbmb1zqXYQaUesLJ0PBKf7kKemu2KMh1Sskx1LR/G62/bThCSa7jiazHk0+t7WntnXUnwgkXqT0W7mCSDQrwdnkgfqEN2mANhM+FUBNw1B+5B2PQ1rBBLK2YgORkZIJdZ9UL9sbfZcLqWst9nywCn+3th/RWFT6Xdk50/LBRkVHtcPZ1Pkq+dxtr10rKY2hqRxWYONWJpCnSKmbZod7lEOxkUJfWf0/9x+0GYH2ctx0sm3q11NV6ALDzzJo0US1GNBR/oRAq+zOCfAvrXIUquzH+E/uWdKS92GWKvxXitVjUIhqGSRwh+n6HaV5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eZk88HOWZaHhJXHMcocH1aSyFE/4awUdZ6gMw5GjFNg=; b=Ijffl/qh7eLsx2J+qQiehaT6KhJ87nUx4CUTFixxQS16D3/jXyFr/N1bt7HFneCayZuSIZKD/yXXAyHXRea6qKjeM86tW4ltWvMKKEhqYu6nPvr3dXYEW0G1L5EKtr+5hgf7ZB8ZxXuMi+G3KTp9w1uJZInv8Sk2vvVoI5RQSm8= Received: from (2603:10b6:610:a9::23) by CH2PR00MB0696.namprd00.prod.outlook.com (2603:10b6:610:7b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3368.0; Wed, 26 Aug 2020 21:12:30 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::b8b7:3f55:bae6:5458]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::b8b7:3f55:bae6:5458%6]) with mapi id 15.20.3368.000; Wed, 26 Aug 2020 21:12:27 +0000 From: Mike Jones To: dick.hardt , Torsten Lodderstedt CC: "last-call@ietf.org" , oauth Thread-Topic: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard Thread-Index: AdZ77Za0JLDyfkgOSU2noMsXqL8EHw== Date: Wed, 26 Aug 2020 21:12:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=b92bed32-f10c-4f53-8858-91e752d3bc45; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-26T21:09:13Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.86.243] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 5a90a64f-4ddc-436a-0dd7-08d84a04bc58 x-ms-traffictypediagnostic: CH2PR00MB0696: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XGWUHgYjYUtC+WqgKZFmB3y93n6OQA3+T0Wh1ABonn5R4/5c0xBm7jOqgGNyKtaRmvBjlh6mQAFQkCH2hCvR8oduVG6gXuif8DEQeI3nuh1TWE8wDjMXfZfpoEBhn3wgLSY8cGrgxkNMOs/n/bbbVGqQPj/MTwCLaNoODzz4wZ0cdQ9SMmInHQlH3ChaIijZ9F65BlxMy1WJgUK5cQS/83/HeacUVGSGnnu1HSIQgRnnYutsjpZa9X21TJVRRmeoaSFFOuRC4xUIU+jbRDrnQbfdA7TuY/T2/5zepnV0kbKqUV1KHB4lGUU1yVvrHg03AF78evyzrEUtqCd4OXdAB7Drgsq9T+W5f+AyOgh2uWjqh5Y52+fqyBVNxuDzB2gE1wWcL3ZdIl+bsiz8Yt55Rm7Z0IiVG8r5yMKqRNokJ/U= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(136003)(376002)(396003)(346002)(53546011)(55016002)(7696005)(66556008)(33656002)(9686003)(8936002)(4326008)(26005)(316002)(186003)(2906002)(66446008)(64756008)(54906003)(110136005)(478600001)(5660300002)(52536014)(8990500004)(66946007)(76116006)(71200400001)(82950400001)(82960400001)(6506007)(66476007)(76236003)(83380400001)(86362001)(10290500003)(8676002)(99710200001)(15866825006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 172ui0ccP7odhn1MNWu8Aj94E6z/W78YbhmdKJWb8VrYgGUCjzR9wSsPOOy0ZsYPHYj1y4Gt5+/MY6jpsbYpmqxGIDT4yN/sh2upcBg1E7SRLqoKCsUhZbDN7F6u4gsxq41Fb03FtlO14E4nLdFLexzs0jJg43yzFj9Ep8KuEZmJ2T5P3fftlcw9BeSjHJlB0BV1OrqmUCC4BZhIDD6Pe9m+z5LHlUx753froDYuS50KsZN27sHN+DDEUdQPA6T9bAgShciWPQvPQYTGGaPqCdepNXzcv7d093mC5El7mrMS5Qk7t+UJLU5U0jbE5Eo0nDHxih1L0plwnYW7BIf3+VaGiOeUjvtnyfS43tIwPPO0LMokONlLsDwwtR0yqBSLLCbc4g+27+pvvmUqsnvv8LBITkiGjXj6wdvLr8WYIV5Vhy+w+JRuPrIa1Z6OFXotOCJj0v+/jNMMObIrk8LzYAPvXFSiyboYhr58M5557ILhX9KNlWgrAbUKf+TW6JWCGx89vBLRImTKbpHzSnEvZF84b4IQ+H1Wj5iR7N7YvtioXYNmwGGkUOUzibptoxu25S/z4divzf5Y8WVQdy5NEdn18nM0nMH/I3n4oqp0Thahcrj8uVvnFLDhQySTSWKeh3zvzsPzSZ1FqQw0RFJIyg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0678DA2BC7234C2AC1CE784DF5541CH2PR00MB0678namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0678.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5a90a64f-4ddc-436a-0dd7-08d84a04bc58 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2020 21:12:27.2101 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: O7JAI8LW3acekMlkINvQbA4ge75073UyQQbmQ859mFq///QVig6ReZCftck7GZHiiUUDm5eTAPugxRdpv1f76Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0696 Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 26 Aug 2020 21:13:04 -0000 --_000_CH2PR00MB0678DA2BC7234C2AC1CE784DF5541CH2PR00MB0678namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIERpY2vigJlzIG9ic2VydmF0aW9uIGFib3V0IHRoZSBwcml2YWN5IGltcGxp Y2F0aW9ucyBvZiB1c2luZyBhbiBJbnRyb3NwZWN0aW9uIEVuZHBvaW50LiAgVGhhdOKAmXMgd2h5 IGl04oCZcyBwcmVmZXJhYmxlIHRvIG5vdCB1c2Ugb25lIGF0IGFsbCBhbmQgaW5zdGVhZCBkaXJl Y3RseSBoYXZlIHRoZSBSZXNvdXJjZSB1bmRlcnN0YW5kIHRoZSBBY2Nlc3MgVG9rZW4uICBPbmUg d2F5IG9mIGRvaW5nIHRoaXMgaXMgdGhlIEpXVCBBY2Nlc3MgVG9rZW4gc3BlYy4gIFRoZXJlIGFy ZSBwbGVudHkgb2Ygb3RoZXJzLg0KDQpUaGUgZG93bnNpZGVzIG9mIHVzaW5nIGFuIEludHJvc3Bl Y3Rpb24gRW5kcG9pbnQgc2hvdWxkIGJlIGRlc2NyaWJlZCBpbiB0aGUgUHJpdmFjeSBDb25zaWRl cmF0aW9ucyBzZWN0aW9uLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZz4gT24gQmVoYWxmIE9mIERpY2sgSGFyZHQNClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0 IDI2LCAyMDIwIDk6NTIgQU0NClRvOiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuPTQwbG9k ZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPg0KQ2M6IGxhc3QtY2FsbEBpZXRmLm9yZzsgb2F1 dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gTGFzdCBDYWxsOiA8 ZHJhZnQtaWV0Zi1vYXV0aC1qd3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS0wOS50eHQ+IChKV1Qg UmVzcG9uc2UgZm9yIE9BdXRoIFRva2VuIEludHJvc3BlY3Rpb24pIHRvIFByb3Bvc2VkIFN0YW5k YXJkDQoNCg0KDQpPbiBXZWQsIEF1ZyAyNiwgMjAyMCBhdCA0OjM3IEFNIFRvcnN0ZW4gTG9kZGVy c3RlZHQgPHRvcnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQw bG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYuLm9yZz4+IHdyb3RlOg0KSGkgRGVuaXMsDQoNCj4g T24gMjUuIEF1ZyAyMDIwLCBhdCAxNjo1NSwgRGVuaXMgPGRlbmlzLmlldGZAZnJlZS5mcjxtYWls dG86ZGVuaXMuaWV0ZkBmcmVlLi5mcj4+IHdyb3RlOg0KDQo+IFRoZSBmYWN0IHRoYXQgdGhlIEFT IHdpbGwga25vdyBleGFjdGx5IHdoZW4gdGhlIGludHJvc3BlY3Rpb24gY2FsbCBoYXMgYmVlbiBt YWRlIGFuZCB0aHVzIGJlIGFibGUgdG8gbWFrZSBzdXJlIHdoaWNoIGNsaWVudA0KPiBoYXMgYXR0 ZW1wdGVkIHBlcmZvcm0gYW4gYWNjZXNzIHRvIHRoYXQgUlMgYW5kIGF0IHdoaWNoIGluc3RhbnQg b2YgdGltZS4gVGhlIHVzZSBvZiB0aGlzIGNhbGwgYWxsb3dzIGFuIEFTIHRvIHRyYWNrIHdoZXJl IGFuZCB3aGVuDQo+IGl0cyBjbGllbnRzIGhhdmUgaW5kZWVkIHByZXNlbnRlZCBhbiBpc3N1ZWQg YWNjZXNzIHRva2VuLg0KDQpUaGF0IGlzIGEgZmFjdC4gSSBkb27igJl0IHRoaW5rIGl0IGlzIGFu IGlzc3VlIHBlciBzZS4gUGxlYXNlIGV4cGxhaW4gdGhlIHByaXZhY3kgaW1wbGljYXRpb25zLg0K DQpBcyBJIHNlZSBpdCwgdGhlIHByaXZhY3kgaW1wbGljYXRpb24gaXMgdGhhdCB0aGUgQVMga25v d3Mgd2hlbiB0aGUgY2xpZW50IChhbmQgcG90ZW50aWFsbHkgdGhlIHVzZXIpIGlzIGFjY2Vzc2lu ZyB0aGUgUlMsIHdoaWNoIGlzIGFsc28gYW4gaW5kaWNhdGlvbiBvZiB3aGVuIHRoZSB1c2VyIGlz IHVzaW5nIHRoZSBjbGllbnQuDQoNCkkgdGhpbmsgaW5jbHVkaW5nIHRoaXMgaW1wbGljYXRpb24g d291bGQgYmUgaW1wb3J0YW50IHRvIGhhdmUgaW4gYSBQcml2YWN5IENvbnNpZGVyYXRpb25zIHNl Y3Rpb24uDQoNCi9EaWNrDQrhkKcNCg== --_000_CH2PR00MB0678DA2BC7234C2AC1CE784DF5541CH2PR00MB0678namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGFncmVlIHdpdGggRGlja+KAmXMgb2Jz ZXJ2YXRpb24gYWJvdXQgdGhlIHByaXZhY3kgaW1wbGljYXRpb25zIG9mIHVzaW5nIGFuIEludHJv c3BlY3Rpb24gRW5kcG9pbnQuJm5ic3A7IFRoYXTigJlzIHdoeSBpdOKAmXMgcHJlZmVyYWJsZSB0 byBub3QgdXNlIG9uZSBhdCBhbGwgYW5kIGluc3RlYWQgZGlyZWN0bHkgaGF2ZSB0aGUgUmVzb3Vy Y2UgdW5kZXJzdGFuZCB0aGUgQWNjZXNzDQogVG9rZW4uJm5ic3A7IE9uZSB3YXkgb2YgZG9pbmcg dGhpcyBpcyB0aGUgSldUIEFjY2VzcyBUb2tlbiBzcGVjLiZuYnNwOyBUaGVyZSBhcmUgcGxlbnR5 IG9mIG90aGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlRoZSBkb3du c2lkZXMgb2YgdXNpbmcgYW4gSW50cm9zcGVjdGlvbiBFbmRwb2ludCBzaG91bGQgYmUgZGVzY3Jp YmVkIGluIHRoZSBQcml2YWN5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t OjwvYj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBP ZiA8L2I+DQpEaWNrIEhhcmR0PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDI2 LCAyMDIwIDk6NTIgQU08YnI+DQo8Yj5Ubzo8L2I+IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3Rv cnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBsYXN0LWNhbGxAaWV0Zi5vcmc7IG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtaWV0Zi1v YXV0aC1qd3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS0wOS50eHQmZ3Q7IChKV1QgUmVzcG9uc2Ug Zm9yIE9BdXRoIFRva2VuIEludHJvc3BlY3Rpb24pIHRvIFByb3Bvc2VkIFN0YW5kYXJkPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDI2LCAyMDIw IGF0IDQ6MzcgQU0gVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7dG9yc3Rlbj08YSBocmVmPSJtYWls dG86NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi4ub3JnIj40MGxvZGRlcnN0ZWR0Lm5ldEBk bWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRGVuaXMsPGJyPg0KPGJyPg0KJmd0OyBP biAyNS4gQXVnIDIwMjAsIGF0IDE2OjU1LCBEZW5pcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRlbmlz LmlldGZAZnJlZS4uZnIiIHRhcmdldD0iX2JsYW5rIj5kZW5pcy5pZXRmQGZyZWUuZnI8L2E+Jmd0 OyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IFRoZSBmYWN0IHRoYXQgdGhlIEFTIHdpbGwga25vdyBl eGFjdGx5IHdoZW4gdGhlIGludHJvc3BlY3Rpb24gY2FsbCBoYXMgYmVlbiBtYWRlIGFuZCB0aHVz IGJlIGFibGUgdG8gbWFrZSBzdXJlIHdoaWNoIGNsaWVudA0KPGJyPg0KJmd0OyBoYXMgYXR0ZW1w dGVkIHBlcmZvcm0gYW4gYWNjZXNzIHRvIHRoYXQgUlMgYW5kIGF0IHdoaWNoIGluc3RhbnQgb2Yg dGltZS4gVGhlIHVzZSBvZiB0aGlzIGNhbGwgYWxsb3dzIGFuIEFTIHRvIHRyYWNrIHdoZXJlIGFu ZCB3aGVuDQo8YnI+DQomZ3Q7IGl0cyBjbGllbnRzIGhhdmUgaW5kZWVkIHByZXNlbnRlZCBhbiBp c3N1ZWQgYWNjZXNzIHRva2VuLjxicj4NCjxicj4NClRoYXQgaXMgYSBmYWN0LiBJIGRvbuKAmXQg dGhpbmsgaXQgaXMgYW4gaXNzdWUgcGVyIHNlLiBQbGVhc2UgZXhwbGFpbiB0aGUgcHJpdmFjeSBp bXBsaWNhdGlvbnMuDQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFzIEkgc2VlIGl0LCB0aGUgcHJpdmFjeSBpbXBsaWNhdGlvbiBp cyB0aGF0IHRoZSBBUyBrbm93cyA8Yj4NCndoZW48L2I+IHRoZSBjbGllbnQgKGFuZCBwb3RlbnRp YWxseSB0aGUgdXNlcikgaXMgYWNjZXNzaW5nIHRoZSBSUywgd2hpY2ggaXMgYWxzbyBhbiBpbmRp Y2F0aW9uIG9mDQo8Yj53aGVuPC9iPiB0aGUgdXNlciBpcyB1c2luZyB0aGUgY2xpZW50LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5r IGluY2x1ZGluZyB0aGlzIGltcGxpY2F0aW9uIHdvdWxkIGJlIGltcG9ydGFudCB0byBoYXZlIGlu IGEgUHJpdmFjeSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vRGljazxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpbWcgYm9y ZGVyPSIwIiB3aWR0aD0iMSIgaGVpZ2h0PSIxIiBzdHlsZT0id2lkdGg6LjAxMDRpbjtoZWlnaHQ6 LjAxMDRpbiIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJodHRwczovL21haWxmb29nYWUuYXBwc3Bv dC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlwZT16 ZXJvY29udGVudCZhbXA7Z3VpZD04ZjI2YWM1Mi0xMDgzLTRlNmQtOTQ0YS1iZDkxZWQ2MGZhOGMi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CH2PR00MB0678DA2BC7234C2AC1CE784DF5541CH2PR00MB0678namp_-- From nobody Wed Aug 26 15:16:54 2020 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 9DA043A093A for ; Wed, 26 Aug 2020 15:16:52 -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_FONT_LOW_CONTRAST=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 kGqh3VwrxxAf for ; Wed, 26 Aug 2020 15:16:50 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 543DC3A0934 for ; Wed, 26 Aug 2020 15:16:50 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id m22so4166144ljj.5 for ; Wed, 26 Aug 2020 15:16:50 -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=N96mq3kxZ7sFwwyniutso4NEGauCNvAydA74KWLOWWY=; b=U6+GWIan30Yxy1E/KT0tdxrpGg6K2D3mZ8jRbL9Lz/g5vgtVN9MV1C2N0frZebgRV1 aU5c80CfevJfc2BKtKbCh6e/3PO3ptjm33A8BifTwUWejzr8akmE6I+g36ml++wh2k0g d8WR3x7Zg06SrtbErHsnN7Lmb4Het+IXJzoqKgBIGsMf9cyEKJ1smy3beUX3TdCWXHwC YBQ/LtGVuh1InE12lF0+VHPVUknkkQXeF8TJmijLV91lodRFx6CiLSn8VFwYJdwdjgsJ zvfuZky0Nye9Gpc1jCrJ1trbGSj2PutN6OZ7w0OyzUXOW8EgPRolT4KvIyhJBIy2SPaL xL2w== 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=N96mq3kxZ7sFwwyniutso4NEGauCNvAydA74KWLOWWY=; b=EBESf9FDEj4bwZDyehSazbwBhxCUHrpbKpNEtwxuYj/Tts1Qi+vdX6vq9o0YhmKlIQ OwozQ/CARQdIMR7g4y+zMIDMRRksKRULSazUocyGfsMycd55t3aJIGrrY38ddm1Fe3uO bdyHUx5HilUd3FVWxE1lR2WT+K2XOU1EXEask+eTVL6R8VOFmXa0DVi4YfN1RhPJpcCR jhAW3vlibGdpJaRIARF5cqJPwFxLe4zjF61UrjfvYMSUfVYH0juD4dKJtQsmYkskSpmZ 7UbMaiCb1t0pGqivluMwKS9JLU0AGWHku3VUPyA1x3j113p+ls4xhrS0958P2IIkZi8n K4ag== X-Gm-Message-State: AOAM533mSJ1OqLziWivZWUfg7NbNM6hbNDmnUSa4+arZ2HK3+8bHiDcD 88IP4QUkaxKumRfZfZ1qK+Y4WoH0Yc8hBHha2GI= X-Google-Smtp-Source: ABdhPJymZjjW3IlepI71GQ4cSGHTbfcqSTGXDwWpX0iq4R1b/Ei8K3XibDD98WF0NcZUGGBmgDFcqrMN20AigEnnEgg= X-Received: by 2002:a2e:7215:: with SMTP id n21mr8770762ljc.242.1598480208096; Wed, 26 Aug 2020 15:16:48 -0700 (PDT) MIME-Version: 1.0 References: <7C0FD285-F677-4501-B2FB-9431A59855F6@mit.edu> In-Reply-To: From: Dick Hardt Date: Wed, 26 Aug 2020 15:16:12 -0700 Message-ID: To: Brian Campbell Cc: Justin Richer , oauth Content-Type: multipart/alternative; boundary="000000000000fbf08f05adcf2ca2" Archived-At: Subject: Re: [OAUTH-WG] WGLC Review of PAR 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, 26 Aug 2020 22:16:53 -0000 --000000000000fbf08f05adcf2ca2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think one-time use may be overly restrictive, and I don't think it is the property that we actually want. Give the request URI is in a redirect from the browser, there is a good chance of a race condition where the same browser request is made more than once, for example, while the browser is loading the authorization URL at the AS, the user could refresh the page causing the authorization URL to be reloaded. Would the reload count as a second use? One could argue it either way. What I think we want from what I understand, is the request URI MUST be unique so that there is no confusion on which request is being referenced. I did not see anything about the expiry time of the request URI (but I did not look super hard). If that is not there, then I think the request URI MUST expire in a "short" period of time. =E1=90=A7 On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell wrote: > Thanks Justin. Just a couple more responses to responses inline below (bu= t > with lots of content that needs no further discussion removed). > > A TL;DR for the WG is that I'd like to get some wider feedback on the > question of changing the one-time-use condition on the request_uri from a > SHOULD to a MUST. > > On Tue, Aug 25, 2020 at 4:57 PM Justin Richer wrote: > >> Hi Brian, just a couple responses inline where it seemed fitting. Thanks >> for going through everything! >> =E2=80=94 Justin >> >> On Aug 25, 2020, at 6:01 PM, Brian Campbell >> wrote: >> >> Thanks for the review and comments Justin. Replies (or attempts thereat) >> are inline below. >> >> >> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer wrote: >> >>> I=E2=80=99ve done a full read through of the PAR specification, and her= e are my >>> notes on it. >>> >>> >>>> =C2=B62: Of necessity, this spec mixes parameters in the authoriza= tion >>>> endpoint and token endpoint registries into a single request. Is there= any >>>> danger of conflict between them? The registry holds them in one list b= ut >>>> they could possibly have different semantics in both places. >>>> >>> >>> I think that technically such danger does exist but that it's highly >>> unlikely in practice. Especially because the only token endpoint parame= ters >>> that are relevant to PAR are those that deal with client authentication >>> (currently client_secret, client_assertion, and client_assertion_type).= I'm >>> also not sure what can reasonably be done about it given the way the >>> registries are. I guess PAR could update the registration for those thr= ee >>> (client_secret, client_assertion, and client_assertion_type) to also >>> indicate authorization request as a usage location with some commentary >>> that it's only for avoiding name collisions. And offer some guidance ab= out >>> doing the same for any future client auth methods being defined. But >>> honestly I'm not sure what, if anything, to do here? >>> >>> And yes it is super unfortunate that client auth and protocol parameter= s >>> got mixed together in the HTTP body. I didn't cause that situation but = I've >>> certainly contributed to it and for that I apologize. >>> >> >> I think the only perfect solution is to go back in time and fix the >> registries with based on the last decade of knowledge in using them. :P >> >> For this, I think maybe being very prescriptive about the fact that the >> only parameters from the token endpoint that are allowed here are those >> used for client authentication and that when they show up, they=E2=80=99= re >> interpreted as in the token endpoint request not the authorization endpo= int >> request. Does that work? >> > > I think so, yes. And will work on incorporating some text towards that > end. > > > > >> I don=E2=80=99t see why a request URI with unguessable values isn=E2= =80=99t a MUST >>> for one-time-use, is there a reason? >>> >> >> The reason AFAIK was to not be overly prescriptive and allow for >> eventually consistent or not atomic storage of the data by not strictly >> requiring the AS to enforce one-time-use. Do you think that's too loose = or >> could be worded/explained differently or better? >> >> >> I do think it=E2=80=99s too loose and it should be a MUST, and the metho= ds for >> enforcing that =E2=80=9CMUST=E2=80=9D are going to vary based on the dep= loyments and >> implementations out there. >> >> > I'd be okay with making it a MUST but think maybe it'd be good to hear > from a few more people in the WG before committing to that change. > > Can I ask some folks to weigh in on this one? I'm leaning towards making > the change barring objections. > > > *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 sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000fbf08f05adcf2ca2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think one-time use may be overly restrictive, and I don&= #39;t think it is the property that we actually want.

Gi= ve the request URI is in a redirect from the browser, there is a good chanc= e of a race condition where the same browser request is made more than once= , for example, while the browser is loading the authorization URL at the AS= , the user could refresh the page causing the authorization URL to be reloa= ded. Would the reload count as a second use? One could argue it either=C2= =A0way.

What I think we want from what I understan= d, is the request URI MUST be unique so that there is no confusion on which= request is being referenced.=C2=A0

I did not see = anything about the expiry time of the request URI (but I did not look super= hard). If that is not there, then I think the request URI MUST expire in a= "short" period of time.


=
=E1=90=A7

On Wed, Aug 26, 2020 at 1:45 PM Br= ian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
T= hanks=C2=A0Justin. Just a couple more responses to responses inline below (= but with lots of content that needs no further discussion removed).

A TL;DR for the WG is that I'd like = to get some wider feedback on the question of changing the one-time-use con= dition on the request_uri from a SHOULD to a MUST.

On Tue, Aug 25, 2020= at 4:57 PM Justin Richer <jricher@mit.edu> wrote:
Hi Brian, just a couple responses inline where = it seemed fitting. Thanks for going through everything!
=C2=A0=E2=80=94= Justin

On Aug 25, 2020, at 6:01= PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks for the review and comments Justin.= Replies (or attempts thereat) are inline below.

=
On Wed, Aug 19, 2020 at 2:06 PM Justin Richer <jricher@mit.edu> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
I=E2=80=99ve done a full read through of the PAR specification, and here a= re my notes on it.


=C2=A0 =C2=A0 =C2=B62: Of necessity, this = spec mixes parameters in the authorization endpoint and token endpoint regi= stries into a single request. Is there any danger of conflict between them?= The registry holds them in one list but they could possibly have different= semantics in both places.

I th= ink that technically such danger does exist but that it's highly unlike= ly in practice. Especially because the only token endpoint parameters that = are relevant to PAR are those that deal with client authentication (current= ly client_secret, client_assertion, and client_assertion_type). I'm als= o not sure what can reasonably be done about it given the way the registrie= s are. I guess PAR could update the registration for those three (client_se= cret, client_assertion, and client_assertion_type) to also indicate authori= zation request as a usage location with some commentary that it's only = for avoiding name collisions. And offer some guidance about doing the same = for any future client auth methods being defined. But honestly I'm not = sure what, if anything, to do here?=C2=A0

And= yes it is super unfortunate that client auth and protocol parameters got m= ixed together in the HTTP body. I didn't cause that situation but I'= ;ve certainly contributed to it and for that I apologize.
<= /blockquote>

I think the = only perfect solution is to go back in time and fix the registries with bas= ed on the last decade of knowledge in using them. :P=C2=A0

For this, I think maybe being very prescriptive about the fact tha= t the only parameters from the token endpoint that are allowed here are tho= se used for client authentication and that when they show up, they=E2=80=99= re interpreted as in the token endpoint request not the authorization endpo= int request. Does that work?

<= /div>
I think so, yes. And will work on incorporating some text towards= that end.


=C2=A0
=C2=A0 =C2=A0 I don=E2=80=99t s= ee why a request URI with unguessable values isn=E2=80=99t a MUST for one-t= ime-use, is there a reason?

The= reason AFAIK was to not be overly prescriptive and allow for eventually co= nsistent or not atomic storage of the data by not strictly requiring the AS= to enforce one-time-use. Do you think that's too loose or could be wor= ded/explained differently or better?=C2=A0

I do think it=E2=80=99s too loose and it should be= a MUST, and the methods for enforcing that =E2=80=9CMUST=E2=80=9D are goin= g to vary based on the deployments and implementations out there.=C2=A0

I'd be okay wi= th making it a MUST but think maybe it'd be good to hear from a few mor= e people in the WG before committing to that change.

Can I ask some folks to weigh in on this one? I'm leaning towar= ds making the change barring objections.


<= 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 th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000fbf08f05adcf2ca2-- From nobody Thu Aug 27 06:48:45 2020 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 301423A0B2C for ; Thu, 27 Aug 2020 06:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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 hFUNlhPmEVcg for ; Thu, 27 Aug 2020 06:48:43 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 B326A3A0943 for ; Thu, 27 Aug 2020 06:48:42 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id a21so7764566ejp.0 for ; Thu, 27 Aug 2020 06:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kHeXIKmH65EUQSrx7OAbDut9oPWI2hHaFImpWWyBHlQ=; b=doTCS7PDZosT+LySONKvde5DR2C3j6Hv31x8SWSktmBbdFnk6/aE2BTuDL9yxt0oCW 6xXjHVVPoWm9XAI8mj51PYzOwyZ9nbjcfnlpYUaw3xirVS9jCTJq2wjMjfDoWOCki/4Q b0kjYW188d+hatKp5C01xo6Nc/oRz6TTZyBLEJMa09dqVfR6M/s14sHcgyXCcWxox5Tb dq2VhNKAXthc6UBfCmMyt633NqisPqm2wYtNeA48RzoiSjsqaI/PPLiNGPK4MOOzq5zF 5ekiJGUgDlzeZFXxSqePdqMSG69dBkLXWNA5hP9mjy/0KT6Jv1dRtnOoJFLSGmwlwFrL Uq7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kHeXIKmH65EUQSrx7OAbDut9oPWI2hHaFImpWWyBHlQ=; b=TsaNCpDR1g/EFV5WVaME1jJFpkb2xOvq0jQfiPxFNzfPTgTyl09sYE1Z2kgxdmk2SV V8kRdHhe78Kc9d1XjPy5sjT7G9/GuYuLPsx5a+7SNuuqvqDNFBSQHRYZXTuNyUTkwx9H +hqLQQUMS5YlLWPXCznmRurQEdq/qf/GLBjOU2KCSGps0VbqyxxA87oUvVZFcjU+036Z M6iwN6Ayj8lOoH1hkhfmx59bb9MXYJAPAGMNs9ph6iZvqMhoHSoNH3wXum838GGNZVF8 yarx1Eip1xoKG/GNt5eVF62FOVS37Q9/lc0WM9K7f0wUDVDkvO8sP4EEqHdf4Hr05dg7 rT7A== X-Gm-Message-State: AOAM5318oGvrnN5taFENgux36kFvagerfOYHatJ2ic8pHlfuaqZ2fUsT moyh94CHXaIqrT4h7DUg4WUPXg== X-Google-Smtp-Source: ABdhPJw/b4yn0hEbsFobapzU0mz0UJwq90mQdze6JP9aiUd3p4I/Hqw+3qZaE83bn47S8AX51sPW6w== X-Received: by 2002:a17:906:54d3:: with SMTP id c19mr22307411ejp.408.1598536121160; Thu, 27 Aug 2020 06:48:41 -0700 (PDT) Received: from p200300eb8f1e2a30818db2e1d08b89c0.dip0.t-ipconnect.de (p200300eb8f1e2a30818db2e1d08b89c0.dip0.t-ipconnect.de. [2003:eb:8f1e:2a30:818d:b2e1:d08b:89c0]) by smtp.gmail.com with ESMTPSA id e14sm1615365edl.86.2020.08.27.06.48.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Aug 2020 06:48:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Torsten Lodderstedt In-Reply-To: Date: Thu, 27 Aug 2020 15:48:38 +0200 Cc: "last-call@ietf.org" , oauth Content-Transfer-Encoding: quoted-printable Message-Id: <412A63AD-DDE1-4BFE-8234-5A721A0ED88D@lodderstedt.net> References: To: Mike Jones , "dick.hardt" X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 27 Aug 2020 13:48:44 -0000 Will the following text work for you? Implementers should be aware that a token introspection request lets the = AS know when the client=20 (and potentially the user) is accessing the RS, which is also an = indication of when the user is using=20 the client. If this impliction is not accepatable, implementars = MUST use other means to carry=20 access token data, e.g. directly transferring the data needed by = the RS within the access token. > On 26. Aug 2020, at 23:12, Mike Jones = wrote: >=20 > I agree with Dick=E2=80=99s observation about the privacy implications = of using an Introspection Endpoint. That=E2=80=99s why it=E2=80=99s = preferable to not use one at all and instead directly have the Resource = understand the Access Token. One way of doing this is the JWT Access = Token spec. There are plenty of others. > =20 > The downsides of using an Introspection Endpoint should be described = in the Privacy Considerations section. > =20 > -- Mike > =20 > From: OAuth On Behalf Of Dick Hardt > Sent: Wednesday, August 26, 2020 9:52 AM > To: Torsten Lodderstedt > Cc: last-call@ietf.org; oauth > Subject: Re: [OAUTH-WG] Last Call: = (JWT Response for = OAuth Token Introspection) to Proposed Standard > =20 > =20 > =20 > On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt = wrote: > Hi Denis, >=20 > > On 25. Aug 2020, at 16:55, Denis wrote: >=20 > > The fact that the AS will know exactly when the introspection call = has been made and thus be able to make sure which client=20 > > has attempted perform an access to that RS and at which instant of = time. The use of this call allows an AS to track where and when=20 > > its clients have indeed presented an issued access token. >=20 > That is a fact. I don=E2=80=99t think it is an issue per se. Please = explain the privacy implications. > =20 > As I see it, the privacy implication is that the AS knows when the = client (and potentially the user) is accessing the RS, which is also an = indication of when the user is using the client. > =20 > I think including this implication would be important to have in a = Privacy Considerations section. > =20 > /Dick > =E1=90=A7 From nobody Thu Aug 27 07:17:39 2020 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 408893A0C6F for ; Thu, 27 Aug 2020 07:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 K6VtKSuos3lz for ; Thu, 27 Aug 2020 07:17:36 -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 6B0F43A0CA8 for ; Thu, 27 Aug 2020 07:17:36 -0700 (PDT) Received: from [192.168.1.11] (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 07REHSHW028210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Aug 2020 10:17:29 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2C684F06-197A-47B1-9489-A3A02397FD15" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 27 Aug 2020 10:17:28 -0400 In-Reply-To: Cc: Brian Campbell , oauth To: Dick Hardt References: <7C0FD285-F677-4501-B2FB-9431A59855F6@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] WGLC Review of PAR 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, 27 Aug 2020 14:17:38 -0000 --Apple-Mail=_2C684F06-197A-47B1-9489-A3A02397FD15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We already have this same property with authorization codes, and it=E2=80=99= s managed today reasonably well (in my opinion). If you submit the same = request URI twice in the same browser (the refresh you=E2=80=99re = talking about), it shouldn=E2=80=99t start two separate authorization = requests, but it would be reasonable to detect that the same session = attached to the same request URI value showed up twice and continue the = session as appropriate.=20 None of this is in conflict with =E2=80=9Cone time use=E2=80=9D, in my = view, since you=E2=80=99re actively detecting the session and source of = the value. =E2=80=94 Justin > On Aug 26, 2020, at 6:16 PM, Dick Hardt wrote: >=20 > I think one-time use may be overly restrictive, and I don't think it = is the property that we actually want. >=20 > Give the request URI is in a redirect from the browser, there is a = good chance of a race condition where the same browser request is made = more than once, for example, while the browser is loading the = authorization URL at the AS, the user could refresh the page causing the = authorization URL to be reloaded. Would the reload count as a second = use? One could argue it either way. >=20 > What I think we want from what I understand, is the request URI MUST = be unique so that there is no confusion on which request is being = referenced.=20 >=20 > I did not see anything about the expiry time of the request URI (but I = did not look super hard). If that is not there, then I think the request = URI MUST expire in a "short" period of time. >=20 >=20 >=20 > =E1=90=A7 >=20 > On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell = > wrote: > Thanks Justin. Just a couple more responses to responses inline below = (but with lots of content that needs no further discussion removed).=20 >=20 > A TL;DR for the WG is that I'd like to get some wider feedback on the = question of changing the one-time-use condition on the request_uri from = a SHOULD to a MUST.=20 >=20 > On Tue, Aug 25, 2020 at 4:57 PM Justin Richer > wrote: > Hi Brian, just a couple responses inline where it seemed fitting. = Thanks for going through everything! > =E2=80=94 Justin >=20 >> On Aug 25, 2020, at 6:01 PM, Brian Campbell = > wrote: >>=20 >> Thanks for the review and comments Justin. Replies (or attempts = thereat) are inline below. >>=20 >>=20 >> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer > wrote: >> I=E2=80=99ve done a full read through of the PAR specification, and = here are my notes on it. >>=20 >>=20 >> =C2=B62: Of necessity, this spec mixes parameters in the = authorization endpoint and token endpoint registries into a single = request. Is there any danger of conflict between them? The registry = holds them in one list but they could possibly have different semantics = in both places. >>=20 >> I think that technically such danger does exist but that it's highly = unlikely in practice. Especially because the only token endpoint = parameters that are relevant to PAR are those that deal with client = authentication (currently client_secret, client_assertion, and = client_assertion_type). I'm also not sure what can reasonably be done = about it given the way the registries are. I guess PAR could update the = registration for those three (client_secret, client_assertion, and = client_assertion_type) to also indicate authorization request as a usage = location with some commentary that it's only for avoiding name = collisions. And offer some guidance about doing the same for any future = client auth methods being defined. But honestly I'm not sure what, if = anything, to do here? =20 >>=20 >> And yes it is super unfortunate that client auth and protocol = parameters got mixed together in the HTTP body. I didn't cause that = situation but I've certainly contributed to it and for that I apologize.=20= >=20 > I think the only perfect solution is to go back in time and fix the = registries with based on the last decade of knowledge in using them. :P=20= >=20 > For this, I think maybe being very prescriptive about the fact that = the only parameters from the token endpoint that are allowed here are = those used for client authentication and that when they show up, = they=E2=80=99re interpreted as in the token endpoint request not the = authorization endpoint request. Does that work? >=20 > I think so, yes. And will work on incorporating some text towards that = end.=20 >=20 >=20 > =20 >> I don=E2=80=99t see why a request URI with unguessable values = isn=E2=80=99t a MUST for one-time-use, is there a reason? >>=20 >> The reason AFAIK was to not be overly prescriptive and allow for = eventually consistent or not atomic storage of the data by not strictly = requiring the AS to enforce one-time-use. Do you think that's too loose = or could be worded/explained differently or better?=20 >=20 > I do think it=E2=80=99s too loose and it should be a MUST, and the = methods for enforcing that =E2=80=9CMUST=E2=80=9D are going to vary = based on the deployments and implementations out there.=20 >=20 >=20 > I'd be okay with making it a MUST but think maybe it'd be good to hear = from a few more people in the WG before committing to that change.=20 >=20 > Can I ask some folks to weigh in on this one? I'm leaning towards = making the change barring objections.=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.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_2C684F06-197A-47B1-9489-A3A02397FD15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We = already have this same property with authorization codes, and it=E2=80=99s= managed today reasonably well (in my opinion). If you submit the same = request URI twice in the same browser (the refresh you=E2=80=99re = talking about), it shouldn=E2=80=99t start two separate authorization = requests, but it would be reasonable to detect that the same session = attached to the same request URI value showed up twice and continue the = session as appropriate. 

None of this is in conflict with =E2=80=9Cone time use=E2=80=9D= , in my view, since you=E2=80=99re actively detecting the session and = source of the value.

 =E2=80=94 Justin

On Aug = 26, 2020, at 6:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I think one-time use may be = overly restrictive, and I don't think it is the property that we = actually want.

Give = the request URI is in a redirect from the browser, there is a good = chance of a race condition where the same browser request is made more = than once, for example, while the browser is loading the authorization = URL at the AS, the user could refresh the page causing the authorization = URL to be reloaded. Would the reload count as a second use? One could = argue it either way.

What I think we want from what I understand, is the request = URI MUST be unique so that there is no confusion on which request is = being referenced. 

I did not see anything about the expiry time of the request = URI (but I did not look super hard). If that is not there, then I think = the request URI MUST expire in a "short" period of time.



3D""=E1=90=A7

On Wed, Aug = 26, 2020 at 1:45 PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Thanks Justin. Just a couple more responses = to responses inline below (but with lots of content that needs no = further discussion removed).

A TL;DR for the WG is = that I'd like to get some wider feedback on the question of changing the = one-time-use condition on the request_uri from a SHOULD to a MUST.

On Tue, Aug 25, 2020 at 4:57 PM Justin = Richer <jricher@mit.edu> wrote:
Hi Brian, just = a couple responses inline where it seemed fitting. Thanks for going = through everything!
 =E2=80=94 Justin

On Aug 25, 2020, at 6:01 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Thanks for the review and comments Justin. = Replies (or attempts thereat) are inline below.


On Wed, Aug = 19, 2020 at 2:06 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99ve= done a full read through of the PAR specification, and here are my = notes on it.


    =C2=B62: = Of necessity, this spec mixes parameters in the authorization endpoint = and token endpoint registries into a single request. Is there any danger = of conflict between them? The registry holds them in one list but they = could possibly have different semantics in both = places.

I think that technically such danger does exist but that it's = highly unlikely in practice. Especially because the only token endpoint = parameters that are relevant to PAR are those that deal with client = authentication (currently client_secret, client_assertion, and = client_assertion_type). I'm also not sure what can reasonably be done = about it given the way the registries are. I guess PAR could update the = registration for those three (client_secret, client_assertion, and = client_assertion_type) to also indicate authorization request as a usage = location with some commentary that it's only for avoiding name = collisions. And offer some guidance about doing the same for any future = client auth methods being defined. But honestly I'm not sure what, if = anything, to do here? 

And yes it is super unfortunate that = client auth and protocol parameters got mixed together in the HTTP body. = I didn't cause that situation but I've certainly contributed to it and = for that I apologize.

I think the only perfect = solution is to go back in time and fix the registries with based on the = last decade of knowledge in using them. :P 

For this, I think maybe being very = prescriptive about the fact that the only parameters from the token = endpoint that are allowed here are those used for client authentication = and that when they show up, they=E2=80=99re interpreted as in the token = endpoint request not the authorization endpoint request. Does that = work?

I think so, yes. And will work on = incorporating some text towards that end.


 
    I don=E2=80=99t see why a request URI with = unguessable values isn=E2=80=99t a MUST for one-time-use, is there a = reason?

The reason AFAIK was to not be overly prescriptive and allow = for eventually consistent or not atomic storage of the data by not = strictly requiring the AS to enforce one-time-use. Do you think that's = too loose or could be worded/explained differently or better?  =

I do think it=E2=80=99s too loose and = it should be a MUST, and the methods for enforcing that =E2=80=9CMUST=E2=80= =9D are going to vary based on the deployments and implementations out = there. 


I'd be okay with making = it a MUST but think maybe it'd be good to hear from a few more people in = the WG before committing to that change.

Can I ask some folks to = weigh in on this one? I'm leaning towards making the change barring = objections.


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

= --Apple-Mail=_2C684F06-197A-47B1-9489-A3A02397FD15-- From nobody Thu Aug 27 07:20:03 2020 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 3E56E3A0CD7; Thu, 27 Aug 2020 07:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 uohW2p17y9nc; Thu, 27 Aug 2020 07:19:54 -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 B3BCF3A0CC5; Thu, 27 Aug 2020 07:19:54 -0700 (PDT) Received: from [192.168.1.11] (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 07REJpgk029106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Aug 2020 10:19:52 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8AB5B518-8B9A-44E8-81EA-0DDDD1B8CE01" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 27 Aug 2020 10:19:51 -0400 In-Reply-To: <412A63AD-DDE1-4BFE-8234-5A721A0ED88D@lodderstedt.net> Cc: Mike Jones , "dick.hardt" , "last-call@ietf.org" , oauth To: Torsten Lodderstedt References: <412A63AD-DDE1-4BFE-8234-5A721A0ED88D@lodderstedt.net> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 27 Aug 2020 14:19:56 -0000 --Apple-Mail=_8AB5B518-8B9A-44E8-81EA-0DDDD1B8CE01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would clarify that this doesn=E2=80=99t necessarily say that the = user=E2=80=99s there, and remove the normative requirement (which = doesn=E2=80=99t have enforceable teeth in this context): Implementers should be aware that a token introspection request lets the = AS know when the client=20 (and potentially the user) is accessing the RS, which can also = indicate when the user is using=20 the client. If this implication is not acceptable, implementers can = use other means to carry=20 access token data, e.g. directly transferring the data needed by the = RS within the access token. =E2=80=94 Justin > On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt = wrote: >=20 > Will the following text work for you? >=20 > Implementers should be aware that a token introspection request lets = the AS know when the client=20 > (and potentially the user) is accessing the RS, which is also an = indication of when the user is using=20 > the client. If this impliction is not accepatable, implementars = MUST use other means to carry=20 > access token data, e.g. directly transferring the data needed by = the RS within the access token. >=20 >=20 >> On 26. Aug 2020, at 23:12, Mike Jones = wrote: >>=20 >> I agree with Dick=E2=80=99s observation about the privacy = implications of using an Introspection Endpoint. That=E2=80=99s why = it=E2=80=99s preferable to not use one at all and instead directly have = the Resource understand the Access Token. One way of doing this is the = JWT Access Token spec. There are plenty of others. >>=20 >> The downsides of using an Introspection Endpoint should be described = in the Privacy Considerations section. >>=20 >> -- Mike >>=20 >> From: OAuth On Behalf Of Dick Hardt >> Sent: Wednesday, August 26, 2020 9:52 AM >> To: Torsten Lodderstedt >> Cc: last-call@ietf.org; oauth >> Subject: Re: [OAUTH-WG] Last Call: = (JWT Response for = OAuth Token Introspection) to Proposed Standard >>=20 >>=20 >>=20 >> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt = wrote: >> Hi Denis, >>=20 >>> On 25. Aug 2020, at 16:55, Denis wrote: >>=20 >>> The fact that the AS will know exactly when the introspection call = has been made and thus be able to make sure which client=20 >>> has attempted perform an access to that RS and at which instant of = time. The use of this call allows an AS to track where and when=20 >>> its clients have indeed presented an issued access token. >>=20 >> That is a fact. I don=E2=80=99t think it is an issue per se. Please = explain the privacy implications. >>=20 >> As I see it, the privacy implication is that the AS knows when the = client (and potentially the user) is accessing the RS, which is also an = indication of when the user is using the client. >>=20 >> I think including this implication would be important to have in a = Privacy Considerations section. >>=20 >> /Dick >> =E1=90=A7 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_8AB5B518-8B9A-44E8-81EA-0DDDD1B8CE01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = would clarify that this doesn=E2=80=99t necessarily say that the = user=E2=80=99s there, and remove the normative requirement (which = doesn=E2=80=99t have enforceable teeth in this context):

Implementers should be = aware that a token introspection request lets the AS know when = the client 
    (and potentially the = user) is accessing the RS, which can also indicate = when the user is using 
    the = client. If this implication is not acceptable, implementers = can use other means to carry 
    = access token data, e.g. directly transferring the data needed by the RS = within the access token.


 =E2=80=94 Justin

On Aug = 27, 2020, at 9:48 AM, Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> = wrote:

Will the following text work for you?

Implementers should be aware that a token introspection = request lets the AS know when the client
=     (and potentially the user) is accessing the RS, = which is also an indication of when the user is using
=     the client. If this impliction is not = accepatable, implementars MUST use other means to carry
=     access token data, e.g. directly transferring = the data needed by the RS within the access token.


On 26. = Aug 2020, at 23:12, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:

I agree with Dick=E2=80=99s = observation about the privacy implications of using an Introspection = Endpoint.  That=E2=80=99s why it=E2=80=99s preferable to not use = one at all and instead directly have the Resource understand the Access = Token.  One way of doing this is the JWT Access Token spec. =  There are plenty of others.

The = downsides of using an Introspection Endpoint should be described in the = Privacy Considerations section.

=             &n= bsp;           &nbs= p;            =             &n= bsp;    -- Mike

From: = OAuth <oauth-bounces@ietf.org> On Behalf Of Dick Hardt
Sent: Wednesday, August 26, 2020 9:52 AM
To: = Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>
Cc: last-call@ietf.org; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Last Call: = <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response = for OAuth Token Introspection) to Proposed Standard



On Wed, Aug 26, 2020 at 4:37 AM = Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
Hi Denis,

On 25. Aug 2020, at 16:55, Denis <denis.ietf@free.fr> = wrote:

The fact that the AS will know exactly when the = introspection call has been made and thus be able to make sure which = client
has attempted perform an access to that RS and at = which instant of time. The use of this call allows an AS to track where = and when
its clients have indeed presented an issued = access token.

That is a fact. = I don=E2=80=99t think it is an issue per se. Please explain the privacy = implications.

As I see it, the privacy = implication is that the AS knows when the client (and potentially the = user) is accessing the RS, which is also an indication of when the user = is using the client.

I think including this = implication would be important to have in a Privacy Considerations = section.

/Dick
=E1=90=A7

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

= --Apple-Mail=_8AB5B518-8B9A-44E8-81EA-0DDDD1B8CE01-- From nobody Thu Aug 27 07:45:09 2020 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 0D3603A0C49 for ; Thu, 27 Aug 2020 07:45:04 -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 zhgdP9c-FdZY for ; Thu, 27 Aug 2020 07:45:01 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 0CD1F3A0C44 for ; Thu, 27 Aug 2020 07:45:00 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id q8so673187lfb.6 for ; Thu, 27 Aug 2020 07:45:00 -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=lZqF5of2yXmlvWhKVRdpoKle/3s+CWYzsqKVEwuEFyQ=; b=ITyxToFkm+B8kUZw929DAGszuDdZnJ+gardwYDll7BRS/y85drCwZPs20dLOLqrsdP vIMFRRBj4IPD4pjb3L2/kfbG747JcLFcEnRxpDpmG7VBQ4aVtbIUV/hhx3v4PMqC7XNJ KC7jZAiScTGeXVJ4ZeGZrKr7jA5VncRvhZUPhjCASxHmNAFqQLur92QGXkdTbCyVFeHs zEGfqHMljJn2/cFwpe6rQmFkaqFGRr3fjNfDVoxVP5tnBmKg9SHQkhUbUJ/fyFoDyqXd xwH6lbxq4KxtUoKjBZr+xSkY6uXXrVRA82vopV/6gjZoOk0A3+y5fxb/U0aewudx0W43 5hkg== 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=lZqF5of2yXmlvWhKVRdpoKle/3s+CWYzsqKVEwuEFyQ=; b=bHmLVdZHoeRVT3cwL5tNUrliYndqs7mUCezuM2WwevPEgsO4e3fDwfkj9ou/j7kyEs Rbq+wAaqhh2Pp23A4BfGHqwHkQjsTWR6t/eZD+UTgoB9IJUs7SF24AknUZpR7NovKQRM 1pz58Xjg/rxqOqjlen3EexIGjB7umkgqGlSNDzy2BWYxQwp7MtDCHoHUeQWfoH5rUIZ7 uiPTvME02rOsmMfjWk9IJ6js6bfnrX+6uFlNl1Gc3mHoQo4EC0/GY9ZJoDwqeZPGaOXv gxxbsWAHC3a0tbjbSYwIbZotPCVINC68sH7EOs1kKW0Kzb/w4NQVn3ATfLfm0vCsq8kx K08Q== X-Gm-Message-State: AOAM533iXZer/16V+kzaT1x2bJHilEBPH5ejSzPzlORu8foF9GK/UbM1 vHCZhIl52AC66oPnBQnyO7YNVFwME8t3Pd36p1R2ibveOgb95jwlRGOfDKxpVjls0MRvPDBBcvk xZ1FRHYdRXO6PvQ== X-Google-Smtp-Source: ABdhPJxYeQPGOq4FXYuoqXYC44ACV0drNXKitBUL/FuewOaoqsbt0yc8y1pqU4nF7YHEMrBv0m5s+yQIOvjjgrRvtPQ= X-Received: by 2002:a19:6e45:: with SMTP id q5mr10125424lfk.104.1598539498917; Thu, 27 Aug 2020 07:44:58 -0700 (PDT) MIME-Version: 1.0 References: <412A63AD-DDE1-4BFE-8234-5A721A0ED88D@lodderstedt.net> In-Reply-To: From: Brian Campbell Date: Thu, 27 Aug 2020 08:44:32 -0600 Message-ID: To: Justin Richer Cc: Torsten Lodderstedt , "last-call@ietf.org" , oauth , Mike Jones , "dick.hardt" Content-Type: multipart/alternative; boundary="000000000000fe33a305addcfab8" Archived-At: Subject: Re: [OAUTH-WG] [Last-Call] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 27 Aug 2020 14:45:04 -0000 --000000000000fe33a305addcfab8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Thu, Aug 27, 2020 at 8:20 AM Justin Richer wrote: > I would clarify that this doesn=E2=80=99t necessarily say that the user= =E2=80=99s there, > and remove the normative requirement (which doesn=E2=80=99t have enforcea= ble teeth > in this context): > > Implementers should be aware that a token introspection request lets the > AS know when the client > (and potentially the user) is accessing the RS, which *can also > indicate* when the user is using > the client. If this implication is not acceptable, *implementers can > use other means* to carry > access token data, e.g. directly transferring the data needed by the > RS within the access token. > > > =E2=80=94 Justin > > On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt < > torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote: > > Will the following text work for you? > > Implementers should be aware that a token introspection request lets the > AS know when the client > (and potentially the user) is accessing the RS, which is also an > indication of when the user is using > the client. If this impliction is not accepatable, implementars MUST > use other means to carry > access token data, e.g. directly transferring the data needed by the > RS within the access token. > > > On 26. Aug 2020, at 23:12, Mike Jones < > Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: > > I agree with Dick=E2=80=99s observation about the privacy implications of= using an > Introspection Endpoint. That=E2=80=99s why it=E2=80=99s preferable to no= t use one at all > and instead directly have the Resource understand the Access Token. One > way of doing this is the JWT Access Token spec. There are plenty of othe= rs. > > The downsides of using an Introspection Endpoint should be described in > the Privacy Considerations section. > > -- Mike > > From: OAuth On Behalf Of Dick Hardt > Sent: Wednesday, August 26, 2020 9:52 AM > To: Torsten Lodderstedt > Cc: last-call@ietf.org; oauth > Subject: Re: [OAUTH-WG] Last Call: > (JWT Response for > OAuth Token Introspection) to Proposed Standard > > > > On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt < > torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote: > Hi Denis, > > On 25. Aug 2020, at 16:55, Denis wrote: > > > The fact that the AS will know exactly when the introspection call has > been made and thus be able to make sure which client > has attempted perform an access to that RS and at which instant of time. > The use of this call allows an AS to track where and when > its clients have indeed presented an issued access token. > > > That is a fact. I don=E2=80=99t think it is an issue per se. Please expla= in the > privacy implications. > > As I see it, the privacy implication is that the AS knows when the client > (and potentially the user) is accessing the RS, which is also an indicati= on > of when the user is using the client. > > I think including this implication would be important to have in a Privac= y > Considerations section. > > /Dick > =E1=90=A7 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call > --=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._ --000000000000fe33a305addcfab8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Thu, Aug 27, 2020 at 8:20 AM Justin Richer <jricher@mit.edu> wrote:
I would clarify that this doesn=E2=80=99t necessarily say th= at the user=E2=80=99s there, and remove the normative requirement (which do= esn=E2=80=99t have enforceable teeth in this context):

I= mplementers should be aware that a token introspection request lets the AS = know when the=C2=A0client=C2=A0
=C2=A0 =C2=A0 (and potentially the user)= is accessing the RS, which can also indicate when the user is=C2=A0= using=C2=A0
=C2=A0 =C2=A0 the client. If this implication is not accepta= ble, implementers can use other means to carry=C2=A0
=C2=A0 =C2= =A0 access token data, e.g. directly transferring the data needed by the RS= within the access token.


=C2=A0=E2= =80=94 Justin

On Aug 27, 2020,= at 9:48 AM, Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc= .ietf.org> wrote:

Will the following text work fo= r you?

Implementers should be aware that a token introspection reque= st lets the AS know when the client
=C2=A0=C2=A0=C2=A0=C2=A0(and poten= tially the user) is accessing the RS, which is also an indication of when t= he user is using
=C2=A0=C2=A0=C2=A0=C2=A0the client. If this implictio= n is not accepatable, implementars MUST use other means to carry
=C2= =A0=C2=A0=C2=A0=C2=A0access token data, e.g. directly transferring the data= needed by the RS within the access token.


On 26. Aug 2020, at 23:12, Mike Jones <Michael.Jones=3D40m= icrosoft.com@dmarc.ietf.org> wrote:

I agree with Dick=E2=80= =99s observation about the privacy implications of using an Introspection E= ndpoint.=C2=A0 That=E2=80=99s why it=E2=80=99s preferable to not use one at= all and instead directly have the Resource understand the Access Token.=C2= =A0 One way of doing this is the JWT Access Token spec.=C2=A0 There are ple= nty of others.

The downsides of using an Introspection Endpoint shou= ld be described in the Privacy Considerations section.

=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=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=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-- Mike

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Dic= k Hardt
Sent: Wednesday, August 26, 2020 9:52 AM
To: Torsten Lodderst= edt <torsten=3D40lodderstedt.net@dmarc.ietf.org>
Cc: last-call@ietf.org;= oauth <oauth@ietf.o= rg>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i= ntrospection-response-09.txt> (JWT Response for OAuth Token Introspectio= n) to Proposed Standard



On Wed, Aug 26, 2020 at 4:37 AM Tors= ten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>= wrote:
Hi Denis,

On 25. Aug 2020, at 1= 6:55, Denis <den= is.ietf@free.fr> wrote:

The fact that the AS will know exactly when the introspection call has be= en made and thus be able to make sure which client
has attempted perfor= m an access to that RS and at which instant of time. The use of this call a= llows an AS to track where and when
its clients have indeed presented a= n issued access token.

That is a fact. I don=E2=80=99t = think it is an issue per se. Please explain the privacy implications.
As I see it, the privacy implication is that the AS knows when the client= (and potentially the user) is accessing the RS, which is also an indicatio= n of when the user is using the client.

I think including this impli= cation would be important to have in a Privacy Considerations section.
<= br>/Dick
=E1=90=A7

_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo= /oauth

--
last-call mailing list
last-call@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/last-call

<= 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. --000000000000fe33a305addcfab8-- From nobody Thu Aug 27 09:12:49 2020 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 8379A3A0FE9 for ; Thu, 27 Aug 2020 09:12:47 -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_FONT_LOW_CONTRAST=0.001, 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=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 Lph868Re5mSb for ; Thu, 27 Aug 2020 09:12:45 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 0F1753A100F for ; Thu, 27 Aug 2020 09:12:37 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id w25so7038303ljo.12 for ; Thu, 27 Aug 2020 09:12:36 -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=5z/7AGJOuTsSpAzZp/P9Ah2NqWIRN4yAsL8mdCWtC5I=; b=QHIV5LCknk4+f3yTTdQrrerN8/ETNYw3vMn840Xf8P/hDbbh+aTAw5jeAB9iGG4f2/ eyljbe+LhU0ldGJtnHunG4LX88wmVv5eu1aJyDJwVPHJ7rwC4Uniswy0Z/mzBvwEOIOm YqBkJeHPjqemRlPPJWricq1GkplCTchmBSP9lneLCRf8CVhjAZA3pxeDnyHHMZbS/lUj JR8uc2TrvTOhWCnS3ESzR8QereLnBdOfKxKA6WW8G9HR53Y223GDrklS/oaAc0c0LK5/ 4ipd+DIbnj2H2fykHTDjuv3BGA4BUZumFvr9jKsoXHJiYFIIxLgXPB4KWEOcvfHUFjTK cpYQ== 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=5z/7AGJOuTsSpAzZp/P9Ah2NqWIRN4yAsL8mdCWtC5I=; b=KlmtDPSCqIMXHHtiu25Ikdgs2WLLkkoTxCjqv2z/v76JRm8vAMZ3Tdu2dafJa9ATIj ilqCrFd/BsFj7nLhBtrSGp7Y8v2J5X/nrYghBWB/4i4DjZOdgoQwn77f4JlsSCVkEJkL 5wBNpefOFnaTKlnOYFmV3JPjHL2UUDqXip9YAMKnW2FlXFL4QBrtHn6G0IS+SdON3lz1 lzRm+MNJ9mpTRv0vh919sOOj5cV96hKdhvAXoVQRqhVQuPmdE00poeJa+zTDlyp9bhnL Fjo368BIqdxAzsDPp0xm5wiWrgrzTM2WrmDjZOKD61tbHMIxg0uaMPJLh++n6tcbcy1Z d8Ug== X-Gm-Message-State: AOAM5332tL1Nys56QnZe7C7Olrgt4gNF3pevQ7bU/Mtd1MRyUKsjtY96 2LcaWEnrpMpDCU+yAqAih1L/BgOBU+4laLUqhsg= X-Google-Smtp-Source: ABdhPJxE53Zs9KXVGAXDXqFW2EY14VQKXMnsnyW5073eCuB3p00gAlUsDcKkkRhZquZDdaZi9qqoXmsvrTCaiYKcklA= X-Received: by 2002:a2e:9695:: with SMTP id q21mr9179145lji.437.1598544754767; Thu, 27 Aug 2020 09:12:34 -0700 (PDT) MIME-Version: 1.0 References: <7C0FD285-F677-4501-B2FB-9431A59855F6@mit.edu> In-Reply-To: From: Dick Hardt Date: Thu, 27 Aug 2020 09:11:57 -0700 Message-ID: To: Justin Richer Cc: Brian Campbell , oauth Content-Type: multipart/alternative; boundary="00000000000043fb6005adde34e8" Archived-At: Subject: Re: [OAUTH-WG] WGLC Review of PAR 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, 27 Aug 2020 16:12:48 -0000 --00000000000043fb6005adde34e8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That is not correct. The authorization code one-time-use is directly between the client and the AS. The client has a number of mechanisms to ensure it only presents the authorization code to the AS once, such as a session that was set when the user started at the client. In contrast, in a redirect from the client to the AS, the client loses control on how many times the user-agent loads the URL at the AS. Additionally, there is unlikely to be an active browser session at the AS, so the AS can not easily differentiate between a URL load from the same user, or different users. If one-time-use, one of them MUST fail. If the two requests happen to be from the same user (because of a reload, which the user did because the AS was slow to respond), there is no way for the AS to know which of the requests is the one that is current in front of the user. While the AS can internally ensure processing of the request once, one-time-use would dictate that it provides a failure message to one of the requests. /Dick =E1=90=A7 On Thu, Aug 27, 2020 at 7:17 AM Justin Richer wrote: > We already have this same property with authorization codes, and it=E2=80= =99s > managed today reasonably well (in my opinion). If you submit the same > request URI twice in the same browser (the refresh you=E2=80=99re talking= about), > it shouldn=E2=80=99t start two separate authorization requests, but it wo= uld be > reasonable to detect that the same session attached to the same request U= RI > value showed up twice and continue the session as appropriate. > > None of this is in conflict with =E2=80=9Cone time use=E2=80=9D, in my vi= ew, since you=E2=80=99re > actively detecting the session and source of the value. > > =E2=80=94 Justin > > On Aug 26, 2020, at 6:16 PM, Dick Hardt wrote: > > I think one-time use may be overly restrictive, and I don't think it is > the property that we actually want. > > Give the request URI is in a redirect from the browser, there is a good > chance of a race condition where the same browser request is made more th= an > once, for example, while the browser is loading the authorization URL at > the AS, the user could refresh the page causing the authorization URL to = be > reloaded. Would the reload count as a second use? One could argue it > either way. > > What I think we want from what I understand, is the request URI MUST be > unique so that there is no confusion on which request is being referenced= . > > I did not see anything about the expiry time of the request URI (but I di= d > not look super hard). If that is not there, then I think the request URI > MUST expire in a "short" period of time. > > > > =E1=90=A7 > > On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> Thanks Justin. Just a couple more responses to responses inline below >> (but with lots of content that needs no further discussion removed). >> >> A TL;DR for the WG is that I'd like to get some wider feedback on the >> question of changing the one-time-use condition on the request_uri from = a >> SHOULD to a MUST. >> >> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer wrote: >> >>> Hi Brian, just a couple responses inline where it seemed fitting. Thank= s >>> for going through everything! >>> =E2=80=94 Justin >>> >>> On Aug 25, 2020, at 6:01 PM, Brian Campbell >>> wrote: >>> >>> Thanks for the review and comments Justin. Replies (or attempts thereat= ) >>> are inline below. >>> >>> >>> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer wrote: >>> >>>> I=E2=80=99ve done a full read through of the PAR specification, and he= re are my >>>> notes on it. >>>> >>>> >>>>> =C2=B62: Of necessity, this spec mixes parameters in the authoriz= ation >>>>> endpoint and token endpoint registries into a single request. Is ther= e any >>>>> danger of conflict between them? The registry holds them in one list = but >>>>> they could possibly have different semantics in both places. >>>>> >>>> >>>> I think that technically such danger does exist but that it's highly >>>> unlikely in practice. Especially because the only token endpoint param= eters >>>> that are relevant to PAR are those that deal with client authenticatio= n >>>> (currently client_secret, client_assertion, and client_assertion_type)= . I'm >>>> also not sure what can reasonably be done about it given the way the >>>> registries are. I guess PAR could update the registration for those th= ree >>>> (client_secret, client_assertion, and client_assertion_type) to also >>>> indicate authorization request as a usage location with some commentar= y >>>> that it's only for avoiding name collisions. And offer some guidance a= bout >>>> doing the same for any future client auth methods being defined. But >>>> honestly I'm not sure what, if anything, to do here? >>>> >>>> And yes it is super unfortunate that client auth and protocol >>>> parameters got mixed together in the HTTP body. I didn't cause that >>>> situation but I've certainly contributed to it and for that I apologiz= e. >>>> >>> >>> I think the only perfect solution is to go back in time and fix the >>> registries with based on the last decade of knowledge in using them. :P >>> >>> For this, I think maybe being very prescriptive about the fact that the >>> only parameters from the token endpoint that are allowed here are those >>> used for client authentication and that when they show up, they=E2=80= =99re >>> interpreted as in the token endpoint request not the authorization endp= oint >>> request. Does that work? >>> >> >> I think so, yes. And will work on incorporating some text towards that >> end. >> >> >> >> >>> I don=E2=80=99t see why a request URI with unguessable values isn= =E2=80=99t a MUST >>>> for one-time-use, is there a reason? >>>> >>> >>> The reason AFAIK was to not be overly prescriptive and allow for >>> eventually consistent or not atomic storage of the data by not strictly >>> requiring the AS to enforce one-time-use. Do you think that's too loose= or >>> could be worded/explained differently or better? >>> >>> >>> I do think it=E2=80=99s too loose and it should be a MUST, and the meth= ods for >>> enforcing that =E2=80=9CMUST=E2=80=9D are going to vary based on the de= ployments and >>> implementations out there. >>> >>> >> I'd be okay with making it a MUST but think maybe it'd be good to hear >> from a few more people in the WG before committing to that change. >> >> Can I ask some folks to weigh in on this one? I'm leaning towards making >> the change barring objections. >> >> >> *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 send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.*______________________________________________= _ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > --00000000000043fb6005adde34e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That is not correct.

The authorizat= ion=C2=A0code one-time-use is directly between the client and the AS. The c= lient has a number of mechanisms to ensure it only presents the authorizati= on code to the AS once,=C2=A0such as a session that was set when the user s= tarted at the client.

In contrast, in a redirect f= rom the client to the AS, the client loses control on how many times the us= er-agent loads the URL at the AS. Additionally, there is unlikely=C2=A0to b= e an active browser session at the AS, so the AS can not easily differentia= te between a URL load from the same user, or different users. If one-time-u= se, one of them MUST fail. If the two requests happen to be from the same u= ser (because of a reload, which the user did because the AS was slow to res= pond), there is no way for the AS to know which of the requests is the one = that is current in front of the user. While the AS can internally ensure pr= ocessing of the request once, one-time-use would dictate that it provides a= failure message to one of the requests.

/Dick


3D""=E1=90=A7

<= div class=3D"gmail_quote">
On Thu, Aug= 27, 2020 at 7:17 AM Justin Richer <j= richer@mit.edu> wrote:
We already have thi= s same property with authorization codes, and it=E2=80=99s managed today re= asonably well (in my opinion). If you submit the same request URI twice in = the same browser (the refresh you=E2=80=99re talking about), it shouldn=E2= =80=99t start two separate authorization requests, but it would be reasonab= le to detect that the same session attached to the same request URI value s= howed up twice and continue the session as appropriate.=C2=A0

None of this is in conflict with =E2=80=9Cone time use=E2=80=9D, in m= y view, since you=E2=80=99re actively detecting the session and source of t= he value.

=C2=A0=E2=80=94 Justin

On Aug 26, 2020, at 6:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I think one-time use may be ov= erly restrictive, and I don't think it is the property that we actually= want.

Give the request URI is in a redirect from the br= owser, there is a good chance of a race condition where the same browser re= quest is made more than once, for example, while the browser is loading the= authorization URL at the AS, the user could refresh the page causing the a= uthorization URL to be reloaded. Would the reload count as a second use? On= e could argue it either=C2=A0way.

What I think we = want from what I understand, is the request URI MUST be unique so that ther= e is no confusion on which request is being referenced.=C2=A0
I did not see anything about the expiry time of the request URI= (but I did not look super hard). If that is not there, then I think the re= quest URI MUST expire in a "short" period of time.

=


3D""=E1=90=A7
On= Wed, Aug 26, 2020 at 1:45 PM Brian Campbell <bcampbell=3D40pingidentity.com= @dmarc.ietf.org> wrote:
Thanks=C2=A0Justin. Just a= couple more responses to responses inline below (but with lots of content = that needs no further discussion removed).

<= /div>
A TL;DR for the WG is that I'd like to get some wider feedbac= k on the question of changing the one-time-use condition on the request_uri= from a SHOULD to a MUST.

On Tue, Aug 25, 2020 at 4:57 PM Justin Richer= <jricher@mit.edu> wrote:
Hi Brian, just a couple responses inline where it seemed fitting. Thanks= for going through everything!
=C2=A0=E2=80=94 Justin


Thanks for the review and comments Justin. Replies (or attempts the= reat) are inline below.


On Wed, Aug 19, 202= 0 at 2:06 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99ve done a full= read through of the PAR specification, and here are my notes on it.

=C2=A0 =C2=A0 =C2=B62: Of necessity, this spec mixes parameters in = the authorization endpoint and token endpoint registries into a single requ= est. Is there any danger of conflict between them? The registry holds them = in one list but they could possibly have different semantics in both places= .

I think that technically such= danger does exist but that it's highly unlikely in practice. Especiall= y because the only token endpoint parameters that are relevant to PAR are t= hose that deal with client authentication (currently client_secret, client_= assertion, and client_assertion_type). I'm also not sure what can reaso= nably be done about it given the way the registries are. I guess PAR could = update the registration for those three (client_secret, client_assertion, a= nd client_assertion_type) to also indicate authorization request as a usage= location with some commentary that it's only for avoiding name collisi= ons. And offer some guidance about doing the same for any future client aut= h methods being defined. But honestly I'm not sure what, if anything, t= o do here?=C2=A0

And yes it is super unfortun= ate that client auth and protocol parameters got mixed together in the HTTP= body. I didn't cause that situation but I've certainly contributed= to it and for that I apologize.
<= /div>

I think the only perfect solution is = to go back in time and fix the registries with based on the last decade of = knowledge in using them. :P=C2=A0

For this, I thin= k maybe being very prescriptive about the fact that the only parameters fro= m the token endpoint that are allowed here are those used for client authen= tication and that when they show up, they=E2=80=99re interpreted as in the = token endpoint request not the authorization endpoint request. Does that wo= rk?

I think so, yes= . And will work on incorporating some text towards that end.


=C2=A0
=C2=A0 =C2=A0 I don=E2=80=99t see why a request URI with = unguessable values isn=E2=80=99t a MUST for one-time-use, is there a reason= ?

The reason AFAIK was to not b= e overly prescriptive and allow for eventually consistent or not atomic sto= rage of the data by not strictly requiring the AS to enforce one-time-use. = Do you think that's too loose or could be worded/explained differently = or better?=C2=A0

I= do think it=E2=80=99s too loose and it should be a MUST, and the methods f= or enforcing that =E2=80=9CMUST=E2=80=9D are going to vary based on the dep= loyments and implementations out there.=C2=A0


I'd be okay with making it a MUST but th= ink maybe it'd be good to hear from a few more people in the WG before = committing to that change.

Can I ask some fol= ks to weigh in on this one? I'm leaning towards making the change barri= ng objections.


<= 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 th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--00000000000043fb6005adde34e8-- From nobody Thu Aug 27 09:16:36 2020 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 EAA7E3A104B; Thu, 27 Aug 2020 09:16:34 -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_FONT_LOW_CONTRAST=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 VCuJrmI_KMBR; Thu, 27 Aug 2020 09:16:32 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 5BD863A104C; Thu, 27 Aug 2020 09:16:32 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id f26so7052149ljc.8; Thu, 27 Aug 2020 09:16:32 -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=QqYeq+qjhVgwubr9DEOHZV/1F/DCnfxJ/5+s5bQv+fU=; b=kK1BVmP+rC0eK6A835FCGfy8W1jd9/h1wqrAwiZLo30gl+uFBrs3YWGf45GmvZSAMT dnySWZ/d35u3EnbQNFDClTmc5ZdDTDcTGU/uV/3OgM6bzgaUVAYplYA6USlm9cqzCtY0 oqSC3guiRgUd3eBgCGJCkqnuaS8sSsibr4TPcVhc9ZR1ndbI+hMYYwpAJztwG+uAtFai vjxAyZPd3bBUqPoZZPSHvfhyc3yrbERCsFlEL/eBx5YI8i7L+nx+LTl+e3+uE17ARZAU sVAfim+NBUuZEjd1NcFW+xIu7Ky6dhwKAXI37BcPaPWWlOvQObhDuLHMY2IluO/l0/41 ROSA== 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=QqYeq+qjhVgwubr9DEOHZV/1F/DCnfxJ/5+s5bQv+fU=; b=d1Dl1sXM9xv5sLVYSceiYhaiAZgs3vMxu90Vr2YpK3SaZEMlQsvRwiN6H4uKvdNDVg l6ahfJbZU72pIT/u+J0k5pSt4EJcuuhQ3K3ilDROyapGlYjsMeWdi9E44tGPuuBKKog+ kqr6TPzB73l0aCzd9A1gK2waGbI5Rl1h9Pmf60C9s18+f4DjTSeR1Rwhh+U8uvNlzvPo lALN0+hIs4hAVBb8UEd/XHaQphbzdbzSgxy1ZlyR0ebIsynCRUVh/YTEaDE+pKRdGquU 7R1VpajeudZZy+OrQi/XpOJcWYT7SsWxh/oA4quc2q0GG1FHUMEzQDNqhtBk+mlNB9HC C/LA== X-Gm-Message-State: AOAM532prZDM/2lOVMfYXuGcacmVMrUIaCne777bVedVQdoNStjSa4ui kJe+JU8TGMOeTckxH8lMdjz0uC2KUNcO0T1KduNnBFVm2jHKAQ== X-Google-Smtp-Source: ABdhPJyx6y3TprROjFJHmni+DyM7ZTeEzh53MgXQdSpKxciyq2kLUE8oBG2hrMz0e1pU6s+5qmrzsmOaONqnmQAxfOk= X-Received: by 2002:a2e:7215:: with SMTP id n21mr10718610ljc.242.1598544990440; Thu, 27 Aug 2020 09:16:30 -0700 (PDT) MIME-Version: 1.0 References: <412A63AD-DDE1-4BFE-8234-5A721A0ED88D@lodderstedt.net> In-Reply-To: From: Dick Hardt Date: Thu, 27 Aug 2020 09:15:53 -0700 Message-ID: To: Justin Richer Cc: Torsten Lodderstedt , Mike Jones , "last-call@ietf.org" , oauth Content-Type: multipart/alternative; boundary="0000000000005011a205adde42c2" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 27 Aug 2020 16:16:35 -0000 --0000000000005011a205adde42c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here is a crisper revision. Implementers should be aware that a token introspection request lets the AS know when the client is accessing the RS, which may indicate when the user is using the client. If this implication is not acceptable, implementers can use other means to carry access token data, e.g. directly transferring the data needed by the RS within the access token. =E1=90=A7 On Thu, Aug 27, 2020 at 7:19 AM Justin Richer wrote: > I would clarify that this doesn=E2=80=99t necessarily say that the user= =E2=80=99s there, > and remove the normative requirement (which doesn=E2=80=99t have enforcea= ble teeth > in this context): > > Implementers should be aware that a token introspection request lets the > AS know when the client > (and potentially the user) is accessing the RS, which *can also > indicate* when the user is using > the client. If this implication is not acceptable, *implementers can > use other means* to carry > access token data, e.g. directly transferring the data needed by the > RS within the access token. > > > =E2=80=94 Justin > > On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt < > torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote: > > Will the following text work for you? > > Implementers should be aware that a token introspection request lets the > AS know when the client > (and potentially the user) is accessing the RS, which is also an > indication of when the user is using > the client. If this impliction is not accepatable, implementars MUST > use other means to carry > access token data, e.g. directly transferring the data needed by the > RS within the access token. > > > On 26. Aug 2020, at 23:12, Mike Jones < > Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: > > I agree with Dick=E2=80=99s observation about the privacy implications of= using an > Introspection Endpoint. That=E2=80=99s why it=E2=80=99s preferable to no= t use one at all > and instead directly have the Resource understand the Access Token. One > way of doing this is the JWT Access Token spec. There are plenty of othe= rs. > > The downsides of using an Introspection Endpoint should be described in > the Privacy Considerations section. > > -- Mike > > From: OAuth On Behalf Of Dick Hardt > Sent: Wednesday, August 26, 2020 9:52 AM > To: Torsten Lodderstedt > Cc: last-call@ietf.org; oauth > Subject: Re: [OAUTH-WG] Last Call: > (JWT Response for > OAuth Token Introspection) to Proposed Standard > > > > On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt < > torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote: > Hi Denis, > > On 25. Aug 2020, at 16:55, Denis wrote: > > > The fact that the AS will know exactly when the introspection call has > been made and thus be able to make sure which client > has attempted perform an access to that RS and at which instant of time. > The use of this call allows an AS to track where and when > its clients have indeed presented an issued access token. > > > That is a fact. I don=E2=80=99t think it is an issue per se. Please expla= in the > privacy implications. > > As I see it, the privacy implication is that the AS knows when the client > (and potentially the user) is accessing the RS, which is also an indicati= on > of when the user is using the client. > > I think including this implication would be important to have in a Privac= y > Considerations section. > > /Dick > =E1=90=A7 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --0000000000005011a205adde42c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here is a crisper revision.

Imple= menters should be aware that a token introspection request lets the AS know= when the client
=C2=A0 =C2=A0 is accessing the RS, which may=C2=A0indi= cate when the user is using
=C2=A0 =C2=A0 the client. If this implicati= on is not acceptable, implementers can use other means to carry
=C2=A0 = =C2=A0 access token data, e.g. directly transferring the data needed by the= RS within the access token.
3D""=E1=90=A7

<= div class=3D"gmail_quote">
On Thu, Aug= 27, 2020 at 7:19 AM Justin Richer <j= richer@mit.edu> wrote:
I would clarify tha= t this doesn=E2=80=99t necessarily say that the user=E2=80=99s there, and r= emove the normative requirement (which doesn=E2=80=99t have enforceable tee= th in this context):

Implementers should be aware that a= token introspection request lets the AS know when the=C2=A0client=C2=A0=C2=A0 =C2=A0 (and potentially the user) is accessing the RS, which can= also indicate when the user is=C2=A0using=C2=A0
=C2=A0 =C2=A0 the c= lient. If this implication is not acceptable, implementers can use other= means to carry=C2=A0
=C2=A0 =C2=A0 access token data, e.g. directly= transferring the data needed by the RS within the access token.

=C2=A0=E2=80=94 Justin

On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt <<= a href=3D"mailto:torsten=3D40lodderstedt.net@dmarc.ietf.org" target=3D"_bla= nk">torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:

Will the following text work for you?

Implementers should be a= ware that a token introspection request lets the AS know when the client =C2=A0=C2=A0=C2=A0=C2=A0(and potentially the user) is accessing the RS, = which is also an indication of when the user is using
=C2=A0=C2=A0=C2= =A0=C2=A0the client. If this impliction is not accepatable, implementars MU= ST use other means to carry
=C2=A0=C2=A0=C2=A0=C2=A0access token data,= e.g. directly transferring the data needed by the RS within the access tok= en.


On 26. Aug 2020, at 23:12, Mike Jo= nes <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wro= te:

I agree with Dick=E2=80=99s observation about the privacy implic= ations of using an Introspection Endpoint.=C2=A0 That=E2=80=99s why it=E2= =80=99s preferable to not use one at all and instead directly have the Reso= urce understand the Access Token.=C2=A0 One way of doing this is the JWT Ac= cess Token spec.=C2=A0 There are plenty of others.

The downsides of = using an Introspection Endpoint should be described in the Privacy Consider= ations section.

=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=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=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-- Mike

From: OAuth = <oauth-bounc= es@ietf.org> On Behalf Of Dick Hardt
Sent: Wednesday, August 26, = 2020 9:52 AM
To: Torsten Lodderstedt <torsten=3D40lodderstedt.ne= t@dmarc.ietf.org>
Cc: last-call@ietf.org; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] L= ast Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT R= esponse for OAuth Token Introspection) to Proposed Standard



= On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt <torsten=3D40lo= dderstedt.net@dmarc.ietf.org> wrote:
Hi Denis,

On 25. Aug 2020, at 16:55, Denis <denis.ietf@free.fr> wrote:

The fact that the AS will know exactl= y when the introspection call has been made and thus be able to make sure w= hich client
has attempted perform an access to that RS and at which ins= tant of time. The use of this call allows an AS to track where and when its clients have indeed presented an issued access token.
=
That is a fact. I don=E2=80=99t think it is an issue per se. Please exp= lain the privacy implications.

As I see it, the privacy implication = is that the AS knows when the client (and potentially the user) is accessin= g the RS, which is also an indication of when the user is using the client.=

I think including this implication would be important to have in a = Privacy Considerations section.

/Dick
=E1=90=A7
<= br>_______________________________________________
OAuth mailing listOAuth@ietf.org
= h= ttps://www.ietf.org/mailman/listinfo/oauth
=
--0000000000005011a205adde42c2-- From dima.postnikov@gmail.com Thu Aug 27 20:26:56 2020 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 1051B3A1511 for ; Thu, 27 Aug 2020 20:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=postnikov-net.20150623.gappssmtp.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 RB4WZEjU8iqD for ; Thu, 27 Aug 2020 20:26:54 -0700 (PDT) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 CE0F73A150F for ; Thu, 27 Aug 2020 20:26:54 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id 2so3672768pjx.5 for ; Thu, 27 Aug 2020 20:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=postnikov-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=LyAnSv0etM8nkWSutkBFiUqGsGBO2NVOSabN4ocqaps=; b=I1it2UFUEKMtMmqgLIGqFWlJD+Iz+X1I2ZGdPKjvS1y6L2buCVWxI9xnSfJhn15RHR 9rbxjkvPmiC0hQvsHsHbO8aLQenGjMgBtb5KyJ6wmz+EiTqrF3CXfTO7VQwuVB4tWWf3 mK3T3J+DpzB7kAW9CFLKJohnOAuSgN8Tz/qD+KUS0VHUuDNu4V4K+w9hy2Ld7uHABw0x OX3U/PaSAPoL4w9dLIe6C1g7dWdO/afab8NVDM5tgryzDkoVHTeFcbYrCx9KafNPx2Aw ZaSUbBKG9YbhOzx95g5qfMoLxAcz8YeNigtu8ujQDB5QmZG2PL2J/56VzG6H0niY6/YQ W3hQ== 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=LyAnSv0etM8nkWSutkBFiUqGsGBO2NVOSabN4ocqaps=; b=kCi4L1WGBx2rZsYlmgSfd0HyZYsj9R1Jq77Ajg/zlPCBc5XeSnGXpX6iaRbhqqzVwb qE8rhL/LFni0KT7HbO72d2IdHNyJWUEkAJ+B2zG/OwhQiHua3X0GNXnC5VGrvdB6zu9x +C6TBvRLjW7o88vd6cD0DmeRyWlTb+VvsAkFaLKa8R6Xk5ivVI/NQYbkGv3bS0/YQytl Xb8PyVttonndUZcrrpGr1OZzVkOI4V2S0cCLpAiwnAm6nPbLvIVKXXPpGxx56B3xj4y+ c4w/b5hilsn/LBPjP8IcVaAK4+CweYSTYKDEsnjTylsIe/FCURFdMxlfRRMwFAMdnAlR 5GIA== X-Gm-Message-State: AOAM530J3kXV6f4DXDgvgwtBi6VhGiu4lqi0MmZR/1p+mBZ/cyXVLqgU vtoNjuCIKS+9ufrTBix8uxq/TjaZd3yiPd8qqjBtoU8RggYUvTTn X-Google-Smtp-Source: ABdhPJxGw+2O6EnEuMoOQYLjIqLTUq85HxDuFsd1qclygTDXzyGn7N9qYRj4ytuEPae/ZW7qLO6TZxNd2P025zHF+Yo= X-Received: by 2002:a17:90a:fe0e:: with SMTP id ck14mr631520pjb.218.1598585213969; Thu, 27 Aug 2020 20:26:53 -0700 (PDT) MIME-Version: 1.0 From: Dima Postnikov Date: Fri, 28 Aug 2020 13:26:41 +1000 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000d2681905ade79f78" Archived-At: Subject: [OAUTH-WG] third party applications 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, 28 Aug 2020 04:05:27 -0000 --000000000000d2681905ade79f78 Content-Type: text/plain; charset="UTF-8" Hi, Can "third-party" term be removed from the specification? The standard and associated best practices apply to other applications that act on behalf of a resource owner, too (internal, "first-party" and etc). Regards, Dima The OAuth 2.1 authorization framework enables a *third-party* application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749 . --000000000000d2681905ade79f78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Can "third-party" term be= removed from the specification?

The standard and = associated best practices apply to other applications that act on behalf of= a resource owner, too (internal, "first-party" and etc).

Regards,

Dima

The OAuth 2.1 authorization framework enabl=
es a third-party
   application to obtain limited access to an HTTP service, either on
   behalf of a resource owner by orchestrating an approval interaction
   between the resource owner and the HTTP service, or by allowing the
   third-party application to obtain access on its own behalf.  This
   specification replaces and obsoletes the OAuth 2.0 Authorization
   Framework described in RFC 6749.
--000000000000d2681905ade79f78-- From nobody Fri Aug 28 03:01:57 2020 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 36E2B3A166F for ; Fri, 28 Aug 2020 03:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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 PhXEd6FBoF9H for ; Fri, 28 Aug 2020 03:01:53 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 4F27F3A08C0 for ; Fri, 28 Aug 2020 03:01:53 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id u1so625594edi.4 for ; Fri, 28 Aug 2020 03:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/SeWc6WWYXxA7K3aUQNspfephGR3+pBCvmURncPi1jc=; b=bs8ujkcMYbdlXqmlxxC1QJHDAz0GwGSRRYnoC2wU1m9si9Ud4ss4HGoA9A9huViog2 dKYmMPrneN+HSoK4VuyH5fQFd6xyjLdr3Fm4Y3SIvp1JUFlPc5+GPQHRFsFqBCdu/tkH rejX5eI95KuJZc1xajicR/aXEoa0OyaH4njlUpUayhxhj9haanOXaxR0s1LgRGpzMG3G ojeTVgYY9p/Rg0L/SZqw8wnN8kzKr96yvqb15lHz38L48dQtxs/igKcrg9praddFQ8VF OMHiMSvrXswMMrGHtx6dfj+lrKQzIdxGo91YsMW5piERIpRsi1zxgG2xUnPvqYAHqfNh xEWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/SeWc6WWYXxA7K3aUQNspfephGR3+pBCvmURncPi1jc=; b=DNZ/vGMzyq88z4r86wHrValCRhPdrfPngOCW09n6462+2QayVWN187I8J+GYe+rDuG oOhY3clTD3pRG/M1AMuXqZJiT8pcDLFH6c+27SDi6GVR3P/Vq8b+N/YY/z6N6j7uCZyB U6XzLcyww0ZU3eVSbVQmVRNi7wjIm9ukw/lCoKnvB4NMyoRJN6X+nvURJjlpvCP7Iuf3 PjY3EJhkSpGA4wEpPTAxObkfGu8GE6aoPAtR7EleYQDaq9fLnVhzs34c/k32kUO77015 oCWqW7njqfey35JOyf3H7rEcu7h7HHLfKF3UUX+mq+d63AkmbTP1P59NB0qwMV++Hczo Nutg== X-Gm-Message-State: AOAM532KlwQ7kHXkEalm7caNWTWvL4GM1tgFPwZYZdwB/2FVdY6MpAhb M+pCo/hIjuxJp9nXYAoQLmaHY2krDnRvcYgE X-Google-Smtp-Source: ABdhPJztlvRFtvy4Xw4bI87b6kQ43sYZVyAzGdIia6vGQTnZ+94qV35hMvJ4eXgcg7BlQalJSYRayA== X-Received: by 2002:a05:6402:17a2:: with SMTP id j2mr1000455edy.79.1598608911578; Fri, 28 Aug 2020 03:01:51 -0700 (PDT) Received: from p200300eb8f1e2a7f0135b1f6009a5514.dip0.t-ipconnect.de (p200300eb8f1e2a7f0135b1f6009a5514.dip0.t-ipconnect.de. [2003:eb:8f1e:2a7f:135:b1f6:9a:5514]) by smtp.gmail.com with ESMTPSA id q16sm461324ejo.49.2020.08.28.03.01.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Aug 2020 03:01:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Torsten Lodderstedt In-Reply-To: Date: Fri, 28 Aug 2020 12:01:49 +0200 Cc: oauth Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dima Postnikov X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] third party applications 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, 28 Aug 2020 10:01:55 -0000 I agree. OAuth works for 3rd as well as 1st parties as well.=20 > On 28. Aug 2020, at 05:26, Dima Postnikov wrote: >=20 > Hi, >=20 > Can "third-party" term be removed from the specification? >=20 > The standard and associated best practices apply to other applications = that act on behalf of a resource owner, too (internal, "first-party" and = etc). >=20 > Regards, >=20 > Dima >=20 > The OAuth 2.1 authorization framework enables a third-party >=20 > application to obtain limited access to an HTTP service, either on > behalf of a resource owner by orchestrating an approval interaction > between the resource owner and the HTTP service, or by allowing the > third-party application to obtain access on its own behalf. This > specification replaces and obsoletes the OAuth 2.0 Authorization > Framework described in=20 > RFC 6749. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Aug 28 03:54:48 2020 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 E151A3A0B34 for ; Fri, 28 Aug 2020 03:54:47 -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, 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 (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 HWNVabWnRxMn for ; Fri, 28 Aug 2020 03:54:44 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 1B6563A08EE for ; Fri, 28 Aug 2020 03:54:43 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id r15so863206wrp.13 for ; Fri, 28 Aug 2020 03:54:43 -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=zTkJ2vPufmf+ZD1Am02tkUCliDiOaBNgZvuP524jDqo=; b=UIsBoyUBuz2FChbi8uccFVslBURwOU4xzen7tFlUr0USK7QvijxUHqZ6wyx/eXwI6d EKNygCusIR7BVqUS/lTXQzxkKDRH5GERu3qrMh7Avcqxg3VxbuxDbwqEt2IYcdLWrkaQ psJkYU7O1AEiaCFl7IVf5ocloapxqGfiJg2XE= 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=zTkJ2vPufmf+ZD1Am02tkUCliDiOaBNgZvuP524jDqo=; b=nBy3gjSMO0MMt7HMDJ1FC10Y1vQWGkbMoxHT1nXqY0Kj2SeP0fRXu8/aqC6hpXLi8S wT823H4xCuRPje8neVlW81ROjmseBCtGrawtXPePmjMHNB5ExwhF8V53vb/qtSeYEtBJ WvFiOpuIsj62XfCRFU+L+2cOa/rNoeHdTNdbI68JjwOjSMzBN+v8jw8rBr3ks5XoJnzM 6Fhys4p32EQ+Jl88jlO0nnbeonCgjL7MmhyGaQMXM6kZprQYvc2e89xeRUAB13f2eOda fpCsiYxoYrKN/zTaffkHhPUXLaFGj9IaUC/OwSdG85oDrL2MwgPGqVi1RvAKR38vfQvu GXBQ== X-Gm-Message-State: AOAM53355WabdtNRLifMKW6y9+AljHo2TYXUUbh+hYNiSTDelu3JD/S7 Ncv8Rkbgb2+hiHgKEkblOxDM8A== X-Google-Smtp-Source: ABdhPJwa/25v7y52tv0ovlfjSnMUACPGlbHuEQAJ/eP+jXttN1GqdmLBVo44C0qLwXhKCDQRcF43DQ== X-Received: by 2002:a5d:650b:: with SMTP id x11mr972351wru.46.1598612081909; Fri, 28 Aug 2020 03:54:41 -0700 (PDT) Received: from [10.0.0.6] (38.227.143.150.dyn.plus.net. [150.143.227.38]) by smtp.gmail.com with ESMTPSA id j7sm1676424wmj.38.2020.08.28.03.54.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Aug 2020 03:54:41 -0700 (PDT) From: Neil Madden Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_32A8092E-6CBD-4FE3-80A7-C89704DF5B07" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 28 Aug 2020 11:54:40 +0100 In-Reply-To: Cc: oauth To: Brian Campbell References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] WGLC review of PAR 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, 28 Aug 2020 10:54:48 -0000 --Apple-Mail=_32A8092E-6CBD-4FE3-80A7-C89704DF5B07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the response Brian, I agree with your comments. I=E2=80=99ve = been scratching my head for a non-OIDC example for the URI swapping = issue, but can=E2=80=99t think of one that isn=E2=80=99t very contrived = at the moment. =E2=80=94 Neil > On 26 Aug 2020, at 21:04, Brian Campbell = wrote: >=20 > Thanks Neil. Appreciate the review and feedback. My attempts at = responses are inline below.=20 >=20 >=20 > On Thu, Aug 20, 2020 at 5:30 AM Neil Madden > wrote: > As promised in the last interim meeting, I=E2=80=99ve reviewed the = current (03) draft-ietf-oauth-par document. Overall it looks close to = ready to me, with mostly minor comments and one security-relevant = comment on section 2.1 that should be discussed further, and one = additional proposed security consideration: >=20 > Abstract: > The wording here could be improved - =E2=80=9Callows clients to push = an authorization request [=E2=80=A6] used as a reference to the data in = a subsequent authorization request.=E2=80=9D Both the pushed data and = the call to the authorization endpoint are referred to as an = =E2=80=9Cauthorization request=E2=80=9D. Maybe change the second usage = to =E2=80=9Cin a subsequent call to the authorization endpoint=E2=80=9D. >=20 > Makes sense.=20 > =20 >=20 > Section 1: > The introductory part here is quite long. Maybe adding a new = sub-heading before the example would make it flow better. >=20 > Will look at breaking it up.=20 > =20 >=20 > The end of the introduction uses the acronym =E2=80=9CPAR=E2=80=9D for = the first time, but never explicitly defines it. >=20 > Will fix.=20 > =20 >=20 > I agree with Justin that ACR is not the best example to lead with. If = it stays there should be a reference to OIDC to explain what this means. >=20 > Yup.=20 > =20 >=20 > The paragraph that begins =E2=80=9CIt also allows clients to push the = form encoded =E2=80=A6=E2=80=9D is confusing because the use of = =E2=80=9Calso=E2=80=9D suggests this is different from the previous = paragraph, but it seems to actually be saying the same thing? >=20 > Yeah, that is rather awkward because it is the same thing. Will fix.=20= > =20 >=20 > =E2=80=9C[=E2=80=A6] but it also allows clients requiring > an even higher security level, especially cryptographically = confirmed > non-repudiation, to explicitly adopt JWT-based request objects=E2=80=9D= >=20 > The =E2=80=9Cbut=E2=80=9D should be an =E2=80=9Cand=E2=80=9D in this = paragraph. It=E2=80=99s also not clear what is being said here - isn=E2=80= =99t JAR what provides JWT-based request objects?=20 >=20 > Yeah, JAR defines JWT-based request objects and PAR allows for their = use by sending the 'request' parameter to the PAR endpoint. Will try = and make that more clear. > =20 >=20 > The paragraph beginning =E2=80=9CAs a further benefit, =E2=80=A6=E2=80=9D= is a little bit of a Columbo moment (=E2=80=9CJust one more = thing=E2=80=A6=E2=80=9D) at the end of the introduction. Maybe move this = as another bullet point at the start of the section. The following = paragraph can then be rewritten as =E2=80=9CThe increased confidence in = the identity of the client during the authorization process allows = confidential clients to provide a different redirect_uri on every = request. [=E2=80=A6]=E2=80=9D >=20 > Agree with the sentiment here and will endeavor to rework things = along the lines of the suggestion.=20 >=20 > =20 > Section 2: > The 3rd paragraph contains statements like=20 > The endpoint also supports sending all authorization > request parameters as request object according to > [I-D.ietf-oauth-jwsreq = ]. > presumably this is not a normative requirement that any PAR = implementation has to also support JAR, or is it? Maybe change the = wording to =E2=80=9CMAY also support =E2=80=A6=E2=80=9D. >=20 > Interesting question. PAR has a normative reference to JAR for the = request_uri parameter at the authz endpoint. But does that necessitate = that every PAR implementation also has to support all of JAR? I'm = thinking probably not. I mean, different but related, an AS PAR = implementation might legitimately support the request_uri parameter with = URI values that it creates but not support the more general retrieval of = arbitrary URIs. In the same vein, it seems legit and still useful to = support PAR without also supporting request object JWTs. So yeah, I = think changing this to MAY or something similar would be appropriate.=20 > =20 >=20 > The first mention of =E2=80=9Ctoken_endpoint_auth_method=E2=80=9D and = client metadata should have a reference to RFC 7591 - currently it=E2=80=99= s only referenced later in section 2.1. >=20 > Will fix.=20 >=20 > 2.1: > I=E2=80=99m a little bit wary of the relaxing of the redirect_uri = processing rules, because this removes a layer of defence in depth. With = the current requirement for pre-registered URIs an attacker needs to = compromise the redirect endpoint *and* the client credentials in order = to steal an authorization code and use it. With this change, = compromising the client credentials alone would be enough. If the = use-case is specifically in a PKI environment, could the redirect_uri be = baked into the cert? Maybe this use-case could be better addressed in a = separate draft. >=20 > I agree that the specifics of a PKI type environment use-case would = be better in a separate draft or profile somewhere. And do plan to add = some more considerations around the possibility of relaxed redirect_uri = validation.=20 >=20 >=20 > 2.2: > The definition of =E2=80=9Cexpires_in=E2=80=9D as a "JSON number" = suggests that fractional/floating-point values are allowed. Presumably = this is intended to be an integer?=20 >=20 > Yes and I need to clarify that it's a positive integer.=20 >=20 > =20 > Is there a recommended minimum/maximum? Suggested wording: >=20 > =3D=3D=3D > * "expires_in" : A JSON number that represents the lifetime of the > request URI in seconds as a positive integer. The lifetime = SHOULD=20 > be at least 5 seconds and at most 600 seconds, but other values = are > permitted at the discretion of the authorization server. > =3D=3D=3D >=20 > Those values are fairly arbitrary - 5 seconds seems a reasonable lower = bound for a client with a bad network connection, and 10 minutes seems = more than adequate upper bound for the typical uses. >=20 > Arbitrary, yes. But also pretty reasonable. I'm not too keen on using = arbitrary values with normative language, however, even if reasonable. I = think we could work them in with slightly different language something = like, "for example, at least 5 seconds but at most 600".=20 > =20 >=20 > 3: > I confirmed that the request JWT verifies with the given JWK using our = internal JWT library :-) >=20 > Yay for interoperability! I produced those using a different JWT = library :)=20 >=20 > 5: > =E2=80=9Crequire_pushed_authorization_requests=E2=80=9D might be = better named =E2=80=9Crequires_pushed_authorization_requests=E2=80=9D = given that it is describing the server=E2=80=99s policy rather than = telling the client to require them, but this is a really pedantic point. = Same for the client metadata in section 6. >=20 > Fair point but I don't think sufficient to warrant a change to a = protocol parameter name at this point.=20 > =20 >=20 > 7: > I would like to propose an additional security consideration, with the = following wording: >=20 > =3D=3D=3D > 7.5. Request URI swapping >=20 > An attacker could capture the request URI from one request and then = substitute it into a different authorization request. For example, in = the context of OpenID Connect, an attacker could replace a request URI = asking for a high level of authentication assurance with one that = requires a lower level of assurance. Clients SHOULD make use of PKCE, a = unique =E2=80=9Cstate" parameter, or the OIDC =E2=80=9Cnonce=E2=80=9D = parameter in the pushed request object to prevent this attack. > =3D=3D=3D >=20 > Thanks. Will incorporate (with added refs and minor tweaks). I'm = wondering if there's a good example that isn't OpenID Connect though? = Just thinking something OAuth only might be more accessible to most = readers (similar to what you and Justin pointed out that the ACR example = earlier in the draft may not be the best). =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. --Apple-Mail=_32A8092E-6CBD-4FE3-80A7-C89704DF5B07 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the response Brian, I agree with your comments. = I=E2=80=99ve been scratching my head for a non-OIDC example for the URI = swapping issue, but can=E2=80=99t think of one that isn=E2=80=99t very = contrived at the moment.

=E2=80=94 Neil

On 26 Aug 2020, at 21:04, Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks Neil. Appreciate the review and = feedback. My attempts at responses are inline below. 


On Thu, Aug = 20, 2020 at 5:30 AM Neil Madden <neil.madden@forgerock.com> wrote:
As promised in the last interim meeting, I=E2=80=99ve = reviewed the current (03) draft-ietf-oauth-par document. Overall it = looks close to ready to me, with mostly minor comments and one = security-relevant comment on section 2.1 that should be discussed = further, and one additional proposed security consideration:

Abstract:
The wording here could be improved - =E2=80=9Callows clients = to push an authorization request [=E2=80=A6] used as a reference to the = data in a subsequent authorization request.=E2=80=9D Both the pushed = data and the call to the authorization endpoint are referred to as an = =E2=80=9Cauthorization request=E2=80=9D. Maybe change the second usage = to =E2=80=9Cin a subsequent call to the authorization = endpoint=E2=80=9D.

Makes sense. 
 

Section = 1:
The introductory part here is quite long. Maybe = adding a new sub-heading before the example would make it flow = better.

Will look at breaking it up. 
 

The end = of the introduction uses the acronym =E2=80=9CPAR=E2=80=9D for the first = time, but never explicitly defines it.

Will fix. 
 

I agree = with Justin that ACR is not the best example to lead with. If it stays = there should be a reference to OIDC to explain what this = means.

Yup. 
 

The paragraph that = begins =E2=80=9CIt also allows clients to push the form encoded =E2=80=A6=E2= =80=9D is confusing because the use of =E2=80=9Calso=E2=80=9D suggests = this is different from the previous paragraph, but it seems to actually = be saying the same thing?

Yeah, that is rather awkward because it = is the same thing. Will fix. 
 

=E2=80=9C[=E2=80=A6] but it also allows clients = requiring
 =
  an even higher security level, especially cryptographically confirmed
   non-repudiation, to explicitly adopt JWT-based request =
objects=E2=80=9D

The =E2=80=9Cbut=E2=80=9D=
 should be an =E2=80=9Cand=E2=80=9D in this paragraph. It=E2=80=99s also =
not clear what is being said here - isn=E2=80=99t JAR what provides =
JWT-based request objects?

Yeah, JAR defines = JWT-based request objects and PAR allows for their use by sending the = 'request' parameter to the PAR endpoint.  Will try and make that = more clear.
 

The paragraph beginning =E2=80=9CAs a further benefit, =E2=80=A6=
=E2=80=9D is a little bit of a Columbo moment (=E2=80=9CJust one more =
thing=E2=80=A6=E2=80=9D) at the end of the introduction. Maybe move this =
as another bullet point at the start of the section. The following =
paragraph can then be rewritten as =E2=80=9CThe increased confidence in =
the identity of the client during the authorization process allows =
confidential clients to provide a different redirect_uri on every =
request. [=E2=80=A6]=E2=80=9D

 Agree with the = sentiment here and will endeavor to rework things along the lines of the = suggestion. 

 
Section =
2:
The 3rd paragraph contains statements =
like 
The endpoint also supports sending all =
authorization
   =
request parameters as request object according to
   [I-D.ietf-oauth-jwsreq].
presumably = this is not a normative requirement that any PAR implementation has to = also support JAR, or is it? Maybe change the wording to =E2=80=9CMAY = also support =E2=80=A6=E2=80=9D.

Interesting question. = PAR has a normative reference to JAR for the request_uri parameter at = the authz endpoint. But does that necessitate that every PAR = implementation also has to support all of JAR? I'm thinking probably = not. I mean, different but related, an AS PAR implementation might = legitimately support the request_uri parameter with URI values that it = creates but not support the more general retrieval of arbitrary URIs. In = the same vein, it seems legit and still useful to support PAR without = also supporting request object JWTs. So yeah, I think changing this to = MAY or something similar would be appropriate. 
 

The = first mention of =E2=80=9Ctoken_endpoint_auth_method=E2=80=9D and client = metadata should have a reference to RFC 7591 - currently it=E2=80=99s = only referenced later in section 2.1.

Will fix. 

2.1:
I=E2=80=99m a little bit wary of the relaxing of the = redirect_uri processing rules, because this removes a layer of defence = in depth. With the current requirement for pre-registered URIs an = attacker needs to compromise the redirect endpoint *and* the client = credentials in order to steal an authorization code and use it. With = this change, compromising the client credentials alone would be enough. = If the use-case is specifically in a PKI environment, could the = redirect_uri be baked into the cert? Maybe this use-case could be better = addressed in a separate draft.
 I agree that the specifics of a = PKI type environment use-case would be better in a separate draft or = profile somewhere. And do plan to add some more considerations around = the possibility of relaxed redirect_uri validation. 


2.2:
The definition of = =E2=80=9Cexpires_in=E2=80=9D as a "JSON number" suggests that = fractional/floating-point values are allowed. Presumably this is = intended to be an integer? 

Yes and I need to = clarify that it's a positive integer. 

 
Is= there a recommended minimum/maximum? Suggested wording:

=3D=3D=3D
   *  "expires_in" : =
A JSON number that represents the lifetime of the
      request URI in seconds as a positive integer. The lifetime =
SHOULD 
      be at least 5 =
seconds and at most 600 seconds, but other values are
      permitted at the discretion of the =
authorization server.
=3D=3D=3D

Those values are fairly = arbitrary - 5 seconds seems a reasonable lower bound for a client with a = bad network connection, and 10 minutes seems more than adequate upper = bound for the typical uses.

Arbitrary, yes. But also pretty = reasonable. I'm not too keen on using arbitrary values with normative = language, however, even if reasonable. I think we could work them in = with slightly different language something like, "for example, at least = 5 seconds but at most 600". 
 

3:
I confirmed that the request JWT = verifies with the given JWK using our internal JWT library = :-)

Yay for interoperability!  I produced those using a = different JWT library :) 

5:
=E2=80=9Crequire_pushed_authorization_requests=E2=80=9D might = be better named =E2=80=9Crequires_pushed_authorization_requests=E2=80= =9D given that it is describing the server=E2=80=99s policy rather than = telling the client to require them, but this is a really pedantic point. = Same for the client metadata in section 6.

Fair point but I don't = think sufficient to warrant a change to a protocol parameter name at = this point. 
 

7:
I would like to = propose an additional security consideration, with the following = wording:

=3D=3D=3D
7.5. Request URI = swapping

An = attacker could capture the request URI from one request and then = substitute it into a different authorization request. For example, in = the context of OpenID Connect, an attacker could replace a request URI = asking for a high level of authentication assurance with one that = requires a lower level of assurance. Clients SHOULD make use of PKCE, a = unique =E2=80=9Cstate" parameter, or the OIDC =E2=80=9Cnonce=E2=80=9D = parameter in the pushed request object to prevent this attack.
=3D=3D=3D

Thanks. Will incorporate (with added = refs and minor tweaks). I'm wondering if there's a good example that = isn't OpenID Connect though? Just thinking something OAuth only might be = more accessible to most readers (similar to what you and Justin pointed = out that the ACR example earlier in the draft may not be the best). =   

 

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.

= --Apple-Mail=_32A8092E-6CBD-4FE3-80A7-C89704DF5B07-- From nobody Fri Aug 28 06:29:48 2020 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 E22863A02BE for ; Fri, 28 Aug 2020 06:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_32=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 jLWOwwQ0vDua for ; Fri, 28 Aug 2020 06:29:44 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 8A91D3A0128 for ; Fri, 28 Aug 2020 06:29:44 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id z17so325882lfi.12 for ; Fri, 28 Aug 2020 06:29:44 -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=9R3qvcTRTtXsrAXvFgCen6nGwd0uWUFMTiVdcqa1Dhk=; b=IQVftAOahGNU0k0wIas6bvkZnuPgTc71DnKR7sYyJ28UgIMmbwDoyhHSnS6ZuwTO/n xIoyFqHr9zCMqkO6IiQrLrEfHadXINrxWvX98/6uyz3wb5mcUhxO6WrBNlEXfb1k5Gwu UUVjSdBDrs7OSmuwTH0vcPl8tLoEKjWE2qdyHB/+cT9GxG7y+uZI911tRsCV7gMPPIDK EVx4y/MnBEIFT6820xdtGjuD+xdc/GzzIIC7VIigMlukE9HUSzfyNchZ6xdgJ1Ar2K66 R4okWeYuy2iuhnWW39qsQUQWMJOxWJoKgBtwjQOz1HRI16tfTk4bIgK1XDJg8DARqwBX LhlQ== 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=9R3qvcTRTtXsrAXvFgCen6nGwd0uWUFMTiVdcqa1Dhk=; b=RkzvrIhZzpTAwAMMVJ7E0jIU6Er1HSKyJmOrxRzvHJZs6JCho9bUmBd9y5SQHJNN7A CczHEz/BYa+Z4Yronjesl21l/hGf04cnmuLoddqAJxr4x+FKPE7VSlDVjvOESTURlBbT iTUDQaJQKsUdcrm8VpLLXmK7Q2E0/YeALEpvj4l2HeuR6RrJy7Yvmg+DBtWWTONand07 YzOImyqDnkarQBkUsvEs6b5jzCCGkpaQ1eZfZJAFlGPMJo8At9Z5WiwR2pVTi6ZrZ3Tb TYFrey0fgeBWjxriqq0isMvROEcYLXArKggPLDtNv6B7luimBg1hPpQDjof0EbqFuuvQ +1hQ== X-Gm-Message-State: AOAM533eF6zegOIoCCGnoDNetz9BVa47YEf61E4t3k+xWzSb3DizqVr8 jKtz6lWK7Xnnd6CxszxZpsIby5HFMwsu2+sAAZc= X-Google-Smtp-Source: ABdhPJwpU4Xn9VTsJOSqFcLtxeX6v0uKdKzwV6IU9AoLfBNMv3zGEi5Rg5zO4KN28O+LJbVPY2XtVRhIpm9k143a3R0= X-Received: by 2002:a19:942:: with SMTP id 63mr812858lfj.23.1598621382376; Fri, 28 Aug 2020 06:29:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 28 Aug 2020 06:29:05 -0700 Message-ID: To: Torsten Lodderstedt Cc: Dima Postnikov , oauth Content-Type: multipart/alternative; boundary="000000000000a0815705adf00b11" Archived-At: Subject: Re: [OAUTH-WG] third party applications 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, 28 Aug 2020 13:29:47 -0000 --000000000000a0815705adf00b11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The driver in my opinion for first-party use of OAuth is to separate the trust domains so that the application is scoped in what it can do vs an application that has full access to all resources. I agree that third-party can indicate that internal use does not apply. How about the following? The OAuth 2.1 authorization framework enables an *independent* application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749. =E1=90=A7 On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt wrote: > I agree. OAuth works for 3rd as well as 1st parties as well. > > > On 28. Aug 2020, at 05:26, Dima Postnikov wrote: > > > > Hi, > > > > Can "third-party" term be removed from the specification? > > > > The standard and associated best practices apply to other applications > that act on behalf of a resource owner, too (internal, "first-party" and > etc). > > > > Regards, > > > > Dima > > > > The OAuth 2.1 authorization framework enables a third-party > > > > application to obtain limited access to an HTTP service, either on > > behalf of a resource owner by orchestrating an approval interaction > > between the resource owner and the HTTP service, or by allowing the > > third-party application to obtain access on its own behalf. This > > specification replaces and obsoletes the OAuth 2.0 Authorization > > Framework described in > > RFC 6749. > > _______________________________________________ > > 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 > --000000000000a0815705adf00b11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The driver in my opinion for first-party use of OAuth is t= o separate the trust domains so that the application is scoped in what it c= an do vs an application that has full access to all resources. I agree that= third-party can indicate that internal use does not apply. How about the f= ollowing?

=C2=A0 =C2=A0The OAuth 2.1 authorization frame= work enables an independent
=C2=A0 =C2=A0application to obtain li= mited access to an HTTP service, either on
=C2=A0 =C2=A0behalf of a reso= urce owner by orchestrating an approval interaction
=C2=A0 =C2=A0between= the resource owner and the HTTP service, or by allowing the
=C2=A0 =C2= =A0application to obtain access on its own behalf.=C2=A0 This
=C2=A0 =C2= =A0specification replaces and obsoletes the OAuth 2.0 Authorization
=C2= =A0 =C2=A0Framework described in RFC 6749.
3D""=E1=90= =A7

On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt <torsten= =3D40lodderstedt.net@dm= arc.ietf.org> wrote:
I agree. OAuth works for 3rd as well as 1st parties as well.
> On 28. Aug 2020, at 05:26, Dima Postnikov <dima@postnikov.net> wrote:
>
> Hi,
>
> Can "third-party" term be removed from the specification? >
> The standard and associated best practices apply to other applications= that act on behalf of a resource owner, too (internal, "first-party&q= uot; and etc).
>
> Regards,
>
> Dima
>
> The OAuth 2.1 authorization framework enables a third-party
>
>=C2=A0 =C2=A0 application to obtain limited access to an HTTP service, = either on
>=C2=A0 =C2=A0 behalf of a resource owner by orchestrating an approval i= nteraction
>=C2=A0 =C2=A0 between the resource owner and the HTTP service, or by al= lowing the
>=C2=A0 =C2=A0 third-party application to obtain access on its own behal= f.=C2=A0 This
>=C2=A0 =C2=A0 specification replaces and obsoletes the OAuth 2.0 Author= ization
>=C2=A0 =C2=A0 Framework described in
> RFC 6749.
> _______________________________________________
> 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
--000000000000a0815705adf00b11-- From nobody Fri Aug 28 07:49:48 2020 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 8A2CD3A0CF8 for ; Fri, 28 Aug 2020 07:49:46 -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, 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 QGi03v-ZrvYl for ; Fri, 28 Aug 2020 07:49:45 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 BFECA3A0CF4 for ; Fri, 28 Aug 2020 07:49:44 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id ba12so1416970edb.2 for ; Fri, 28 Aug 2020 07:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Gj0hkq8mLEnt7ETh4N1aZiUNPU24zYEsQaJR8bYrwXo=; b=YezUYltr8+lXXIof8YyyXnS6DoJtHpL6tatkZKd+3UwKBcXe+qOljZcA5bDIPpR2gR yeQef8XsAJ23y5he67+iuzDGvwrC6WaBpsXv2emBfQ1oqgauqjRbQZCF85VKfu5iAYJ9 MOC7yUbR762bjHcmmBAUNXGT/TzWsqTGor5alUdgzLwIegtGVNzTnX+JJH1iqZz1DKaF ZzCh1Ft8IgLbpvPjgbEeNcSY07GHy1Cp7HflPrpxcq7tJa/7gv3nIOp1Y/qAWBVyItG8 u9VDFlt4nPhhf1KCAd3K7HdGNxW7m4Our5hwaO23TjNiCMvKD5G6WSmxlyQ3bmA6rLE3 fSOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Gj0hkq8mLEnt7ETh4N1aZiUNPU24zYEsQaJR8bYrwXo=; b=snba2Ow+HFZ0I+c80p4OaO4R9C0TSeJ+1qZLLHdq2oRAoTWK6HlTOqIMPizcWQCGVl R4uFkDpS96LgGWXdr1QEafm8rUEMGJI2m869l4otG4TOzZw3TD6T5W6QkUm7k8XRorRy TSaDdHCyU/QjaVN+oiPoNHKjmuZexZVm1Goqc/RUqYWZ1g9QildfUt9CpmL2Ovt3S0vg KN8qctXJrFHhpw7nKYUVdWkWCPsljDFDOotftHIWH8htdeNcOVqdcSBpf+2BRGoX5lKj 4WYYxcu/CTLpeZWjYYTHiFe0KMqzPvJxr3jG0aaEiVW3Zoobjryy6BoQUvcuV+f3UKLI 92CA== X-Gm-Message-State: AOAM530ydshQvyj2SxqJfTK2pb+4nPFQdHp1ZwoBbPBm9VLixWeXjkyW vnxNFCoj7k7S5fIbGZqJZKQElw== X-Google-Smtp-Source: ABdhPJwpEm3Rcitiowr8oQ8bUDv0KzYnveWizWWbthP1/YXttoX7ddDErNCYYGoFej1+QAb6KvmmBQ== X-Received: by 2002:a05:6402:b32:: with SMTP id bo18mr2263192edb.201.1598626183061; Fri, 28 Aug 2020 07:49:43 -0700 (PDT) Received: from p200300eb8f1e2a7f0135b1f6009a5514.dip0.t-ipconnect.de (p200300eb8f1e2a7f0135b1f6009a5514.dip0.t-ipconnect.de. [2003:eb:8f1e:2a7f:135:b1f6:9a:5514]) by smtp.gmail.com with ESMTPSA id n14sm1188787edb.52.2020.08.28.07.49.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Aug 2020 07:49:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Torsten Lodderstedt In-Reply-To: Date: Fri, 28 Aug 2020 16:49:41 +0200 Cc: Dima Postnikov , oauth Content-Transfer-Encoding: quoted-printable Message-Id: <2F52A020-8C82-4593-97D7-BE4C252CADD8@lodderstedt.net> References: To: Dick Hardt X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] third party applications 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, 28 Aug 2020 14:49:47 -0000 In my experience OAuth is used in 1st party scenarios as means to = separate functions (e.g. central user management vs. different products) = within the same trust domain thus enabling architectural flexibility.=20 I would just remove any constraint on the kind of applications OAuth can = be used for. I don=E2=80=99t see how this governs the protocol design. =20= > On 28. Aug 2020, at 15:29, Dick Hardt wrote: >=20 > The driver in my opinion for first-party use of OAuth is to separate = the trust domains so that the application is scoped in what it can do vs = an application that has full access to all resources. I agree that = third-party can indicate that internal use does not apply. How about the = following? >=20 > The OAuth 2.1 authorization framework enables an independent > application to obtain limited access to an HTTP service, either on > behalf of a resource owner by orchestrating an approval interaction > between the resource owner and the HTTP service, or by allowing the > application to obtain access on its own behalf. This > specification replaces and obsoletes the OAuth 2.0 Authorization > Framework described in RFC 6749. > =E1=90=A7 >=20 > On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt = wrote: > I agree. OAuth works for 3rd as well as 1st parties as well.=20 >=20 > > On 28. Aug 2020, at 05:26, Dima Postnikov = wrote: > >=20 > > Hi, > >=20 > > Can "third-party" term be removed from the specification? > >=20 > > The standard and associated best practices apply to other = applications that act on behalf of a resource owner, too (internal, = "first-party" and etc). > >=20 > > Regards, > >=20 > > Dima > >=20 > > The OAuth 2.1 authorization framework enables a third-party > >=20 > > application to obtain limited access to an HTTP service, either = on > > behalf of a resource owner by orchestrating an approval = interaction > > between the resource owner and the HTTP service, or by allowing = the > > third-party application to obtain access on its own behalf. This > > specification replaces and obsoletes the OAuth 2.0 Authorization > > Framework described in=20 > > RFC 6749. > > _______________________________________________ > > 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 From nobody Fri Aug 28 07:57:39 2020 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 2034E3A0C52 for ; Fri, 28 Aug 2020 07:57:37 -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_FONT_LOW_CONTRAST=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 64gCcXRQr-Gw for ; Fri, 28 Aug 2020 07:57:35 -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 EFEB63A0C57 for ; Fri, 28 Aug 2020 07:57:34 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id f26so1626638ljc.8 for ; Fri, 28 Aug 2020 07:57:34 -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=YKIxr0wIXgAMF5O2lOEhBsPZVdLZd2Zlp9ADmvcfvwY=; b=SVto7taw5Qu987cJ0CxJGJn+KmzLL8NNDYkvrjgKEkolMvcgmZH0EtXLkbeafIxOGj dygZZE8QFb9n7CrPuDnTgDrOCKRFne4+BzDDp6vq/xwFyHqu0xKX1IrdhYa1I/2tMxYI 0MdP7rec9dvAjuzm3EjDzdR1KNnljmyJeTCtM7AA6affHiPjzOVNXVLyv0qQay/554Lo p8g4uroWzEkGoCpgdwSri1ie40Q13Ai0GjYwhrIwU9Duv3auENgf0Zb5WvFydXKQhqXf ds1EraLIppLvBUWSMCX9Vxfge6lj+c1mqGUcefWsgWt0pLYro30wHGmjTAnEbwWx8OhL 7GWQ== 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=YKIxr0wIXgAMF5O2lOEhBsPZVdLZd2Zlp9ADmvcfvwY=; b=EeLCK5tmiXUS8UDp10iSfFC6EeOMT9h7EM7yc3hlcGz5g5rVNylnpaCqxakdZsAYVG PvYqNeyrAbrSfFMseoX8J/+WmlukDQyvji94nR5MQFcU9kBZlfByrpyD82IQZaoyCMGg NiPbXe4csn0dgvh8B3zYsBRAanmn4nBsSVj9LzistKgkHq9RTEUkL516YNJ3yaCCsaNR gRujt2B2SXipKas+9FcdbJoyhIHTzcAKPe33rCHhBqiQZen731aIsep6BH4fr6+YEhMu lOak4VnCGT1NXJqwB7ggzNqKKosUvIIRUme1gqc8eK2U7jCzBYXUivKcuT0a2a0JufAx 1KAg== X-Gm-Message-State: AOAM533gwEhJIBk/ww/jxYip+XmaZOdx+xJXN/1kHDuKxAA322UU1JVq e6dXInApf4ItC3Hc2+7jNpCGjUAgmlock3gg3SCR89fNFL8= X-Google-Smtp-Source: ABdhPJzki026YFkxig7sZ+5yj35+XZ+bqhb/s1sYAOMspDq9gEhWQRNsJtUGc/mViypNFu9N6TWvskTHUtmXjl0w54M= X-Received: by 2002:a2e:9b45:: with SMTP id o5mr1050965ljj.142.1598626652860; Fri, 28 Aug 2020 07:57:32 -0700 (PDT) MIME-Version: 1.0 References: <2F52A020-8C82-4593-97D7-BE4C252CADD8@lodderstedt.net> In-Reply-To: <2F52A020-8C82-4593-97D7-BE4C252CADD8@lodderstedt.net> From: Dick Hardt Date: Fri, 28 Aug 2020 07:56:56 -0700 Message-ID: To: Torsten Lodderstedt Cc: Dima Postnikov , oauth Content-Type: multipart/alternative; boundary="000000000000c5b54105adf145b9" Archived-At: Subject: Re: [OAUTH-WG] third party applications 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, 28 Aug 2020 14:57:37 -0000 --000000000000c5b54105adf145b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, OAuth is not very useful in a monolithic application. No need for an interoperable protocol for that kind of application. And in separating functions, you are creating separate trust domains. Yes, it is still all internal, but it enables a separation of concerns. =E1=90=A7 On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt wrote: > In my experience OAuth is used in 1st party scenarios as means to separat= e > functions (e.g. central user management vs. different products) within th= e > same trust domain thus enabling architectural flexibility. > > I would just remove any constraint on the kind of applications OAuth can > be used for. I don=E2=80=99t see how this governs the protocol design. > > > On 28. Aug 2020, at 15:29, Dick Hardt wrote: > > > > The driver in my opinion for first-party use of OAuth is to separate th= e > trust domains so that the application is scoped in what it can do vs an > application that has full access to all resources. I agree that third-par= ty > can indicate that internal use does not apply. How about the following? > > > > The OAuth 2.1 authorization framework enables an independent > > application to obtain limited access to an HTTP service, either on > > behalf of a resource owner by orchestrating an approval interaction > > between the resource owner and the HTTP service, or by allowing the > > application to obtain access on its own behalf. This > > specification replaces and obsoletes the OAuth 2.0 Authorization > > Framework described in RFC 6749. > > =E1=90=A7 > > > > On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt 40lodderstedt.net@dmarc.ietf.org> wrote: > > I agree. OAuth works for 3rd as well as 1st parties as well. > > > > > On 28. Aug 2020, at 05:26, Dima Postnikov wrote: > > > > > > Hi, > > > > > > Can "third-party" term be removed from the specification? > > > > > > The standard and associated best practices apply to other application= s > that act on behalf of a resource owner, too (internal, "first-party" and > etc). > > > > > > Regards, > > > > > > Dima > > > > > > The OAuth 2.1 authorization framework enables a third-party > > > > > > application to obtain limited access to an HTTP service, either on > > > behalf of a resource owner by orchestrating an approval interactio= n > > > between the resource owner and the HTTP service, or by allowing th= e > > > third-party application to obtain access on its own behalf. This > > > specification replaces and obsoletes the OAuth 2.0 Authorization > > > Framework described in > > > RFC 6749. > > > _______________________________________________ > > > 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 > > --000000000000c5b54105adf145b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, OAuth is not very useful in a monolithic application= . No need for an interoperable protocol for that kind of application.
<= br>
And in separating functions, you are creating separate trust = domains. Yes, it is still all internal, but it enables a separation of conc= erns.
=E1=90=A7

On Fri, Aug 28, 2020 at 7:49 AM T= orsten Lodderstedt <torsten@l= odderstedt.net> wrote:
In my experience OAuth is used in 1st party scenarios as mean= s to separate functions (e.g. central user management vs. different product= s) within the same trust domain thus enabling architectural flexibility.
I would just remove any constraint on the kind of applications OAuth can be= used for. I don=E2=80=99t see how this governs the protocol design.=C2=A0 =

> On 28. Aug 2020, at 15:29, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> The driver in my opinion for first-party use of OAuth is to separate t= he trust domains so that the application is scoped in what it can do vs an = application that has full access to all resources. I agree that third-party= can indicate that internal use does not apply. How about the following? >
>=C2=A0 =C2=A0 The OAuth 2.1 authorization framework enables an independ= ent
>=C2=A0 =C2=A0 application to obtain limited access to an HTTP service, = either on
>=C2=A0 =C2=A0 behalf of a resource owner by orchestrating an approval i= nteraction
>=C2=A0 =C2=A0 between the resource owner and the HTTP service, or by al= lowing the
>=C2=A0 =C2=A0 application to obtain access on its own behalf.=C2=A0 Thi= s
>=C2=A0 =C2=A0 specification replaces and obsoletes the OAuth 2.0 Author= ization
>=C2=A0 =C2=A0 Framework described in RFC 6749.
> =E1=90=A7
>
> On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt <torsten=3D40lodders= tedt.net@dmarc.ietf.org> wrote:
> I agree. OAuth works for 3rd as well as 1st parties as well.
>
> > On 28. Aug 2020, at 05:26, Dima Postnikov <dima@postnikov.net> wrote:
> >
> > Hi,
> >
> > Can "third-party" term be removed from the specificatio= n?
> >
> > The standard and associated best practices apply to other applica= tions that act on behalf of a resource owner, too (internal, "first-pa= rty" and etc).
> >
> > Regards,
> >
> > Dima
> >
> > The OAuth 2.1 authorization framework enables a third-party
> >
> >=C2=A0 =C2=A0 application to obtain limited access to an HTTP serv= ice, either on
> >=C2=A0 =C2=A0 behalf of a resource owner by orchestrating an appro= val interaction
> >=C2=A0 =C2=A0 between the resource owner and the HTTP service, or = by allowing the
> >=C2=A0 =C2=A0 third-party application to obtain access on its own = behalf.=C2=A0 This
> >=C2=A0 =C2=A0 specification replaces and obsoletes the OAuth 2.0 A= uthorization
> >=C2=A0 =C2=A0 Framework described in
> > RFC 6749.
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/oauth=
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

--000000000000c5b54105adf145b9-- From nobody Fri Aug 28 08:07:35 2020 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 2188C3A0C5E for ; Fri, 28 Aug 2020 08:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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 ZWoCp23lyefQ for ; Fri, 28 Aug 2020 08:07:32 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 58B103A0BE0 for ; Fri, 28 Aug 2020 08:07:32 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id a26so1974210ejc.2 for ; Fri, 28 Aug 2020 08:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jij21muY4aGcTfrRQqi6IQuvtg+LwXFb0yLH/idCOmQ=; b=iVjwPh1EFSTls/LTjR7/k4hovwubAMRmGkDiHF09iOdBrsg5U7s7XePlUcmB9fNFLs z7/UlHkQ0ziocp6P8RA4IGYN7RRSBWM97s/6ddAVZ+hE12eGfW7tudVCMBKIHFMKz6IY QqntD63Ez6CK88pgT93UDTMmI601xYECsuvCMnC8IG4A7O/5URHOv4wEj36VW7xt/uLN daSgOlakqw1lLA2Q2OUHjTKN0xFJMqm6WaOCvEWTjh1DCKtZ9c9OIqSEBJNltniqMGU+ cR+s2ZdTfwkvoq/iD8WqEGtfKWs6fuQYKcX98jvkWdfEb3WJXHzsrmei3vpd2XPG9SNH 806Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jij21muY4aGcTfrRQqi6IQuvtg+LwXFb0yLH/idCOmQ=; b=grY/GaoY5ZqKlRDNKV1OwmKiISMev+RledDHQpwHFHunBEtqAT3VI+8jvWvmWgPgCu 2789KTeltGnFUXRaTXT/vChWnj5EmG6Cd/CsSNjwpsJMOeaP7oeFKpglajZcvFIvu9K8 W2xj95OmTx2DDfMtDG+aNaopPwk+Tf36MRAlgZDaqYaNHMSTxEas8fqWSYCZsTD6p8vU FKAxFwkE/FhP0DiXivlDx/HZxxaE3Z1r2rX2vDh8h5ZihoNLbfQlTp7E5QhB05RHKaRY npOz65Oe23IfMExTwn5XbMdjlhnR+9WCOzWWbtMITyIRWvdWBlQ68wAMc9nKIFebPe/B 9Z/w== X-Gm-Message-State: AOAM531NWfDX2Swd/TeesQ9aLYzynYmsUYOyZnn682cMPoOmzduJuvfK yA4DReKSiYWR/Qwz9I2MYA+KBw== X-Google-Smtp-Source: ABdhPJxzizPKAYXl+YlhB/jZ6JvDKXaGJr4gflSvT1/CVKN9Cy/4q0IJMbYEY9YgB8CQ0AWlNw7cVw== X-Received: by 2002:a17:906:a293:: with SMTP id i19mr2356836ejz.523.1598627250620; Fri, 28 Aug 2020 08:07:30 -0700 (PDT) Received: from p200300eb8f1e2a7f0135b1f6009a5514.dip0.t-ipconnect.de (p200300eb8f1e2a7f0135b1f6009a5514.dip0.t-ipconnect.de. [2003:eb:8f1e:2a7f:135:b1f6:9a:5514]) by smtp.gmail.com with ESMTPSA id t21sm979852ejr.62.2020.08.28.08.07.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Aug 2020 08:07:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Torsten Lodderstedt In-Reply-To: Date: Fri, 28 Aug 2020 17:07:26 +0200 Cc: Dima Postnikov , oauth Content-Transfer-Encoding: quoted-printable Message-Id: References: <2F52A020-8C82-4593-97D7-BE4C252CADD8@lodderstedt.net> To: Dick Hardt X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] third party applications 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, 28 Aug 2020 15:07:34 -0000 > On 28. Aug 2020, at 16:56, Dick Hardt wrote: >=20 > Well, OAuth is not very useful in a monolithic application. No need = for an interoperable protocol for that kind of application. I don=E2=80=99t know why we need to make any assumptions about the = application that uses OAuth. A lot of assumptions might turn out to be = wrong. So if me make assumptions they must be relevant for the protocol = design.=20 So again, why is =E2=80=9Cindependent=E2=80=9D or =E2=80=9Cthird-party=E2=80= =9D relevant for the protocol design?=20 >=20 > And in separating functions, you are creating separate trust domains. = Yes, it is still all internal, but it enables a separation of concerns. > =E1=90=A7 >=20 > On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt = wrote: > In my experience OAuth is used in 1st party scenarios as means to = separate functions (e.g. central user management vs. different products) = within the same trust domain thus enabling architectural flexibility.=20 >=20 > I would just remove any constraint on the kind of applications OAuth = can be used for. I don=E2=80=99t see how this governs the protocol = design. =20 >=20 > > On 28. Aug 2020, at 15:29, Dick Hardt wrote: > >=20 > > The driver in my opinion for first-party use of OAuth is to separate = the trust domains so that the application is scoped in what it can do vs = an application that has full access to all resources. I agree that = third-party can indicate that internal use does not apply. How about the = following? > >=20 > > The OAuth 2.1 authorization framework enables an independent > > application to obtain limited access to an HTTP service, either = on > > behalf of a resource owner by orchestrating an approval = interaction > > between the resource owner and the HTTP service, or by allowing = the > > application to obtain access on its own behalf. This > > specification replaces and obsoletes the OAuth 2.0 Authorization > > Framework described in RFC 6749. > > =E1=90=A7 > >=20 > > On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt = wrote: > > I agree. OAuth works for 3rd as well as 1st parties as well.=20 > >=20 > > > On 28. Aug 2020, at 05:26, Dima Postnikov = wrote: > > >=20 > > > Hi, > > >=20 > > > Can "third-party" term be removed from the specification? > > >=20 > > > The standard and associated best practices apply to other = applications that act on behalf of a resource owner, too (internal, = "first-party" and etc). > > >=20 > > > Regards, > > >=20 > > > Dima > > >=20 > > > The OAuth 2.1 authorization framework enables a third-party > > >=20 > > > application to obtain limited access to an HTTP service, either = on > > > behalf of a resource owner by orchestrating an approval = interaction > > > between the resource owner and the HTTP service, or by allowing = the > > > third-party application to obtain access on its own behalf. = This > > > specification replaces and obsoletes the OAuth 2.0 = Authorization > > > Framework described in=20 > > > RFC 6749. > > > _______________________________________________ > > > 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 >=20 From nobody Fri Aug 28 09:00:02 2020 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 D35A83A0CEF for ; Fri, 28 Aug 2020 09:00:00 -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, MIME_QP_LONG_LINE=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=manicode.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 f3CceJjGZRAu for ; Fri, 28 Aug 2020 08:59:59 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 4A5853A0CFA for ; Fri, 28 Aug 2020 08:59:58 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id q3so684440pls.11 for ; Fri, 28 Aug 2020 08:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=/AEx9IGkYJTP06RUxo3whltAusIbVTNy9nQCdwbMdj0=; b=g6cpZZRlBK6jSEN9b6bWj5L/Bf47u/gOAY3voXIt+zD3p0wHkmp+bamlOXHJ/0T2FX +xtFTsNQ3RQj5xiD+PpdqdqiRNkQ3CmDbYTG0Lm3Ek9mkgkVdJVQfEZTYBEN6pgUsAg1 jU2mPbt6l2GtpJ6rVnH4kIUgtRE3ZqJDSFf3kCdRs59UyeWKPmZZw891ncqBh6J/U94E sei4gg18GxzqNnIgeS9O/o+nAF2Ze44AN+czfbefoCr4S22xhBacpCjeUPfXKN72T/vl cagKxrkP4SSzYP36J32JqBc/LG7lvh2ByI/YXce5nHhyw11dmgk4NWoUGwX9bNTto6bt +svQ== 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=/AEx9IGkYJTP06RUxo3whltAusIbVTNy9nQCdwbMdj0=; b=lkPwSAQfk6iZ14QbsDlWWuqoWAi8jkcWvOLMJkehpOSfINqxlsnucI923EAiYqYEmO NgKb8wCwD52GKSf/ky9eMQd9Zq/W2/3Kwt70Q/WXy6BbgRAqaZQAZzwGnF1qQF10Kz0x uA4l7wTpQCcVpC2xT+jGZffxairFusxdmBfSBrcM5ya9XU+Zq4VEFkxPdzOlGrXyF1WE OT2GedEG8mrLMPsWxngDLkPGPz/uaRMwM7YUN9Fgy5ErOsX5uCnfuFov4fSH+O8Pl3oK W5YuTNqdu2A6H6udUD50qH2kur7IjGn2dl6EU6N2oEEEHookatlOrFtgyl8vkCLqwPnw 0jVg== X-Gm-Message-State: AOAM532a8otS0cEUmCuUn2OXnf8T+cZdN0iMi/Jo/HImH8Yz7rL3seij JFsMYH3vcy64oS1sWokftA5sKU4q+bDB/i6L X-Google-Smtp-Source: ABdhPJxmIiPVK3WbUbJ2iFspt5xkAEm300cTYDez7+JB6UoyHxvyHasTqC+gTzufEIrheL2Is04XNQ== X-Received: by 2002:a17:90a:6881:: with SMTP id a1mr1875229pjd.208.1598630394774; Fri, 28 Aug 2020 08:59:54 -0700 (PDT) Received: from ?IPv6:2605:e000:112c:15:28d3:5ef7:8c7b:7aac? ([2605:e000:112c:15:28d3:5ef7:8c7b:7aac]) by smtp.gmail.com with ESMTPSA id 37sm1736640pjo.8.2020.08.28.08.59.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Aug 2020 08:59:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jim Manico Mime-Version: 1.0 (1.0) Date: Fri, 28 Aug 2020 05:59:52 -1000 Message-Id: <8507D885-1006-4BAC-8365-93FC93C91437@manicode.com> References: Cc: Dick Hardt , oauth In-Reply-To: To: Torsten Lodderstedt X-Mailer: iPhone Mail (17G80) Archived-At: Subject: Re: [OAUTH-WG] third party applications 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, 28 Aug 2020 16:00:01 -0000 It does not make sense to use OAuth in most single party situations. These s= ingle-party OAuth use cases are frequently a complete misuse of the framewor= k. I +1 the language =E2=80=9C3rd party=E2=80=9D in an effort to steer imple= mentors in the right direction. -- Jim Manico @Manicode > On Aug 28, 2020, at 5:07 AM, Torsten Lodderstedt wrote: >=20 > =EF=BB=BF >> On 28. Aug 2020, at 16:56, Dick Hardt wrote: >>=20 >> Well, OAuth is not very useful in a monolithic application. No need for a= n interoperable protocol for that kind of application. >=20 > I don=E2=80=99t know why we need to make any assumptions about the applica= tion that uses OAuth. A lot of assumptions might turn out to be wrong. So if= me make assumptions they must be relevant for the protocol design.=20 >=20 > So again, why is =E2=80=9Cindependent=E2=80=9D or =E2=80=9Cthird-party=E2=80= =9D relevant for the protocol design?=20 >=20 >>=20 >> And in separating functions, you are creating separate trust domains. Yes= , it is still all internal, but it enables a separation of concerns. >> =E1=90=A7 >>=20 >> On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt wrote: >> In my experience OAuth is used in 1st party scenarios as means to separat= e functions (e.g. central user management vs. different products) within the= same trust domain thus enabling architectural flexibility.=20 >>=20 >> I would just remove any constraint on the kind of applications OAuth can b= e used for. I don=E2=80=99t see how this governs the protocol design. =20 >>=20 >>>> On 28. Aug 2020, at 15:29, Dick Hardt wrote: >>>=20 >>> The driver in my opinion for first-party use of OAuth is to separate the= trust domains so that the application is scoped in what it can do vs an app= lication that has full access to all resources. I agree that third-party can= indicate that internal use does not apply. How about the following? >>>=20 >>> The OAuth 2.1 authorization framework enables an independent >>> application to obtain limited access to an HTTP service, either on >>> behalf of a resource owner by orchestrating an approval interaction >>> between the resource owner and the HTTP service, or by allowing the >>> application to obtain access on its own behalf. This >>> specification replaces and obsoletes the OAuth 2.0 Authorization >>> Framework described in RFC 6749. >>> =E1=90=A7 >>>=20 >>>> On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt wrote: >>> I agree. OAuth works for 3rd as well as 1st parties as well.=20 >>>=20 >>>> On 28. Aug 2020, at 05:26, Dima Postnikov wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> Can "third-party" term be removed from the specification? >>>>=20 >>>> The standard and associated best practices apply to other applications t= hat act on behalf of a resource owner, too (internal, "first-party" and etc)= . >>>>=20 >>>> Regards, >>>>=20 >>>> Dima >>>>=20 >>>> The OAuth 2.1 authorization framework enables a third-party >>>>=20 >>>> application to obtain limited access to an HTTP service, either on >>>> behalf of a resource owner by orchestrating an approval interaction >>>> between the resource owner and the HTTP service, or by allowing the >>>> third-party application to obtain access on its own behalf. This >>>> specification replaces and obsoletes the OAuth 2.0 Authorization >>>> Framework described in=20 >>>> RFC 6749. >>>> _______________________________________________ >>>> 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 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Aug 28 09:24:34 2020 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 974563A0DCB for ; Fri, 28 Aug 2020 09:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 XVrhZ00R5uzO for ; Fri, 28 Aug 2020 09:24:30 -0700 (PDT) Received: from mail-yb1-xb44.google.com (mail-yb1-xb44.google.com [IPv6:2607:f8b0:4864:20::b44]) (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 5D2A93A0DCA for ; Fri, 28 Aug 2020 09:24:30 -0700 (PDT) Received: by mail-yb1-xb44.google.com with SMTP id u6so876476ybf.1 for ; Fri, 28 Aug 2020 09:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MUlpJLgM+3t5CR6NOW6pL0yrahfaCLOT2oy4B37UjSw=; b=DpLRCXXQv288pePZMqF17d4iKTipLQtijaXMrS4nrRJxNDxMFeld8kBVDKhgzUwUri tauPxaIEvhoHZYSsE//rDgRn2q7m7789MZvWZS98NIuTg8aSDQi5valIBn8wIkhlMU6d 59z717CnjlQOchluG7vgnfBAI2WLa25nZcPykcz07U9qzB2TNS9QlsVnmiqy3ihVg11x a6InTbt21BPXkgQ6iAuoT6ALIqCLbmiYr+rSD3ofPcZSKSMBpOUce3n8SeCQbZJef8Gk UhLNjI91DrvuhfZGW8S6IzZBbJOBv4mpKMVXMjWT2rtYxiVbbBn6hSlTe+gDuYXE+Wav 8wRA== 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=MUlpJLgM+3t5CR6NOW6pL0yrahfaCLOT2oy4B37UjSw=; b=HGmMT/uVxl/9xjXahJ8GzAuwjkF68Dr8nEROgh3BDkrIOGFYD3vMFjWAsYIPYVJO6g ScwmjvUMhF4Epv4+gjopysCWl8SMBIJnRoRWphDXskUo6G5WA2FezRP0c2sh2wgkJzWk asy7NIbU8aIx8Z6+RiivWJN1wATuJx0yqyJ8sN1emc32dI5oRibaz/S0zsNDssJZn2Va LVVtCQZ6zXJjLhalnYiSYaxeMB4QmPoSRGwI/hdwpO8/pWeX7DJEc5Yfx/fdqUsF4Bct SIRLBJ3OHXBoTwKlrTybz6VgPB0viQW/YtehccEGueAipa2ztboo0HdWMkQbLfGY2Xuv UNxw== X-Gm-Message-State: AOAM532k3kvLm5cbMfrWP/sJG6xaP7aDSQ0bBoJwpKd9k9fZKod6mgJl hJReylSF9Ha4dqys83Yz7V017ruUa6/j1PAJo0I2aJg6fqc= X-Google-Smtp-Source: ABdhPJzPzjV2rG4OLHYxLrhADm2VCTbppPWQezVS9NmKIdQpNjMB712khTuyacpjg3737R2Kd4HpJHmOPxmKCHYdifI= X-Received: by 2002:a25:a441:: with SMTP id f59mr3478768ybi.42.1598631869287; Fri, 28 Aug 2020 09:24:29 -0700 (PDT) MIME-Version: 1.0 References: <8507D885-1006-4BAC-8365-93FC93C91437@manicode.com> In-Reply-To: <8507D885-1006-4BAC-8365-93FC93C91437@manicode.com> From: Jeff Craig Date: Fri, 28 Aug 2020 11:24:18 -0500 Message-ID: To: Jim Manico Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="000000000000b2869f05adf27c12" Archived-At: Subject: Re: [OAUTH-WG] third party applications 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, 28 Aug 2020 16:24:33 -0000 --000000000000b2869f05adf27c12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OAuth may be overkill for most single-party cases, but there is nothing about the protocol that precludes the use case. A similar argument could be made that including the third-party language steers implementers who perhaps would benefit from OAuth away from the specification, making both positions low-value arguments. It could make sense to provide a section discussing this single-party vs third-party issue elsewhere in the document (or perhaps in a BCP covering application authentication and authorization that discusses OAuth, but also other options), but I think the Abstract of this document does not benefit from over classifying the application. On Fri, Aug 28, 2020 at 11:00 AM Jim Manico wrote: > It does not make sense to use OAuth in most single party situations. Thes= e > single-party OAuth use cases are frequently a complete misuse of the > framework. I +1 the language =E2=80=9C3rd party=E2=80=9D in an effort to = steer implementors > in the right direction. > > -- > Jim Manico > @Manicode > > > > On Aug 28, 2020, at 5:07 AM, Torsten Lodderstedt 40lodderstedt.net@dmarc.ietf.org> wrote: > > > > =EF=BB=BF > >> On 28. Aug 2020, at 16:56, Dick Hardt wrote: > >> > >> Well, OAuth is not very useful in a monolithic application. No need fo= r > an interoperable protocol for that kind of application. > > > > I don=E2=80=99t know why we need to make any assumptions about the appl= ication > that uses OAuth. A lot of assumptions might turn out to be wrong. So if m= e > make assumptions they must be relevant for the protocol design. > > > > So again, why is =E2=80=9Cindependent=E2=80=9D or =E2=80=9Cthird-party= =E2=80=9D relevant for the > protocol design? > > > >> > >> And in separating functions, you are creating separate trust domains. > Yes, it is still all internal, but it enables a separation of concerns. > >> =E1=90=A7 > >> > >> On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> In my experience OAuth is used in 1st party scenarios as means to > separate functions (e.g. central user management vs. different products) > within the same trust domain thus enabling architectural flexibility. > >> > >> I would just remove any constraint on the kind of applications OAuth > can be used for. I don=E2=80=99t see how this governs the protocol design= . > >> > >>>> On 28. Aug 2020, at 15:29, Dick Hardt wrote: > >>> > >>> The driver in my opinion for first-party use of OAuth is to separate > the trust domains so that the application is scoped in what it can do vs = an > application that has full access to all resources. I agree that third-par= ty > can indicate that internal use does not apply. How about the following? > >>> > >>> The OAuth 2.1 authorization framework enables an independent > >>> application to obtain limited access to an HTTP service, either on > >>> behalf of a resource owner by orchestrating an approval interaction > >>> between the resource owner and the HTTP service, or by allowing the > >>> application to obtain access on its own behalf. This > >>> specification replaces and obsoletes the OAuth 2.0 Authorization > >>> Framework described in RFC 6749. > >>> =E1=90=A7 > >>> > >>>> On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt 40lodderstedt.net@dmarc.ietf.org> wrote: > >>> I agree. OAuth works for 3rd as well as 1st parties as well. > >>> > >>>> On 28. Aug 2020, at 05:26, Dima Postnikov wrote= : > >>>> > >>>> Hi, > >>>> > >>>> Can "third-party" term be removed from the specification? > >>>> > >>>> The standard and associated best practices apply to other > applications that act on behalf of a resource owner, too (internal, > "first-party" and etc). > >>>> > >>>> Regards, > >>>> > >>>> Dima > >>>> > >>>> The OAuth 2.1 authorization framework enables a third-party > >>>> > >>>> application to obtain limited access to an HTTP service, either on > >>>> behalf of a resource owner by orchestrating an approval interactio= n > >>>> between the resource owner and the HTTP service, or by allowing th= e > >>>> third-party application to obtain access on its own behalf. This > >>>> specification replaces and obsoletes the OAuth 2.0 Authorization > >>>> Framework described in > >>>> RFC 6749. > >>>> _______________________________________________ > >>>> 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 > >> > > > > _______________________________________________ > > 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 > --000000000000b2869f05adf27c12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OAuth may be overkill for most single-party cases, but the= re is nothing about the protocol that precludes the use case. A similar arg= ument could be made that including the third-party language steers implemen= ters who perhaps would benefit from OAuth away from the specification, maki= ng both positions low-value arguments. It could make sense to provide a sec= tion discussing this single-party vs third-party issue elsewhere in the doc= ument (or perhaps in a BCP covering application authentication and authoriz= ation that discusses OAuth, but also other options), but I think the Abstra= ct of this document does not benefit from over classifying the application.=

= On Fri, Aug 28, 2020 at 11:00 AM Jim Manico <jim@manicode.com> wrote:
It does not make sense to use OAuth in most single= party situations. These single-party OAuth use cases are frequently a comp= lete misuse of the framework. I +1 the language =E2=80=9C3rd party=E2=80=9D= in an effort to steer implementors in the right direction.

--
Jim Manico
@Manicode


> On Aug 28, 2020, at 5:07 AM, Torsten Lodderstedt <torsten=3D40loddersted= t.net@dmarc.ietf.org> wrote:
>
> =EF=BB=BF
>> On 28. Aug 2020, at 16:56, Dick Hardt <dick.hardt@gmail.com> wrote:
>>
>> Well, OAuth is not very useful in a monolithic application. No nee= d for an interoperable protocol for that kind of application.
>
> I don=E2=80=99t know why we need to make any assumptions about the app= lication that uses OAuth. A lot of assumptions might turn out to be wrong. = So if me make assumptions they must be relevant for the protocol design. >
> So again, why is =E2=80=9Cindependent=E2=80=9D or =E2=80=9Cthird-party= =E2=80=9D relevant for the protocol design?
>
>>
>> And in separating functions, you are creating separate trust domai= ns. Yes, it is still all internal, but it enables a separation of concerns.=
>> =E1=90=A7
>>
>> On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt <torsten@lodderstedt.net<= /a>> wrote:
>> In my experience OAuth is used in 1st party scenarios as means to = separate functions (e.g. central user management vs. different products) wi= thin the same trust domain thus enabling architectural flexibility.
>>
>> I would just remove any constraint on the kind of applications OAu= th can be used for. I don=E2=80=99t see how this governs the protocol desig= n.=C2=A0
>>
>>>> On 28. Aug 2020, at 15:29, Dick Hardt <dick.hardt@gmail.com> wrot= e:
>>>
>>> The driver in my opinion for first-party use of OAuth is to se= parate the trust domains so that the application is scoped in what it can d= o vs an application that has full access to all resources. I agree that thi= rd-party can indicate that internal use does not apply. How about the follo= wing?
>>>
>>>=C2=A0 =C2=A0The OAuth 2.1 authorization framework enables an i= ndependent
>>>=C2=A0 =C2=A0application to obtain limited access to an HTTP se= rvice, either on
>>>=C2=A0 =C2=A0behalf of a resource owner by orchestrating an app= roval interaction
>>>=C2=A0 =C2=A0between the resource owner and the HTTP service, o= r by allowing the
>>>=C2=A0 =C2=A0application to obtain access on its own behalf.=C2= =A0 This
>>>=C2=A0 =C2=A0specification replaces and obsoletes the OAuth 2.0= Authorization
>>>=C2=A0 =C2=A0Framework described in RFC 6749.
>>> =E1=90=A7
>>>
>>>> On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt <to= rsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
>>> I agree. OAuth works for 3rd as well as 1st parties as well. <= br> >>>
>>>> On 28. Aug 2020, at 05:26, Dima Postnikov <dima@postnikov.net> wrot= e:
>>>>
>>>> Hi,
>>>>
>>>> Can "third-party" term be removed from the speci= fication?
>>>>
>>>> The standard and associated best practices apply to other = applications that act on behalf of a resource owner, too (internal, "f= irst-party" and etc).
>>>>
>>>> Regards,
>>>>
>>>> Dima
>>>>
>>>> The OAuth 2.1 authorization framework enables a third-part= y
>>>>
>>>>=C2=A0 =C2=A0application to obtain limited access to an HTT= P service, either on
>>>>=C2=A0 =C2=A0behalf of a resource owner by orchestrating an= approval interaction
>>>>=C2=A0 =C2=A0between the resource owner and the HTTP servic= e, or by allowing the
>>>>=C2=A0 =C2=A0third-party application to obtain access on it= s own behalf.=C2=A0 This
>>>>=C2=A0 =C2=A0specification replaces and obsoletes the OAuth= 2.0 Authorization
>>>>=C2=A0 =C2=A0Framework described in
>>>> RFC 6749.
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oa= uth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>>
>
> _______________________________________________
> 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
--000000000000b2869f05adf27c12-- From nobody Fri Aug 28 09:37:19 2020 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 E30813A0DEE for ; Fri, 28 Aug 2020 09:37:16 -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=parecki.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 XaRJaKKUKjsq for ; Fri, 28 Aug 2020 09:37:14 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 E74943A0DF3 for ; Fri, 28 Aug 2020 09:37:13 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id m23so1994271iol.8 for ; Fri, 28 Aug 2020 09:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OPUa6miKlADczBljYH0AuLO9DVDzGNMLMXRTpAyG+ps=; b=S5h/0qxeVzu9HG5PVRZaH6WQ03a4KKGBKxe+ahDE5MOTkgY/uBLeunjAa6/1i8udaK CAKAtruRWWlFyf7Fij+mov+CYQVLZOiuVlokkEUCEN7loHYwwaaNA97XhlQX1wdJCeNd OBKhDMZG8Wev9RozFPAcdpY4yi3v+xz/tlvPsDazNq4ox0YYZRX3W19jCyoMlfL/b2Y7 hXSW/DuplE2Q2PWwg84++0J5xeiK/Vjt0oeuZ1bfAKyBAqzAjdMSah+aeRMwl/1LtmHU lAbIOVvbqk/69JfNcbIbql2cPGCTrJK8IStSRBc7vQ/2XUsgA/uFrVNL37UNKHuMhJ+A LpSg== 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=OPUa6miKlADczBljYH0AuLO9DVDzGNMLMXRTpAyG+ps=; b=XRkHrtx3FX98FGwCHNaKEbAzDeNhMwV+Jln/TDIksNXFyt0TCgMzlWK012faoLPWfe 2PrwyB6rnjeAwtUEcGr5GiBAABBV4TwX/6o75ZeaTOJrKXpuAmL+uo96aI11Nt1R6/uE RTMcIVd72cGs2Iph4/X3/cdRFsBCm1mviuz0ckSU7A5yI4/RMDVQCVohY73O7nXSLOLG 66N9GWWDNZj7Z6kx+X+ILjq/jXsHMUYZUtROa75KLKXAC/J3H+TYn1OxMFSac9rddror Ty9hgd8qlIDzpt/OtAuY0es3AYaq8NsM9/hhNH5wd6HOjH+M3wBoBBnxLO8+r7TgEMtd D+CQ== X-Gm-Message-State: AOAM531pbHtx52sHLccQetiAbudTJAjhXVP+nAAWA4gHHgBZXSobDcaa 0wemVTnwOz3k4XgEoM13Xaazgu6cXuplvQ== X-Google-Smtp-Source: ABdhPJxTmTUzXUQNFqTMkWoBsydkj+gHAEUJEk1pH7sKFXhwSPOs3P7AtMzWyUrwZ8YQBAPvVyhfHg== X-Received: by 2002:a05:6638:621:: with SMTP id h1mr1977883jar.143.1598632632478; Fri, 28 Aug 2020 09:37:12 -0700 (PDT) Received: from mail-il1-f172.google.com (mail-il1-f172.google.com. [209.85.166.172]) by smtp.gmail.com with ESMTPSA id z72sm786516iof.29.2020.08.28.09.37.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Aug 2020 09:37:11 -0700 (PDT) Received: by mail-il1-f172.google.com with SMTP id t4so1218405iln.1 for ; Fri, 28 Aug 2020 09:37:10 -0700 (PDT) X-Received: by 2002:a92:9986:: with SMTP id t6mr1347615ilk.28.1598632630617; Fri, 28 Aug 2020 09:37:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Fri, 28 Aug 2020 09:36:59 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Torsten Lodderstedt Cc: Dima Postnikov , oauth Content-Type: multipart/alternative; boundary="000000000000130f8905adf2aa3b" Archived-At: Subject: Re: [OAUTH-WG] third party applications 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, 28 Aug 2020 16:37:17 -0000 --000000000000130f8905adf2aa3b Content-Type: text/plain; charset="UTF-8" I agree. While the original motivations for OAuth were to support third-party apps, it's proven to be useful in many other kinds of situations as well, even when it's a "first-party" app but the OAuth server is operated by a different organization than the APIs. I don't think the abstract needs any qualification on this and would only confuse people further. Any clarifications of which situations are appropriate for using OAuth could be explored in a different section in the spec. Aaron Parecki On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt wrote: > I agree. OAuth works for 3rd as well as 1st parties as well. > > > On 28. Aug 2020, at 05:26, Dima Postnikov wrote: > > > > Hi, > > > > Can "third-party" term be removed from the specification? > > > > The standard and associated best practices apply to other applications > that act on behalf of a resource owner, too (internal, "first-party" and > etc). > > > > Regards, > > > > Dima > > > > The OAuth 2.1 authorization framework enables a third-party > > > > application to obtain limited access to an HTTP service, either on > > behalf of a resource owner by orchestrating an approval interaction > > between the resource owner and the HTTP service, or by allowing the > > third-party application to obtain access on its own behalf. This > > specification replaces and obsoletes the OAuth 2.0 Authorization > > Framework described in > > RFC 6749. > > _______________________________________________ > > 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 > --000000000000130f8905adf2aa3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree. While the original motivations for OAuth were to = support third-party apps, it's proven to be useful in many other kinds = of situations as well, even when it's a "first-party" app but= the OAuth server is operated by a different organization than the APIs. I = don't think the abstract needs any qualification on this and would only= confuse people further. Any clarifications of which situations are appropr= iate for using OAuth could be explored in a different section in the spec.<= div>
Aaron Parecki

=
On Fri, Aug 28, 2020 at 3:02 AM Torst= en Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
I agree. OAuth works for 3rd as well = as 1st parties as well.

> On 28. Aug 2020, at 05:26, Dima Postnikov <dima@postnikov.net> wrote:
>
> Hi,
>
> Can "third-party" term be removed from the specification? >
> The standard and associated best practices apply to other applications= that act on behalf of a resource owner, too (internal, "first-party&q= uot; and etc).
>
> Regards,
>
> Dima
>
> The OAuth 2.1 authorization framework enables a third-party
>
>=C2=A0 =C2=A0 application to obtain limited access to an HTTP service, = either on
>=C2=A0 =C2=A0 behalf of a resource owner by orchestrating an approval i= nteraction
>=C2=A0 =C2=A0 between the resource owner and the HTTP service, or by al= lowing the
>=C2=A0 =C2=A0 third-party application to obtain access on its own behal= f.=C2=A0 This
>=C2=A0 =C2=A0 specification replaces and obsoletes the OAuth 2.0 Author= ization
>=C2=A0 =C2=A0 Framework described in
> RFC 6749.
> _______________________________________________
> 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
--000000000000130f8905adf2aa3b-- From nobody Fri Aug 28 17:22:06 2020 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 0837D3A0E75 for ; Fri, 28 Aug 2020 17:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-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=microsoft.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 mbFKkUVFJQd2 for ; Fri, 28 Aug 2020 17:21:59 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640113.outbound.protection.outlook.com [40.107.64.113]) (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 200ED3A0E74 for ; Fri, 28 Aug 2020 17:21:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZCX4kjcoZMLRQY5C5g4xXZAe7KYqQjAWSMxFQtLD3L7TY+e0sRtb2mU0qv/J7bB3+CnG2szsnR2aT1DTgCfvS8OM/qOO+Sof4/JM4L2TjI0RAkbSpzvuEV0+sprpOTCihybbRGZ9vLZxB2qhy7yLKAI3+/TzAr587x5jPHKcDBsQ3/6axu+Kmkq0VB3yH3XDz478nmtgG573++HH8616Jzo3Xvkk6LHG+DguVxA7XTcDqHZzs/wTXx/6/NmwPBBjNz9Iavl2Bze0RFr/glyC2BE6sekyM25pqm3o/nAFG2ytlUYV37ZHXRMAX4IPKgLk+rwjtNBhQnLxvjHaefqWzQ== 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=X5cXwrMZ/wCUyvHHelpRZayPgctFWfVPG3t8EmC0KxM=; b=H4fMBqjMVBdIWVnRLpfEPzP6VIVUFLn9IWAm0stYOqCqrhcCK+SxnoszHjivZU5176QdTj71tagbiqsa8tkMGdtW+LfUIOB8wyACTZfvqdF5IUQWvoV3eXECBebCmgl5eqXq+E6x9OBTSHAQrcdN3yRPNV61A62RnjlZTLLpFfo/d0mVF/MSUZSPj6F8xpFWnM+0SFwAqkah1YtOGtJEDzGzvrtOnLywrzGXgmSgj/4Rie9eAXifTaynoDlLmLrvaf6gLQvqVLvzAfzYofjVGzgHp7BpZTJ+tX2K4UEEnIr4Cq75JYeV828d7aisEZjrq12C509aVupo0pA6hngNmA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X5cXwrMZ/wCUyvHHelpRZayPgctFWfVPG3t8EmC0KxM=; b=ba0NrGoXx7Y0DJuRsH4qUbMkB0/g9pPvEzjZTACwOIEP0FaRPa7o5dK74EqzLGGHHKEFminTcKvHQby2FIgv+/BrPKhMs628oUFP+tMqanDb977zp7rxt7kqUIKSTqvTdxCrBgxZiAXZ8V1tYYIuAlSuWuSi2bkTseRGHa8k+kw= Received: from (2603:10b6:5:21c::8) by DM6PR00MB0831.namprd00.prod.outlook.com (2603:10b6:5:20d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3375.0; Sat, 29 Aug 2020 00:21:56 +0000 Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::201a:3483:38b9:fe9f]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::201a:3483:38b9:fe9f%3]) with mapi id 15.20.3375.000; Sat, 29 Aug 2020 00:21:56 +0000 From: Mike Jones To: dick.hardt , Justin Richer CC: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] WGLC Review of PAR Thread-Index: AdZ9mmVYNw8LyZ0tRL6OVh0+8bIpvg== Date: Sat, 29 Aug 2020 00:21:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=b99b2b34-cc9d-425d-bcc4-f7ef39d0bf06; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-29T00:20:23Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.94.10] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 23368013-6d0e-4a0c-4144-08d84bb189cf x-ms-traffictypediagnostic: DM6PR00MB0831: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr 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: zoOBbQZ5rkk6KR6dxKzXCOXlM0fwy1+t/kOTg87q6CLJ6seNs+GrMQS/NP9BctLCMXzILjxOkJmLZJFNVwtFikpYz0wP/Rc0V2IZwbVxs/Zz59k9wxVBK87ld6X/jJWQlE3ciChJwDXgZgX0AzjMPkhofXRVK5DY/MY7B6HhqJazjbo820OWATJvzDp+YlD396JKtnOTS3aPIpWy39jOM+3FZs9EVVoSZmdXhEwq2RzA0RODi+kqtJhYzYDSI+nF736phcSkWnHzbuADu4cO50sLMwputa+P6mviJNICbQ2hgxsUSVFT3T77QWNJgc47hvHgoQ87aC3ZFHUSC4Z60yruv48pEN4ijwaMAlQ+YdJgN85iuBqAcM29LWiCr5b0QxvFd+0zPAaUwSH2tiLTwoAaEye3kuRRXf9ERHIY9BBzT4b2jE0PXndurK62fWiDeby8buQeS/i2uH6BqjMRjg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0684.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(346002)(376002)(136003)(366004)(66946007)(10290500003)(86362001)(166002)(2906002)(8990500004)(4326008)(66574015)(8936002)(76236003)(8676002)(83380400001)(76116006)(66476007)(66556008)(64756008)(71200400001)(33656002)(54906003)(110136005)(66446008)(6506007)(53546011)(26005)(186003)(52536014)(82960400001)(82950400001)(7696005)(9686003)(478600001)(55016002)(316002)(5660300002)(966005)(99710200001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: c9kBSzvAOMuYaDlwUFiS3IQpLlp5GohfeyEFQ7W3zE4xJSmNk0PMoLxHEB0fBR72NbsjqJl20hC6i6Y3FLsleCgsasFWHI28HZo0RbQCbybsrfT+N7DO/lSUCzTw58Dw8XCQvzyA4HtrLW3QdUxyPb0GqMawfEEU7pX6/cpo3d4V4bHgjK7AepArcPY+6qAnu+eYAKM0P13G5NlE9zk0uTTCcklgJ9gLxtxjuHtPb0Sb2BbE5g6uEQMP/kV3mDnJ/JWLeiQVKoaLKAc12dwqWp3HpVyldhbN9KdSWOnqHC0cXvfRZE5itaHDBfqPk5ow6y7q2jSoeVGQpKATICZbRsd8oksrI899becnidZsYfxsUYb3YbKVXupJr1bmcKn6/mlDyUChyZlnp6JGb1e7NM/I1Sys6lMp/mazIvsEpHGrg7+WD7WgZ8DCsjxU8FGjIPuGoeLsvoR3Wq6Z/AMf0oCaqb8RxC9hsZNrWLnty2IA+DXI2zOX0yYRBLInlUiA4if3IMnR0wOjgE5hOe+FhPThJKL3FhqMhQNfZCbK+7g+znKOA7MLcmGSNc4IhSG6zOwJTSY0xviDssYjXv57uYYA+mVKNqADTG20w9+rHNhAsBPm3tUCzIbptIbUi5nhs/QGKjAG6WYGUiF1bR/w7w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0684BEBE5FAB3E2C483298B4F5531DM6PR00MB0684namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0684.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 23368013-6d0e-4a0c-4144-08d84bb189cf X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2020 00:21:56.4956 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: D4HVbtTvcuLY2hBnnTNViie7H2i2zdvNRrftGDTMfHv7zDk1CXPblPoomQSbaovz9t9QsMtTKi86ZIadIq2yMQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0831 Archived-At: Subject: Re: [OAUTH-WG] WGLC Review of PAR 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, 29 Aug 2020 00:22:03 -0000 --_000_DM6PR00MB0684BEBE5FAB3E2C483298B4F5531DM6PR00MB0684namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIERpY2sgdGhhdCBpdCB3b3VsZCBiZSBhIG1pc3Rha2UgdG8gbWFrZSB0aGUg VVJMIG9uZS10aW1lIHVzZS4gIEl04oCZcyB1bmVuZm9yY2VhYmxlIGFuZCB1bm5lY2Vzc2FyaWx5 IGdldHMgaW4gdGhlIHdheSBvZiB2YWx1YWJsZSBkZXBsb3ltZW50IHBhdHRlcm5zLg0KDQpGcm9t OiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIERpY2sgSGFyZHQN ClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjcsIDIwMjAgOToxMiBBTQ0KVG86IEp1c3RpbiBSaWNo ZXIgPGpyaWNoZXJAbWl0LmVkdT4NCkNjOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGlu Z2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz47IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFdHTEMgUmV2aWV3IG9mIFBBUg0KDQpUaGF0IGlzIG5vdCBj b3JyZWN0Lg0KDQpUaGUgYXV0aG9yaXphdGlvbiBjb2RlIG9uZS10aW1lLXVzZSBpcyBkaXJlY3Rs eSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBBUy4gVGhlIGNsaWVudCBoYXMgYSBudW1iZXIg b2YgbWVjaGFuaXNtcyB0byBlbnN1cmUgaXQgb25seSBwcmVzZW50cyB0aGUgYXV0aG9yaXphdGlv biBjb2RlIHRvIHRoZSBBUyBvbmNlLCBzdWNoIGFzIGEgc2Vzc2lvbiB0aGF0IHdhcyBzZXQgd2hl biB0aGUgdXNlciBzdGFydGVkIGF0IHRoZSBjbGllbnQuDQoNCkluIGNvbnRyYXN0LCBpbiBhIHJl ZGlyZWN0IGZyb20gdGhlIGNsaWVudCB0byB0aGUgQVMsIHRoZSBjbGllbnQgbG9zZXMgY29udHJv bCBvbiBob3cgbWFueSB0aW1lcyB0aGUgdXNlci1hZ2VudCBsb2FkcyB0aGUgVVJMIGF0IHRoZSBB Uy4gQWRkaXRpb25hbGx5LCB0aGVyZSBpcyB1bmxpa2VseSB0byBiZSBhbiBhY3RpdmUgYnJvd3Nl ciBzZXNzaW9uIGF0IHRoZSBBUywgc28gdGhlIEFTIGNhbiBub3QgZWFzaWx5IGRpZmZlcmVudGlh dGUgYmV0d2VlbiBhIFVSTCBsb2FkIGZyb20gdGhlIHNhbWUgdXNlciwgb3IgZGlmZmVyZW50IHVz ZXJzLiBJZiBvbmUtdGltZS11c2UsIG9uZSBvZiB0aGVtIE1VU1QgZmFpbC4gSWYgdGhlIHR3byBy ZXF1ZXN0cyBoYXBwZW4gdG8gYmUgZnJvbSB0aGUgc2FtZSB1c2VyIChiZWNhdXNlIG9mIGEgcmVs b2FkLCB3aGljaCB0aGUgdXNlciBkaWQgYmVjYXVzZSB0aGUgQVMgd2FzIHNsb3cgdG8gcmVzcG9u ZCksIHRoZXJlIGlzIG5vIHdheSBmb3IgdGhlIEFTIHRvIGtub3cgd2hpY2ggb2YgdGhlIHJlcXVl c3RzIGlzIHRoZSBvbmUgdGhhdCBpcyBjdXJyZW50IGluIGZyb250IG9mIHRoZSB1c2VyLiBXaGls ZSB0aGUgQVMgY2FuIGludGVybmFsbHkgZW5zdXJlIHByb2Nlc3Npbmcgb2YgdGhlIHJlcXVlc3Qg b25jZSwgb25lLXRpbWUtdXNlIHdvdWxkIGRpY3RhdGUgdGhhdCBpdCBwcm92aWRlcyBhIGZhaWx1 cmUgbWVzc2FnZSB0byBvbmUgb2YgdGhlIHJlcXVlc3RzLg0KDQovRGljaw0KDQoNCuGQpw0KDQpP biBUaHUsIEF1ZyAyNywgMjAyMCBhdCA3OjE3IEFNIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0 LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQpXZSBhbHJlYWR5IGhhdmUgdGhp cyBzYW1lIHByb3BlcnR5IHdpdGggYXV0aG9yaXphdGlvbiBjb2RlcywgYW5kIGl04oCZcyBtYW5h Z2VkIHRvZGF5IHJlYXNvbmFibHkgd2VsbCAoaW4gbXkgb3BpbmlvbikuIElmIHlvdSBzdWJtaXQg dGhlIHNhbWUgcmVxdWVzdCBVUkkgdHdpY2UgaW4gdGhlIHNhbWUgYnJvd3NlciAodGhlIHJlZnJl c2ggeW914oCZcmUgdGFsa2luZyBhYm91dCksIGl0IHNob3VsZG7igJl0IHN0YXJ0IHR3byBzZXBh cmF0ZSBhdXRob3JpemF0aW9uIHJlcXVlc3RzLCBidXQgaXQgd291bGQgYmUgcmVhc29uYWJsZSB0 byBkZXRlY3QgdGhhdCB0aGUgc2FtZSBzZXNzaW9uIGF0dGFjaGVkIHRvIHRoZSBzYW1lIHJlcXVl c3QgVVJJIHZhbHVlIHNob3dlZCB1cCB0d2ljZSBhbmQgY29udGludWUgdGhlIHNlc3Npb24gYXMg YXBwcm9wcmlhdGUuDQoNCk5vbmUgb2YgdGhpcyBpcyBpbiBjb25mbGljdCB3aXRoIOKAnG9uZSB0 aW1lIHVzZeKAnSwgaW4gbXkgdmlldywgc2luY2UgeW914oCZcmUgYWN0aXZlbHkgZGV0ZWN0aW5n IHRoZSBzZXNzaW9uIGFuZCBzb3VyY2Ugb2YgdGhlIHZhbHVlLg0KDQog4oCUIEp1c3Rpbg0KDQoN Ck9uIEF1ZyAyNiwgMjAyMCwgYXQgNjoxNiBQTSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFp bC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQoNCkkgdGhpbmsgb25l LXRpbWUgdXNlIG1heSBiZSBvdmVybHkgcmVzdHJpY3RpdmUsIGFuZCBJIGRvbid0IHRoaW5rIGl0 IGlzIHRoZSBwcm9wZXJ0eSB0aGF0IHdlIGFjdHVhbGx5IHdhbnQuDQoNCkdpdmUgdGhlIHJlcXVl c3QgVVJJIGlzIGluIGEgcmVkaXJlY3QgZnJvbSB0aGUgYnJvd3NlciwgdGhlcmUgaXMgYSBnb29k IGNoYW5jZSBvZiBhIHJhY2UgY29uZGl0aW9uIHdoZXJlIHRoZSBzYW1lIGJyb3dzZXIgcmVxdWVz dCBpcyBtYWRlIG1vcmUgdGhhbiBvbmNlLCBmb3IgZXhhbXBsZSwgd2hpbGUgdGhlIGJyb3dzZXIg aXMgbG9hZGluZyB0aGUgYXV0aG9yaXphdGlvbiBVUkwgYXQgdGhlIEFTLCB0aGUgdXNlciBjb3Vs ZCByZWZyZXNoIHRoZSBwYWdlIGNhdXNpbmcgdGhlIGF1dGhvcml6YXRpb24gVVJMIHRvIGJlIHJl bG9hZGVkLiBXb3VsZCB0aGUgcmVsb2FkIGNvdW50IGFzIGEgc2Vjb25kIHVzZT8gT25lIGNvdWxk IGFyZ3VlIGl0IGVpdGhlciB3YXkuDQoNCldoYXQgSSB0aGluayB3ZSB3YW50IGZyb20gd2hhdCBJ IHVuZGVyc3RhbmQsIGlzIHRoZSByZXF1ZXN0IFVSSSBNVVNUIGJlIHVuaXF1ZSBzbyB0aGF0IHRo ZXJlIGlzIG5vIGNvbmZ1c2lvbiBvbiB3aGljaCByZXF1ZXN0IGlzIGJlaW5nIHJlZmVyZW5jZWQu DQoNCkkgZGlkIG5vdCBzZWUgYW55dGhpbmcgYWJvdXQgdGhlIGV4cGlyeSB0aW1lIG9mIHRoZSBy ZXF1ZXN0IFVSSSAoYnV0IEkgZGlkIG5vdCBsb29rIHN1cGVyIGhhcmQpLiBJZiB0aGF0IGlzIG5v dCB0aGVyZSwgdGhlbiBJIHRoaW5rIHRoZSByZXF1ZXN0IFVSSSBNVVNUIGV4cGlyZSBpbiBhICJz aG9ydCIgcGVyaW9kIG9mIHRpbWUuDQoNCg0KDQrhkKcNCg0KT24gV2VkLCBBdWcgMjYsIDIwMjAg YXQgMTo0NSBQTSBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBk bWFyYy5pZXRmLm9yZzxtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPj4g d3JvdGU6DQpUaGFua3MgSnVzdGluLiBKdXN0IGEgY291cGxlIG1vcmUgcmVzcG9uc2VzIHRvIHJl c3BvbnNlcyBpbmxpbmUgYmVsb3cgKGJ1dCB3aXRoIGxvdHMgb2YgY29udGVudCB0aGF0IG5lZWRz IG5vIGZ1cnRoZXIgZGlzY3Vzc2lvbiByZW1vdmVkKS4NCg0KQSBUTDtEUiBmb3IgdGhlIFdHIGlz IHRoYXQgSSdkIGxpa2UgdG8gZ2V0IHNvbWUgd2lkZXIgZmVlZGJhY2sgb24gdGhlIHF1ZXN0aW9u IG9mIGNoYW5naW5nIHRoZSBvbmUtdGltZS11c2UgY29uZGl0aW9uIG9uIHRoZSByZXF1ZXN0X3Vy aSBmcm9tIGEgU0hPVUxEIHRvIGEgTVVTVC4NCg0KT24gVHVlLCBBdWcgMjUsIDIwMjAgYXQgNDo1 NyBQTSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVk dT4+IHdyb3RlOg0KSGkgQnJpYW4sIGp1c3QgYSBjb3VwbGUgcmVzcG9uc2VzIGlubGluZSB3aGVy ZSBpdCBzZWVtZWQgZml0dGluZy4gVGhhbmtzIGZvciBnb2luZyB0aHJvdWdoIGV2ZXJ5dGhpbmch DQog4oCUIEp1c3Rpbg0KDQoNCk9uIEF1ZyAyNSwgMjAyMCwgYXQgNjowMSBQTSwgQnJpYW4gQ2Ft cGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lk ZW50aXR5LmNvbT4+IHdyb3RlOg0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcgYW5kIGNvbW1lbnRz IEp1c3Rpbi4gUmVwbGllcyAob3IgYXR0ZW1wdHMgdGhlcmVhdCkgYXJlIGlubGluZSBiZWxvdy4N Cg0KDQpPbiBXZWQsIEF1ZyAxOSwgMjAyMCBhdCAyOjA2IFBNIEp1c3RpbiBSaWNoZXIgPGpyaWNo ZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQpJ4oCZdmUgZG9uZSBh IGZ1bGwgcmVhZCB0aHJvdWdoIG9mIHRoZSBQQVIgc3BlY2lmaWNhdGlvbiwgYW5kIGhlcmUgYXJl IG15IG5vdGVzIG9uIGl0Lg0KDQoNCiAgICDCtjI6IE9mIG5lY2Vzc2l0eSwgdGhpcyBzcGVjIG1p eGVzIHBhcmFtZXRlcnMgaW4gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYW5kIHRva2VuIGVu ZHBvaW50IHJlZ2lzdHJpZXMgaW50byBhIHNpbmdsZSByZXF1ZXN0LiBJcyB0aGVyZSBhbnkgZGFu Z2VyIG9mIGNvbmZsaWN0IGJldHdlZW4gdGhlbT8gVGhlIHJlZ2lzdHJ5IGhvbGRzIHRoZW0gaW4g b25lIGxpc3QgYnV0IHRoZXkgY291bGQgcG9zc2libHkgaGF2ZSBkaWZmZXJlbnQgc2VtYW50aWNz IGluIGJvdGggcGxhY2VzLi4NCg0KSSB0aGluayB0aGF0IHRlY2huaWNhbGx5IHN1Y2ggZGFuZ2Vy IGRvZXMgZXhpc3QgYnV0IHRoYXQgaXQncyBoaWdobHkgdW5saWtlbHkgaW4gcHJhY3RpY2UuIEVz cGVjaWFsbHkgYmVjYXVzZSB0aGUgb25seSB0b2tlbiBlbmRwb2ludCBwYXJhbWV0ZXJzIHRoYXQg YXJlIHJlbGV2YW50IHRvIFBBUiBhcmUgdGhvc2UgdGhhdCBkZWFsIHdpdGggY2xpZW50IGF1dGhl bnRpY2F0aW9uIChjdXJyZW50bHkgY2xpZW50X3NlY3JldCwgY2xpZW50X2Fzc2VydGlvbiwgYW5k IGNsaWVudF9hc3NlcnRpb25fdHlwZSkuIEknbSBhbHNvIG5vdCBzdXJlIHdoYXQgY2FuIHJlYXNv bmFibHkgYmUgZG9uZSBhYm91dCBpdCBnaXZlbiB0aGUgd2F5IHRoZSByZWdpc3RyaWVzIGFyZS4g SSBndWVzcyBQQVIgY291bGQgdXBkYXRlIHRoZSByZWdpc3RyYXRpb24gZm9yIHRob3NlIHRocmVl IChjbGllbnRfc2VjcmV0LCBjbGllbnRfYXNzZXJ0aW9uLCBhbmQgY2xpZW50X2Fzc2VydGlvbl90 eXBlKSB0byBhbHNvIGluZGljYXRlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBhcyBhIHVzYWdlIGxv Y2F0aW9uIHdpdGggc29tZSBjb21tZW50YXJ5IHRoYXQgaXQncyBvbmx5IGZvciBhdm9pZGluZyBu YW1lIGNvbGxpc2lvbnMuIEFuZCBvZmZlciBzb21lIGd1aWRhbmNlIGFib3V0IGRvaW5nIHRoZSBz YW1lIGZvciBhbnkgZnV0dXJlIGNsaWVudCBhdXRoIG1ldGhvZHMgYmVpbmcgZGVmaW5lZC4gQnV0 IGhvbmVzdGx5IEknbSBub3Qgc3VyZSB3aGF0LCBpZiBhbnl0aGluZywgdG8gZG8gaGVyZT8NCg0K QW5kIHllcyBpdCBpcyBzdXBlciB1bmZvcnR1bmF0ZSB0aGF0IGNsaWVudCBhdXRoIGFuZCBwcm90 b2NvbCBwYXJhbWV0ZXJzIGdvdCBtaXhlZCB0b2dldGhlciBpbiB0aGUgSFRUUCBib2R5LiBJIGRp ZG4ndCBjYXVzZSB0aGF0IHNpdHVhdGlvbiBidXQgSSd2ZSBjZXJ0YWlubHkgY29udHJpYnV0ZWQg dG8gaXQgYW5kIGZvciB0aGF0IEkgYXBvbG9naXplLg0KDQpJIHRoaW5rIHRoZSBvbmx5IHBlcmZl Y3Qgc29sdXRpb24gaXMgdG8gZ28gYmFjayBpbiB0aW1lIGFuZCBmaXggdGhlIHJlZ2lzdHJpZXMg d2l0aCBiYXNlZCBvbiB0aGUgbGFzdCBkZWNhZGUgb2Yga25vd2xlZGdlIGluIHVzaW5nIHRoZW0u IDpQDQoNCkZvciB0aGlzLCBJIHRoaW5rIG1heWJlIGJlaW5nIHZlcnkgcHJlc2NyaXB0aXZlIGFi b3V0IHRoZSBmYWN0IHRoYXQgdGhlIG9ubHkgcGFyYW1ldGVycyBmcm9tIHRoZSB0b2tlbiBlbmRw b2ludCB0aGF0IGFyZSBhbGxvd2VkIGhlcmUgYXJlIHRob3NlIHVzZWQgZm9yIGNsaWVudCBhdXRo ZW50aWNhdGlvbiBhbmQgdGhhdCB3aGVuIHRoZXkgc2hvdyB1cCwgdGhleeKAmXJlIGludGVycHJl dGVkIGFzIGluIHRoZSB0b2tlbiBlbmRwb2ludCByZXF1ZXN0IG5vdCB0aGUgYXV0aG9yaXphdGlv biBlbmRwb2ludCByZXF1ZXN0LiBEb2VzIHRoYXQgd29yaz8NCg0KSSB0aGluayBzbywgeWVzLi4g QW5kIHdpbGwgd29yayBvbiBpbmNvcnBvcmF0aW5nIHNvbWUgdGV4dCB0b3dhcmRzIHRoYXQgZW5k Lg0KDQoNCg0KICAgIEkgZG9u4oCZdCBzZWUgd2h5IGEgcmVxdWVzdCBVUkkgd2l0aCB1bmd1ZXNz YWJsZSB2YWx1ZXMgaXNu4oCZdCBhIE1VU1QgZm9yIG9uZS10aW1lLXVzZSwgaXMgdGhlcmUgYSBy ZWFzb24/DQoNClRoZSByZWFzb24gQUZBSUsgd2FzIHRvIG5vdCBiZSBvdmVybHkgcHJlc2NyaXB0 aXZlIGFuZCBhbGxvdyBmb3IgZXZlbnR1YWxseSBjb25zaXN0ZW50IG9yIG5vdCBhdG9taWMgc3Rv cmFnZSBvZiB0aGUgZGF0YSBieSBub3Qgc3RyaWN0bHkgcmVxdWlyaW5nIHRoZSBBUyB0byBlbmZv cmNlIG9uZS10aW1lLXVzZS4gRG8geW91IHRoaW5rIHRoYXQncyB0b28gbG9vc2Ugb3IgY291bGQg YmUgd29yZGVkL2V4cGxhaW5lZCBkaWZmZXJlbnRseSBvciBiZXR0ZXI/DQoNCkkgZG8gdGhpbmsg aXTigJlzIHRvbyBsb29zZSBhbmQgaXQgc2hvdWxkIGJlIGEgTVVTVCwgYW5kIHRoZSBtZXRob2Rz IGZvciBlbmZvcmNpbmcgdGhhdCDigJxNVVNU4oCdIGFyZSBnb2luZyB0byB2YXJ5IGJhc2VkIG9u IHRoZSBkZXBsb3ltZW50cyBhbmQgaW1wbGVtZW50YXRpb25zIG91dCB0aGVyZS4NCg0KDQpJJ2Qg YmUgb2theSB3aXRoIG1ha2luZyBpdCBhIE1VU1QgYnV0IHRoaW5rIG1heWJlIGl0J2QgYmUgZ29v ZCB0byBoZWFyIGZyb20gYSBmZXcgbW9yZSBwZW9wbGUgaW4gdGhlIFdHIGJlZm9yZSBjb21taXR0 aW5nIHRvIHRoYXQgY2hhbmdlLg0KDQpDYW4gSSBhc2sgc29tZSBmb2xrcyB0byB3ZWlnaCBpbiBv biB0aGlzIG9uZT8gSSdtIGxlYW5pbmcgdG93YXJkcyBtYWtpbmcgdGhlIGNoYW5nZSBiYXJyaW5n IG9iamVjdGlvbnMuDQoNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xl IHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3Ry aWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4u ICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUg bWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFu ayB5b3UuX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_DM6PR00MB0684BEBE5FAB3E2C483298B4F5531DM6PR00MB0684namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJ IjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkdhZHVnaTsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSBhZ3JlZSB3 aXRoIERpY2sgdGhhdCBpdCB3b3VsZCBiZSBhIG1pc3Rha2UgdG8gbWFrZSB0aGUgVVJMIG9uZS10 aW1lIHVzZS4mbmJzcDsgSXTigJlzIHVuZW5mb3JjZWFibGUgYW5kIHVubmVjZXNzYXJpbHkgZ2V0 cyBpbiB0aGUgd2F5IG9mIHZhbHVhYmxlIGRlcGxveW1lbnQgcGF0dGVybnMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBPQXV0aCAmbHQ7b2F1dGgtYm91 bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkRpY2sgSGFyZHQ8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAyNywgMjAyMCA5OjEyIEFNPGJyPg0KPGI+VG86 PC9iPiBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5p ZXRmLm9yZyZndDs7IG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtPQVVUSC1XR10gV0dMQyBSZXZpZXcgb2YgUEFSPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgaXMgbm90IGNvcnJlY3QuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYXV0aG9yaXphdGlvbiZuYnNwO2Nv ZGUgb25lLXRpbWUtdXNlIGlzIGRpcmVjdGx5IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIEFT LiBUaGUgY2xpZW50IGhhcyBhIG51bWJlciBvZiBtZWNoYW5pc21zIHRvIGVuc3VyZSBpdCBvbmx5 IHByZXNlbnRzIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgdG8gdGhlIEFTIG9uY2UsJm5ic3A7c3Vj aCBhcyBhIHNlc3Npb24gdGhhdCB3YXMgc2V0IHdoZW4gdGhlIHVzZXIgc3RhcnRlZA0KIGF0IHRo ZSBjbGllbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkluIGNvbnRyYXN0LCBpbiBhIHJlZGlyZWN0IGZyb20gdGhlIGNsaWVudCB0byB0aGUg QVMsIHRoZSBjbGllbnQgbG9zZXMgY29udHJvbCBvbiBob3cgbWFueSB0aW1lcyB0aGUgdXNlci1h Z2VudCBsb2FkcyB0aGUgVVJMIGF0IHRoZSBBUy4gQWRkaXRpb25hbGx5LCB0aGVyZSBpcyB1bmxp a2VseSZuYnNwO3RvIGJlIGFuIGFjdGl2ZSBicm93c2VyIHNlc3Npb24gYXQgdGhlIEFTLCBzbyB0 aGUgQVMgY2FuIG5vdCBlYXNpbHkNCiBkaWZmZXJlbnRpYXRlIGJldHdlZW4gYSBVUkwgbG9hZCBm cm9tIHRoZSBzYW1lIHVzZXIsIG9yIGRpZmZlcmVudCB1c2Vycy4gSWYgb25lLXRpbWUtdXNlLCBv bmUgb2YgdGhlbSBNVVNUIGZhaWwuIElmIHRoZSB0d28gcmVxdWVzdHMgaGFwcGVuIHRvIGJlIGZy b20gdGhlIHNhbWUgdXNlciAoYmVjYXVzZSBvZiBhIHJlbG9hZCwgd2hpY2ggdGhlIHVzZXIgZGlk IGJlY2F1c2UgdGhlIEFTIHdhcyBzbG93IHRvIHJlc3BvbmQpLCB0aGVyZSBpcyBubyB3YXkNCiBm b3IgdGhlIEFTIHRvIGtub3cgd2hpY2ggb2YgdGhlIHJlcXVlc3RzIGlzIHRoZSBvbmUgdGhhdCBp cyBjdXJyZW50IGluIGZyb250IG9mIHRoZSB1c2VyLiBXaGlsZSB0aGUgQVMgY2FuIGludGVybmFs bHkgZW5zdXJlIHByb2Nlc3Npbmcgb2YgdGhlIHJlcXVlc3Qgb25jZSwgb25lLXRpbWUtdXNlIHdv dWxkIGRpY3RhdGUgdGhhdCBpdCBwcm92aWRlcyBhIGZhaWx1cmUgbWVzc2FnZSB0byBvbmUgb2Yg dGhlIHJlcXVlc3RzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4vRGljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGltZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiBzdHlsZT0i d2lkdGg6LjAxMDRpbjtoZWlnaHQ6LjAxMDRpbiIgaWQ9Il94MDAwMF9pMTAyNiIgc3JjPSJodHRw czovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0Zw YkM1amIyMCUzRCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD05N2I5YzU1NC05NTliLTQ5 NjYtOGViZC01NjFlZWRjNTk0N2YiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwg QXVnIDI3LCAyMDIwIGF0IDc6MTcgQU0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmpyaWNoZXJAbWl0LmVkdSI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2UgYWxyZWFkeSBoYXZlIHRoaXMgc2FtZSBwcm9wZXJ0eSB3aXRoIGF1dGhvcml6YXRpb24gY29k ZXMsIGFuZCBpdOKAmXMgbWFuYWdlZCB0b2RheSByZWFzb25hYmx5IHdlbGwgKGluIG15IG9waW5p b24pLiBJZiB5b3Ugc3VibWl0IHRoZSBzYW1lIHJlcXVlc3QgVVJJIHR3aWNlIGluIHRoZSBzYW1l IGJyb3dzZXIgKHRoZSByZWZyZXNoIHlvdeKAmXJlIHRhbGtpbmcgYWJvdXQpLCBpdCBzaG91bGRu 4oCZdCBzdGFydCB0d28NCiBzZXBhcmF0ZSBhdXRob3JpemF0aW9uIHJlcXVlc3RzLCBidXQgaXQg d291bGQgYmUgcmVhc29uYWJsZSB0byBkZXRlY3QgdGhhdCB0aGUgc2FtZSBzZXNzaW9uIGF0dGFj aGVkIHRvIHRoZSBzYW1lIHJlcXVlc3QgVVJJIHZhbHVlIHNob3dlZCB1cCB0d2ljZSBhbmQgY29u dGludWUgdGhlIHNlc3Npb24gYXMgYXBwcm9wcmlhdGUuJm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob25lIG9mIHRoaXMgaXMgaW4gY29uZmxpY3Qg d2l0aCDigJxvbmUgdGltZSB1c2XigJ0sIGluIG15IHZpZXcsIHNpbmNlIHlvdeKAmXJlIGFjdGl2 ZWx5IGRldGVjdGluZyB0aGUgc2Vzc2lvbiBhbmQgc291cmNlIG9mIHRoZSB2YWx1ZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCU IEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g QXVnIDI2LCAyMDIwLCBhdCA2OjE2IFBNLCBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86 ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSB0aGluayBvbmUtdGltZSB1c2UgbWF5IGJlIG92ZXJseSByZXN0cmljdGl2ZSwgYW5k IEkgZG9uJ3QgdGhpbmsgaXQgaXMgdGhlIHByb3BlcnR5IHRoYXQgd2UgYWN0dWFsbHkgd2FudC48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdpdmUgdGhlIHJl cXVlc3QgVVJJIGlzIGluIGEgcmVkaXJlY3QgZnJvbSB0aGUgYnJvd3NlciwgdGhlcmUgaXMgYSBn b29kIGNoYW5jZSBvZiBhIHJhY2UgY29uZGl0aW9uIHdoZXJlIHRoZSBzYW1lIGJyb3dzZXIgcmVx dWVzdCBpcyBtYWRlIG1vcmUgdGhhbiBvbmNlLCBmb3IgZXhhbXBsZSwgd2hpbGUgdGhlIGJyb3dz ZXIgaXMgbG9hZGluZyB0aGUgYXV0aG9yaXphdGlvbiBVUkwgYXQgdGhlIEFTLCB0aGUgdXNlcg0K IGNvdWxkIHJlZnJlc2ggdGhlIHBhZ2UgY2F1c2luZyB0aGUgYXV0aG9yaXphdGlvbiBVUkwgdG8g YmUgcmVsb2FkZWQuIFdvdWxkIHRoZSByZWxvYWQgY291bnQgYXMgYSBzZWNvbmQgdXNlPyBPbmUg Y291bGQgYXJndWUgaXQgZWl0aGVyJm5ic3A7d2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IEkgdGhpbmsgd2Ugd2FudCBmcm9tIHdo YXQgSSB1bmRlcnN0YW5kLCBpcyB0aGUgcmVxdWVzdCBVUkkgTVVTVCBiZSB1bmlxdWUgc28gdGhh dCB0aGVyZSBpcyBubyBjb25mdXNpb24gb24gd2hpY2ggcmVxdWVzdCBpcyBiZWluZyByZWZlcmVu Y2VkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGRpZCBub3Qgc2VlIGFueXRoaW5nIGFib3V0IHRoZSBleHBpcnkgdGltZSBvZiB0 aGUgcmVxdWVzdCBVUkkgKGJ1dCBJIGRpZCBub3QgbG9vayBzdXBlciBoYXJkKS4gSWYgdGhhdCBp cyBub3QgdGhlcmUsIHRoZW4gSSB0aGluayB0aGUgcmVxdWVzdCBVUkkgTVVTVCBleHBpcmUgaW4g YSAmcXVvdDtzaG9ydCZxdW90OyBwZXJpb2Qgb2YgdGltZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGltZyBib3JkZXI9 IjAiIHdpZHRoPSIxIiBoZWlnaHQ9IjEiIHN0eWxlPSJ3aWR0aDouMDEwNGluO2hlaWdodDouMDEw NGluIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNv bS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9j b250ZW50JmFtcDtndWlkPTk5NThmMmJmLWRmZDEtNDM1My1iNmM4LTQyMGQ2YmMzODA2MCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBdWcgMjYsIDIwMjAgYXQgMTo0NSBQTSBC cmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsPTxhIGhyZWY9Im1haWx0bzo0MHBpbmdpZGVudGl0 eS5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MHBpbmdpZGVudGl0eS5jb21A ZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzJm5ic3A7 SnVzdGluLiBKdXN0IGEgY291cGxlIG1vcmUgcmVzcG9uc2VzIHRvIHJlc3BvbnNlcyBpbmxpbmUg YmVsb3cgKGJ1dCB3aXRoIGxvdHMgb2YgY29udGVudCB0aGF0IG5lZWRzIG5vIGZ1cnRoZXIgZGlz Y3Vzc2lvbiByZW1vdmVkKS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BIFRMO0RSIGZvciB0aGUgV0cgaXMgdGhhdCBJJ2QgbGlrZSB0byBn ZXQgc29tZSB3aWRlciBmZWVkYmFjayBvbiB0aGUgcXVlc3Rpb24gb2YgY2hhbmdpbmcgdGhlIG9u ZS10aW1lLXVzZSBjb25kaXRpb24gb24gdGhlIHJlcXVlc3RfdXJpIGZyb20gYSBTSE9VTEQgdG8g YSBNVVNULg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBUdWUsIEF1ZyAyNSwgMjAyMCBhdCA0OjU3IFBNIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9 Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBCcmlhbiwganVzdCBhIGNvdXBsZSByZXNwb25zZXMg aW5saW5lIHdoZXJlIGl0IHNlZW1lZCBmaXR0aW5nLiBUaGFua3MgZm9yIGdvaW5nIHRocm91Z2gg ZXZlcnl0aGluZyE8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDvigJQgSnVzdGluPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBBdWcgMjUsIDIwMjAsIGF0IDY6MDEgUE0sIEJyaWFuIENhbXBiZWxsICZsdDs8YSBo cmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5i Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRo ZSByZXZpZXcgYW5kIGNvbW1lbnRzIEp1c3Rpbi4gUmVwbGllcyAob3IgYXR0ZW1wdHMgdGhlcmVh dCkgYXJlIGlubGluZSBiZWxvdy4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDE5LCAyMDIw IGF0IDI6MDYgUE0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0 LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPknigJl2ZSBkb25lIGEgZnVsbCByZWFkIHRocm91Z2ggb2YgdGhlIFBBUiBzcGVjaWZpY2F0 aW9uLCBhbmQgaGVyZSBhcmUgbXkgbm90ZXMgb24gaXQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyDCtjI6IE9mIG5lY2Vzc2l0eSwgdGhpcyBzcGVjIG1peGVzIHBhcmFtZXRlcnMgaW4gdGhlIGF1 dGhvcml6YXRpb24gZW5kcG9pbnQgYW5kIHRva2VuIGVuZHBvaW50IHJlZ2lzdHJpZXMgaW50byBh IHNpbmdsZSByZXF1ZXN0LiBJcyB0aGVyZSBhbnkgZGFuZ2VyIG9mIGNvbmZsaWN0IGJldHdlZW4g dGhlbT8gVGhlIHJlZ2lzdHJ5IGhvbGRzIHRoZW0gaW4gb25lIGxpc3QgYnV0IHRoZXkgY291bGQg cG9zc2libHkNCiBoYXZlIGRpZmZlcmVudCBzZW1hbnRpY3MgaW4gYm90aCBwbGFjZXMuLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhhdCB0ZWNobmljYWxseSBzdWNoIGRhbmdlciBkb2Vz IGV4aXN0IGJ1dCB0aGF0IGl0J3MgaGlnaGx5IHVubGlrZWx5IGluIHByYWN0aWNlLiBFc3BlY2lh bGx5IGJlY2F1c2UgdGhlIG9ubHkgdG9rZW4gZW5kcG9pbnQgcGFyYW1ldGVycyB0aGF0IGFyZSBy ZWxldmFudCB0byBQQVIgYXJlIHRob3NlIHRoYXQgZGVhbCB3aXRoIGNsaWVudCBhdXRoZW50aWNh dGlvbiAoY3VycmVudGx5IGNsaWVudF9zZWNyZXQsDQogY2xpZW50X2Fzc2VydGlvbiwgYW5kIGNs aWVudF9hc3NlcnRpb25fdHlwZSkuIEknbSBhbHNvIG5vdCBzdXJlIHdoYXQgY2FuIHJlYXNvbmFi bHkgYmUgZG9uZSBhYm91dCBpdCBnaXZlbiB0aGUgd2F5IHRoZSByZWdpc3RyaWVzIGFyZS4gSSBn dWVzcyBQQVIgY291bGQgdXBkYXRlIHRoZSByZWdpc3RyYXRpb24gZm9yIHRob3NlIHRocmVlIChj bGllbnRfc2VjcmV0LCBjbGllbnRfYXNzZXJ0aW9uLCBhbmQgY2xpZW50X2Fzc2VydGlvbl90eXBl KSB0bw0KIGFsc28gaW5kaWNhdGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGFzIGEgdXNhZ2UgbG9j YXRpb24gd2l0aCBzb21lIGNvbW1lbnRhcnkgdGhhdCBpdCdzIG9ubHkgZm9yIGF2b2lkaW5nIG5h bWUgY29sbGlzaW9ucy4gQW5kIG9mZmVyIHNvbWUgZ3VpZGFuY2UgYWJvdXQgZG9pbmcgdGhlIHNh bWUgZm9yIGFueSBmdXR1cmUgY2xpZW50IGF1dGggbWV0aG9kcyBiZWluZyBkZWZpbmVkLiBCdXQg aG9uZXN0bHkgSSdtIG5vdCBzdXJlIHdoYXQsIGlmIGFueXRoaW5nLA0KIHRvIGRvIGhlcmU/Jm5i c3A7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BbmQgeWVzIGl0IGlzIHN1cGVyIHVuZm9ydHVuYXRlIHRoYXQgY2xpZW50IGF1dGggYW5kIHBy b3RvY29sIHBhcmFtZXRlcnMgZ290IG1peGVkIHRvZ2V0aGVyIGluIHRoZSBIVFRQIGJvZHkuIEkg ZGlkbid0IGNhdXNlIHRoYXQgc2l0dWF0aW9uIGJ1dCBJJ3ZlIGNlcnRhaW5seSBjb250cmlidXRl ZCB0byBpdCBhbmQgZm9yIHRoYXQgSSBhcG9sb2dpemUuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoZSBvbmx5IHBl cmZlY3Qgc29sdXRpb24gaXMgdG8gZ28gYmFjayBpbiB0aW1lIGFuZCBmaXggdGhlIHJlZ2lzdHJp ZXMgd2l0aCBiYXNlZCBvbiB0aGUgbGFzdCBkZWNhZGUgb2Yga25vd2xlZGdlIGluIHVzaW5nIHRo ZW0uIDpQJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkZvciB0aGlzLCBJIHRoaW5rIG1heWJlIGJlaW5nIHZlcnkgcHJlc2NyaXB0aXZl IGFib3V0IHRoZSBmYWN0IHRoYXQgdGhlIG9ubHkgcGFyYW1ldGVycyBmcm9tIHRoZSB0b2tlbiBl bmRwb2ludCB0aGF0IGFyZSBhbGxvd2VkIGhlcmUgYXJlIHRob3NlIHVzZWQgZm9yIGNsaWVudCBh dXRoZW50aWNhdGlvbiBhbmQgdGhhdCB3aGVuIHRoZXkgc2hvdyB1cCwgdGhleeKAmXJlIGludGVy cHJldGVkIGFzIGluIHRoZSB0b2tlbg0KIGVuZHBvaW50IHJlcXVlc3Qgbm90IHRoZSBhdXRob3Jp emF0aW9uIGVuZHBvaW50IHJlcXVlc3QuIERvZXMgdGhhdCB3b3JrPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHNvLCB5ZXMuLiBBbmQgd2lsbCB3b3JrIG9uIGlu Y29ycG9yYXRpbmcgc29tZSB0ZXh0IHRvd2FyZHMgdGhhdCBlbmQuDQo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7ICZuYnNwOyBJIGRvbuKAmXQgc2VlIHdoeSBhIHJlcXVlc3QgVVJJIHdpdGgg dW5ndWVzc2FibGUgdmFsdWVzIGlzbuKAmXQgYSBNVVNUIGZvciBvbmUtdGltZS11c2UsIGlzIHRo ZXJlIGEgcmVhc29uPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSByZWFzb24gQUZBSUsgd2FzIHRv IG5vdCBiZSBvdmVybHkgcHJlc2NyaXB0aXZlIGFuZCBhbGxvdyBmb3IgZXZlbnR1YWxseSBjb25z aXN0ZW50IG9yIG5vdCBhdG9taWMgc3RvcmFnZSBvZiB0aGUgZGF0YSBieSBub3Qgc3RyaWN0bHkg cmVxdWlyaW5nIHRoZSBBUyB0byBlbmZvcmNlIG9uZS10aW1lLXVzZS4gRG8geW91IHRoaW5rIHRo YXQncyB0b28gbG9vc2Ugb3IgY291bGQgYmUgd29yZGVkL2V4cGxhaW5lZA0KIGRpZmZlcmVudGx5 IG9yIGJldHRlcj8mbmJzcDsgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg ZG8gdGhpbmsgaXTigJlzIHRvbyBsb29zZSBhbmQgaXQgc2hvdWxkIGJlIGEgTVVTVCwgYW5kIHRo ZSBtZXRob2RzIGZvciBlbmZvcmNpbmcgdGhhdCDigJxNVVNU4oCdIGFyZSBnb2luZyB0byB2YXJ5 IGJhc2VkIG9uIHRoZSBkZXBsb3ltZW50cyBhbmQgaW1wbGVtZW50YXRpb25zIG91dCB0aGVyZS4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ2QgYmUgb2theSB3aXRoIG1ha2luZyBpdCBh IE1VU1QgYnV0IHRoaW5rIG1heWJlIGl0J2QgYmUgZ29vZCB0byBoZWFyIGZyb20gYSBmZXcgbW9y ZSBwZW9wbGUgaW4gdGhlIFdHIGJlZm9yZSBjb21taXR0aW5nIHRvIHRoYXQgY2hhbmdlLg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiBJ IGFzayBzb21lIGZvbGtzIHRvIHdlaWdoIGluIG9uIHRoaXMgb25lPyBJJ20gbGVhbmluZyB0b3dh cmRzIG1ha2luZyB0aGUgY2hhbmdlIGJhcnJpbmcgb2JqZWN0aW9ucy4NCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdv ZSBVSSZxdW90OyxzZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4w cHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1 c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywNCiB1c2UsIGRpc3Ry aWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4u Jm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRl IHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIu IFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_DM6PR00MB0684BEBE5FAB3E2C483298B4F5531DM6PR00MB0684namp_-- From nobody Sat Aug 29 04:24:19 2020 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 E20ED3A1355 for ; Sat, 29 Aug 2020 04:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=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 o68otszCXOVI for ; Sat, 29 Aug 2020 04:24:15 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 283373A1353 for ; Sat, 29 Aug 2020 04:24:14 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id d26so2522225ejr.1 for ; Sat, 29 Aug 2020 04:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ACNSBk2v48neIMVReVVqnDTySrQd1NbvK+K4ywg3hh4=; b=M3k359PRoCkEhPqG+S8A+V43bTaOxUw4b5aJYNkuQTIidHy36x4UCpw14d5fjm8eM7 D8Ts0MG+U+wqaU6EIC+ELfdJzMyEdSWYD7ZLgguXbCE07tFVKvOrnnpN8SlTOZdcVYjd GCoPLcbETa+6DvrZlRGmb+/uNMopWT3yavZOfIHcaZmo8LQgyEqAumys47dnKvuGN48M cktIDOah0IF5yMKEW1tvqdgifn7r+7yrObcf+Qj69NCvWwTaTUcoAtSnZ2aZgsiU0UcT 97HwuHw2oMuRjbtSZk/9cNcZLiKSbPnOX3FstlWLX7tORiKe1DmJ4H5wBq9TNqLcjlAQ eHqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ACNSBk2v48neIMVReVVqnDTySrQd1NbvK+K4ywg3hh4=; b=JYY6JatTiy8wOx7CCxWZ/k0a/sB49sEHlU/VnSNpz+jasqfQuZrohm3E2YrWcpnXX+ +2H+vmb3jA0v1nnA0XROVp9AY/KkZxC8mLFOPiVvLBa6Q91iBO0rtGgzvFep3KjJHov1 Y8GfB77qGWDiJJBPff/h1bFYW9fKyQx5Bw0PRN9oI7yo0hDUs8zlDWeeLMLZ/s7idUqC 55BDghHM5GRnCy6rZdlqS+9h9SYBdAbGFmbvWewQHOT6IzstxF8gW7FcB20PLegxKLk2 JBkmukxfA4ItSS4aYjOA5O4IqVkqDwfjGtvAXiycAB0tRVRVM9++lgOtuSbt2p2QRfd+ TrUg== X-Gm-Message-State: AOAM530Jqw0Jd9EPqfVOKR3edjwwYUfVR0S6JaXRR7BmfnGAkQJjBWq7 3P+zYBDjBAEu5qzW5THQ9o0oiA== X-Google-Smtp-Source: ABdhPJxRxyA7+CkAoGNJkhE5NreHUrORL9um8SDocEpRMdoVrXKOG58/z+arlwLGH4IQ2mJCbcHxBA== X-Received: by 2002:a17:906:8289:: with SMTP id h9mr1463903ejx.45.1598700253350; Sat, 29 Aug 2020 04:24:13 -0700 (PDT) Received: from p200300eb8f1e2a0741fe1768a10f1ac2.dip0.t-ipconnect.de (p200300eb8f1e2a0741fe1768a10f1ac2.dip0.t-ipconnect.de. [2003:eb:8f1e:2a07:41fe:1768:a10f:1ac2]) by smtp.gmail.com with ESMTPSA id n14sm1855477edb.52.2020.08.29.04.24.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Aug 2020 04:24:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Torsten Lodderstedt In-Reply-To: Date: Sat, 29 Aug 2020 13:24:11 +0200 Cc: Justin Richer , Brian Campbell , oauth Content-Transfer-Encoding: quoted-printable Message-Id: <102C6B96-C1FA-4BC1-8932-C7F4F377CFFE@lodderstedt.net> References: <7C0FD285-F677-4501-B2FB-9431A59855F6@mit.edu> To: Dick Hardt X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] WGLC Review of PAR 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, 29 Aug 2020 11:24:18 -0000 You are making a good point here. The reason we added the one time use = constraint was the fact the client will include parameters supposed to = be used only once, e.g. the PKCE code_challenge. For a traditional = authorisation request, we would recommend the client to use a per = transaction (=3D=3D one time use) code_challenge, but PKCE does not = require the AS to enforce it. Mapping this to PAR means, we SHOULD = recommend the client to use the request_uri only once but not require = the AS to enforce it.=20 Would the following text work for you? Since parts of the request content, e.g. the "code_challenge" parameter value, is unique to a certain authorization request,=20 the client SHOULD use the "request_uri" only once. I also would move this text to section 4. > On 27. Aug 2020, at 18:11, Dick Hardt wrote: >=20 > That is not correct. >=20 > The authorization code one-time-use is directly between the client and = the AS. The client has a number of mechanisms to ensure it only presents = the authorization code to the AS once, such as a session that was set = when the user started at the client. >=20 > In contrast, in a redirect from the client to the AS, the client loses = control on how many times the user-agent loads the URL at the AS. = Additionally, there is unlikely to be an active browser session at the = AS, so the AS can not easily differentiate between a URL load from the = same user, or different users. If one-time-use, one of them MUST fail. = If the two requests happen to be from the same user (because of a = reload, which the user did because the AS was slow to respond), there is = no way for the AS to know which of the requests is the one that is = current in front of the user. While the AS can internally ensure = processing of the request once, one-time-use would dictate that it = provides a failure message to one of the requests. >=20 > /Dick >=20 >=20 > =E1=90=A7 >=20 > On Thu, Aug 27, 2020 at 7:17 AM Justin Richer wrote: > We already have this same property with authorization codes, and = it=E2=80=99s managed today reasonably well (in my opinion). If you = submit the same request URI twice in the same browser (the refresh = you=E2=80=99re talking about), it shouldn=E2=80=99t start two separate = authorization requests, but it would be reasonable to detect that the = same session attached to the same request URI value showed up twice and = continue the session as appropriate.=20 >=20 > None of this is in conflict with =E2=80=9Cone time use=E2=80=9D, in my = view, since you=E2=80=99re actively detecting the session and source of = the value. >=20 > =E2=80=94 Justin >=20 >> On Aug 26, 2020, at 6:16 PM, Dick Hardt wrote: >>=20 >> I think one-time use may be overly restrictive, and I don't think it = is the property that we actually want. >>=20 >> Give the request URI is in a redirect from the browser, there is a = good chance of a race condition where the same browser request is made = more than once, for example, while the browser is loading the = authorization URL at the AS, the user could refresh the page causing the = authorization URL to be reloaded. Would the reload count as a second = use? One could argue it either way. >>=20 >> What I think we want from what I understand, is the request URI MUST = be unique so that there is no confusion on which request is being = referenced.=20 >>=20 >> I did not see anything about the expiry time of the request URI (but = I did not look super hard). If that is not there, then I think the = request URI MUST expire in a "short" period of time. >>=20 >>=20 >>=20 >> =E1=90=A7 >>=20 >> On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell = wrote: >> Thanks Justin. Just a couple more responses to responses inline below = (but with lots of content that needs no further discussion removed).=20 >>=20 >> A TL;DR for the WG is that I'd like to get some wider feedback on the = question of changing the one-time-use condition on the request_uri from = a SHOULD to a MUST.=20 >>=20 >> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer = wrote: >> Hi Brian, just a couple responses inline where it seemed fitting. = Thanks for going through everything! >> =E2=80=94 Justin >>=20 >>> On Aug 25, 2020, at 6:01 PM, Brian Campbell = wrote: >>>=20 >>> Thanks for the review and comments Justin. Replies (or attempts = thereat) are inline below. >>>=20 >>>=20 >>> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer = wrote: >>> I=E2=80=99ve done a full read through of the PAR specification, and = here are my notes on it. >>>=20 >>>=20 >>> =C2=B62: Of necessity, this spec mixes parameters in the = authorization endpoint and token endpoint registries into a single = request. Is there any danger of conflict between them? The registry = holds them in one list but they could possibly have different semantics = in both places.. >>>=20 >>> I think that technically such danger does exist but that it's highly = unlikely in practice. Especially because the only token endpoint = parameters that are relevant to PAR are those that deal with client = authentication (currently client_secret, client_assertion, and = client_assertion_type). I'm also not sure what can reasonably be done = about it given the way the registries are. I guess PAR could update the = registration for those three (client_secret, client_assertion, and = client_assertion_type) to also indicate authorization request as a usage = location with some commentary that it's only for avoiding name = collisions. And offer some guidance about doing the same for any future = client auth methods being defined. But honestly I'm not sure what, if = anything, to do here? =20 >>>=20 >>> And yes it is super unfortunate that client auth and protocol = parameters got mixed together in the HTTP body. I didn't cause that = situation but I've certainly contributed to it and for that I apologize.=20= >>=20 >> I think the only perfect solution is to go back in time and fix the = registries with based on the last decade of knowledge in using them. :P=20= >>=20 >> For this, I think maybe being very prescriptive about the fact that = the only parameters from the token endpoint that are allowed here are = those used for client authentication and that when they show up, = they=E2=80=99re interpreted as in the token endpoint request not the = authorization endpoint request. Does that work? >>=20 >> I think so, yes.. And will work on incorporating some text towards = that end.=20 >>=20 >>=20 >> =20 >>> I don=E2=80=99t see why a request URI with unguessable values = isn=E2=80=99t a MUST for one-time-use, is there a reason? >>>=20 >>> The reason AFAIK was to not be overly prescriptive and allow for = eventually consistent or not atomic storage of the data by not strictly = requiring the AS to enforce one-time-use. Do you think that's too loose = or could be worded/explained differently or better?=20 >>=20 >> I do think it=E2=80=99s too loose and it should be a MUST, and the = methods for enforcing that =E2=80=9CMUST=E2=80=9D are going to vary = based on the deployments and implementations out there.=20 >>=20 >>=20 >> I'd be okay with making it a MUST but think maybe it'd be good to = hear from a few more people in the WG before committing to that change.=20= >>=20 >> Can I ask some folks to weigh in on this one? I'm leaning towards = making the change barring objections.=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.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Sat Aug 29 04:52:29 2020 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 1C2A73A1377 for ; Sat, 29 Aug 2020 04:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=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 t7V6riXWtBaH for ; Sat, 29 Aug 2020 04:52:25 -0700 (PDT) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 2D3EE3A1373 for ; Sat, 29 Aug 2020 04:52:25 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id o18so2531029eje.7 for ; Sat, 29 Aug 2020 04:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uC+MQ9n4rLuhSjuuGoG/J6Ul5iWExsVhuJJI2Z5qkOk=; b=HSVjs26TObO+ScEz05JUmvaGDZAUGhObsSW/ETiXyJUMJY4n/0mw3wYfgzxcS0/kR6 SUKAe7LI9femc1hI9qj/BUw+K/QoTyio8JUwFNbvq1QUW84wYzAYSkPIJz6Fh0wBnuFt ahzuzlcOLR1o2KNUgMGx+6KveLavvyTSVAQjU/zEz1k5CusJrEEwG4c0IdygHLigctRj FRil1hKwr9sL0cuT7ONBUJyodzQTgo4JqnL014TLZemjZgy98joPHoykNS+ZHwM8PZ9+ SJ6ceqG9GD4Pln6l6jixZAYSgReH24NvbPoHGVl+5N/8LOpDwqNPy6uxMMkrnhkjNVIe dScA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uC+MQ9n4rLuhSjuuGoG/J6Ul5iWExsVhuJJI2Z5qkOk=; b=cwOIBOYbQWaAkrNwRdT3zV/Eb4mcJXNEhDMse8GdRaP1iNbbdMIksCkiHyMiWSKv7n etIhrhwIXN/36tX0FT7jy18+T5AOJ5GprDPN+j7sI6bSGQnxV/O/mrG3K03vy01jF0nv 9XebZY1RvW0yXTmUaxwBBkshrSjJyIP1+2IFlmOoTThGnXPhWnM78VYHfYmkcfiA63+8 TMYKfr/ovUhu2x76QfvXIN1O/zrTQ4Gmk53QHZq90sOxqbxrGAgAXP2QOgG4KK9jhcsU sclzMAUo74uxT9Q1hNJeDiNoFioRvDVeHySmiOvDx+Tf9v8N0VLn+ZCaWCEQXYysuVMQ 9Qww== X-Gm-Message-State: AOAM531iZW7km3nfdG8/BOy3H8DXSQj05DB8+fRWBqbZOkACv3G60hhA hElLOUqajxCo06jV4TiqqYlvxA== X-Google-Smtp-Source: ABdhPJy06rhpnshmjygZUgocPlrL7n3ov9Bv4SPkLisd0ealMS4epuweytiAtFdWLC/GiUICmqS1mw== X-Received: by 2002:a17:906:8289:: with SMTP id h9mr1554617ejx.45.1598701943433; Sat, 29 Aug 2020 04:52:23 -0700 (PDT) Received: from p200300eb8f1e2a0741fe1768a10f1ac2.dip0.t-ipconnect.de (p200300eb8f1e2a0741fe1768a10f1ac2.dip0.t-ipconnect.de. [2003:eb:8f1e:2a07:41fe:1768:a10f:1ac2]) by smtp.gmail.com with ESMTPSA id t22sm2045078ejf.24.2020.08.29.04.52.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Aug 2020 04:52:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Torsten Lodderstedt In-Reply-To: Date: Sat, 29 Aug 2020 13:52:21 +0200 Cc: oauth , Brian Campbell Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C0FD285-F677-4501-B2FB-9431A59855F6@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] WGLC Review of PAR 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, 29 Aug 2020 11:52:27 -0000 >=20 >=20 > =C2=B66: Does the AS really have "the ability to authenticate and = authorize clients=E2=80=9D? I think what we mean here is "the ability to = authenticate clients and validate client requests=E2=80=9D, but I=E2=80=99= m not positive of the intent.=20 >=20 > I think the intent is that the AS can check whether a client is = authorized to make a particular authorization request (specific scopes, = response type, etc.). But checking authorization to request = authorization is confusing wording. I think your working is less = confusing and still allows for the intent.=20 >=20 > I'll let Torsten interject if he feels differently as I think he = originally wrote the text in question.=20 that was the original intent. I think =E2=80=9Cvalidate" is fine.=20 >=20 > =20 >=20 > =C2=B67: I=E2=80=99m not sure I buy this example. Even if the = clientID is managed externally, the association with a set or pattern of = allowed redirect URIs is still important, and the AS will need to know = what that is. I think this example could lead an AS developer to = (erroneously and dangerously) conclude that they don=E2=80=99t have to = check any other values in a request, including scope and redirect URI. = It=E2=80=99s important that DynReg doesn=E2=80=99t alleviate that issue, = but removal of DynReg doesn=E2=80=99t really change things in that = regard. Suggest removing example or reworking paragraph. >=20 > I'm going to have to defer to Torsten on this because, to be honest, = I'm not too sure about it myself. I tend to lean towards thinking the = draft would be better off without it.=20 >=20 In the traditional authorization flow, the redirect_uri serves as way to = make sure the AS is really talking to the legit client and the allowed = redirect_uri values are determined by the legit client at registration = time (might be manually). With PAR, we have a much stronger means to ensure the AS is talking to = the legit client. That=E2=80=99s why I don=E2=80=99t see an issue with = letting the client set a per transaction redirect_uri. This will give = the client more flexibility (mint AS-specific redirect URIs on the fly) = and makes client management much easier since redirect URIs are the most = volatile part of a client policy.=20 It also makes use of OAuth much easier in deployments where client = identities are managed by external entities (even without any idea of = OAuth). A prominent example is open banking in the EU (aka PSD2). The = (technical) identity of any PSD2-licensed client is asserted by an eIDAS = compliant CA in a special X.509 certificate. Those certificates contain = the permissions (access to account information and/or payment initiation = allowed) and the identity (member state specific). But they don=E2=80=99t = contain OAuth policy values. Nevertheless, the regulation requires any = financial institution in the EU to at runtime, without any registration, = to accept and process calls from any licensed PSD2 clients. There are two ways to cope with it in OAuth context: a) use dynamic client registration with the X.509 cert as credential. = Unfortunately, RFC 7591 does not support other client authentication = means then an initial access token. Beside that, it would violate the = text of the regulation.=20 b) establish a redirect URL with every transaction. This is the = recommended approach in at least one of the PSD2 specs. PAR is a clean way to solve that problem.=20 I don=E2=80=99t want this text to cause confusing. On the other hand = this potential of PAR is way too important to not mention it at all. = What about moving it into a special section "redirect_uri management=E2=80= =9D? >=20 From nobody Sat Aug 29 05:26:26 2020 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 9C32D3A13BA for ; Sat, 29 Aug 2020 05:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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 VjqelEx1SQ5B for ; Sat, 29 Aug 2020 05:26:22 -0700 (PDT) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 9A37B3A0891 for ; Sat, 29 Aug 2020 05:26:21 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id s19so2602002eju.6 for ; Sat, 29 Aug 2020 05:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XaaEZiI9D+NjQX7WfRj5SVgH2/A2ooc0wUJZ/rF389g=; b=sUmmDC/qvlGiIlERrDoDLpvw//O8PTgvRovO0G4krb8AON6iIdGXjx93Nei2X6ZipN znMcGpoKOUvGxBtwSqMmQTx58PuawT7EYmbQLizia7j0mLWTe0rbygAh5gmIOqaft/wR s64QV+4H6fflHHCQjRnrhilmOZGQcJVFrqi5+cvuJFcumegTY38Om7etuP1d0PYg3+HA MZx5VsQ/kMOCxOkA1hmyj+j43gMJKGMAQL2qN+w7Vcfr/AAywOPRcTPN3MueGYVbHnCG jcj+MGqOm7QX1cOyoGW0oB6XIk583AIOAU2C2hfF22j9v6N3+0WfsC4p6/X6Mw6EgPRv ugpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XaaEZiI9D+NjQX7WfRj5SVgH2/A2ooc0wUJZ/rF389g=; b=cpl2vuvG7TAqAZkTFe+Ot2+eIi0Ab1sFLVfvyrfA55C/3X1jZoSeukk09wQLkLned4 EXD7esF/2NLsPtrBEFb4tRXDl37n1sYkrmbITkmsacR5Y7HK59ZND7p7vLjt0galDV1B MSDElOjq5UEERsgw/waGLpyFJjRf3Wb6DSnPMfoRL4TLWy04UK/TrtWb80vQ4Au+UxRz V/6tbNImUGA0ssnwL00uSNLTKg3TfzkBCDgFl+IoSIBy8wWTDf3CQwmQODnuXFEMb64m zjEdM5k4b0oXNhgmKr0muLx8QzwrR1Y6qyeiYSW4RLomvVveB1cJkT8M5G1/pJAT6oAl 1sIg== X-Gm-Message-State: AOAM533IHQLKZWEfSJg5SPOhHiSQx6rko32iKKKnaHrDmIYO7bhmARMU Gky+fojPiTgKbWXCxLKUqp36qtpDadFZax2w X-Google-Smtp-Source: ABdhPJykdPtf30EJEiDx2iQCgaETTVaAU04yOSkIa/lwvvQz6DVLQiT8yA123nGYUg+z/wOuT+GSuA== X-Received: by 2002:a17:906:656:: with SMTP id t22mr3216563ejb.392.1598703979879; Sat, 29 Aug 2020 05:26:19 -0700 (PDT) Received: from p200300eb8f1e2a0741fe1768a10f1ac2.dip0.t-ipconnect.de (p200300eb8f1e2a0741fe1768a10f1ac2.dip0.t-ipconnect.de. [2003:eb:8f1e:2a07:41fe:1768:a10f:1ac2]) by smtp.gmail.com with ESMTPSA id hk14sm2083324ejb.88.2020.08.29.05.26.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Aug 2020 05:26:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Torsten Lodderstedt In-Reply-To: Date: Sat, 29 Aug 2020 14:26:18 +0200 Cc: OAuth WG , Brian Campbell Content-Transfer-Encoding: quoted-printable Message-Id: <60E8987A-09FC-4D63-9FE1-CE800F319B54@lodderstedt.net> References: <159620115034.32558.6249632084531225541@ietfa.amsl.com> To: Francis Pouatcha X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-03.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: Sat, 29 Aug 2020 12:26:24 -0000 > On 11. Aug 2020, at 23:55, Brian Campbell = wrote: >=20 > Hi Francis,=20 >=20 > My apologies for the tardy response to this - I was away for some time = on holiday. But thank you for the review and feedback on the draft. I've = tried to respond inline below. >=20 >=20 > On Fri, Jul 31, 2020 at 5:01 PM Francis Pouatcha = wrote: > Bellow is the only remark I found from reviewing the draft draft: >=20 > 2.1. Request:=20 >=20 > requires the parameters "code_challenge" and "code_challenge_method" = but > = https://openid.net/specs/openid-financial-api-part-2-ID2.html#confidential= -client mentions that RFC7636 is not required for confidential clients. = I guess those two parameters have to be taken off the mandatory list and = pushed to the list below. >=20 > The list of parameters in Section 2.1 is qualified with a "basic = parameter set will typically include" and is definitely not intended to = convey a set of required parameters. It's just a list of parameters that = make up a hypothetical typical request. Perhaps some text in the = section or even the formatting needs to be adjusted so as to (hopefully) = avoid any confusion like this that the list somehow conveys normative = requirements? Just a note: according to = https://tools.ietf.org/html/draft-ietf-oauth-security-topics and = https://tools.ietf.org/html/draft-ietf-oauth-v2-1, code_challenge is a = mandatory parameter for any client. That=E2=80=99s why we included it in = this list.=20 The FAPI WG also considers to make PKCE mandatory in FAPI 1. FAPI 2 = requires it anyway.=20 >=20 > =20 > - Using jwsreq, non repudiation is provided as request is signed = (jws). This section also mentions that the request can be sent as form = url encoded (x-www-form-urlencoded). In this case, there is no way to = provide non repudiation unless we mention that request can be signed by = client using signature methods declared by the AS (AS metadata). >=20 > I am not aware of any signature methods or means of an AS declaring = support for a signature method in metadata that are sufficiently = standardized to be mentioned in the context of this draft. The "request" = parameter https://tools.ietf.org/html/draft-ietf-oauth-par-03#section-3 = can be sent to the PAR endpoint and should provide the same notation of = non-repudiation as does jwsreq. I think that's sufficient treatment of = non-repudiation for the PAR draft.=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.ietf.org/mailman/listinfo/oauth From nobody Sat Aug 29 05:34:32 2020 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 85A943A0770 for ; Sat, 29 Aug 2020 05:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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 BMDvT8Z8OFNx for ; Sat, 29 Aug 2020 05:34:21 -0700 (PDT) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 0FDEA3A0417 for ; Sat, 29 Aug 2020 05:34:20 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id a26so2653691ejc.2 for ; Sat, 29 Aug 2020 05:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=42cGxLJ+90pFZzgsfAb5qzNKjuPZNoyGE796OQZj0pE=; b=OK5defRl31rsfsB2YUqMHytbv/VpvnokWXxpg7awJEUY9nvsoOjs4tHL+kDPPkEhNg EFmQyL59XpcVI6PVmDrcN3Dw4TPRH/tj9txL5x+XRb4JSuo1PHYH2YUlukRsJn9kzJfE 61l0G1kxNmaTvJeLrzG0Dlq8hDQFTnSfyfyqdlwo0+IRNLnUyUwRR7Ct8pXpFSb6rDbk 9nuwuOhMvYvMbfQk976UuKrusZD0edTuULNqj1NNDgnKIwzQGUexFT9pRGdzLlXuQT5h M60qhNrYjg6e6XvJhQi1BAp1LsAdw1nZDe+yRVw8oEo1XxnuzW/SgyPCnBzarEV4akSI GA0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=42cGxLJ+90pFZzgsfAb5qzNKjuPZNoyGE796OQZj0pE=; b=h8CpWIkkKHGLsvLb5mGKGZPB8RRaHaziT06VukWGSFqMrlY+h4vOkq5guWQJH1mgup iAyyotF03Qf/AtnoXz1ovUXizF3xkCbIb57cq+wed00B4xArSk2NXCtkJbR0NM6kIZGC hutTuHVt+iI2bA0Qu0fttI8rNuWA97G/WeEFpVFCuI89aTBgcPliqd0RjGpu5Jt+iVyw Q9Y6bY5LRWaQzxWWRm42FceHKSW3Wh9uyJE5H0Dn8ouVtkVZ0w/VSRI8ITPkqRoZaANp Ig92H9Q+QGjA3t4775aeJJei8KqZHS1pjndQry6igvXxqviL75ED6M+l7/330DyQ1Twu HVNg== X-Gm-Message-State: AOAM531j4zMebDrPZH4LcM203aegbdX+P8cwAIwlCci/lL0aRqiQ0606 ga/7RYfQWJ5ODla8HpizK5Qnribb2B4rSx+5 X-Google-Smtp-Source: ABdhPJx/awSg13xQxDZNKFqELaz3WSAhvL6RSkfPd5EorSq7BTeUIGdLqWQreWGLhMzesmhf79VCsw== X-Received: by 2002:a17:906:34c7:: with SMTP id h7mr3506743ejb.50.1598704459259; Sat, 29 Aug 2020 05:34:19 -0700 (PDT) Received: from p200300eb8f1e2a0741fe1768a10f1ac2.dip0.t-ipconnect.de (p200300eb8f1e2a0741fe1768a10f1ac2.dip0.t-ipconnect.de. [2003:eb:8f1e:2a07:41fe:1768:a10f:1ac2]) by smtp.gmail.com with ESMTPSA id x24sm2051265edq.39.2020.08.29.05.34.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Aug 2020 05:34:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Torsten Lodderstedt In-Reply-To: Date: Sat, 29 Aug 2020 14:34:17 +0200 Cc: oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6E29CD61-6F80-4A8B-A6D9-6A616532FDB6@lodderstedt.net> References: <101390f1-0d6e-e5fe-861b-4d7e9b7816dd@danielfett.de> <7877fdc2-eeb0-18dd-5a89-ecb30800eacf@danielfett.de> To: Karsten Meyer zu Selhausen X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Mix-Up Revisited 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, 29 Aug 2020 12:34:31 -0000 > On 11. Aug 2020, at 08:20, Karsten Meyer zu Selhausen = wrote: >=20 > Hi all, >=20 > I think we all agree that proper countermeasures of mix-up attacks = should definitely be part of the BCP and 2.1 due to the severe impact = successful mix-up attacks have. > Theoretically speaking every client which supports multiple AS is = potentially vulnerable to mix-up attacks. While in practice it might = seem unlikely it is possible that one of the honest AS the client = supports gets compromised and can be utilized for a mix-up attack.=20 >=20 > In a previous thread of last November = (https://mailarchive.ietf.org/arch/msg/oauth/A7F5xSEa8DdfxHKWHW3Mqol_a4A/)= I discussed why =E2=80=9Cuse distinct redirect URIs for each AS=E2=80=9D = is not an effective countermeasure against mix-up attacks (if dynamic = client registration is used). I would argue that this is especially = important for mobile applications, SPAs, and other native applications = because it is very common for them to use dynamic client registration. = Many iOS applications now must support multiple AS since Apple forces = the support for =E2=80=9CSign in with Apple=E2=80=9D if any single = sign-on provider is supported. This policy makes mix-up attacks = applicable. >=20 > I fully agree with Daniel, Brian, and Mike that it is important to = define and register the =E2=80=9Ciss=E2=80=9D parameter properly to = ensure that both clients and AS understand and use it in the correct = way. I understand that OAuth 2.1 is not meant to introduce and define = new parameters but I strongly suggest that the =E2=80=9Ciss=E2=80=9D = parameter should be introduced and defined elsewhere so that it can be = natively included in 2.1. In other words the =E2=80=9Ciss=E2=80=9D = parameter should be integrated in 2.1 the same way PKCE is: the initial = definition of the parameter(s) is in another document (RFC 7636 in the = case of PKCE) and then included in 2.1. >=20 > What do you think would be the best place to define and register the = =E2=80=9Ciss=E2=80=9D parameter? Would it be worthwhile to reactivate = and update =E2=80=9Cdraft-ietf-oauth-mix-up-mitigation=E2=80=9D? That=E2=80=99s a decision of the authors. Alternatively, a new small = draft (referring to the BCP=E2=80=99s attack description) should do the = job as well. Mind to write an ID? :-) >=20 > Best regards, >=20 > Karsten >=20 >=20 >=20 > On 18.06.2020 22:49, Mike Jones wrote: >> I support documenting the use of the issuer to mitigate mix-up = attacks. Note that while issuer was first defined by OpenID Connect, it = became art of OAuth 2.0 in RFC 8414 - OAuth 2.0 Authorization Server = Metadata. >> =20 >> -- Mike >> =20 >> From: OAuth On Behalf Of Brian Campbell >> Sent: Thursday, June 18, 2020 1:32 PM >> To: Daniel Fett >> Cc: oauth >> Subject: [EXTERNAL] Re: [OAUTH-WG] Mix-Up Revisited >> =20 >> In my (probably simplistic) understanding of things, the root = underlying issue that allows for mix-up in its variations is the lack of = anything identifying the AS in the authorization response. Following = from that, introducing and using an `iss` authorization response = parameter has always seemed like the most straightforward approach for = mitigating the issue (which was part of the = draft-ietf-oauth-mix-up-mitigation but other parameters were also = included and, for reasons I'm not sure about, interest in that work = faded in favor of telling clients to use per AS redirect URIs) . Though = for the `iss` authorization response parameter to be effective, all = parties involved need to know about it and act on it. So I think it'd = need to be something more than a passing recommendation in the BCP. It = should be defined, registered, explained, etc.. Actually introducing a = new parameter is maybe going beyond the expected scope of the BCP (or = 2.1). But maybe that's ok, if we're at least more intentional about it.=20= >> =20 >> On Sun, Jun 7, 2020 at 7:53 AM Daniel Fett = wrote: >> Hi all, >> I was wondering if we should move towards introducing and (more = explicitly) recommending the iss parameter in the security BCP, for the = reasons laid out below and in the article (which is now = athttps://danielfett.de/2020/05/04/mix-up-revisited/). >> =20 >> Any thoughts on this? >> =20 >> -Daniel >> =20 >> Am 04.05.20 um 19:34 schrieb Daniel Fett: >> Hi all, >>=20 >> to make substantiated recommendations for FAPI 2.0, the security = considerations for PAR, and the security BCP, I did another analysis on = the threats that arise from mix-up attacks. I was interested in = particular in two questions: >>=20 >> =E2=80=A2 Does PAR help preventing mix-up attacks? >> =E2=80=A2 Do we need JARM to prevent mix-up attacks? >> I wrote down several attack variants and configurations in the = following document: = https://danielfett.github.io/notes/oauth/Mix-Up%20Revisited.html >>=20 >> The key takeaways are: >>=20 >> =E2=80=A2 The security BCP needs to make clear that per-AS = redirect URIs are only sufficient if OAuth Metadata is not used to = resolve multiple issuers. Otherwise, per-Issuer redirect URIs or the iss = parameter MUST be used. >> =E2=80=A2 PAR-enabled authorization servers can protect the = integrity better and protect against Mix-Up Attacks better if they ONLY = accept PAR requests. >> =E2=80=A2 We should emphasize the importance of the iss = parameter (or issuer) in the authorization response. Maybe introduce = this parameter in the security BCP or another document? >> =E2=80=A2 Sender-constrained access tokens help against mix-up = attacks when the access token is targeted. >> =E2=80=A2 Sender-constraining the authorization code (PAR + = PAR-DPoP?) might be worth looking into. >> I would like to hear your thoughts! >>=20 >> -Daniel >>=20 >> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=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. >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >>=20 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --=20 > Karsten Meyer zu Selhausen > IT Security Consultant > Phone: +49 (0)234 / 54456499 > Web:=09 > https://hackmanit.de > | IT Security Consulting, Penetration Testing, Security Training >=20 > Unsere n=C3=A4chste Live Online-Schulung zur Sicherheit von OAuth und = OpenID Connect am 24.09 + 25.09: >=20 > = https://hackmanit.de/de/schulungen/109-live-online-schulung-single-sign-on= -sicherheit-oauth-openid-connect-am-24-und-25-09-2020 >=20 >=20 > Hackmanit GmbH > Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus) > 44789 Bochum >=20 > Registergericht: Amtsgericht Bochum, HRB 14896 > Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. = Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Sat Aug 29 08:22:41 2020 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 37AB63A0C4D; Sat, 29 Aug 2020 08:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 WIBsVkIVWUQx; Sat, 29 Aug 2020 08:22:37 -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 4A9C13A0C31; Sat, 29 Aug 2020 08:22:37 -0700 (PDT) Received: from [172.16.101.121] (50-245-27-6-static.hfc.comcastbusiness.net [50.245.27.6]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07TFMXup011932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 29 Aug 2020 11:22:35 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Justin Richer In-Reply-To: Date: Sat, 29 Aug 2020 11:22:32 -0400 Cc: oauth , Brian Campbell Content-Transfer-Encoding: quoted-printable Message-Id: <03845E0A-3563-4FF5-A3F9-318A1C928B89@mit.edu> References: <7C0FD285-F677-4501-B2FB-9431A59855F6@mit.edu> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] WGLC Review of PAR 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, 29 Aug 2020 15:22:39 -0000 I completely agree with the utility of the function in question here and = it needs to be included. I=E2=80=99m in favor of creating a dedicated = section for redirect_uri management, so that we can explain exactly how = and why to relax the requirement from core OAuth. In addition, I think = we want to discuss that the AS might have its own restrictions on which = redirect URIs an authenticated client might be able to use. For example, = registering a client with a Redirect URI prefix, or allowing only a = query parameter to vary at runtime. All of these can be enforced in PAR = because the client is presenting its authentication, as you point out, = so the AS can determine which policies should apply. =E2=80=94 Justin > On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt = wrote: >=20 >=20 >>=20 >>=20 >> =C2=B66: Does the AS really have "the ability to authenticate and = authorize clients=E2=80=9D? I think what we mean here is "the ability to = authenticate clients and validate client requests=E2=80=9D, but I=E2=80=99= m not positive of the intent.=20 >>=20 >> I think the intent is that the AS can check whether a client is = authorized to make a particular authorization request (specific scopes, = response type, etc.). But checking authorization to request = authorization is confusing wording. I think your working is less = confusing and still allows for the intent.=20 >>=20 >> I'll let Torsten interject if he feels differently as I think he = originally wrote the text in question.=20 >=20 > that was the original intent. I think =E2=80=9Cvalidate" is fine.=20 >=20 >>=20 >>=20 >>=20 >> =C2=B67: I=E2=80=99m not sure I buy this example. Even if the = clientID is managed externally, the association with a set or pattern of = allowed redirect URIs is still important, and the AS will need to know = what that is. I think this example could lead an AS developer to = (erroneously and dangerously) conclude that they don=E2=80=99t have to = check any other values in a request, including scope and redirect URI. = It=E2=80=99s important that DynReg doesn=E2=80=99t alleviate that issue, = but removal of DynReg doesn=E2=80=99t really change things in that = regard. Suggest removing example or reworking paragraph. >>=20 >> I'm going to have to defer to Torsten on this because, to be honest, = I'm not too sure about it myself. I tend to lean towards thinking the = draft would be better off without it.=20 >>=20 >=20 > In the traditional authorization flow, the redirect_uri serves as way = to make sure the AS is really talking to the legit client and the = allowed redirect_uri values are determined by the legit client at = registration time (might be manually). >=20 > With PAR, we have a much stronger means to ensure the AS is talking to = the legit client. That=E2=80=99s why I don=E2=80=99t see an issue with = letting the client set a per transaction redirect_uri. This will give = the client more flexibility (mint AS-specific redirect URIs on the fly) = and makes client management much easier since redirect URIs are the most = volatile part of a client policy.=20 >=20 > It also makes use of OAuth much easier in deployments where client = identities are managed by external entities (even without any idea of = OAuth). A prominent example is open banking in the EU (aka PSD2). The = (technical) identity of any PSD2-licensed client is asserted by an eIDAS = compliant CA in a special X.509 certificate. Those certificates contain = the permissions (access to account information and/or payment initiation = allowed) and the identity (member state specific). But they don=E2=80=99t = contain OAuth policy values. Nevertheless, the regulation requires any = financial institution in the EU to at runtime, without any registration, = to accept and process calls from any licensed PSD2 clients. >=20 > There are two ways to cope with it in OAuth context: > a) use dynamic client registration with the X.509 cert as credential. = Unfortunately, RFC 7591 does not support other client authentication = means then an initial access token. Beside that, it would violate the = text of the regulation.=20 > b) establish a redirect URL with every transaction. This is the = recommended approach in at least one of the PSD2 specs. >=20 > PAR is a clean way to solve that problem.=20 >=20 > I don=E2=80=99t want this text to cause confusing. On the other hand = this potential of PAR is way too important to not mention it at all. = What about moving it into a special section "redirect_uri management=E2=80= =9D? >=20 >>=20 >=20 From nobody Sat Aug 29 08:25:35 2020 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 E6FB13A0C67; Sat, 29 Aug 2020 08:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 PylE4rlmuzm6; Sat, 29 Aug 2020 08:25:32 -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 356AE3A0C68; Sat, 29 Aug 2020 08:25:31 -0700 (PDT) Received: from [172.16.101.121] (50-245-27-6-static.hfc.comcastbusiness.net [50.245.27.6]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07TFPS3p012864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 29 Aug 2020 11:25:28 -0400 From: Justin Richer Message-Id: <08D01F36-367B-4F23-9602-9C2A2AE49DA3@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_46FEE9FA-AFDF-4BE5-8C7B-E47CC6C1A598" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Sat, 29 Aug 2020 11:25:27 -0400 In-Reply-To: Cc: Torsten Lodderstedt , Mike Jones , "last-call@ietf.org" , oauth To: Dick Hardt References: <412A63AD-DDE1-4BFE-8234-5A721A0ED88D@lodderstedt.net> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 29 Aug 2020 15:25:34 -0000 --Apple-Mail=_46FEE9FA-AFDF-4BE5-8C7B-E47CC6C1A598 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Dick. I agree with removing the excess parenthetical, but I = intentionally avoided using a lowercase =E2=80=9Cmay=E2=80=9D in the = middle of the text (in favor of =E2=80=9Ccan=E2=80=9D) to avoid = normative-sounding non-normative language, so I=E2=80=99d recommend that = change be kept: Implementers should be aware that a token introspection request lets the = AS know when the client=20 is accessing the RS, which can also indicate when the user is using=20= the client. If this implication is not acceptable, implementers can = use other means to carry=20 access token data, e.g. directly transferring the data needed by the = RS within the access token. > On Aug 27, 2020, at 12:15 PM, Dick Hardt wrote: >=20 > Here is a crisper revision. >=20 > Implementers should be aware that a token introspection request lets = the AS know when the client=20 > is accessing the RS, which may indicate when the user is using=20 > the client. If this implication is not acceptable, implementers = can use other means to carry=20 > access token data, e.g. directly transferring the data needed by = the RS within the access token. > =E1=90=A7 >=20 > On Thu, Aug 27, 2020 at 7:19 AM Justin Richer > wrote: > I would clarify that this doesn=E2=80=99t necessarily say that the = user=E2=80=99s there, and remove the normative requirement (which = doesn=E2=80=99t have enforceable teeth in this context): >=20 > Implementers should be aware that a token introspection request lets = the AS know when the client=20 > (and potentially the user) is accessing the RS, which can also = indicate when the user is using=20 > the client. If this implication is not acceptable, implementers = can use other means to carry=20 > access token data, e.g. directly transferring the data needed by = the RS within the access token. >=20 >=20 > =E2=80=94 Justin >=20 >> On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt = > wrote: >>=20 >> Will the following text work for you? >>=20 >> Implementers should be aware that a token introspection request lets = the AS know when the client=20 >> (and potentially the user) is accessing the RS, which is also an = indication of when the user is using=20 >> the client. If this impliction is not accepatable, implementars = MUST use other means to carry=20 >> access token data, e.g. directly transferring the data needed by = the RS within the access token. >>=20 >>=20 >>> On 26. Aug 2020, at 23:12, Mike Jones = > wrote: >>>=20 >>> I agree with Dick=E2=80=99s observation about the privacy = implications of using an Introspection Endpoint. That=E2=80=99s why = it=E2=80=99s preferable to not use one at all and instead directly have = the Resource understand the Access Token. One way of doing this is the = JWT Access Token spec. There are plenty of others. >>>=20 >>> The downsides of using an Introspection Endpoint should be described = in the Privacy Considerations section. >>>=20 >>> -- Mike >>>=20 >>> From: OAuth > = On Behalf Of Dick Hardt >>> Sent: Wednesday, August 26, 2020 9:52 AM >>> To: Torsten Lodderstedt > >>> Cc: last-call@ietf.org ; oauth = > >>> Subject: Re: [OAUTH-WG] Last Call: = (JWT Response for = OAuth Token Introspection) to Proposed Standard >>>=20 >>>=20 >>>=20 >>> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt = > wrote: >>> Hi Denis, >>>=20 >>>> On 25. Aug 2020, at 16:55, Denis > wrote: >>>=20 >>>> The fact that the AS will know exactly when the introspection call = has been made and thus be able to make sure which client=20 >>>> has attempted perform an access to that RS and at which instant of = time. The use of this call allows an AS to track where and when=20 >>>> its clients have indeed presented an issued access token. >>>=20 >>> That is a fact. I don=E2=80=99t think it is an issue per se. Please = explain the privacy implications. >>>=20 >>> As I see it, the privacy implication is that the AS knows when the = client (and potentially the user) is accessing the RS, which is also an = indication of when the user is using the client. >>>=20 >>> I think including this implication would be important to have in a = Privacy Considerations section. >>>=20 >>> /Dick >>> =E1=90=A7 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 --Apple-Mail=_46FEE9FA-AFDF-4BE5-8C7B-E47CC6C1A598 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, Dick. I agree with removing the excess parenthetical, = but I intentionally avoided using a lowercase =E2=80=9Cmay=E2=80=9D in = the middle of the text  (in favor of =E2=80=9Ccan=E2=80=9D) = ;to avoid normative-sounding non-normative language, so I=E2=80=99d = recommend that change be kept:

Implementers should be aware that a token introspection = request lets the AS know when the client 
  =   is accessing the RS, which can also indicate when the user is = using 
    the client. If this implication = is not acceptable, implementers can use other means to carry 
    access token data, e.g. directly transferring = the data needed by the RS within the access token.

On Aug 27, 2020, at 12:15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Here is a crisper = revision.

Implementers should = be aware that a token introspection request lets the AS know when the = client
    is accessing the RS, which = may indicate when the user is using
    = the client. If this implication is not acceptable, implementers can use = other means to carry
    access token data, = e.g. directly transferring the data needed by the RS within the access = token.
3D""=E1=90=A7

On Thu, Aug = 27, 2020 at 7:19 AM Justin Richer <jricher@mit.edu> wrote:
I would clarify that this doesn=E2=80=99t = necessarily say that the user=E2=80=99s there, and remove the normative = requirement (which doesn=E2=80=99t have enforceable teeth in this = context):

Implementers= should be aware that a token introspection request lets the AS know = when the client 
    (and potentially = the user) is accessing the RS, which can also indicate = when the user is using 
    the = client. If this implication is not acceptable, implementers = can use other means to carry 
    = access token data, e.g. directly transferring the data needed by the RS = within the access token.


 =E2=80=94 Justin

On Aug = 27, 2020, at 9:48 AM, Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> = wrote:

Will the = following text work for you?

Implementers = should be aware that a token introspection request lets the AS know when = the client
    (and potentially the = user) is accessing the RS, which is also an indication of when the user = is using
    the client. If this = impliction is not accepatable, implementars MUST use other means to = carry
    access token data, e.g. = directly transferring the data needed by the RS within the access = token.


On 26. Aug 2020, at 23:12, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:

I agree with Dick=E2=80=99s = observation about the privacy implications of using an Introspection = Endpoint.  That=E2=80=99s why it=E2=80=99s preferable to not use = one at all and instead directly have the Resource understand the Access = Token.  One way of doing this is the JWT Access Token spec.  = There are plenty of others.

The downsides = of using an Introspection Endpoint should be described in the Privacy = Considerations section.

=             &n= bsp;           &nbs= p;            =             &n= bsp;    -- Mike

From: = OAuth <oauth-bounces@ietf.org> On Behalf Of Dick Hardt
Sent: Wednesday, August 26, 2020 9:52 AM
To: = Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>
Cc: last-call@ietf.org; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] = Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> = (JWT Response for OAuth Token Introspection) to Proposed Standard



On Wed, Aug 26, = 2020 at 4:37 AM Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
Hi Denis,

On 25. Aug 2020, at 16:55, Denis <denis.ietf@free.fr> wrote:

The fact that the AS will know exactly when the introspection = call has been made and thus be able to make sure which client
has attempted perform an access to that RS and at which = instant of time. The use of this call allows an AS to track where and = when
its clients have indeed presented an issued access = token.

That is a fact. I = don=E2=80=99t think it is an issue per se. Please explain the privacy = implications.

As I see it, the privacy = implication is that the AS knows when the client (and potentially the = user) is accessing the RS, which is also an indication of when the user = is using the client.

I think including this = implication would be important to have in a Privacy Considerations = section.

/Dick
=E1=90=A7

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


= --Apple-Mail=_46FEE9FA-AFDF-4BE5-8C7B-E47CC6C1A598-- From nobody Sat Aug 29 08:49:07 2020 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 7B8833A0CB8 for ; Sat, 29 Aug 2020 08:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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 MdG3TF8C6t-C for ; Sat, 29 Aug 2020 08:49:03 -0700 (PDT) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 487133A0CB4 for ; Sat, 29 Aug 2020 08:49:03 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id d26so3072980ejr.1 for ; Sat, 29 Aug 2020 08:49:03 -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=xTaUxCB9RrJ/RGMCv0pOyag4EwZzgctpndiRxsoUbRc=; b=ZaFJTrSKIk/u8BPrMd4NT1lCSx8sk7pMlnbzWaYh2y7gQZu88TAcOc2PhATE/wERwy hA1B07jQvbPLhO7uMvpJgGqGHsNqYaJ51oEUKsCplgGvuk6Jtr/iTnRwDLzAIqM1s448 +SHa7640qxrW3W5ZdieVCrZglcqcxRdjzG2juDQEmhLfP0urRjMItqw3B6vP4hOxMQIc NOtRrnYMnGM1Knxm2zCriMalFgNRZIg7nE8zBilbZBHBjfs86S0ESLJadpIoaj+fkGPN g6h8lH+3d0mLgGsmFt5+KicIbx0LU3PmPY5jBjsU3MD+3bvKXPTl2az3cHdGTbScCWlC chDg== 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=xTaUxCB9RrJ/RGMCv0pOyag4EwZzgctpndiRxsoUbRc=; b=cFgoA1DfOMCtnMfIUCGIMljqtbRBC/kajFRaZ3M6hEuYnQK9q9ZnNaBBjSP5piPKsC KTnY2W/1Sr1MvGOJ+pe3+w2p+2Fvc/X7ERRiSl0/OjMt6uMuYABbbbl9L0NWebIlu3hJ aSysJgPLgcm6a5Dfc3MNvAhh57RVah326Yvldm4tvamEr0rmXoaU1wrHY7zjuV7GvLi0 /JEPP3BTS/g6jDJzua8izGuD8TVfUMU9co4dUNdlGu4wTXkUG8DMCFxrC6aKwpdk36sj gEUsGdxjYXBy86Cds0HOIEBSLGpSNT980TXeLLBrFanP5pzMJBIZW9fdlRsRNW80TACx wacA== X-Gm-Message-State: AOAM530wBRqVKoV8aqvzNzQenyPaqORH/lUnd9Q6siGOy87NY45Aef/I 1LczDdHDnK8Ih7Jl8w9g6zUVLnTWxvwgnZkO X-Google-Smtp-Source: ABdhPJx62+HYlqM7gfnTI5ChZr5YUoulRndCrltXpPbOAFzdPWWmlFHgKb7R/vNV+X8VtQyepZzfwQ== X-Received: by 2002:a17:906:bcd4:: with SMTP id lw20mr3827912ejb.499.1598716141572; Sat, 29 Aug 2020 08:49:01 -0700 (PDT) Received: from [192.168.71.120] (p5b0d9b55.dip0.t-ipconnect.de. [91.13.155.85]) by smtp.gmail.com with ESMTPSA id g19sm2423192ejj.124.2020.08.29.08.49.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Aug 2020 08:49:00 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-27C64ADB-C891-4B14-A36F-B4E5030D4D7B; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sat, 29 Aug 2020 17:48:59 +0200 Message-Id: <82AED181-D7AF-4ACF-B9E1-9F3A30082483@lodderstedt.net> References: <03845E0A-3563-4FF5-A3F9-318A1C928B89@mit.edu> Cc: oauth , Brian Campbell In-Reply-To: <03845E0A-3563-4FF5-A3F9-318A1C928B89@mit.edu> To: Justin Richer X-Mailer: iPad Mail (17G80) Archived-At: Subject: Re: [OAUTH-WG] WGLC Review of PAR 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, 29 Aug 2020 15:49:06 -0000 --Apple-Mail-27C64ADB-C891-4B14-A36F-B4E5030D4D7B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I gone draft this section. > Am 29.08.2020 um 17:22 schrieb Justin Richer : >=20 > =EF=BB=BFI completely agree with the utility of the function in question h= ere and it needs to be included. I=E2=80=99m in favor of creating a dedicate= d section for redirect_uri management, so that we can explain exactly how an= d why to relax the requirement from core OAuth. In addition, I think we want= to discuss that the AS might have its own restrictions on which redirect UR= Is an authenticated client might be able to use. For example, registering a c= lient with a Redirect URI prefix, or allowing only a query parameter to vary= at runtime. All of these can be enforced in PAR because the client is prese= nting its authentication, as you point out, so the AS can determine which po= licies should apply. >=20 > =E2=80=94 Justin >=20 >>> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt wrote: >>>=20 >>>=20 >>>=20 >>>=20 >>> =C2=B66: Does the AS really have "the ability to authenticate and auth= orize clients=E2=80=9D? I think what we mean here is "the ability to authent= icate clients and validate client requests=E2=80=9D, but I=E2=80=99m not pos= itive of the intent.=20 >>>=20 >>> I think the intent is that the AS can check whether a client is authoriz= ed to make a particular authorization request (specific scopes, response typ= e, etc.). But checking authorization to request authorization is confusing w= ording. I think your working is less confusing and still allows for the inte= nt.=20 >>>=20 >>> I'll let Torsten interject if he feels differently as I think he origina= lly wrote the text in question.=20 >>=20 >> that was the original intent. I think =E2=80=9Cvalidate" is fine.=20 >>=20 >>>=20 >>>=20 >>>=20 >>> =C2=B67: I=E2=80=99m not sure I buy this example. Even if the clientID= is managed externally, the association with a set or pattern of allowed red= irect URIs is still important, and the AS will need to know what that is. I t= hink this example could lead an AS developer to (erroneously and dangerously= ) conclude that they don=E2=80=99t have to check any other values in a reque= st, including scope and redirect URI. It=E2=80=99s important that DynReg doe= sn=E2=80=99t alleviate that issue, but removal of DynReg doesn=E2=80=99t rea= lly change things in that regard. Suggest removing example or reworking para= graph. >>>=20 >>> I'm going to have to defer to Torsten on this because, to be honest, I'm= not too sure about it myself. I tend to lean towards thinking the draft wou= ld be better off without it. >>>=20 >>=20 >> In the traditional authorization flow, the redirect_uri serves as way to m= ake sure the AS is really talking to the legit client and the allowed redire= ct_uri values are determined by the legit client at registration time (might= be manually). >>=20 >> With PAR, we have a much stronger means to ensure the AS is talking to th= e legit client. That=E2=80=99s why I don=E2=80=99t see an issue with letting= the client set a per transaction redirect_uri. This will give the client mo= re flexibility (mint AS-specific redirect URIs on the fly) and makes client m= anagement much easier since redirect URIs are the most volatile part of a cl= ient policy.=20 >>=20 >> It also makes use of OAuth much easier in deployments where client identi= ties are managed by external entities (even without any idea of OAuth). A pr= ominent example is open banking in the EU (aka PSD2). The (technical) identi= ty of any PSD2-licensed client is asserted by an eIDAS compliant CA in a spe= cial X.509 certificate. Those certificates contain the permissions (access t= o account information and/or payment initiation allowed) and the identity (m= ember state specific). But they don=E2=80=99t contain OAuth policy values. N= evertheless, the regulation requires any financial institution in the EU to a= t runtime, without any registration, to accept and process calls from any li= censed PSD2 clients. >>=20 >> There are two ways to cope with it in OAuth context: >> a) use dynamic client registration with the X.509 cert as credential. Unf= ortunately, RFC 7591 does not support other client authentication means then= an initial access token. Beside that, it would violate the text of the regu= lation.=20 >> b) establish a redirect URL with every transaction. This is the recommend= ed approach in at least one of the PSD2 specs. >>=20 >> PAR is a clean way to solve that problem.=20 >>=20 >> I don=E2=80=99t want this text to cause confusing. On the other hand this= potential of PAR is way too important to not mention it at all. What about m= oving it into a special section "redirect_uri management=E2=80=9D? >>=20 >>>=20 >>=20 >=20 --Apple-Mail-27C64ADB-C891-4B14-A36F-B4E5030D4D7B Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBPgw ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wxggOpMIIDpQIBATCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgM B0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5w LkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODI5MTU0ODU5WjAvBgkqhkiG9w0BCQQxIgQg JgkhM5b3t7d+wpzhqkG7K7aFm0FCbJcOfZjp46uVWU0wgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQEBBQAEggEAhPDW2wQky65myg9HoC+ykaHvQLpMoKXLVDWErcL9rVVr4DEPONxZ FJropr2cv8NEBxFObYHyLA/D/Ey1sSnXzDQWp/ACEE+5KG6Fap2XH2Jkv03v8lIn1CCl5UxgWya3 luwIcxqd06Sliw8esaJZJn9zV8PrMjNHS7j94o4tJpo35VGiKWPaRvOzP0kgCUJRZ+BfZnLeMlhu c+kwFy2SwGCEoGsc4REgHs8wW/vQta4Il99+Vk5G49M2ub74hllPSdJvLrvl0va21nAPvXJPqScc c814ETfC54Wd8VzMexmt7kGlAldf98UU28hROBoiNtX+E3dvnXlYgq7b5wjQJAAAAAAAAA== --Apple-Mail-27C64ADB-C891-4B14-A36F-B4E5030D4D7B-- From nobody Sat Aug 29 15:26:42 2020 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 52A4F3A1107; Sat, 29 Aug 2020 15:26:37 -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_FONT_LOW_CONTRAST=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 Nb57uoPWLaKi; Sat, 29 Aug 2020 15:26:35 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 486B63A1105; Sat, 29 Aug 2020 15:26:35 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id r69so588435lff.4; Sat, 29 Aug 2020 15:26:35 -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=V8/wDmTDvQfVSRW+iS2wBksgTmfERoWfkWa2QNaN3s8=; b=NtnUpAFPNJ7iD9X30juxR24SlfYBoLEb7ZCka7og1ZGLtKYwzCWUJHfmPBz+D8VVXW J8gUNiO5izJIxlwZ8WUMxhSDPFRMQknEIESGbFxZYb5eXm3hUT0YXyBljzJe8aM0iLau 59QjsknnUTXnVQvi2Of72byLPCNcR8V2x2HS38WZivm6WAqK+JflKTo53R1LCanV+dUS aay9djyAxDA2zXn9D2MKRK1vDjbZOsxfLCp+hzcDvFsp4iAhx9pWPjoCU9UVaqOX5b+G bKxDGLQZFqHvmw0NXP9gml3lDfiSFbz+JxSGkO3GhEi0D+x6QiUKb6BmC3DkVxHAITRr Y4nQ== 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=V8/wDmTDvQfVSRW+iS2wBksgTmfERoWfkWa2QNaN3s8=; b=H1El7elstbPD0aPFdj/lTEtLBvEdGvKPBQfO+/VF2Tp311yTHkD/ggI0jEwG6ngCAw liX6WqbjSQddmbxJQIw1zJjoZmjhQajIoomm4HXU9m4Cs10D5H6UXHQcXt0ZUvqm0UlK spk70m86+99x/ib/iRP1O1I/8GfWDG/3e4EmZjYsmieX36tDMcT9dI98GcgHhf5LhwOx C8n7lJsXPc9xnI6iXhYucv92BVJYYBeysZboL2irgXexVOQsEQrwcemx1r8PqAuo4+z4 8rZb2bKW1UbupO0wTtNs95+qmqJ8ZjEp2TyuiZsQr2fgj0hC0Uc0FGzdZVrSDvfWdyUX v+fg== X-Gm-Message-State: AOAM531/1N8uUZPL6dtSVWguE8aGCoaUY6KDXpucLX0xiLsJTLrMpt4V DRnGnxtsqeWTUttvjg7PoAfFdCdUakAEY3ZIdDI= X-Google-Smtp-Source: ABdhPJwbcXb8qnYQ1SNK2A0azrU1U3DOFhB+yEyo7G2Ki93aaVCjNGB2EKgrwqpZpLhAKBp+BagNbJw2zYGaLDE9uMI= X-Received: by 2002:ac2:5298:: with SMTP id q24mr502592lfm.164.1598739993181; Sat, 29 Aug 2020 15:26:33 -0700 (PDT) MIME-Version: 1.0 References: <412A63AD-DDE1-4BFE-8234-5A721A0ED88D@lodderstedt.net> <08D01F36-367B-4F23-9602-9C2A2AE49DA3@mit.edu> In-Reply-To: <08D01F36-367B-4F23-9602-9C2A2AE49DA3@mit.edu> From: Dick Hardt Date: Sat, 29 Aug 2020 15:25:57 -0700 Message-ID: To: Justin Richer Cc: Torsten Lodderstedt , Mike Jones , "last-call@ietf.org" , oauth Content-Type: multipart/alternative; boundary="00000000000061c4c605ae0ba924" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 29 Aug 2020 22:26:37 -0000 --00000000000061c4c605ae0ba924 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The "can" works better, agreed. Thanks! =E1=90=A7 On Sat, Aug 29, 2020 at 8:25 AM Justin Richer wrote: > Thanks, Dick. I agree with removing the excess parenthetical, but I > intentionally avoided using a lowercase =E2=80=9Cmay=E2=80=9D in the midd= le of the > text (in favor of =E2=80=9Ccan=E2=80=9D) to avoid normative-sounding non= -normative > language, so I=E2=80=99d recommend that change be kept: > > Implementers should be aware that a token introspection request lets the > AS know when the client > is accessing the RS, which can also indicate when the user is using > the client. If this implication is not acceptable, implementers can > use other means to carry > access token data, e.g. directly transferring the data needed by the > RS within the access token. > > On Aug 27, 2020, at 12:15 PM, Dick Hardt wrote: > > Here is a crisper revision. > > Implementers should be aware that a token introspection request lets the > AS know when the client > is accessing the RS, which may indicate when the user is using > the client. If this implication is not acceptable, implementers can > use other means to carry > access token data, e.g. directly transferring the data needed by the > RS within the access token. > =E1=90=A7 > > On Thu, Aug 27, 2020 at 7:19 AM Justin Richer wrote: > >> I would clarify that this doesn=E2=80=99t necessarily say that the user= =E2=80=99s there, >> and remove the normative requirement (which doesn=E2=80=99t have enforce= able teeth >> in this context): >> >> Implementers should be aware that a token introspection request lets the >> AS know when the client >> (and potentially the user) is accessing the RS, which *can also >> indicate* when the user is using >> the client. If this implication is not acceptable, *implementers can >> use other means* to carry >> access token data, e.g. directly transferring the data needed by the >> RS within the access token. >> >> >> =E2=80=94 Justin >> >> On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt < >> torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote: >> >> Will the following text work for you? >> >> Implementers should be aware that a token introspection request lets the >> AS know when the client >> (and potentially the user) is accessing the RS, which is also an >> indication of when the user is using >> the client. If this impliction is not accepatable, implementars MUST >> use other means to carry >> access token data, e.g. directly transferring the data needed by the >> RS within the access token. >> >> >> On 26. Aug 2020, at 23:12, Mike Jones < >> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >> >> I agree with Dick=E2=80=99s observation about the privacy implications o= f using >> an Introspection Endpoint. That=E2=80=99s why it=E2=80=99s preferable t= o not use one at >> all and instead directly have the Resource understand the Access Token. >> One way of doing this is the JWT Access Token spec. There are plenty of >> others. >> >> The downsides of using an Introspection Endpoint should be described in >> the Privacy Considerations section. >> >> -- Mike >> >> From: OAuth On Behalf Of Dick Hardt >> Sent: Wednesday, August 26, 2020 9:52 AM >> To: Torsten Lodderstedt >> Cc: last-call@ietf.org; oauth >> Subject: Re: [OAUTH-WG] Last Call: >> (JWT Response for >> OAuth Token Introspection) to Proposed Standard >> >> >> >> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt < >> torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote: >> Hi Denis, >> >> On 25. Aug 2020, at 16:55, Denis wrote: >> >> >> The fact that the AS will know exactly when the introspection call has >> been made and thus be able to make sure which client >> has attempted perform an access to that RS and at which instant of time. >> The use of this call allows an AS to track where and when >> its clients have indeed presented an issued access token. >> >> >> That is a fact. I don=E2=80=99t think it is an issue per se. Please expl= ain the >> privacy implications. >> >> As I see it, the privacy implication is that the AS knows when the clien= t >> (and potentially the user) is accessing the RS, which is also an indicat= ion >> of when the user is using the client. >> >> I think including this implication would be important to have in a >> Privacy Considerations section. >> >> /Dick >> =E1=90=A7 >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > --00000000000061c4c605ae0ba924 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The "can" works better, agreed. Thanks!
3D""=E1=90=A7
On Sat, Aug 29, 2020 at 8:25 AM Justin Richer <jricher@mit.edu> wrote:
Thanks, Dick. I agree with removing the excess parenthetical= , but I intentionally avoided using a lowercase =E2=80=9Cmay=E2=80=9D in th= e middle of the text=C2=A0=C2=A0(in favor of =E2=80=9Ccan=E2=80=9D)=C2=A0to= avoid normative-sounding non-normative language, so I=E2=80=99d recommend = that change be kept:

Implementers should be aware that a= token introspection request lets the AS know when the=C2=A0client=C2=A0=C2=A0 =C2=A0 is accessing the RS, which can also indicate when the user i= s using=C2=A0
=C2=A0 =C2=A0 the client. If this implication is not accep= table, implementers can use other means to carry=C2=A0
=C2=A0 =C2=A0 acc= ess token data, e.g. directly transferring the data needed by the RS within= the access token.

On Aug= 27, 2020, at 12:15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Here is a crisper revision.

Implemen= ters should be aware that a token introspection request lets the AS know wh= en the client
=C2=A0 =C2=A0 is accessing the RS, which may=C2=A0indicat= e when the user is using
=C2=A0 =C2=A0 the client. If this implication = is not acceptable, implementers can use other means to carry
=C2=A0 =C2= =A0 access token data, e.g. directly transferring the data needed by the RS= within the access token.
3D""=E1=90=A7
On Thu, A= ug 27, 2020 at 7:19 AM Justin Richer <jricher@mit.edu> wrote:
I would clarify that this doesn=E2= =80=99t necessarily say that the user=E2=80=99s there, and remove the norma= tive requirement (which doesn=E2=80=99t have enforceable teeth in this cont= ext):

Implementers should be aware that a token introspe= ction request lets the AS know when the=C2=A0client=C2=A0
=C2=A0 =C2=A0 = (and potentially the user) is accessing the RS, which can also indicate<= /b> when the user is=C2=A0using=C2=A0
=C2=A0 =C2=A0 the client. If this = implication is not acceptable, implementers can use other means to c= arry=C2=A0
=C2=A0 =C2=A0 access token data, e.g. directly transferring t= he data needed by the RS within the access token.

=C2=A0=E2=80=94 Justin

On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt <torsten=3D4= 0lodderstedt.net@dmarc.ietf.org> wrote:

Will the = following text work for you?

Implementers should be aware that a tok= en introspection request lets the AS know when the client
=C2=A0=C2=A0= =C2=A0=C2=A0(and potentially the user) is accessing the RS, which is also a= n indication of when the user is using
=C2=A0=C2=A0=C2=A0=C2=A0the cli= ent. If this impliction is not accepatable, implementars MUST use other mea= ns to carry
=C2=A0=C2=A0=C2=A0=C2=A0access token data, e.g. directly t= ransferring the data needed by the RS within the access token.


<= blockquote type=3D"cite">On 26. Aug 2020, at 23:12, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I ag= ree with Dick=E2=80=99s observation about the privacy implications of using= an Introspection Endpoint.=C2=A0 That=E2=80=99s why it=E2=80=99s preferabl= e to not use one at all and instead directly have the Resource understand t= he Access Token.=C2=A0 One way of doing this is the JWT Access Token spec.= =C2=A0 There are plenty of others.

The downsides of using an Introsp= ection Endpoint should be described in the Privacy Considerations section.<= br>
=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=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=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-- Mike

From: OAuth <oauth-bounces@ietf.org= > On Behalf Of Dick Hardt
Sent: Wednesday, August 26, 2020 9:52 AMTo: Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.or= g>
Cc: la= st-call@ietf.org; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Last Call: <d= raft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAu= th Token Introspection) to Proposed Standard



On Wed, Aug 26,= 2020 at 4:37 AM Torsten Lodderstedt <torsten=3D40lodderstedt.net@d= marc.ietf.org> wrote:
Hi Denis,

= On 25. Aug 2020, at 16:55, Denis <denis.ietf@free.fr> wrote:

The fact that the AS will know exactly when the intr= ospection call has been made and thus be able to make sure which client has attempted perform an access to that RS and at which instant of time. T= he use of this call allows an AS to track where and when
its clients ha= ve indeed presented an issued access token.

That is a f= act. I don=E2=80=99t think it is an issue per se. Please explain the privac= y implications.

As I see it, the privacy implication is that the AS = knows when the client (and potentially the user) is accessing the RS, which= is also an indication of when the user is using the client.

I think= including this implication would be important to have in a Privacy Conside= rations section.

/Dick
=E1=90=A7

____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf= .org/mailman/listinfo/oauth


--00000000000061c4c605ae0ba924-- From nobody Sun Aug 30 15:48:43 2020 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 00FA23A0833 for ; Sun, 30 Aug 2020 15:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=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 (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 eUH3mk9QznQE for ; Sun, 30 Aug 2020 15:48:39 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 380423A0831 for ; Sun, 30 Aug 2020 15:48:39 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id j15so2460907lfg.7 for ; Sun, 30 Aug 2020 15:48: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=7oYvtN0LPMBk3bR0HEfd2hSxg007Vknk/5cRcnKjQYk=; b=V04BK4YIoIMK417NQ3d3Zo+5sOwp7GLdl0ncLBcqHggL6rsEcMnRYeYwtNRmHmaPjy T/q12MhsiuR7MVPzEhog0aZBJm62svHh6ps5L0Bc7S5PgfVOJyd5xX9pbrO2Db8X3B2a OOOyvPPCtMSYv3xiWTufOsGV2cAEj3PETz5xvDcU91Tlt8469c399s9DLbFpeztubDsL VcwcWjZamr0gmV8cPQfg82whLLDf2x/2s0imUW0ZKANF/6MjK2wrWIrOaWYETt2sxGpK batOlFm+YwrrMUbCLkVRiyEEH/O1BP9N69ln0LkRSF3btWGZWqoFFEt2eflFXDkHsPDa RS3A== 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=7oYvtN0LPMBk3bR0HEfd2hSxg007Vknk/5cRcnKjQYk=; b=HRNnLbSR+/a88XF5Gq95I1CKE5wwmUQn8RlcjXz7G5xso4eEeludUT0NMDq6daIhKh RfmTDtbz8oIGboeBE5AKJBPSJL0f5+yVr9cgrpyyYGEaCk3966FXVJ8JeDQO2qb6Q7Jv GqyKT6AmKcLasj+df1bIi2xMM+1Q/NvpddEnTm7dwPMPfFSZ57nC1KUzXcm5zxXgsYrb PNHN5ERobPw/pCU64vfVMEloDGPAo9Xn0mm+CuoXNX0C6ARpdpu+2HoWf3AhXoeaBdf9 pp0lkDmOe2Cptxy5D94qcENH1yTK+TEfDTRF0dHWq1GOtiPTVq/r7vrKjMxZdXm7AOw4 LBUg== X-Gm-Message-State: AOAM5333CIlK5m7qYvumKkruFLPuF8cNR5/oU3IdFFj6qN9uD4AQrOtU iIpmLq8O6JQIi1eWEAn75VvRBxoLCyKTUBedxkU= X-Google-Smtp-Source: ABdhPJxoW4Zf+9Ccbf/JTolDDKSlyr31kulHHrZ3D4Rp3DFjdSDBTkextiF82vMQX3xxpLQvulLClrWPhvVEbKKDbQY= X-Received: by 2002:a19:70c:: with SMTP id 12mr4322468lfh.207.1598827717146; Sun, 30 Aug 2020 15:48:37 -0700 (PDT) MIME-Version: 1.0 References: <7C0FD285-F677-4501-B2FB-9431A59855F6@mit.edu> <102C6B96-C1FA-4BC1-8932-C7F4F377CFFE@lodderstedt.net> In-Reply-To: <102C6B96-C1FA-4BC1-8932-C7F4F377CFFE@lodderstedt.net> From: Dick Hardt Date: Sun, 30 Aug 2020 15:48:01 -0700 Message-ID: To: Torsten Lodderstedt Cc: Justin Richer , Brian Campbell , oauth Content-Type: multipart/alternative; boundary="000000000000233afc05ae2016b5" Archived-At: Subject: Re: [OAUTH-WG] WGLC Review of PAR 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, 30 Aug 2020 22:48:42 -0000 --000000000000233afc05ae2016b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't have the context of the text to respond to the exact wording, but I think we can state that the client MUST use the "request_uri" only once, and then explain that the AS may receive duplicate requests if the browser is reloaded. On Sat, Aug 29, 2020 at 4:24 AM Torsten Lodderstedt wrote: > You are making a good point here. The reason we added the one time use > constraint was the fact the client will include parameters supposed to be > used only once, e.g. the PKCE code_challenge. For a traditional > authorisation request, we would recommend the client to use a per > transaction (=3D=3D one time use) code_challenge, but PKCE does not requi= re the > AS to enforce it. Mapping this to PAR means, we SHOULD recommend the clie= nt > to use the request_uri only once but not require the AS to enforce it. > > Would the following text work for you? > > Since parts of the request content, e.g. the "code_challenge" > parameter value, is unique to a certain authorization request, > the client SHOULD use the "request_uri" only once. > > I also would move this text to section 4. > > > On 27. Aug 2020, at 18:11, Dick Hardt wrote: > > > > That is not correct. > > > > The authorization code one-time-use is directly between the client and > the AS. The client has a number of mechanisms to ensure it only presents > the authorization code to the AS once, such as a session that was set whe= n > the user started at the client. > > > > In contrast, in a redirect from the client to the AS, the client loses > control on how many times the user-agent loads the URL at the AS. > Additionally, there is unlikely to be an active browser session at the AS= , > so the AS can not easily differentiate between a URL load from the same > user, or different users. If one-time-use, one of them MUST fail. If the > two requests happen to be from the same user (because of a reload, which > the user did because the AS was slow to respond), there is no way for the > AS to know which of the requests is the one that is current in front of t= he > user. While the AS can internally ensure processing of the request once, > one-time-use would dictate that it provides a failure message to one of t= he > requests. > > > > /Dick > > > > > > =E1=90=A7 > > > > On Thu, Aug 27, 2020 at 7:17 AM Justin Richer wrote: > > We already have this same property with authorization codes, and it=E2= =80=99s > managed today reasonably well (in my opinion). If you submit the same > request URI twice in the same browser (the refresh you=E2=80=99re talking= about), > it shouldn=E2=80=99t start two separate authorization requests, but it wo= uld be > reasonable to detect that the same session attached to the same request U= RI > value showed up twice and continue the session as appropriate. > > > > None of this is in conflict with =E2=80=9Cone time use=E2=80=9D, in my = view, since > you=E2=80=99re actively detecting the session and source of the value. > > > > =E2=80=94 Justin > > > >> On Aug 26, 2020, at 6:16 PM, Dick Hardt wrote: > >> > >> I think one-time use may be overly restrictive, and I don't think it i= s > the property that we actually want. > >> > >> Give the request URI is in a redirect from the browser, there is a goo= d > chance of a race condition where the same browser request is made more th= an > once, for example, while the browser is loading the authorization URL at > the AS, the user could refresh the page causing the authorization URL to = be > reloaded. Would the reload count as a second use? One could argue it eith= er > way. > >> > >> What I think we want from what I understand, is the request URI MUST b= e > unique so that there is no confusion on which request is being referenced= . > >> > >> I did not see anything about the expiry time of the request URI (but I > did not look super hard). If that is not there, then I think the request > URI MUST expire in a "short" period of time. > >> > >> > >> > >> =E1=90=A7 > >> > >> On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> Thanks Justin. Just a couple more responses to responses inline below > (but with lots of content that needs no further discussion removed). > >> > >> A TL;DR for the WG is that I'd like to get some wider feedback on the > question of changing the one-time-use condition on the request_uri from a > SHOULD to a MUST. > >> > >> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer wrote: > >> Hi Brian, just a couple responses inline where it seemed fitting. > Thanks for going through everything! > >> =E2=80=94 Justin > >> > >>> On Aug 25, 2020, at 6:01 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >>> > >>> Thanks for the review and comments Justin. Replies (or attempts > thereat) are inline below. > >>> > >>> > >>> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer wrote= : > >>> I=E2=80=99ve done a full read through of the PAR specification, and h= ere are > my notes on it. > >>> > >>> > >>> =C2=B62: Of necessity, this spec mixes parameters in the authoriz= ation > endpoint and token endpoint registries into a single request. Is there an= y > danger of conflict between them? The registry holds them in one list but > they could possibly have different semantics in both places.. > >>> > >>> I think that technically such danger does exist but that it's highly > unlikely in practice. Especially because the only token endpoint paramete= rs > that are relevant to PAR are those that deal with client authentication > (currently client_secret, client_assertion, and client_assertion_type). I= 'm > also not sure what can reasonably be done about it given the way the > registries are. I guess PAR could update the registration for those three > (client_secret, client_assertion, and client_assertion_type) to also > indicate authorization request as a usage location with some commentary > that it's only for avoiding name collisions. And offer some guidance abou= t > doing the same for any future client auth methods being defined. But > honestly I'm not sure what, if anything, to do here? > >>> > >>> And yes it is super unfortunate that client auth and protocol > parameters got mixed together in the HTTP body. I didn't cause that > situation but I've certainly contributed to it and for that I apologize. > >> > >> I think the only perfect solution is to go back in time and fix the > registries with based on the last decade of knowledge in using them. :P > >> > >> For this, I think maybe being very prescriptive about the fact that th= e > only parameters from the token endpoint that are allowed here are those > used for client authentication and that when they show up, they=E2=80=99r= e > interpreted as in the token endpoint request not the authorization endpoi= nt > request. Does that work? > >> > >> I think so, yes.. And will work on incorporating some text towards tha= t > end. > >> > >> > >> > >>> I don=E2=80=99t see why a request URI with unguessable values isn= =E2=80=99t a MUST > for one-time-use, is there a reason? > >>> > >>> The reason AFAIK was to not be overly prescriptive and allow for > eventually consistent or not atomic storage of the data by not strictly > requiring the AS to enforce one-time-use. Do you think that's too loose o= r > could be worded/explained differently or better? > >> > >> I do think it=E2=80=99s too loose and it should be a MUST, and the met= hods for > enforcing that =E2=80=9CMUST=E2=80=9D are going to vary based on the depl= oyments and > implementations out there. > >> > >> > >> I'd be okay with making it a MUST but think maybe it'd be good to hear > from a few more people in the WG before committing to that change. > >> > >> Can I ask some folks to weigh in on this one? I'm leaning towards > making the change barring objections. > >> > >> > >> 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 fi= le > attachments from your computer. Thank > you._______________________________________________ > >> 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 > > =E1=90=A7 --000000000000233afc05ae2016b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't have the context of the text to respond t= o the exact wording, but I think we can state that the client MUST use the = "request_uri" only once, and then explain that the AS may receive= duplicate requests if the browser is reloaded.

<= /div>
O= n Sat, Aug 29, 2020 at 4:24 AM Torsten Lodderstedt <torsten@lodderstedt.net> wr= ote:
You are mak= ing a good point here. The reason we added the one time use constraint was = the fact the client will include parameters supposed to be used only once, = e.g. the PKCE code_challenge. For a traditional authorisation request, we w= ould recommend the client to use a per transaction (=3D=3D one time use) co= de_challenge, but PKCE does not require the AS to enforce it. Mapping this = to PAR means, we SHOULD recommend the client to use the request_uri only on= ce but not require the AS to enforce it.

Would the following text work for you?

Since parts of the request content, e.g. the "code_challenge"
=C2=A0 =C2=A0parameter value, is unique to a certain authorization request,=
the client SHOULD use the "request_uri" only once.

I also would move this text to section 4.

> On 27. Aug 2020, at 18:11, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> That is not correct.
>
> The authorization code one-time-use is directly between the client and= the AS. The client has a number of mechanisms to ensure it only presents t= he authorization code to the AS once, such as a session that was set when t= he user started at the client.
>
> In contrast, in a redirect from the client to the AS, the client loses= control on how many times the user-agent loads the URL at the AS. Addition= ally, there is unlikely to be an active browser session at the AS, so the A= S can not easily differentiate between a URL load from the same user, or di= fferent users. If one-time-use, one of them MUST fail. If the two requests = happen to be from the same user (because of a reload, which the user did be= cause the AS was slow to respond), there is no way for the AS to know which= of the requests is the one that is current in front of the user. While the= AS can internally ensure processing of the request once, one-time-use woul= d dictate that it provides a failure message to one of the requests.
>
> /Dick
>
>
> =E1=90=A7
>
> On Thu, Aug 27, 2020 at 7:17 AM Justin Richer <jricher@mit.edu> wrote:
> We already have this same property with authorization codes, and it=E2= =80=99s managed today reasonably well (in my opinion). If you submit the sa= me request URI twice in the same browser (the refresh you=E2=80=99re talkin= g about), it shouldn=E2=80=99t start two separate authorization requests, b= ut it would be reasonable to detect that the same session attached to the s= ame request URI value showed up twice and continue the session as appropria= te.
>
> None of this is in conflict with =E2=80=9Cone time use=E2=80=9D, in my= view, since you=E2=80=99re actively detecting the session and source of th= e value.
>
>=C2=A0 =E2=80=94 Justin
>
>> On Aug 26, 2020, at 6:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>
>> I think one-time use may be overly restrictive, and I don't th= ink it is the property that we actually want.
>>
>> Give the request URI is in a redirect from the browser, there is a= good chance of a race condition where the same browser request is made mor= e than once, for example, while the browser is loading the authorization UR= L at the AS, the user could refresh the page causing the authorization URL = to be reloaded. Would the reload count as a second use? One could argue it = either way.
>>
>> What I think we want from what I understand, is the request URI MU= ST be unique so that there is no confusion on which request is being refere= nced.
>>
>> I did not see anything about the expiry time of the request URI (b= ut I did not look super hard). If that is not there, then I think the reque= st URI MUST expire in a "short" period of time.
>>
>>
>>
>> =E1=90=A7
>>
>> On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell <bcampbell=3D40pingi= dentity.com@dmarc.ietf.org> wrote:
>> Thanks Justin. Just a couple more responses to responses inline be= low (but with lots of content that needs no further discussion removed). >>
>> A TL;DR for the WG is that I'd like to get some wider feedback= on the question of changing the one-time-use condition on the request_uri = from a SHOULD to a MUST.
>>
>> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer <jricher@mit.edu> wrote:
>> Hi Brian, just a couple responses inline where it seemed fitting. = Thanks for going through everything!
>>=C2=A0 =E2=80=94 Justin
>>
>>> On Aug 25, 2020, at 6:01 PM, Brian Campbell <bcampbell@pingidentity.co= m> wrote:
>>>
>>> Thanks for the review and comments Justin. Replies (or attempt= s thereat) are inline below.
>>>
>>>
>>> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer <jricher@mit.edu> wrote:
>>> I=E2=80=99ve done a full read through of the PAR specification= , and here are my notes on it.
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0=C2=B62: Of necessity, this spec mixes para= meters in the authorization endpoint and token endpoint registries into a s= ingle request. Is there any danger of conflict between them? The registry h= olds them in one list but they could possibly have different semantics in b= oth places..
>>>
>>> I think that technically such danger does exist but that it= 9;s highly unlikely in practice. Especially because the only token endpoint= parameters that are relevant to PAR are those that deal with client authen= tication (currently client_secret, client_assertion, and client_assertion_t= ype). I'm also not sure what can reasonably be done about it given the = way the registries are. I guess PAR could update the registration for those= three (client_secret, client_assertion, and client_assertion_type) to also= indicate authorization request as a usage location with some commentary th= at it's only for avoiding name collisions. And offer some guidance abou= t doing the same for any future client auth methods being defined. But hone= stly I'm not sure what, if anything, to do here?=C2=A0
>>>
>>> And yes it is super unfortunate that client auth and protocol = parameters got mixed together in the HTTP body. I didn't cause that sit= uation but I've certainly contributed to it and for that I apologize. <= br> >>
>> I think the only perfect solution is to go back in time and fix th= e registries with based on the last decade of knowledge in using them. :P <= br> >>
>> For this, I think maybe being very prescriptive about the fact tha= t the only parameters from the token endpoint that are allowed here are tho= se used for client authentication and that when they show up, they=E2=80=99= re interpreted as in the token endpoint request not the authorization endpo= int request. Does that work?
>>
>> I think so, yes.. And will work on incorporating some text towards= that end.
>>
>>
>>=C2=A0
>>>=C2=A0 =C2=A0 =C2=A0I don=E2=80=99t see why a request URI with = unguessable values isn=E2=80=99t a MUST for one-time-use, is there a reason= ?
>>>
>>> The reason AFAIK was to not be overly prescriptive and allow f= or eventually consistent or not atomic storage of the data by not strictly = requiring the AS to enforce one-time-use. Do you think that's too loose= or could be worded/explained differently or better?
>>
>> I do think it=E2=80=99s too loose and it should be a MUST, and the= methods for enforcing that =E2=80=9CMUST=E2=80=9D are going to vary based = on the deployments and implementations out there.
>>
>>
>> I'd be okay with making it a MUST but think maybe it'd be = good to hear from a few more people in the WG before committing to that cha= nge.
>>
>> Can I ask some folks to weigh in on this one? I'm leaning towa= rds making the change barring objections.
>>
>>
>> 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...=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 attachments from= your computer. Thank you._______________________________________________ >> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

3D""= =E1=90=A7
--000000000000233afc05ae2016b5-- From nobody Mon Aug 31 00:58:24 2020 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 6BCA73A1098 for ; Mon, 31 Aug 2020 00:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-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 z-jEJ3FLk3ND for ; Mon, 31 Aug 2020 00:58:17 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83443A1095 for ; Mon, 31 Aug 2020 00:58:16 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d60 with ME id N7yB2300T2bcEcA037yBA0; Mon, 31 Aug 2020 09:58:14 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 31 Aug 2020 09:58:14 +0200 X-ME-IP: 90.79.51.120 To: Torsten Lodderstedt Cc: Dick Hardt , Justin Richer , "last-call@ietf.org" , Mike Jones , oauth From: Denis References: <412A63AD-DDE1-4BFE-8234-5A721A0ED88D@lodderstedt.net> <08D01F36-367B-4F23-9602-9C2A2AE49DA3@mit.edu> Message-ID: <65a7f2c0-c7e3-5c67-1be6-1dfb2b77779e@free.fr> Date: Mon, 31 Aug 2020 09:58:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------964D13DDADA0E9C9AF1A299A" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 31 Aug 2020 07:58:22 -0000 This is a multi-part message in MIME format. --------------964D13DDADA0E9C9AF1A299A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The last text that has been proposed on the list about this thread is the following: Implementers should be aware that a token introspection request lets the AS know when the client is accessing the RS,       which can also indicate when the user is using the client. If this implication is not acceptable, implementers can use other means       to carry access token data, e.g. directly transferring the data needed by the RS within the access token. The concerns of the implementers have nothing to do with the concerns of the Users. Such a text proposal has nothing to do with a "User consent". *Towards an RFC Errata to RFC 7662* Mike Jones wrote: I agree with Dick’s observation about the privacy implications of using an Introspection Endpoint. That’s why it’s preferable to not use one at all       and instead directly have the Resource understand the Access Token. One way of doing this is the JWT Access Token spec. There are plenty of others. I fully agree. RFC 7662 should have incorporated a more detailed content such as:      In OAuth 2.0 [RFC6749], the contents of tokens are opaque to clients. However, the contents of tokens is not intended to be opaque to RSs.      Token introspection is an OPTIONAL feature of an AS described in OAuth Introspection [RFC 7662] intended for clients that are unable      to support structured access tokens including their validation. The use of this call allows an AS to track where and when its clients have indeed      presented an issued access token. As soon as the RS knows the format of the access token, e.g. using structured token formats such as      JWT [RFC7519], and is able to validate its security features, the call described in OAuth Introspection [RFC 7662] should be avoided, otherwise      the AS will know exactly when the introspection call has been made and thus be able to make sure which client has attempted perform an access      to that RS and at which instant of time. As soon as this call is supported by an AS, the client or the user have no way to prevent the RS to use it. It might be useful to add it, e.g. using an RFC Errata. *Differences with RFC 7662* RFC 7662 defines a protocol that allows authorized protected resources to query the authorization server to determine the set of metadata for a given token that was presented to them by an OAuth 2.0 client. At a first glance, draft-ietf-oauth-jwt-introspection-response-09 seems to be simply a JWT Response for OAuth Token Introspection instead of a JSON document representing the meta information surrounding the token. However, this is not the case since major differences can be identified. RFC 7662 describes an OPTIONAL call able to return a JSON object with the following top-level members: active (REQUIRED), scope (OPTIONAL), client_id (OPTIONAL), username (OPTIONAL), token_type (OPTIONAL), exp (OPTIONAL), iat (OPTIONAL), nbf (OPTIONAL), sub (OPTIONAL), aud (OPTIONAL), iss (OPTIONAL), jti (OPTIONAL) and claims from the "JSON Web Token Claims" registry (OPTIONAL). draft-ietf-oauth-jwt-introspection-response-09 is able to return a JWT as the introspection response. However, the request and the returned information are not the same. Section 4 (Requesting a JWT Response) only provides an example and does not describe the mandatory and optional parameters from the request. Are they identical to those described in RFC 7662 ? No one is able to say. draft-ietf-oauth-jwt-introspection-response-09 describes a response structure which is different from RFC 7662 where a single top-level member is required, i.e. active. The text from draft-ietf-oauth-jwt-introspection-response-09 requires three (in fact four) top-level members. The text states: The JWT MUST include the following top-level claims: * issMUST be set to the issuer URL of the authorization server. * audMUST identify the resource server receiving the token introspection response. * iatMUST be set to the time when the introspection response was created by the authorization server. Note that the text about "active" (i.e. the fourth top-level member) is misplaced in the middle of the token_introspection claim and does not allow to easily understand that the top-level claim "active" MUST be set to either true or false. The text states: The AS determines based on its RS-specific policy what claims about the resource owner to return in the token introspection response. Such a sentence (which does not exist in RFC 7662) is a door wide-opened to return claims that are NOT included into the access token. This protocol should NOT be a protocol that allows authorized RSs to query the AS to obtain metadata that was NOT included into an access token that was presented to them. Torsten wrote: Token introspection has several advantages over structured access tokens, also when it comes to privacy. If one uses a structured access token       in conjunction with different *services*, then this access token needs to contain ALL data required to call ALL these services. This effectively means       the services learn more data than required. One could try to mitigate this by carrying encrypted compartments in the same token, each of them       encrypted with for a certain service. That would be complex and is not covered by current technical standards. Introspection, however, allows the AS       issue a minimal access token (even without any id) and mint specific response for the different RSs. Instead of attempting to imagine complex mechanisms like "encrypted compartments in the same token", it is much simpler to use different access tokens. AFAIK, in addition, there is no notion of "services" in OAuth in RFC 6749, but only a notion of "server". A "server" is not a "service". resource server The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. RFC 6750 is using the wording "audience restriction" to restrict the use of a token to "the intended relying party or set of relying parties" (i.e. to one or more RSs). So if the access token is targeted to one or more RSs, it should only contain what is necessary to accomplish the call on these RSs. This means the RS(s) learn(s) exactly the data that it required. If it is not the case, several access tokens should be used. The principle of "data minimization" implies that an access token should only contain what is necessary to accomplish a call to a given RS. Since this new call is meant to be OPTIONAL, there should be no difference whether the RS decodes and validates the access token by itself or sub-contracts the same operations to the AS. The explanations from Torsten imply that there can be a difference .... which furthermore is left at the full discretion of the AS. *About the secondary use* I wrote: This concern is identified in RFC 6973 as: 5.2.3.Secondary Use Secondary use is the use of collected information about an individual without the individual’s consent for a purpose different from that for which the information was collected.Secondary use may violate people’s expectations or desires.The potential for secondary use can generate uncertainty as to how one’s information will be used in the future, potentially discouraging information exchange in the first place.Secondary use encompasses any use of data, including disclosure. Torsten replied:       This is no secondary use, it’s the primary use *the user consented with*. No "user consent" phase is ever mentioned in order to allow a RS to ask and receive a jwt-introspection-response. The text states: The AS MUST ensure the release of any privacy-sensitive data is legally based. Such a statement does not make sense in practice. A different legal system applies depending upon three factors: the location of the client, the location of the AS and the location of the RS. Unless these three entities are located within the same country (e.g. Switzerland), the same state (e.g. Maryland) or the same union (e.g. the European Union), the AS will be unable to know how to enforce such a statement. The release of any privacy-sensitive data must be under the control of the user who must consent to the release of that privacy-sensitive data. This makes it independent from any legal system. *About the token introspection endpoint * The token introspection endpoint is advertised in RFC 8414 in the following way: introspection_endpoint OPTIONAL.URL of the authorization server’s OAuth 2.0 introspection endpoint [RFC7662]. This endpoint is intended to explicitly support RFC 7662, but not anything else. This draft is intended to support a new functionality that is different from RFC 7662. This means that the AS should not use the same token introspection endpoint. If supported, this new functionality should be supported using a new endpoint, e.g. an introspection_JWT_endpoint. When this new functionality is advertised by an AS by the disclosure of an access point, this does not necessarily mean that it is supported for all the RSs with which that AS has a relationship. The current situation is that the User and his client have no way to know whether or not this new call will indeed be supported by the AS for a given RS. Even the RS can't know it directly, since the only way to know it is to use a "trial and error" mechanism. *A proposal on how to solve the issue* Hereafter is one way on how to solve the issue. The User is the entity that is the best placed to give the User Consent. It would be simpler if the user could ask to the AS to provide to his client a JWT for a given RS that could be used to issue certificates usable for creating qualified electronic signatures. A specific scope could be defined for such a purpose which would detail the claims to be incorporated into the access token and say that these claims shall be verified according to sections 6.2.2 (Initial identity validation) of both ETSI EN 319 411-1 and ETSI EN 319 411-2. The client supporting the user would then communicate that JWT to the RS of its choice. The scope placed into the access token would testify that the claims have indeed been verified according to sections 6.2.2 of both ETSI EN 319 411-1 and ETSI EN 319 411-2. Such a functionality cannot be supported using draft-ietf-oauth-jwt-introspection-response. In case the RS would be unable to decode the access token and/or to validate it, it might make attempt to make a call to the AS according to RFC 7662, if this service is available (but the user has no way to indicate that he consents for making such a call). As a conclusion, since draft-ietf-oauth-jwt-introspection-response harms the user's privacy and fully by-passes the User consent, this draft should not be progressed to the RFC level. Denis > The "can" works better, agreed. Thanks! > ᐧ > > On Sat, Aug 29, 2020 at 8:25 AM Justin Richer > wrote: > > Thanks, Dick. I agree with removing the excess parenthetical, but > I intentionally avoided using a lowercase “may” in the middle of > the text  (in favor of “can”) to avoid normative-sounding > non-normative language, so I’d recommend that change be kept: > > Implementers should be aware that a token introspection request > lets the AS know when the client >     is accessing the RS, which can also indicate when the user is > using >     the client. If this implication is not acceptable, > implementers can use other means to carry >     access token data, e.g. directly transferring the data needed > by the RS within the access token. > >> On Aug 27, 2020, at 12:15 PM, Dick Hardt > > wrote: >> >> Here is a crisper revision. >> >> Implementers should be aware that a token introspection request >> lets the AS know when the client >>     is accessing the RS, which may indicate when the user is using >>     the client. If this implication is not acceptable, >> implementers can use other means to carry >>     access token data, e.g. directly transferring the data needed >> by the RS within the access token. >> ᐧ >> >> On Thu, Aug 27, 2020 at 7:19 AM Justin Richer > > wrote: >> >> I would clarify that this doesn’t necessarily say that the >> user’s there, and remove the normative requirement (which >> doesn’t have enforceable teeth in this context): >> >> Implementers should be aware that a token introspection >> request lets the AS know when the client >>     (and potentially the user) is accessing the RS, which >> *can also indicate* when the user is using >>     the client. If this implication is not acceptable, >> *implementers can use other means* to carry >>     access token data, e.g. directly transferring the data >> needed by the RS within the access token. >> >> >>  — Justin >> >>> On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt >>> >> > wrote: >>> >>> Will the following text work for you? >>> >>> Implementers should be aware that a token introspection >>> request lets the AS know when the client >>>     (and potentially the user) is accessing the RS, which is >>> also an indication of when the user is using >>>     the client. If this impliction is not accepatable, >>> implementars MUST use other means to carry >>>     access token data, e.g. directly transferring the data >>> needed by the RS within the access token. >>> >>> >>>> On 26. Aug 2020, at 23:12, Mike Jones >>>> >>> > wrote: >>>> >>>> I agree with Dick’s observation about the privacy >>>> implications of using an Introspection Endpoint. That’s why >>>> it’s preferable to not use one at all and instead directly >>>> have the Resource understand the Access Token.  One way of >>>> doing this is the JWT Access Token spec.  There are plenty >>>> of others. >>>> >>>> The downsides of using an Introspection Endpoint should be >>>> described in the Privacy Considerations section. >>>> >>>>                                                       -- Mike >>>> >>>> From: OAuth >>> > On Behalf Of Dick Hardt >>>> Sent: Wednesday, August 26, 2020 9:52 AM >>>> To: Torsten Lodderstedt >>>> >>> > >>>> Cc: last-call@ietf.org ; oauth >>>> > >>>> Subject: Re: [OAUTH-WG] Last Call: >>>> (JWT >>>> Response for OAuth Token Introspection) to Proposed Standard >>>> >>>> >>>> >>>> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt >>>> >>> > wrote: >>>> Hi Denis, >>>> >>>>> On 25. Aug 2020, at 16:55, Denis >>>> > wrote: >>>> >>>>> The fact that the AS will know exactly when the >>>>> introspection call has been made and thus be able to make >>>>> sure which client >>>>> has attempted perform an access to that RS and at which >>>>> instant of time. The use of this call allows an AS to >>>>> track where and when >>>>> its clients have indeed presented an issued access token. >>>> >>>> That is a fact. I don’t think it is an issue per se. Please >>>> explain the privacy implications. >>>> >>>> As I see it, the privacy implication is that the AS knows >>>> when the client (and potentially the user) is accessing the >>>> RS, which is also an indication of when the user is using >>>> the client. >>>> >>>> I think including this implication would be important to >>>> have in a Privacy Considerations section. >>>> >>>> /Dick >>>> ᐧ >>> >>> _______________________________________________ >>> 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 --------------964D13DDADA0E9C9AF1A299A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

The last text that has been proposed on the list about this thread is the following:

      Implementers should be aware that a token introspection request lets the AS know when the client is accessing the RS,
      which can also indicate when the user is using the client. If this implication is not acceptable, implementers can use other means
      to carry access token data, e.g. directly transferring the data needed by the RS within the access token.

The concerns of the implementers have nothing to do with the concerns of the Users. Such a text proposal has nothing to do with a "User consent".

Towards an RFC Errata to RFC 7662

Mike Jones wrote:

      I agree with Dick’s observation about the privacy implications of using an Introspection Endpoint. That’s why it’s preferable to not use one at all
      and instead directly have the Resource understand the Access Token. One way of doing this is the JWT Access Token spec. There are plenty of others.

I fully agree.

RFC 7662 should have incorporated a more detailed content such as:

     In OAuth 2.0 [RFC6749], the contents of tokens are opaque to clients. However, the contents of tokens is not intended to be opaque to RSs.
     Token introspection is an OPTIONAL feature of an AS described in OAuth Introspection [RFC 7662] intended for clients that are unable
     to support structured access tokens including their validation. The use of this call allows an AS to track where and when its clients have indeed
     presented an issued access token. As soon as the RS knows the format of the access token, e.g. using structured token formats such as
     JWT [RFC7519], and is able to validate its security features, the call described in OAuth Introspection [RFC 7662] should be avoided, otherwise
     the AS will know exactly when the introspection call has been made and thus be able to make sure which client has attempted perform an access
     to that RS and at which instant of time. As soon as this call is supported by an AS, the client or the user have no way to prevent the RS to use it.

It might be useful to add it, e.g. using an RFC Errata.

Differences with RFC 7662

RFC 7662 defines a protocol that allows authorized protected resources to query the authorization server to determine
the set of metadata for a given token that was presented to them by an OAuth 2.0 client.

At a first glance, draft-ietf-oauth-jwt-introspection-response-09 seems to be simply a JWT Response for OAuth Token Introspection
instead of a JSON document representing the meta information surrounding the token.

However, this is not the case since major differences can be identified.

RFC 7662 describes an OPTIONAL call able to return a JSON object with the following top-level members: active (REQUIRED), scope (OPTIONAL),
client_id (OPTIONAL), username (OPTIONAL), token_type (OPTIONAL), exp (OPTIONAL), iat (OPTIONAL), nbf (OPTIONAL), sub (OPTIONAL),
aud (OPTIONAL), iss (OPTIONAL), jti (OPTIONAL) and claims from the "JSON Web Token Claims" registry (OPTIONAL).

draft-ietf-oauth-jwt-introspection-response-09 is able to return a JWT as the introspection response. However, the request and the returned information
are not the same.

Section 4 (Requesting a JWT Response) only provides an example and does not describe the mandatory and optional parameters from the request.
Are they identical to those described in RFC 7662 ? No one is able to say.

draft-ietf-oauth-jwt-introspection-response-09 describes a response structure which is different from RFC 7662 where a single top-level member is required,
i.e. active. The text from draft-ietf-oauth-jwt-introspection-response-09 requires three (in fact four) top-level members. The text states:

The JWT MUST include the following top-level claims:

  • iss  MUST be set to the issuer URL of the authorization server.
  • aud  MUST identify the resource server receiving the token introspection response.
  • iat  MUST be set to the time when the introspection response was created by the authorization server.

Note that the text about "active" (i.e. the fourth top-level member) is misplaced in the middle of the token_introspection claim and does not allow
to easily understand that the top-level claim "active" MUST be set to either true or false.

The text states:

       The AS determines based on its RS-specific policy what claims about the resource owner to return in the token introspection response.

Such a sentence (which does not exist in RFC 7662) is a door wide-opened to return claims that are NOT included into the access token.
This protocol should NOT be a protocol that allows authorized RSs to query the AS to obtain metadata that was NOT included into an access token
that was presented to them.

Torsten wrote:

      Token introspection has several advantages over structured access tokens, also when it comes to privacy. If one uses a structured access token
      in conjunction with different services, then this access token needs to contain ALL data required to call ALL these services. This effectively means
      the services learn more data than required. One could try to mitigate this by carrying encrypted compartments in the same token, each of them
      encrypted with for a certain service. That would be complex and is not covered by current technical standards. Introspection, however, allows the AS
      issue a minimal access token (even without any id) and mint specific response for the different RSs.

Instead of attempting to imagine complex mechanisms like "encrypted compartments in the same token", it is much simpler to use different access tokens.
AFAIK, in addition, there is no notion of "services" in OAuth in RFC 6749, but only a notion of "server". A "server" is not a "service".

resource server

      The server hosting the protected resources, capable of accepting
      and responding to protected resource requests using access tokens.

RFC 6750 is using the wording "audience restriction" to restrict the use of a token to "the intended relying party or set of relying parties"
(i.e. to one or more RSs).

So if the access token is targeted to one or more RSs, it should only contain what is necessary to accomplish the call on these RSs.
This means the RS(s) learn(s) exactly the data that it required. If it is not the case, several access tokens should be used.

The principle of "data minimization" implies that an access token should only contain what is necessary to accomplish a call to a given RS.

Since this new call is meant to be OPTIONAL, there should be no difference whether the RS decodes and validates the access token by itself
or sub-contracts the same operations to the AS.

The explanations from Torsten imply that there can be a difference .... which furthermore is left at the full discretion of the AS.

About the secondary use

I wrote:

    This concern is identified in RFC 6973 as:

        5.2.3.  Secondary Use

       Secondary use is the use of collected information about an individual
       without the individual’s consent for a purpose different from that
       for which the information was collected.  Secondary use may violate
       people’s expectations or desires.  The potential for secondary use
       can generate uncertainty as to how one’s information will be used in
       the future, potentially discouraging information exchange in the
       first place.  Secondary use encompasses any use of data, including
       disclosure.

Torsten replied:

      This is no secondary use, it’s the primary use the user consented with.

No "user consent" phase is ever mentioned in order to allow a RS to ask and receive a jwt-introspection-response.

The text states:

      The AS MUST ensure the release of any privacy-sensitive data is legally based.

Such a statement does not make sense in practice. A different legal system applies depending upon three factors:
the location of the client, the location of the AS and the location of the RS.

Unless these three entities are located within the same country (e.g. Switzerland), the same state (e.g. Maryland) or
the same union (e.g. the European Union), the AS will be unable to know how to enforce such a statement.

The release of any privacy-sensitive data must be under the control of the user who must consent to the release
of that privacy-sensitive data. This makes it independent from any legal system.

About the token introspection endpoint

The token introspection endpoint is advertised in RFC 8414 in the following way:

      introspection_endpoint
           OPTIONAL.  URL of the authorization server’s OAuth 2.0 introspection endpoint [RFC7662].

This endpoint is intended to explicitly support RFC 7662, but not anything else. This draft is intended to support a new functionality that is different
from RFC 7662. This means that the AS should not use the same token introspection endpoint. If supported, this new functionality should be supported
using a new endpoint, e.g. an introspection_JWT_endpoint.

When this new functionality is advertised by an AS by the disclosure of an access point, this does not necessarily mean that it is supported for all the RSs
with which that AS has a relationship.

The current situation is that the User and his client have no way to know whether or not this new call will indeed be supported by the AS for a given RS.
Even the RS can't know it directly, since the only way to know it is to use a "trial and error" mechanism.

A proposal on how to solve the issue

Hereafter is one way on how to solve the issue.

The User is the entity that is the best placed to give the User Consent. It would be simpler if the user could ask to the AS to provide to his client
a JWT for a given RS that could be used to issue certificates usable for creating qualified electronic signatures. A specific scope could be defined
for such a purpose which would detail the claims to be incorporated into the access token and say that these claims shall be verified according to
sections 6.2.2 (Initial identity validation) of both ETSI EN 319 411-1 and ETSI EN 319 411-2.

The client supporting the user would then communicate that JWT to the RS of its choice. The scope placed into the access token would testify
that the claims have indeed been verified according to sections 6.2.2 of both ETSI EN 319 411-1 and ETSI EN 319 411-2.

Such a functionality cannot be supported using draft-ietf-oauth-jwt-introspection-response.

In case the RS would be unable to decode the access token and/or to validate it, it might make attempt to make a call to the AS according to RFC 7662,
if this service is available (but the user has no way to indicate that he consents for making such a call).

As a conclusion, since draft-ietf-oauth-jwt-introspection-response harms the user's privacy and fully by-passes the User consent,
this draft should not be progressed to the RFC level.

Denis


The "can" works better, agreed. Thanks!
ᐧ

On Sat, Aug 29, 2020 at 8:25 AM Justin Richer <jricher@mit.edu> wrote:
Thanks, Dick. I agree with removing the excess parenthetical, but I intentionally avoided using a lowercase “may” in the middle of the text  (in favor of “can”) to avoid normative-sounding non-normative language, so I’d recommend that change be kept:

Implementers should be aware that a token introspection request lets the AS know when the client 
    is accessing the RS, which can also indicate when the user is using 
    the client. If this implication is not acceptable, implementers can use other means to carry 
    access token data, e.g. directly transferring the data needed by the RS within the access token.

On Aug 27, 2020, at 12:15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Here is a crisper revision.

Implementers should be aware that a token introspection request lets the AS know when the client
    is accessing the RS, which may indicate when the user is using
    the client. If this implication is not acceptable, implementers can use other means to carry
    access token data, e.g. directly transferring the data needed by the RS within the access token.
ᐧ

On Thu, Aug 27, 2020 at 7:19 AM Justin Richer <jricher@mit.edu> wrote:
I would clarify that this doesn’t necessarily say that the user’s there, and remove the normative requirement (which doesn’t have enforceable teeth in this context):

Implementers should be aware that a token introspection request lets the AS know when the client 
    (and potentially the user) is accessing the RS, which can also indicate when the user is using 
    the client. If this implication is not acceptable, implementers can use other means to carry 
    access token data, e.g. directly transferring the data needed by the RS within the access token.


 — Justin

On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org> wrote:

Will the following text work for you?

Implementers should be aware that a token introspection request lets the AS know when the client
    (and potentially the user) is accessing the RS, which is also an indication of when the user is using
    the client. If this impliction is not accepatable, implementars MUST use other means to carry
    access token data, e.g. directly transferring the data needed by the RS within the access token.


On 26. Aug 2020, at 23:12, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

I agree with Dick’s observation about the privacy implications of using an Introspection Endpoint.  That’s why it’s preferable to not use one at all and instead directly have the Resource understand the Access Token.  One way of doing this is the JWT Access Token spec.  There are plenty of others.

The downsides of using an Introspection Endpoint should be described in the Privacy Considerations section.

                                                      -- Mike

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Dick Hardt
Sent: Wednesday, August 26, 2020 9:52 AM
To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
Cc: last-call@ietf.org; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard



On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org> wrote:
Hi Denis,

On 25. Aug 2020, at 16:55, Denis <denis.ietf@free.fr> wrote:

The fact that the AS will know exactly when the introspection call has been made and thus be able to make sure which client
has attempted perform an access to that RS and at which instant of time. The use of this call allows an AS to track where and when
its clients have indeed presented an issued access token.

That is a fact. I don’t think it is an issue per se. Please explain the privacy implications.

As I see it, the privacy implication is that the AS knows when the client (and potentially the user) is accessing the RS, which is also an indication of when the user is using the client.

I think including this implication would be important to have in a Privacy Considerations section.

/Dick
ᐧ

_______________________________________________
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


--------------964D13DDADA0E9C9AF1A299A-- From nobody Mon Aug 31 01:33:36 2020 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 28FB93A10EB for ; Mon, 31 Aug 2020 01:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 ONP_nN2m5qAl for ; Mon, 31 Aug 2020 01:33:26 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 1DFAA3A10E8 for ; Mon, 31 Aug 2020 01:33:25 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id w13so5035238wrk.5 for ; Mon, 31 Aug 2020 01:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=OtjzWbCLRw76mAOJaRenBGRKRyaTiG6mArf9LNqowbA=; b=gDwIRVz+hgzyzpMJpv2zbHFtWwFgHWebcvXBckQw6nLbv2rrayO6TJOfA9Iyb1evdL 3IDUBftVfiguYkZO5UlihRL2Os19gFKSIFZyC9wHeVjqWsz6PfNiE12eSnkGou42oGle /2Hi/7Z92sQOMsIe6CpH2uAUkLBQrRHVbMZuw= 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=OtjzWbCLRw76mAOJaRenBGRKRyaTiG6mArf9LNqowbA=; b=U5BkDBusFQZOaLhI0Ornh5I/JGtiI0doVEZlu1XspC0nlU+J0efyshL7biHfYg0uel H4lfGDWlBHVzDxsqKCKFenoor/ytQBVjAS2WFx/0/VnOP28C5EqyxDkyO+W4c87UUKoJ tWi7mJVjfZwVzPTFS5uN9XAevDbhP6H4VmEaJIfYSFUiRy9+PWrvTAu/St4jcNSxXmWC knM1hH0FKupXfBAINWUg5yA6/mnbqSp+KDc8DobUTerutlLb9Zc5PKvBMqabiKr2lPN0 jQWqhlhrqo951hlP8MXwmzuc1dzIRzCN5MA0p0yE9Vlvy9hPmWKLZXqXHVbPgJupOZ+M of6Q== X-Gm-Message-State: AOAM531Sg2hBXBMidJvIC4IMLo3AozXLPBBD60ifx4bjsog+P0q3zHoS lF4kLuD89t114qirDhGOZJZCQA== X-Google-Smtp-Source: ABdhPJxMr0rpEZHgjf6/TCa602d9oqr8fZjn7WkP0KAowGhdaVlwrG/nE8ZlRIvwRaCSJqxkg6p3YQ== X-Received: by 2002:adf:f189:: with SMTP id h9mr591031wro.122.1598862804089; Mon, 31 Aug 2020 01:33:24 -0700 (PDT) Received: from [10.0.0.3] (38.227.143.150.dyn.plus.net. [150.143.227.38]) by smtp.gmail.com with ESMTPSA id o2sm11734324wrh.70.2020.08.31.01.33.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Aug 2020 01:33:23 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9DC168A0-83A9-4F74-9DA7-42F6C5DB6718 Content-Transfer-Encoding: 7bit From: Neil Madden Mime-Version: 1.0 (1.0) Date: Mon, 31 Aug 2020 09:33:22 +0100 Message-Id: <32F1225F-1366-46BB-A17C-396854D553FB@forgerock.com> References: Cc: "dick.hardt" , Torsten Lodderstedt , "last-call@ietf.org" , oauth In-Reply-To: To: Mike Jones X-Mailer: iPhone Mail (17G80) Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 31 Aug 2020 08:33:29 -0000 --Apple-Mail-9DC168A0-83A9-4F74-9DA7-42F6C5DB6718 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable But if you want to handle revocation (and you do), then the alternative is s= hort-lived access tokens with frequent refreshing, which also informs the AS= of activity. So is this any better? If an org running an RS decides to use a 3rd-party AS (eg cloud hosted) then= there are privacy implications to that arrangement, regardless of the speci= fic technology used for token validation. > On 26 Aug 2020, at 22:16, Mike Jones wrote: >=20 > =EF=BB=BF > I agree with Dick=E2=80=99s observation about the privacy implications of u= sing an Introspection Endpoint. That=E2=80=99s why it=E2=80=99s preferable t= o not use one at all and instead directly have the Resource understand the A= ccess Token. One way of doing this is the JWT Access Token spec. There are= plenty of others. > =20 > The downsides of using an Introspection Endpoint should be described in th= e Privacy Considerations section. > =20 > -- Mike > =20 > From: OAuth On Behalf Of Dick Hardt > Sent: Wednesday, August 26, 2020 9:52 AM > To: Torsten Lodderstedt > Cc: last-call@ietf.org; oauth > Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Stand= ard > =20 > =20 > =20 > On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt wrote: > Hi Denis, >=20 > > On 25. Aug 2020, at 16:55, Denis wrote: >=20 > > The fact that the AS will know exactly when the introspection call has b= een made and thus be able to make sure which client=20 > > has attempted perform an access to that RS and at which instant of time.= The use of this call allows an AS to track where and when=20 > > its clients have indeed presented an issued access token. >=20 > That is a fact. I don=E2=80=99t think it is an issue per se. Please explai= n the privacy implications. > =20 > As I see it, the privacy implication is that the AS knows when the client (= and potentially the user) is accessing the RS, which is also an indication o= f when the user is using the client. > =20 > I think including this implication would be important to have in a Privacy= Considerations section. > =20 > /Dick > =E1=90=A7 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-9DC168A0-83A9-4F74-9DA7-42F6C5DB6718 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
But if you want to handle r= evocation (and you do), then the alternative is short-lived access tokens wi= th frequent refreshing, which also informs the AS of activity. So is this an= y better?

If an org running= an RS decides to use a 3rd-party AS (eg cloud hosted) then there are privac= y implications to that arrangement, regardless of the specific technology us= ed for token validation.

On 26 Aug 2020, at 22:16, Mike Jones <Michael.Jon= es=3D40microsoft.com@dmarc.ietf.org> wrote:

=EF=BB=BF

I agree with Dick=E2=80= =99s observation about the privacy implications of using an Introspection En= dpoint.  That=E2=80=99s why it=E2=80=99s preferable to not use one at a= ll and instead directly have the Resource understand the Access Token.  One way of doing this is the JWT Access Token spec.  Ther= e are plenty of others.

 

The downsides of using a= n Introspection Endpoint should be described in the Privacy Considerations s= ection.

 

    = ;            &nb= sp;            &= nbsp;            = ;             --= Mike

 

From: OAuth <oauth-bounces@ietf.org> = On Behalf Of Dick Hardt
Sent: Wednesday, August 26, 2020 9:52 AM
To: Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.or= g>
Cc: last-call@ietf.org; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspec= tion-response-09.txt> (JWT Response for OAuth Token Introspection) to Pro= posed Standard

 

 

 

On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt &= lt;torsten=3D40lodderst= edt.net@dmarc.ietf.org> wrote:

Hi Denis,

> On 25. Aug 2020, at 16:55, Denis <denis.ietf@free.fr> wrote:

> The fact that the AS will know exactly when the introspection call has b= een made and thus be able to make sure which client
> has attempted perform an access to that RS and at which instant of time= . The use of this call allows an AS to track where and when
> its clients have indeed presented an issued access token.

That is a fact. I don=E2=80=99t think it is an issue per se. Please explain t= he privacy implications.

 

As I see it, the privacy implication is that the AS k= nows when the client (and potentially the user) is accessing the RS, which is= also an indication of when the user is using the client.

 

I think including this implication would be important= to have in a Privacy Considerations section.

 

/Dick

=E1=90=A7

_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
= --Apple-Mail-9DC168A0-83A9-4F74-9DA7-42F6C5DB6718-- From nobody Mon Aug 31 08:40:24 2020 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 1E1C43A15FC for ; Mon, 31 Aug 2020 08:40:22 -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_FONT_LOW_CONTRAST=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=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 sTdl5WGFdk9B for ; Mon, 31 Aug 2020 08:40:19 -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 A20BB3A15F6 for ; Mon, 31 Aug 2020 08:40:18 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id c15so3768510lfi.3 for ; Mon, 31 Aug 2020 08:40:18 -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=3pz3e9hlSRQaI4l82X6D0aAQvqVzxbfHOZFwayUGD4s=; b=So7rxjnqn/ywP/oeEvn9rJIQaM67qlbK6GGcNpW7UrMxMlHVPVeRLcz054n54GUws8 Mv2h2uCLpcxmNogL6E01lbMqhvDUpQ9OKDbIMCFd2i8H/NrnsQy01kbhnTlDfWPyBsPZ 8wa3x6bi7uToOw1WYlIKR4LHSiUjyPmA1scoibcu73E4C7OMXS7WNzlLm32fNyijT9UB Pv61x5oS/KJOKado2Uj4HgF950VTny7zrTEt0EsPMjLHCn4Qm2jKTOiFQC+efSgu31W0 /hVcjJeQ0g/4qjdEt9XquGIhp7LqqES22nLTBPpVxnuufCm68X8p53ScNygMXQx2Sh+Q /6Lw== 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=3pz3e9hlSRQaI4l82X6D0aAQvqVzxbfHOZFwayUGD4s=; b=nADdvQF7WjGKq/RoexBP4H0ntzm1G9sI16IjeEpq/66m5nSUx2xZi6qmfpcrJZwPY2 i2sSrQat4thM35Tg0sGMCUdpDjXRtbocGO/FpzxFyPGkNSsG3//7e4MyK0Ju79WuVw8G aSxhI78QoOjWshFf1LDc0AQkE/6WPZbfSYx4n7XGwIT6I6pXKHy4lpT5IYS5Us4zZ7ko G3GhlVFS8Sepxse2tUm4VMND02YShimwovW1AlbieO9PZvaIkuShIHJBGfQjE1GzXeTB uQ8pxYn7+BWc+7RSwS/RQ43D/ZHmWEovJMEyfy2wM3aiWdfEOk2AALWoTXnoOD+xpLJj 5Mbw== X-Gm-Message-State: AOAM530IP3FSqgrO01bQlA+GyG8wfRh5FDqZfGHYq1/8aKZ1UoV1Dmi5 cH5OrDk/Ok6DDSr5jXWok/XofvVim0O63D3LxjDhaxOAIjikBw/YEEHKPcum32Ge46Oei522vHg 6bVSdbGYA722sZg== X-Google-Smtp-Source: ABdhPJxEW5nDlP0u+1uS96Be9NI1LIdCW1Qbur8/dlGYnZOwc9HKsfsSQ78NSvi54Vm0FXDVsSF+ztK/cwoOXFNLSL4= X-Received: by 2002:a19:418a:: with SMTP id o132mr982560lfa.63.1598888416653; Mon, 31 Aug 2020 08:40:16 -0700 (PDT) MIME-Version: 1.0 References: <7C0FD285-F677-4501-B2FB-9431A59855F6@mit.edu> <102C6B96-C1FA-4BC1-8932-C7F4F377CFFE@lodderstedt.net> In-Reply-To: From: Brian Campbell Date: Mon, 31 Aug 2020 09:39:50 -0600 Message-ID: To: Dick Hardt Cc: Torsten Lodderstedt , Justin Richer , oauth Content-Type: multipart/alternative; boundary="0000000000001c518a05ae2e3886" Archived-At: Subject: Re: [OAUTH-WG] WGLC Review of PAR 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, 31 Aug 2020 15:40:22 -0000 --0000000000001c518a05ae2e3886 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not sure how to word it exactly but I think Dick has landed on what we ultimately want this to say. Basically that the "request_uri" is intended to be used only once, the client MUST not use it more than once, and that the AS should also treat it as one-time use but may make reasonable accommodations to more gracefully handle redundant authorization requests due to browser reload or similar. On Sun, Aug 30, 2020 at 4:48 PM Dick Hardt wrote: > I don't have the context of the text to respond to the exact wording, but > I think we can state that the client MUST use the "request_uri" only once= , > and then explain that the AS may receive duplicate requests if the browse= r > is reloaded. > > > On Sat, Aug 29, 2020 at 4:24 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> You are making a good point here. The reason we added the one time use >> constraint was the fact the client will include parameters supposed to b= e >> used only once, e.g. the PKCE code_challenge. For a traditional >> authorisation request, we would recommend the client to use a per >> transaction (=3D=3D one time use) code_challenge, but PKCE does not requ= ire the >> AS to enforce it. Mapping this to PAR means, we SHOULD recommend the cli= ent >> to use the request_uri only once but not require the AS to enforce it. >> >> Would the following text work for you? >> >> Since parts of the request content, e.g. the "code_challenge" >> parameter value, is unique to a certain authorization request, >> the client SHOULD use the "request_uri" only once. >> >> I also would move this text to section 4. >> >> > On 27. Aug 2020, at 18:11, Dick Hardt wrote: >> > >> > That is not correct. >> > >> > The authorization code one-time-use is directly between the client and >> the AS. The client has a number of mechanisms to ensure it only presents >> the authorization code to the AS once, such as a session that was set wh= en >> the user started at the client. >> > >> > In contrast, in a redirect from the client to the AS, the client loses >> control on how many times the user-agent loads the URL at the AS. >> Additionally, there is unlikely to be an active browser session at the A= S, >> so the AS can not easily differentiate between a URL load from the same >> user, or different users. If one-time-use, one of them MUST fail. If the >> two requests happen to be from the same user (because of a reload, which >> the user did because the AS was slow to respond), there is no way for th= e >> AS to know which of the requests is the one that is current in front of = the >> user. While the AS can internally ensure processing of the request once, >> one-time-use would dictate that it provides a failure message to one of = the >> requests. >> > >> > /Dick >> > >> > >> > =E1=90=A7 >> > >> > On Thu, Aug 27, 2020 at 7:17 AM Justin Richer wrote: >> > We already have this same property with authorization codes, and it=E2= =80=99s >> managed today reasonably well (in my opinion). If you submit the same >> request URI twice in the same browser (the refresh you=E2=80=99re talkin= g about), >> it shouldn=E2=80=99t start two separate authorization requests, but it w= ould be >> reasonable to detect that the same session attached to the same request = URI >> value showed up twice and continue the session as appropriate. >> > >> > None of this is in conflict with =E2=80=9Cone time use=E2=80=9D, in my= view, since >> you=E2=80=99re actively detecting the session and source of the value. >> > >> > =E2=80=94 Justin >> > >> >> On Aug 26, 2020, at 6:16 PM, Dick Hardt wrote: >> >> >> >> I think one-time use may be overly restrictive, and I don't think it >> is the property that we actually want. >> >> >> >> Give the request URI is in a redirect from the browser, there is a >> good chance of a race condition where the same browser request is made m= ore >> than once, for example, while the browser is loading the authorization U= RL >> at the AS, the user could refresh the page causing the authorization URL= to >> be reloaded. Would the reload count as a second use? One could argue it >> either way. >> >> >> >> What I think we want from what I understand, is the request URI MUST >> be unique so that there is no confusion on which request is being >> referenced. >> >> >> >> I did not see anything about the expiry time of the request URI (but = I >> did not look super hard). If that is not there, then I think the request >> URI MUST expire in a "short" period of time. >> >> >> >> >> >> >> >> =E1=90=A7 >> >> >> >> On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote: >> >> Thanks Justin. Just a couple more responses to responses inline below >> (but with lots of content that needs no further discussion removed). >> >> >> >> A TL;DR for the WG is that I'd like to get some wider feedback on the >> question of changing the one-time-use condition on the request_uri from = a >> SHOULD to a MUST. >> >> >> >> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer wrote= : >> >> Hi Brian, just a couple responses inline where it seemed fitting. >> Thanks for going through everything! >> >> =E2=80=94 Justin >> >> >> >>> On Aug 25, 2020, at 6:01 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> >> >>> Thanks for the review and comments Justin. Replies (or attempts >> thereat) are inline below. >> >>> >> >>> >> >>> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer >> wrote: >> >>> I=E2=80=99ve done a full read through of the PAR specification, and = here are >> my notes on it. >> >>> >> >>> >> >>> =C2=B62: Of necessity, this spec mixes parameters in the authori= zation >> endpoint and token endpoint registries into a single request. Is there a= ny >> danger of conflict between them? The registry holds them in one list but >> they could possibly have different semantics in both places.. >> >>> >> >>> I think that technically such danger does exist but that it's highly >> unlikely in practice. Especially because the only token endpoint paramet= ers >> that are relevant to PAR are those that deal with client authentication >> (currently client_secret, client_assertion, and client_assertion_type). = I'm >> also not sure what can reasonably be done about it given the way the >> registries are. I guess PAR could update the registration for those thre= e >> (client_secret, client_assertion, and client_assertion_type) to also >> indicate authorization request as a usage location with some commentary >> that it's only for avoiding name collisions. And offer some guidance abo= ut >> doing the same for any future client auth methods being defined. But >> honestly I'm not sure what, if anything, to do here? >> >>> >> >>> And yes it is super unfortunate that client auth and protocol >> parameters got mixed together in the HTTP body. I didn't cause that >> situation but I've certainly contributed to it and for that I apologize. >> >> >> >> I think the only perfect solution is to go back in time and fix the >> registries with based on the last decade of knowledge in using them. :P >> >> >> >> For this, I think maybe being very prescriptive about the fact that >> the only parameters from the token endpoint that are allowed here are th= ose >> used for client authentication and that when they show up, they=E2=80=99= re >> interpreted as in the token endpoint request not the authorization endpo= int >> request. Does that work? >> >> >> >> I think so, yes.. And will work on incorporating some text towards >> that end. >> >> >> >> >> >> >> >>> I don=E2=80=99t see why a request URI with unguessable values is= n=E2=80=99t a >> MUST for one-time-use, is there a reason? >> >>> >> >>> The reason AFAIK was to not be overly prescriptive and allow for >> eventually consistent or not atomic storage of the data by not strictly >> requiring the AS to enforce one-time-use. Do you think that's too loose = or >> could be worded/explained differently or better? >> >> >> >> I do think it=E2=80=99s too loose and it should be a MUST, and the me= thods for >> enforcing that =E2=80=9CMUST=E2=80=9D are going to vary based on the dep= loyments and >> implementations out there. >> >> >> >> >> >> I'd be okay with making it a MUST but think maybe it'd be good to hea= r >> from a few more people in the WG before committing to that change. >> >> >> >> Can I ask some folks to weigh in on this one? I'm leaning towards >> making the change barring objections. >> >> >> >> >> >> 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 f= ile >> attachments from your computer. Thank >> you._______________________________________________ >> >> 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 >> >> =E1=90=A7 > --=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._ --0000000000001c518a05ae2e3886 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not sure how to word it exactly but I think Dick h= as landed on what we ultimately want this to say. Basically that the "= request_uri" is intended to be used only once, the client MUST not use= it more than once, and that the AS should also treat it as one-time use bu= t may make reasonable accommodations to more gracefully handle redundant au= thorization requests due to browser reload or similar.

On Sun, Aug 30, = 2020 at 4:48 PM Dick Hardt <dick.hardt@gmail.com> wrote:
I don't have th= e context of the text to respond to the exact wording, but I think we can s= tate that the client MUST use the "request_uri" only once, and th= en explain that the AS may receive duplicate requests if the browser is rel= oaded.


On Sat, Aug 29, 2020 at 4:24 AM Torsten Lo= dderstedt <= torsten@lodderstedt.net> wrote:
You are making a good point here. The reason we adde= d the one time use constraint was the fact the client will include paramete= rs supposed to be used only once, e.g. the PKCE code_challenge. For a tradi= tional authorisation request, we would recommend the client to use a per tr= ansaction (=3D=3D one time use) code_challenge, but PKCE does not require t= he AS to enforce it. Mapping this to PAR means, we SHOULD recommend the cli= ent to use the request_uri only once but not require the AS to enforce it. =

Would the following text work for you?

Since parts of the request content, e.g. the "code_challenge"
=C2=A0 =C2=A0parameter value, is unique to a certain authorization request,=
the client SHOULD use the "request_uri" only once.

I also would move this text to section 4.

> On 27. Aug 2020, at 18:11, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> That is not correct.
>
> The authorization code one-time-use is directly between the client and= the AS. The client has a number of mechanisms to ensure it only presents t= he authorization code to the AS once, such as a session that was set when t= he user started at the client.
>
> In contrast, in a redirect from the client to the AS, the client loses= control on how many times the user-agent loads the URL at the AS. Addition= ally, there is unlikely to be an active browser session at the AS, so the A= S can not easily differentiate between a URL load from the same user, or di= fferent users. If one-time-use, one of them MUST fail. If the two requests = happen to be from the same user (because of a reload, which the user did be= cause the AS was slow to respond), there is no way for the AS to know which= of the requests is the one that is current in front of the user. While the= AS can internally ensure processing of the request once, one-time-use woul= d dictate that it provides a failure message to one of the requests.
>
> /Dick
>
>
> =E1=90=A7
>
> On Thu, Aug 27, 2020 at 7:17 AM Justin Richer <jricher@mit.edu> wrote:
> We already have this same property with authorization codes, and it=E2= =80=99s managed today reasonably well (in my opinion). If you submit the sa= me request URI twice in the same browser (the refresh you=E2=80=99re talkin= g about), it shouldn=E2=80=99t start two separate authorization requests, b= ut it would be reasonable to detect that the same session attached to the s= ame request URI value showed up twice and continue the session as appropria= te.
>
> None of this is in conflict with =E2=80=9Cone time use=E2=80=9D, in my= view, since you=E2=80=99re actively detecting the session and source of th= e value.
>
>=C2=A0 =E2=80=94 Justin
>
>> On Aug 26, 2020, at 6:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>
>> I think one-time use may be overly restrictive, and I don't th= ink it is the property that we actually want.
>>
>> Give the request URI is in a redirect from the browser, there is a= good chance of a race condition where the same browser request is made mor= e than once, for example, while the browser is loading the authorization UR= L at the AS, the user could refresh the page causing the authorization URL = to be reloaded. Would the reload count as a second use? One could argue it = either way.
>>
>> What I think we want from what I understand, is the request URI MU= ST be unique so that there is no confusion on which request is being refere= nced.
>>
>> I did not see anything about the expiry time of the request URI (b= ut I did not look super hard). If that is not there, then I think the reque= st URI MUST expire in a "short" period of time.
>>
>>
>>
>> =E1=90=A7
>>
>> On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell <bcampbell=3D40pingi= dentity.com@dmarc.ietf.org> wrote:
>> Thanks Justin. Just a couple more responses to responses inline be= low (but with lots of content that needs no further discussion removed). >>
>> A TL;DR for the WG is that I'd like to get some wider feedback= on the question of changing the one-time-use condition on the request_uri = from a SHOULD to a MUST.
>>
>> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer <jricher@mit.edu> wrote:
>> Hi Brian, just a couple responses inline where it seemed fitting. = Thanks for going through everything!
>>=C2=A0 =E2=80=94 Justin
>>
>>> On Aug 25, 2020, at 6:01 PM, Brian Campbell <bcampbell@pingidentity.co= m> wrote:
>>>
>>> Thanks for the review and comments Justin. Replies (or attempt= s thereat) are inline below.
>>>
>>>
>>> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer <jricher@mit.edu> wrote:
>>> I=E2=80=99ve done a full read through of the PAR specification= , and here are my notes on it.
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0=C2=B62: Of necessity, this spec mixes para= meters in the authorization endpoint and token endpoint registries into a s= ingle request. Is there any danger of conflict between them? The registry h= olds them in one list but they could possibly have different semantics in b= oth places..
>>>
>>> I think that technically such danger does exist but that it= 9;s highly unlikely in practice. Especially because the only token endpoint= parameters that are relevant to PAR are those that deal with client authen= tication (currently client_secret, client_assertion, and client_assertion_t= ype). I'm also not sure what can reasonably be done about it given the = way the registries are. I guess PAR could update the registration for those= three (client_secret, client_assertion, and client_assertion_type) to also= indicate authorization request as a usage location with some commentary th= at it's only for avoiding name collisions. And offer some guidance abou= t doing the same for any future client auth methods being defined. But hone= stly I'm not sure what, if anything, to do here?=C2=A0
>>>
>>> And yes it is super unfortunate that client auth and protocol = parameters got mixed together in the HTTP body. I didn't cause that sit= uation but I've certainly contributed to it and for that I apologize. <= br> >>
>> I think the only perfect solution is to go back in time and fix th= e registries with based on the last decade of knowledge in using them. :P <= br> >>
>> For this, I think maybe being very prescriptive about the fact tha= t the only parameters from the token endpoint that are allowed here are tho= se used for client authentication and that when they show up, they=E2=80=99= re interpreted as in the token endpoint request not the authorization endpo= int request. Does that work?
>>
>> I think so, yes.. And will work on incorporating some text towards= that end.
>>
>>
>>=C2=A0
>>>=C2=A0 =C2=A0 =C2=A0I don=E2=80=99t see why a request URI with = unguessable values isn=E2=80=99t a MUST for one-time-use, is there a reason= ?
>>>
>>> The reason AFAIK was to not be overly prescriptive and allow f= or eventually consistent or not atomic storage of the data by not strictly = requiring the AS to enforce one-time-use. Do you think that's too loose= or could be worded/explained differently or better?
>>
>> I do think it=E2=80=99s too loose and it should be a MUST, and the= methods for enforcing that =E2=80=9CMUST=E2=80=9D are going to vary based = on the deployments and implementations out there.
>>
>>
>> I'd be okay with making it a MUST but think maybe it'd be = good to hear from a few more people in the WG before committing to that cha= nge.
>>
>> Can I ask some folks to weigh in on this one? I'm leaning towa= rds making the change barring objections.
>>
>>
>> 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...=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 attachments from= your computer. Thank you._______________________________________________ >> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

3D""=E1=90=A7

<= 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. --0000000000001c518a05ae2e3886-- From nobody Mon Aug 31 10:41:07 2020 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 BDFE23A17CE for ; Mon, 31 Aug 2020 10:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 s3yjyR3O3tY9 for ; Mon, 31 Aug 2020 10:41:02 -0700 (PDT) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 A89783A17C5 for ; Mon, 31 Aug 2020 10:41:02 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id s92so872951ybi.2 for ; Mon, 31 Aug 2020 10:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NNfcVKp4jtUoXfEireLlUBKqqCTsTpAXWT+jC6ab1/U=; b=k6FShN6yw6wncTdFMiebaGSEBMqugrBdzB/9Lvw8ElgjbPP/E7MsThkHFEMKkHIcZE LlVdKel2FQmSggC56vCyF+hG8kuHrW3ElfKS5j6B+8yhqsMtltPplZ8eRqcOrV/vv5Qa q+uHBJl5+FIGSRMl4TKzA/qcyPMMqoZRXH/mr9rY80CcvOoLUKpuqh14kJb2Bjh+HpN/ x9SEpfafeshsu6qgmVjY1SXjYjCiLMDAZ3V+Ty8NRIVCJx9BiYRx8LkXBnZ/JtJN0ZtX myJ8YiNb/FZ88jcAPgmaewDWn/aU+6kY0/LwP7wEdGjpex3Ndj+czRO+SMGpAwNGBGGN hKvw== 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=NNfcVKp4jtUoXfEireLlUBKqqCTsTpAXWT+jC6ab1/U=; b=GgwtaKGPNUkp+MDfQbRqoz99e/hpfEka92uXQ7Lu/kiSzCaCh/8IvHukzEARhZW1lw A19NXhnFGtS382btQKkF3QlFhpESlb8zZO8N0OttfnD/KsduXmT+4bD7FQ7sqPB9JgaJ vXvqLN51SWFbeYFseboAAUNFAl0CMaShM8xFct2E+CIVP40j+lN8dsRBVw8WlRuLgGgM gNid692dU+1gBY8AO+XiPrdrUiCGsQvuNPKmrABWpXrZk5D03PHWk0yuDMUsnR4nzR58 sZBvg1qOClOPoBd7tghSfyvEsZgtIclmnPdjdc2s1XxlUWaiSbQixObjMJfUuKw0ZzIx bwLA== X-Gm-Message-State: AOAM530eHiM3rvfh6IQRKCZbvK3PnADJ+bjDdgvY5RBc7jVlAW9BHzp7 00g0BQ3XYWGXynyxeQH01FNAT5OK5MeVS2MuNpHFEeR33lwAbw== X-Google-Smtp-Source: ABdhPJwO6jbiizM/iAv1b44O9agHbe/WyHnf15jB5WkhTrziUWBlI47jVWGXEPjc6jhrPpVgfhFBAcrk0zVxZIGyt2Q= X-Received: by 2002:a25:a441:: with SMTP id f59mr3820660ybi.42.1598895661516; Mon, 31 Aug 2020 10:41:01 -0700 (PDT) MIME-Version: 1.0 References: <32F1225F-1366-46BB-A17C-396854D553FB@forgerock.com> In-Reply-To: <32F1225F-1366-46BB-A17C-396854D553FB@forgerock.com> From: Jeff Craig Date: Mon, 31 Aug 2020 12:40:50 -0500 Message-ID: To: Neil Madden Cc: Mike Jones , "last-call@ietf.org" , oauth , Torsten Lodderstedt Content-Type: multipart/alternative; boundary="000000000000f095b405ae2fe7ba" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 31 Aug 2020 17:41:07 -0000 --000000000000f095b405ae2fe7ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think that the argument is that token refreshing isn't as strong a signal about usage patterns as introspection calls would be, which I agree with. I also think that if a RS knows it's using an external AS, they've generally accepted this information leakage. This is not to say it's not worth mentioning in the document, but rather that I doubt it will significantly move implementations one way or the other. Generally speaking, I don't like JWTs as Access Tokens. They're verbose, they leak information to clients that clients don't need, and if the RS makes a mistake in their JWT validation, they can create security vulnerabilities. That said, I do think they are preferable to Introspection at request time, and the RS's that I've worked with generally don't want the overhead of Introspection on every usage of the token. I generally argue a shared secret between the RS and the AS is a better solution, but in my experience most cloud-hosted ASes don't offer that option. For this cloud AS situation, I have been tracking draft-ietf-oauth-token-exchange-19 as a means for RSes to setup a Token Endpoint to convert the AS access token into a access token (w/o Refresh) that the RS can accept, thus limiting Introspection to the Refresh flow, but I don't currently have a RS interested in trying to try this flow, but I think that it's a reasonable approach to limiting introspection on every request to the RS, though it does add an additional point of failure during the Token Refresh. This has the same leakage problem that is under discussion here, obviously. On Mon, Aug 31, 2020 at 3:34 AM Neil Madden wrote: > But if you want to handle revocation (and you do), then the alternative i= s > short-lived access tokens with frequent refreshing, which also informs th= e > AS of activity. So is this any better? > > If an org running an RS decides to use a 3rd-party AS (eg cloud hosted) > then there are privacy implications to that arrangement, regardless of th= e > specific technology used for token validation. > > On 26 Aug 2020, at 22:16, Mike Jones 40microsoft.com@dmarc.ietf.org> wrote: > > =EF=BB=BF > > I agree with Dick=E2=80=99s observation about the privacy implications of= using an > Introspection Endpoint. That=E2=80=99s why it=E2=80=99s preferable to no= t use one at all > and instead directly have the Resource understand the Access Token. One > way of doing this is the JWT Access Token spec. There are plenty of othe= rs. > > > > The downsides of using an Introspection Endpoint should be described in > the Privacy Considerations section. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of * Dick Hardt > *Sent:* Wednesday, August 26, 2020 9:52 AM > *To:* Torsten Lodderstedt > *Cc:* last-call@ietf.org; oauth > *Subject:* Re: [OAUTH-WG] Last Call: > (JWT Response for > OAuth Token Introspection) to Proposed Standard > > > > > > > > On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt 40lodderstedt.net@dmarc.ietf.org <40lodderstedt.net@dmarc.ietf..org>> > wrote: > > Hi Denis, > > > On 25. Aug 2020, at 16:55, Denis > wrote: > > > The fact that the AS will know exactly when the introspection call has > been made and thus be able to make sure which client > > has attempted perform an access to that RS and at which instant of time= . > The use of this call allows an AS to track where and when > > its clients have indeed presented an issued access token. > > That is a fact. I don=E2=80=99t think it is an issue per se. Please expla= in the > privacy implications. > > > > As I see it, the privacy implication is that the AS knows * when* the > client (and potentially the user) is accessing the RS, which is also an > indication of *when* the user is using the client. > > > > I think including this implication would be important to have in a Privac= y > Considerations section. > > > > /Dick > > =E1=90=A7 > _______________________________________________ > 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 > --000000000000f095b405ae2fe7ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think=C2=A0that the argument=C2=A0is that token refreshi= ng isn't as strong a signal about usage patterns as introspection calls= would be, which I agree with. I also think that if a RS knows it's usi= ng an external AS, they've generally accepted this information leakage.= This is not to say it's not worth mentioning in the document, but rath= er that I doubt it will significantly move implementations one way or the o= ther.

Generally speaking, I don't like JWTs as Acces= s Tokens. They're verbose, they leak information to clients that client= s don't need, and if the RS makes a mistake in their JWT validation, th= ey can create security vulnerabilities.=C2=A0 That said, I do think they ar= e preferable to Introspection at request time, and the RS's that I'= ve worked with generally don't want the overhead of Introspection on ev= ery usage of the token. I generally argue a shared secret between the RS an= d the AS is a better solution, but in my experience most cloud-hosted ASes = don't offer that option.

For this cloud AS sit= uation, I have been tracking=C2=A0draft-ietf-oauth-token-exchange-19 as a m= eans for RSes to setup a Token Endpoint to convert the AS access token into= a access token (w/o Refresh) that the RS can accept, thus limiting Introsp= ection to the Refresh flow, but I don't currently have a RS interested = in trying to try this flow, but I think that it's a reasonable approach= to limiting introspection on every request to the RS, though it does add a= n additional point of failure during the Token Refresh. This has the same l= eakage problem that is under discussion here, obviously.

On Mon, Aug 3= 1, 2020 at 3:34 AM Neil Madden <neil.madden@forgerock.com> wrote:
But if you= want to handle revocation (and you do), then the alternative is short-live= d access tokens with frequent refreshing, which also informs the AS of acti= vity. So is this any better?

If an org running an RS decides to use a 3rd-party AS (eg cloud hosted) = then there are privacy implications to that arrangement, regardless of the = specific technology used for token validation.

On 26 Aug 2020, at 22:16, Mi= ke Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

=
=EF=BB=BF

I agree with Dick= =E2=80=99s observation about the privacy implications of using an Introspec= tion Endpoint.=C2=A0 That=E2=80=99s why it=E2=80=99s preferable to not use = one at all and instead directly have the Resource understand the Access Token.=C2=A0 One way of doing this is the JWT Access Token spec.=C2=A0 The= re are plenty of others.

=C2=A0<= /u>

The downsides of = using an Introspection Endpoint should be described in the Privacy Consider= ations section.

=C2=A0<= /u>

=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=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=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 -- Mike

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Dick Hardt
Sent: Wednesday, August 26, 2020 9:52 AM
To: Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>
Cc: last-cal= l@ietf.org; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspe= ction-response-09.txt> (JWT Response for OAuth Token Introspection) to P= roposed Standard

=C2=A0

=C2=A0

=C2=A0

On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt = <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:

Hi Denis,

> On 25. Aug 2020, at 16:55, Denis <denis.ietf@free.fr> wrote:

> The fact that the AS will know exactly when the introspection call has= been made and thus be able to make sure which client
> has attempted perform an access to that RS and at which instant of tim= e. The use of this call allows an AS to track where and when
> its clients have indeed presented an issued access token.

That is a fact. I don=E2=80=99t think it is an issue per se. Please explain= the privacy implications.

=C2=A0

As I see it, the privacy implication is that the AS = knows when the client (and potentially the user) is accessing the RS, which i= s also an indication of when the user is using the client.

=C2=A0

I think including this implication would be importan= t to have in a Privacy Considerations section.

=C2=A0

/Dick

=E1=90=A7

_______________________________________________
OAuth= mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth
__________________________= _____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000f095b405ae2fe7ba-- From nobody Mon Aug 31 11:10:06 2020 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 1943C3A1856; Mon, 31 Aug 2020 11:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TfYe65hgpFts; Mon, 31 Aug 2020 11:09:58 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 DB3A23A1854; Mon, 31 Aug 2020 11:09:57 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id r13so7828902ljm.0; Mon, 31 Aug 2020 11:09:57 -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=xtv7KVXgy6jUQPItqnTjxD11ia9j/qko559pgKd15g0=; b=d0nS8ngTQcC3eLz6Nd/5MCwonbdEsZxxSdAn3vDdqVIxFFKJceilK5uKJbMPkTh6e7 mRgRKjXfEEmOeJWUwqINwGtz2yQFUJpPIkYhKCfEmwZWXGMjipjW3aFOwxIfRD/GOAVt OOEHNUKPyk2SusJAA04bLEICN5iqRNMViCmk4w9j3cNS51U4mvSlGmMt2rHy0p28GJLV uVv33tv172A084+YhcY9vXbyWxl7mHaqbcZr0cv0Ww67RppJVSx5+d20cJcbfYn16ZUN 9+7E5mjD4y5kC/zj/0db0ZRK8Ha1hdXHD1Sqc6JiElCGxpfxt7L9yGszsqAEyD8Lbnv0 BJmg== 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=xtv7KVXgy6jUQPItqnTjxD11ia9j/qko559pgKd15g0=; b=T1p4+KLVvbi8KhLB+S0G+vjvvWoYGiNpfO2nlFSal3YH1qr5YQLpQN+kJOfJLACjZP 6awrciZGBRvHBfV5HziHpJe1ChvpBYuHa2x/dko5LPcuoJTPBZTGARUYqd6A5HEXuq5l 61s9kQLhAKrc+rDJCuplSJXX7Nv5YUOL666aE9YKwwCBGPfU2EbfwUgeLoHiAbuhKjYL EkBG6fquaueYTqx90dOub166X/A6unp8HY1PAcXcZDOppg/RZuguHQ5Qx87XmzQQZKsC xxFGXiMhBuQfvKceLk71EQ4KTL9et6aLvGS4ecdtsrvJPUZ0+wNbeSBmYLjNCzvVREdn 410A== X-Gm-Message-State: AOAM531DKQKYyONccs9VSwfmEfKWvdQRGZmmOs1mMvB+Ya03OJ18N5VT iMuOmGA6xmlrNRsKqb4Vo3ygSUA8BIi03HWv+SE= X-Google-Smtp-Source: ABdhPJxZqj+6u793law+fb45r14pzUHb2dvphrJ7//xZkeJ74yLtf7e1tnQ9iMJ3o7DrAHCOgLVTSL4wF7sEEDn81cY= X-Received: by 2002:a2e:81d7:: with SMTP id s23mr1226904ljg.69.1598897395646; Mon, 31 Aug 2020 11:09:55 -0700 (PDT) MIME-Version: 1.0 References: <32F1225F-1366-46BB-A17C-396854D553FB@forgerock.com> In-Reply-To: From: Dick Hardt Date: Mon, 31 Aug 2020 11:09:19 -0700 Message-ID: To: Jeff Craig Cc: Neil Madden , "last-call@ietf.org" , Mike Jones , Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="0000000000004cc45405ae304ffd" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 31 Aug 2020 18:10:00 -0000 --0000000000004cc45405ae304ffd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Another approach to address the privacy implications of a token refresh is a client can obfuscate usage by the user by doing regular token refreshes independent of user activity. =E1=90=A7 On Mon, Aug 31, 2020 at 10:41 AM Jeff Craig wrote: > I think that the argument is that token refreshing isn't as strong a > signal about usage patterns as introspection calls would be, which I agre= e > with. I also think that if a RS knows it's using an external AS, they've > generally accepted this information leakage. This is not to say it's not > worth mentioning in the document, but rather that I doubt it will > significantly move implementations one way or the other. > > Generally speaking, I don't like JWTs as Access Tokens. They're verbose, > they leak information to clients that clients don't need, and if the RS > makes a mistake in their JWT validation, they can create security > vulnerabilities. That said, I do think they are preferable to > Introspection at request time, and the RS's that I've worked with general= ly > don't want the overhead of Introspection on every usage of the token. I > generally argue a shared secret between the RS and the AS is a better > solution, but in my experience most cloud-hosted ASes don't offer that > option. > > For this cloud AS situation, I have been > tracking draft-ietf-oauth-token-exchange-19 as a means for RSes to setup = a > Token Endpoint to convert the AS access token into a access token (w/o > Refresh) that the RS can accept, thus limiting Introspection to the Refre= sh > flow, but I don't currently have a RS interested in trying to try this > flow, but I think that it's a reasonable approach to limiting introspecti= on > on every request to the RS, though it does add an additional point of > failure during the Token Refresh. This has the same leakage problem that = is > under discussion here, obviously. > > On Mon, Aug 31, 2020 at 3:34 AM Neil Madden > wrote: > >> But if you want to handle revocation (and you do), then the alternative >> is short-lived access tokens with frequent refreshing, which also inform= s >> the AS of activity. So is this any better? >> >> If an org running an RS decides to use a 3rd-party AS (eg cloud hosted) >> then there are privacy implications to that arrangement, regardless of t= he >> specific technology used for token validation. >> >> On 26 Aug 2020, at 22:16, Mike Jones > 40microsoft.com@dmarc.ietf.org> wrote: >> >> =EF=BB=BF >> >> I agree with Dick=E2=80=99s observation about the privacy implications o= f using >> an Introspection Endpoint. That=E2=80=99s why it=E2=80=99s preferable t= o not use one at >> all and instead directly have the Resource understand the Access Token. >> One way of doing this is the JWT Access Token spec. There are plenty of >> others. >> >> >> >> The downsides of using an Introspection Endpoint should be described in >> the Privacy Considerations section. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of * Dick Hardt >> *Sent:* Wednesday, August 26, 2020 9:52 AM >> *To:* Torsten Lodderstedt >> *Cc:* last-call@ietf.org; oauth >> *Subject:* Re: [OAUTH-WG] Last Call: >> (JWT Response for >> OAuth Token Introspection) to Proposed Standard >> >> >> >> >> >> >> >> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt > 40lodderstedt.net@dmarc.ietf.org <40lodderstedt.net@dmarc.ietf..org>> >> wrote: >> >> Hi Denis, >> >> > On 25. Aug 2020, at 16:55, Denis > > wrote: >> >> > The fact that the AS will know exactly when the introspection call has >> been made and thus be able to make sure which client >> > has attempted perform an access to that RS and at which instant of >> time. The use of this call allows an AS to track where and when >> > its clients have indeed presented an issued access token. >> >> That is a fact. I don=E2=80=99t think it is an issue per se. Please expl= ain the >> privacy implications. >> >> >> >> As I see it, the privacy implication is that the AS knows * when* the >> client (and potentially the user) is accessing the RS, which is also an >> indication of *when* the user is using the client. >> >> >> >> I think including this implication would be important to have in a >> Privacy Considerations section. >> >> >> >> /Dick >> >> =E1=90=A7 >> _______________________________________________ >> 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 >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000004cc45405ae304ffd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Another approach to address the privacy=C2=A0implications = of a token refresh is=C2=A0a client can obfuscate usage by the user by doin= g regular token refreshes independent of user activity.=C2=A0

3D"==E1=90=A7

On Mon, Aug 31, 2020 at 10:41 AM Jeff Craig= <jeffcraig=3D40google.co= m@dmarc.ietf.org> wrote:
I think=C2=A0that the argument=C2=A0is tha= t token refreshing isn't as strong a signal about usage patterns as int= rospection calls would be, which I agree with. I also think that if a RS kn= ows it's using an external AS, they've generally accepted this info= rmation leakage. This is not to say it's not worth mentioning in the do= cument, but rather that I doubt it will significantly move implementations = one way or the other.

Generally speaking, I don't li= ke JWTs as Access Tokens. They're verbose, they leak information to cli= ents that clients don't need, and if the RS makes a mistake in their JW= T validation, they can create security vulnerabilities.=C2=A0 That said, I = do think they are preferable to Introspection at request time, and the RS&#= 39;s that I've worked with generally don't want the overhead of Int= rospection on every usage of the token. I generally argue a shared secret b= etween the RS and the AS is a better solution, but in my experience most cl= oud-hosted ASes don't offer that option.

For t= his cloud AS situation, I have been tracking=C2=A0draft-ietf-oauth-token-ex= change-19 as a means for RSes to setup a Token Endpoint to convert the AS a= ccess token into a access token (w/o Refresh) that the RS can accept, thus = limiting Introspection to the Refresh flow, but I don't currently have = a RS interested in trying to try this flow, but I think that it's a rea= sonable approach to limiting introspection on every request to the RS, thou= gh it does add an additional point of failure during the Token Refresh. Thi= s has the same leakage problem that is under discussion here, obviously.

On Mon, Aug 31, 2020 at 3:34 AM Neil Madden <neil.madden@forgerock.com> wr= ote:
But if you want to handle revocation (and you do), = then the alternative is short-lived access tokens with frequent refreshing,= which also informs the AS of activity. So is this any better?

If an org running an RS decides to use= a 3rd-party AS (eg cloud hosted) then there are privacy implications to th= at arrangement, regardless of the specific technology used for token valida= tion.

On 26 Aug 2020, at 22:16, Mike Jones <Michael.Jones=3D40microsoft.com@dma= rc.ietf.org> wrote:

=EF=BB=BF

I agree with Dick= =E2=80=99s observation about the privacy implications of using an Introspec= tion Endpoint.=C2=A0 That=E2=80=99s why it=E2=80=99s preferable to not use = one at all and instead directly have the Resource understand the Access Token.=C2=A0 One way of doing this is the JWT Access Token spec.=C2=A0 The= re are plenty of others.

=C2=A0<= /u>

The downsides of = using an Introspection Endpoint should be described in the Privacy Consider= ations section.

=C2=A0<= /u>

=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=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=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 -- Mike

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Dick Hardt
Sent: Wednesday, August 26, 2020 9:52 AM
To: Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>
Cc: last-cal= l@ietf.org; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspe= ction-response-09.txt> (JWT Response for OAuth Token Introspection) to P= roposed Standard

=C2=A0

=C2=A0

=C2=A0

On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt = <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:

Hi Denis,

> On 25. Aug 2020, at 16:55, Denis <denis.ietf@free.fr> wrote:

> The fact that the AS will know exactly when the introspection call has= been made and thus be able to make sure which client
> has attempted perform an access to that RS and at which instant of tim= e. The use of this call allows an AS to track where and when
> its clients have indeed presented an issued access token.

That is a fact. I don=E2=80=99t think it is an issue per se. Please explain= the privacy implications.

=C2=A0

As I see it, the privacy implication is that the AS = knows when the client (and potentially the user) is accessing the RS, which i= s also an indication of when the user is using the client.

=C2=A0

I think including this implication would be importan= t to have in a Privacy Considerations section.

=C2=A0

/Dick

=E1=90=A7

_______________________________________________
OAuth= mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth
__________________________= _____________________
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
--0000000000004cc45405ae304ffd-- From nobody Mon Aug 31 11:51:18 2020 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 72A063A1888 for ; Mon, 31 Aug 2020 11:51:12 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 (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 EuyGG80Oh7f9 for ; Mon, 31 Aug 2020 11:51:10 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 9DD5A3A18A1 for ; Mon, 31 Aug 2020 11:51:09 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id w5so6957649wrp.8 for ; Mon, 31 Aug 2020 11:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=1l4fVQedbqIv6e8wIa747DJ9aApyFi0oHorKSf4883I=; b=R6UeA4Ktvp9MdYQIdVsuAmXa6mxKKvOA60gS9pM1DBki9yCGGCOSPPc1bHACwvFLL0 Az/PdyTF/hvDWDzuiybzMVIQ/Mjl0oo1zQhKPiIEMPdpHsQykU/YlxH3VyFcz/Q7+Jhf p02KjLjSVuhvmkOF+Sknd1bTRCcXDMayu07Yo= 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=1l4fVQedbqIv6e8wIa747DJ9aApyFi0oHorKSf4883I=; b=ptg8etaD6yYOklCirfaoS8oVN3y+6l8D8x+TA88A/fsQ41RBjHrUbnE6Xu7GIs3Ub7 s8P+GjYqQx2cPOlqBntzoFmUCMhn15RDAeNZfcyagyDkX2HOSJD8GYSLgG9dhl///cQ9 iP56629FVsvE+7iKhoW+qVcC574dIbMlUuqdMFNmynQG2PW7yZxWNKgLrhOgiLOzl6E9 jB2cP8tjBAAR92EWDHbGgnJkVWpfXJ+ORxcsU7+FwOBv1KAszJwW7+eeXiTDNn8O9+GX DFgkw+s42eyKXl6QaCxQ9/OKZ7swY3xWlEdxz/ufp/pN40AFNBiwNwB4VjDnHJIfAViq 4BsQ== X-Gm-Message-State: AOAM530LqYjT7TN4Lw3Wta/9m7NPBVKDI3IogMvFwxYtTh4AY0sM8aoV dYLoAMJMsafXdlxhUzjOJgwfDQ== X-Google-Smtp-Source: ABdhPJzp9iFBOsdFjl3VpAnc4X+i0VFPeqK6NSAbnpjRLLPBwZfyVBO+8tE4TCLcaNBpxyhn+sUKGA== X-Received: by 2002:adf:dfd1:: with SMTP id q17mr3103733wrn.347.1598899867647; Mon, 31 Aug 2020 11:51:07 -0700 (PDT) Received: from [10.0.0.3] (38.227.143.150.dyn.plus.net. [150.143.227.38]) by smtp.gmail.com with ESMTPSA id o2sm579284wmo.37.2020.08.31.11.51.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Aug 2020 11:51:07 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B2EFC8E0-2872-4FD4-8EC0-6C40B58AFA47 Content-Transfer-Encoding: 7bit From: Neil Madden Mime-Version: 1.0 (1.0) Date: Mon, 31 Aug 2020 19:51:06 +0100 Message-Id: <4D84C4C3-3BCF-4BA9-A182-2CF2CAFE10A5@forgerock.com> References: Cc: Mike Jones , "last-call@ietf.org" , oauth , Torsten Lodderstedt In-Reply-To: To: Jeff Craig X-Mailer: iPhone Mail (17G80) Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 31 Aug 2020 18:51:13 -0000 --Apple-Mail-B2EFC8E0-2872-4FD4-8EC0-6C40B58AFA47 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 31 Aug 2020, at 18:41, Jeff Craig wrote: >=20 > =EF=BB=BF > I think that the argument is that token refreshing isn't as strong a signa= l about usage patterns as introspection calls would be, which I agree with. It=E2=80=99s usually pretty similar in my experience (see below). =20 > I also think that if a RS knows it's using an external AS, they've general= ly accepted this information leakage. This is not to say it's not worth ment= ioning in the document, but rather that I doubt it will significantly move i= mplementations one way or the other. Right.=20 >=20 > Generally speaking, I don't like JWTs as Access Tokens. They're verbose, t= hey leak information to clients that clients don't need, and if the RS makes= a mistake in their JWT validation, they can create security vulnerabilities= . That said, I do think they are preferable to Introspection at request tim= e, and the RS's that I've worked with generally don't want the overhead of I= ntrospection on every usage of the token. Generally you=E2=80=99d cache the result of the introspection call to mitiga= te this overhead. (Eg some reverse proxies or API gateways can do this). The= two approaches are pretty similar: either you have 10 second access tokens a= nd refresh, or you introspect and cache the response for 10 seconds.=20 I much prefer introspection because there are far fewer ways to mess it up, b= ut the JWT approach can be useful if you have clients accessing a lot of dif= ferent RSes.=20 > I generally argue a shared secret between the RS and the AS is a better so= lution, but in my experience most cloud-hosted ASes don't offer that option.= >=20 > For this cloud AS situation, I have been tracking draft-ietf-oauth-token-e= xchange-19 as a means for RSes to setup a Token Endpoint to convert the AS a= ccess token into a access token (w/o Refresh) that the RS can accept, thus l= imiting Introspection to the Refresh flow, but I don't currently have a RS i= nterested in trying to try this flow, but I think that it's a reasonable app= roach to limiting introspection on every request to the RS, though it does a= dd an additional point of failure during the Token Refresh. This has the sam= e leakage problem that is under discussion here, obviously. >=20 >> On Mon, Aug 31, 2020 at 3:34 AM Neil Madden w= rote: >> But if you want to handle revocation (and you do), then the alternative i= s short-lived access tokens with frequent refreshing, which also informs the= AS of activity. So is this any better? >>=20 >> If an org running an RS decides to use a 3rd-party AS (eg cloud hosted) t= hen there are privacy implications to that arrangement, regardless of the sp= ecific technology used for token validation. >>=20 >>>> On 26 Aug 2020, at 22:16, Mike Jones wrote: >>>>=20 >>> =EF=BB=BF >>> I agree with Dick=E2=80=99s observation about the privacy implications o= f using an Introspection Endpoint. That=E2=80=99s why it=E2=80=99s preferab= le to not use one at all and instead directly have the Resource understand t= he Access Token. One way of doing this is the JWT Access Token spec. There= are plenty of others. >>>=20 >>> =20 >>>=20 >>> The downsides of using an Introspection Endpoint should be described in t= he Privacy Considerations section. >>>=20 >>> =20 >>>=20 >>> -- Mike >>>=20 >>> =20 >>>=20 >>> From: OAuth On Behalf Of Dick Hardt >>> Sent: Wednesday, August 26, 2020 9:52 AM >>> To: Torsten Lodderstedt >>> Cc: last-call@ietf.org; oauth >>> Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Sta= ndard >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt wrote: >>>=20 >>> Hi Denis, >>>=20 >>> > On 25. Aug 2020, at 16:55, Denis wrote: >>>=20 >>> > The fact that the AS will know exactly when the introspection call has= been made and thus be able to make sure which client=20 >>> > has attempted perform an access to that RS and at which instant of tim= e. The use of this call allows an AS to track where and when=20 >>> > its clients have indeed presented an issued access token. >>>=20 >>> That is a fact. I don=E2=80=99t think it is an issue per se. Please expl= ain the privacy implications. >>>=20 >>> =20 >>>=20 >>> As I see it, the privacy implication is that the AS knows when the clien= t (and potentially the user) is accessing the RS, which is also an indicatio= n of when the user is using the client. >>>=20 >>> =20 >>>=20 >>> I think including this implication would be important to have in a Priva= cy Considerations section. >>>=20 >>> =20 >>>=20 >>> /Dick >>>=20 >>> =E1=90=A7 >>>=20 >>> _______________________________________________ >>> 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-B2EFC8E0-2872-4FD4-8EC0-6C40B58AFA47 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 31 Aug 2020, at 18:41, Jeff Craig <jeffcrai= g@google.com> wrote:

=
=EF=BB=BF
I think that the argument&nb= sp;is that token refreshing isn't as strong a signal about usage patterns as= introspection calls would be, which I agree with.
=

It=E2=80=99s usually pretty similar in my experience (se= e below).  

I also think that if a RS knows it's using an external AS, they've= generally accepted this information leakage. This is not to say it's not wo= rth mentioning in the document, but rather that I doubt it will significantl= y move implementations one way or the other.
Right. 


Generally speaking, I don't like JWTs= as Access Tokens. They're verbose, they leak information to clients that cl= ients don't need, and if the RS makes a mistake in their JWT validation, the= y can create security vulnerabilities.  That said, I do think they are p= referable to Introspection at request time, and the RS's that I've worked wi= th generally don't want the overhead of Introspection on every usage of the t= oken.

Generally you=E2=80= =99d cache the result of the introspection call to mitigate this overhead. (= Eg some reverse proxies or API gateways can do this). The two approaches are= pretty similar: either you have 10 second access tokens and refresh, or you= introspect and cache the response for 10 seconds. 

I much prefer introspection because there are far fewer ways to mess i= t up, but the JWT approach can be useful if you have clients accessing a lot= of different RSes. 

I generally argue a shared secret between the RS and= the AS is a better solution, but in my experience most cloud-hosted ASes do= n't offer that option.

For this cloud AS situation,= I have been tracking draft-ietf-oauth-token-exchange-19 as a means for= RSes to setup a Token Endpoint to convert the AS access token into a access= token (w/o Refresh) that the RS can accept, thus limiting Introspection to t= he Refresh flow, but I don't currently have a RS interested in trying to try= this flow, but I think that it's a reasonable approach to limiting introspe= ction on every request to the RS, though it does add an additional point of f= ailure during the Token Refresh. This has the same leakage problem that is u= nder discussion here, obviously.

On Mon, Aug 31, 2020 at 3:34 AM Neil Madden <neil.madden@forgerock.com> wr= ote:
But if you want to handle revocation (and you do), then= the alternative is short-lived access tokens with frequent refreshing, whic= h also informs the AS of activity. So is this any better?

If an org running an RS decides to use a 3rd-= party AS (eg cloud hosted) then there are privacy implications to that arran= gement, regardless of the specific technology used for token validation.

On 2= 6 Aug 2020, at 22:16, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org<= /a>> wrote:

=EF=BB=BF

I agree with Dick=E2= =80=99s observation about the privacy implications of using an Introspection= Endpoint.  That=E2=80=99s why it=E2=80=99s preferable to not use one a= t all and instead directly have the Resource understand the Access Token.  One way of doing this is the JWT Access Token spec.  Ther= e are plenty of others.

 

The downsides of u= sing an Introspection Endpoint should be described in the Privacy Considerat= ions section.

 

   =             &nbs= p;            &n= bsp;            =             &nbs= p; -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of= Dick Hardt
Sent: Wednesday, August 26, 2020 9:52 AM
To: Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org&= gt;
Cc: last-call= @ietf.org; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspec= tion-response-09.txt> (JWT Response for OAuth Token Introspection) to Pro= posed Standard

 

 

 

On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt &= lt;torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:

Hi Denis,

> On 25. Aug 2020, at 16:55, Denis <denis.ietf@free.fr> wrote:

> The fact that the AS will know exactly when the introspection call has b= een made and thus be able to make sure which client
> has attempted perform an access to that RS and at which instant of time= . The use of this call allows an AS to track where and when
> its clients have indeed presented an issued access token.

That is a fact. I don=E2=80=99t think it is an issue per se. Please explain t= he privacy implications.

 

As I see it, the privacy implication is that the AS k= nows when the client (and potentially the user) is accessing the RS, which is= also an indication of when the user is using the client.

 

I think including this implication would be important= to have in a Privacy Considerations section.

 

/Dick

=E1=90=A7

_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth
________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-B2EFC8E0-2872-4FD4-8EC0-6C40B58AFA47-- From nobody Mon Aug 31 15:48:08 2020 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 3841B3A19AC; Mon, 31 Aug 2020 15:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ltN5hyigwMdy; Mon, 31 Aug 2020 15:48:01 -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 8B6F93A0121; Mon, 31 Aug 2020 15:48:01 -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 07VMlshv027778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 31 Aug 2020 18:47:56 -0400 Date: Mon, 31 Aug 2020 15:47:53 -0700 From: Benjamin Kaduk To: Denis Cc: Torsten Lodderstedt , "last-call@ietf.org" , oauth , Mike Jones Message-ID: <20200831224753.GP16914@kduck.mit.edu> References: <412A63AD-DDE1-4BFE-8234-5A721A0ED88D@lodderstedt.net> <08D01F36-367B-4F23-9602-9C2A2AE49DA3@mit.edu> <65a7f2c0-c7e3-5c67-1be6-1dfb2b77779e@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <65a7f2c0-c7e3-5c67-1be6-1dfb2b77779e@free.fr> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard 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, 31 Aug 2020 22:48:04 -0000 Hi all, On Mon, Aug 31, 2020 at 09:58:11AM +0200, Denis wrote: > The last text that has been proposed on the list about this thread is > the following: > > Implementers should be aware that a token introspection request lets the > AS know when the client is accessing the RS, >       which can also indicate when the user is using the client. If > this implication is not acceptable, implementers can use other means >       to carry access token data, e.g. directly transferring the data > needed by the RS within the access token. > > The concerns of the implementers have nothing to do with the concerns of > the Users. Such a text proposal has nothing to do with a "User consent". > > *Towards an RFC Errata to RFC 7662* > > Mike Jones wrote: > > I agree with Dick’s observation about the privacy implications of using > an Introspection Endpoint. That’s why it’s preferable to not use one at all >       and instead directly have the Resource understand the Access > Token. One way of doing this is the JWT Access Token spec. There are > plenty of others. > > I fully agree. > > RFC 7662 should have incorporated a more detailed content such as: > >      In OAuth 2.0 [RFC6749], the contents of tokens are opaque to > clients. However, the contents of tokens is not intended to be opaque to > RSs. >      Token introspection is an OPTIONAL feature of an AS described in > OAuth Introspection [RFC 7662] intended for clients that are unable >      to support structured access tokens including their validation. > The use of this call allows an AS to track where and when its clients > have indeed >      presented an issued access token. As soon as the RS knows the > format of the access token, e.g. using structured token formats such as >      JWT [RFC7519], and is able to validate its security features, the > call described in OAuth Introspection [RFC 7662] should be avoided, > otherwise >      the AS will know exactly when the introspection call has been made > and thus be able to make sure which client has attempted perform an access >      to that RS and at which instant of time. As soon as this call is > supported by an AS, the client or the user have no way to prevent the RS > to use it. > > It might be useful to add it, e.g. using an RFC Errata. I do not believe this would be an appropriate usage of an Errata Report -- it changes the meaning of the RFC away from what the WG intended at the time of publication. Use of tokens that are just opaque DB handles (along with some form of introspection) is desirable when a prominent threat is leakage of token contents from the browser. We have had numerous discussions over the years of various ways in which information can leak from the browser, including history APIs, malicious javascript, and more. While these threats are not always applicable in all deployment models, they are still present, just as the threats that you propose we defend against are not always of concern in all deployment models. AFAICT, given the technologies currently available, there is not one universal solution that will address all concerns, and deployments will have to make a trade-off. I think we need to acknowledge that there are different deployment models and that (for example) giving the user visibility into the token contents is not always desired, given the other risks that the current mechanisms for providing that visibility open up. -Ben P.S. your usage of the phrase "the User and his client" (below) suggests that you are still picturing the client as being local to the user, as is the case for, e.g., a TLS client or an IMAP client. This is not the original model for an OAuth, where the client can just as well be a headless server in a cloud somewhere. > *Differences with RFC 7662* > > RFC 7662 defines a protocol that allows authorized protected resources > to query the authorization server to determine > the set of metadata for a given token that was presented to them by an > OAuth 2.0 client. > > At a first glance, draft-ietf-oauth-jwt-introspection-response-09 seems > to be simply a JWT Response for OAuth Token Introspection > instead of a JSON document representing the meta information surrounding > the token. > > However, this is not the case since major differences can be identified. > > RFC 7662 describes an OPTIONAL call able to return a JSON object with > the following top-level members: active (REQUIRED), scope (OPTIONAL), > client_id (OPTIONAL), username (OPTIONAL), token_type (OPTIONAL), exp > (OPTIONAL), iat (OPTIONAL), nbf (OPTIONAL), sub (OPTIONAL), > aud (OPTIONAL), iss (OPTIONAL), jti (OPTIONAL) and claims from the "JSON > Web Token Claims" registry (OPTIONAL). > > draft-ietf-oauth-jwt-introspection-response-09 is able to return a JWT > as the introspection response. However, the request and the returned > information > are not the same. > > Section 4 (Requesting a JWT Response) only provides an example and does > not describe the mandatory and optional parameters from the request. > Are they identical to those described in RFC 7662 ? No one is able to say. > > draft-ietf-oauth-jwt-introspection-response-09 describes a response > structure which is different from RFC 7662 where a single top-level > member is required, > i.e. active. The text from > draft-ietf-oauth-jwt-introspection-response-09 requires three (in fact > four) top-level members. The text states: > > The JWT MUST include the following top-level claims: > > * issMUST be set to the issuer URL of the authorization server. > * audMUST identify the resource server receiving the token > introspection response. > * iatMUST be set to the time when the introspection response was > created by the authorization server. > > Note that the text about "active" (i.e. the fourth top-level member) is > misplaced in the middle of the token_introspection claim and does not allow > to easily understand that the top-level claim "active" MUST be set to > either true or false. > > The text states: > > The AS determines based on its RS-specific policy what claims about the > resource owner to return in the token introspection response. > > Such a sentence (which does not exist in RFC 7662) is a door wide-opened > to return claims that are NOT included into the access token. > This protocol should NOT be a protocol that allows authorized RSs to > query the AS to obtain metadata that was NOT included into an access token > that was presented to them. > > Torsten wrote: > > Token introspection has several advantages over structured access > tokens, also when it comes to privacy. If one uses a structured access > token >       in conjunction with different *services*, then this access token > needs to contain ALL data required to call ALL these services. This > effectively means >       the services learn more data than required. One could try to > mitigate this by carrying encrypted compartments in the same token, each > of them >       encrypted with for a certain service. That would be complex and > is not covered by current technical standards. Introspection, however, > allows the AS >       issue a minimal access token (even without any id) and mint > specific response for the different RSs. > > Instead of attempting to imagine complex mechanisms like "encrypted > compartments in the same token", it is much simpler to use different > access tokens. > AFAIK, in addition, there is no notion of "services" in OAuth in RFC > 6749, but only a notion of "server". A "server" is not a "service". > > resource server > > The server hosting the protected resources, capable of accepting > and responding to protected resource requests using access tokens. > > RFC 6750 is using the wording "audience restriction" to restrict the use > of a token to "the intended relying party or set of relying parties" > (i.e. to one or more RSs). > > So if the access token is targeted to one or more RSs, it should only > contain what is necessary to accomplish the call on these RSs. > This means the RS(s) learn(s) exactly the data that it required. If it > is not the case, several access tokens should be used. > > The principle of "data minimization" implies that an access token should > only contain what is necessary to accomplish a call to a given RS. > > Since this new call is meant to be OPTIONAL, there should be no > difference whether the RS decodes and validates the access token by itself > or sub-contracts the same operations to the AS. > > The explanations from Torsten imply that there can be a difference .... > which furthermore is left at the full discretion of the AS. > > *About the secondary use* > > I wrote: > > This concern is identified in RFC 6973 as: > > 5.2.3.Secondary Use > > Secondary use is the use of collected information about an individual > without the individual’s consent for a purpose different from that > for which the information was collected.Secondary use may violate > people’s expectations or desires.The potential for secondary use > can generate uncertainty as to how one’s information will be used in > the future, potentially discouraging information exchange in the > first place.Secondary use encompasses any use of data, including > disclosure. > > Torsten replied: > >       This is no secondary use, it’s the primary use *the user > consented with*. > > No "user consent" phase is ever mentioned in order to allow a RS to ask > and receive a jwt-introspection-response. > > The text states: > > The AS MUST ensure the release of any privacy-sensitive data is legally > based. > > Such a statement does not make sense in practice. A different legal > system applies depending upon three factors: > the location of the client, the location of the AS and the location of > the RS. > > Unless these three entities are located within the same country (e.g. > Switzerland), the same state (e.g. Maryland) or > the same union (e.g. the European Union), the AS will be unable to know > how to enforce such a statement. > > The release of any privacy-sensitive data must be under the control of > the user who must consent to the release > of that privacy-sensitive data. This makes it independent from any legal > system. > > *About the token introspection endpoint > * > The token introspection endpoint is advertised in RFC 8414 in the > following way: > > introspection_endpoint > OPTIONAL.URL of the authorization server’s OAuth 2.0 introspection > endpoint [RFC7662]. > > This endpoint is intended to explicitly support RFC 7662, but not > anything else. This draft is intended to support a new functionality > that is different > from RFC 7662. This means that the AS should not use the same token > introspection endpoint. If supported, this new functionality should be > supported > using a new endpoint, e.g. an introspection_JWT_endpoint. > > When this new functionality is advertised by an AS by the disclosure of > an access point, this does not necessarily mean that it is supported for > all the RSs > with which that AS has a relationship. > > The current situation is that the User and his client have no way to > know whether or not this new call will indeed be supported by the AS for > a given RS. > Even the RS can't know it directly, since the only way to know it is to > use a "trial and error" mechanism. > > *A proposal on how to solve the issue* > > Hereafter is one way on how to solve the issue. > > The User is the entity that is the best placed to give the User Consent. > It would be simpler if the user could ask to the AS to provide to his > client > a JWT for a given RS that could be used to issue certificates usable for > creating qualified electronic signatures. A specific scope could be defined > for such a purpose which would detail the claims to be incorporated into > the access token and say that these claims shall be verified according to > sections 6.2.2 (Initial identity validation) of both ETSI EN 319 411-1 > and ETSI EN 319 411-2. > > The client supporting the user would then communicate that JWT to the RS > of its choice. The scope placed into the access token would testify > that the claims have indeed been verified according to sections 6.2.2 of > both ETSI EN 319 411-1 and ETSI EN 319 411-2. > > Such a functionality cannot be supported using > draft-ietf-oauth-jwt-introspection-response. > > In case the RS would be unable to decode the access token and/or to > validate it, it might make attempt to make a call to the AS according to > RFC 7662, > if this service is available (but the user has no way to indicate that > he consents for making such a call). > > As a conclusion, since draft-ietf-oauth-jwt-introspection-response harms > the user's privacy and fully by-passes the User consent, > this draft should not be progressed to the RFC level. > > Denis > > > > The "can" works better, agreed. Thanks! > > ᐧ > > > > On Sat, Aug 29, 2020 at 8:25 AM Justin Richer > > wrote: > > > > Thanks, Dick. I agree with removing the excess parenthetical, but > > I intentionally avoided using a lowercase “may” in the middle of > > the text  (in favor of “can”) to avoid normative-sounding > > non-normative language, so I’d recommend that change be kept: > > > > Implementers should be aware that a token introspection request > > lets the AS know when the client > >     is accessing the RS, which can also indicate when the user is > > using > >     the client. If this implication is not acceptable, > > implementers can use other means to carry > >     access token data, e.g. directly transferring the data needed > > by the RS within the access token. > > > >> On Aug 27, 2020, at 12:15 PM, Dick Hardt >> > wrote: > >> > >> Here is a crisper revision. > >> > >> Implementers should be aware that a token introspection request > >> lets the AS know when the client > >>     is accessing the RS, which may indicate when the user is using > >>     the client. If this implication is not acceptable, > >> implementers can use other means to carry > >>     access token data, e.g. directly transferring the data needed > >> by the RS within the access token. > >> ᐧ > >> > >> On Thu, Aug 27, 2020 at 7:19 AM Justin Richer >> > wrote: > >> > >> I would clarify that this doesn’t necessarily say that the > >> user’s there, and remove the normative requirement (which > >> doesn’t have enforceable teeth in this context): > >> > >> Implementers should be aware that a token introspection > >> request lets the AS know when the client > >>     (and potentially the user) is accessing the RS, which > >> *can also indicate* when the user is using > >>     the client. If this implication is not acceptable, > >> *implementers can use other means* to carry > >>     access token data, e.g. directly transferring the data > >> needed by the RS within the access token. > >> > >> > >>  — Justin > >> > >>> On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt > >>> >>> > wrote: > >>> > >>> Will the following text work for you? > >>> > >>> Implementers should be aware that a token introspection > >>> request lets the AS know when the client > >>>     (and potentially the user) is accessing the RS, which is > >>> also an indication of when the user is using > >>>     the client. If this impliction is not accepatable, > >>> implementars MUST use other means to carry > >>>     access token data, e.g. directly transferring the data > >>> needed by the RS within the access token. > >>> > >>> > >>>> On 26. Aug 2020, at 23:12, Mike Jones > >>>> >>>> > wrote: > >>>> > >>>> I agree with Dick’s observation about the privacy > >>>> implications of using an Introspection Endpoint. That’s why > >>>> it’s preferable to not use one at all and instead directly > >>>> have the Resource understand the Access Token.  One way of > >>>> doing this is the JWT Access Token spec.  There are plenty > >>>> of others. > >>>> > >>>> The downsides of using an Introspection Endpoint should be > >>>> described in the Privacy Considerations section. > >>>> > >>>>                                                       -- Mike > >>>> > >>>> From: OAuth >>>> > On Behalf Of Dick Hardt > >>>> Sent: Wednesday, August 26, 2020 9:52 AM > >>>> To: Torsten Lodderstedt > >>>> >>>> > > >>>> Cc: last-call@ietf.org ; oauth > >>>> > > >>>> Subject: Re: [OAUTH-WG] Last Call: > >>>> (JWT > >>>> Response for OAuth Token Introspection) to Proposed Standard > >>>> > >>>> > >>>> > >>>> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt > >>>> >>>> > wrote: > >>>> Hi Denis, > >>>> > >>>>> On 25. Aug 2020, at 16:55, Denis >>>>> > wrote: > >>>> > >>>>> The fact that the AS will know exactly when the > >>>>> introspection call has been made and thus be able to make > >>>>> sure which client > >>>>> has attempted perform an access to that RS and at which > >>>>> instant of time. The use of this call allows an AS to > >>>>> track where and when > >>>>> its clients have indeed presented an issued access token. > >>>> > >>>> That is a fact. I don’t think it is an issue per se. Please > >>>> explain the privacy implications. > >>>> > >>>> As I see it, the privacy implication is that the AS knows > >>>> when the client (and potentially the user) is accessing the > >>>> RS, which is also an indication of when the user is using > >>>> the client. > >>>> > >>>> I think including this implication would be important to > >>>> have in a Privacy Considerations section. > >>>> > >>>> /Dick > >>>> ᐧ > >>> > >>> _______________________________________________ > >>> 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth


=
On Wed, Aug 26, 2020 at 4:37 AM Torst= en Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
Hi Denis,

> On 25. Aug 2020, at 16:55, Denis <denis.ietf@free.fr> wrote:

> The fact that the AS will know exactly when the introspection call has= been made and thus be able to make sure which client
> has attempted perform an access to that RS and at which instant of tim= e. The use of this call allows an AS to track where and when
> its clients have indeed presented an issued access token.

That is a fact. I don=E2=80=99t think it is an issue per se. Please explain= the privacy implications.

As I see it= , the privacy implication is that the AS knows when the client (and = potentially the user) is accessing the RS, which is also an indication of <= b>when the user is using the client.

I think i= ncluding this implication would be important to have in a Privacy Considera= tions section.

/Dick