From nobody Sun Jun 2 01:10:19 2019 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 B8BFE120073 for ; Sun, 2 Jun 2019 01:10:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 HsmAR8qwJz8a for ; Sun, 2 Jun 2019 01:10:16 -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 BB24312008F for ; Sun, 2 Jun 2019 01:10:15 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id f10so8529168wmb.1 for ; Sun, 02 Jun 2019 01:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PzjUeutmcZ5VvRlDQncXQhNaKuozhuhn5wEkhrlMocs=; b=gqES2JE4JjdCO5nWbkEUQyfTBniQPVxwmYA9Qg04Q7q5hQ5Y0gD7CoxvQUSuNRfBLR vgP8AlnnmxJpsewW5wdG+Oo847go9K7K8UkyMoBvJJBTbJ1GfYnMxgKL1V2C0lN+695T zhhcr54rYpjkVGZyprnJ8bOHkXuqJjAr39+5R396Z9U+AT/YpddnSG4l+vvYUG/uvxEg C+J2wwpN1HhmVsVdbXNdsEPYwZyu2SbCccnYqlx6AqMWbbeJixUaZKgAxrJpaCxuDreV 5GeX45rK+8LOqz/fkonO/3UKsaE2w6Pbudp8b4arzvewjFiRerwi1oMaz6oQfKBl1iFa CSKg== 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=PzjUeutmcZ5VvRlDQncXQhNaKuozhuhn5wEkhrlMocs=; b=m66C7QPptqQtRQQj8AC1HebN4N3Gm2ZC8HJlBS6PmBRYz+d9ET9gr3BOUstr42a5S9 B7ZvvE5EjqnKOsXQ/mIXE2ol+8dHkgUvEDXzF0Tn1Bp6zjOshHEHreEhlnsl7cRQqZUa c3YSHoosq2dThmY/heb47zU9n6lC5x3fg/l1gYG2qSh+J/mnBdofYo3ImDodgapHcnx8 wd9dFzmXKLPa7l48qzOCSH7e4w6QnN8sRK8hrkLpPJzqYaIyH1DsBCVW2QOAnqMJ6SJb 7TdRYy20ymUFrECMIr0Ue2Eu90wKGSXsM325bP6KgE7U37pjWAuNhDZktqHIkaa0atqV HtWg== X-Gm-Message-State: APjAAAXu0580mqK9orGkoPCp2oeFOqHyx7emcFSQeR+vspJzD1HF8kNA vdbmWFl0zYsGBP5aOpo3iun7+A== X-Google-Smtp-Source: APXvYqyZAAg9hwW0uDzX+lgWsU02ITNa2Vy9MSAE08x5Gf7ALjoo0hSQmb9F3VACbzfR1WEdrS99wg== X-Received: by 2002:a7b:cc0d:: with SMTP id f13mr11249767wmh.1.1559463014120; Sun, 02 Jun 2019 01:10:14 -0700 (PDT) Received: from fon.sh2.org.uk (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id l18sm26240051wrh.54.2019.06.02.01.10.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Jun 2019 01:10:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Joseph Heenan In-Reply-To: Date: Sun, 2 Jun 2019 09:10:11 +0100 Cc: oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Janak Amarasena X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] Device Authorization Grant Interval 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, 02 Jun 2019 08:10:18 -0000 Hi Janak, Interestingly this came up when discussing the CIBA specification (which = builds upon device authorization grant to some extent) recently: = https://bitbucket.org/openid/mobile/issues/135/token-endpoint-response-whe= n-client-polls The thought that group came up with is that returning = =E2=80=98invalid_request=E2=80=99 would be appropriate - ideally = appropriate error_description to make it easy to understand what=E2=80=99s= going on. Cheers, Joseph > On 21 May 2019, at 06:21, Janak Amarasena = wrote: >=20 > Hi all, >=20 > In the OAuth2 Device Authorization Grant, what would be an appropriate = response if the client does not respect the set polling interval and = keeps on polling with a lower interval? >=20 > Thank you, > Best Regards, >=20 > Janak Amarasena > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Jun 3 05:09:14 2019 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 7460812006B; Mon, 3 Jun 2019 05:09:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rdd@cert.org, rifaat.ietf@gmail.com, oauth-chairs@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155956375243.24296.15419619112752826454.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2019 05:09:12 -0700 Archived-At: Subject: [OAUTH-WG] oauth - New Meeting Session Request for IETF 105 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 12:09:13 -0000 A new meeting session request has just been submitted by Rifaat Shekh-Yusef, a Chair of the oauth working group. --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Rifaat Shekh-Yusef Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: acme tls rats sipcore anima Second Priority: ace secevent teep suit core tokbind saag People who must be present: Roman Danyliw Hannes Tschofenig Rifaat Shekh-Yusef Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Jun 3 09:11:53 2019 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 8BA7412006B for ; Mon, 3 Jun 2019 09:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 BuD-p79HLvQ6 for ; Mon, 3 Jun 2019 09:11:49 -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 A88AE120241 for ; Mon, 3 Jun 2019 09:11:46 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x53GBjbR001180 for ; Mon, 3 Jun 2019 12:11:45 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x53GBjbR001180 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1559578305; bh=Z0S8sWK7zt2aWnmvPrCxkqWvPRdGrSz9pU5Ve03huHk=; h=From:To:Subject:Date:From; b=mXxw/VD18v/DYbbE9Bih0IE9TXjc7178MF0HXgphCnGsv4wkCGBbrBXAvf7wxGK9x XN6aUTHbEkOfYOs4XyMAejFXnr3Br0tAEg5i1aiXBV00obtFZSuu4TOqpobec/Vx20 AMmtIwFqFb2Dl54n7HfIunjgFT5nAfPbZ6cEb+Yc= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x53GBfZE006475 for ; Mon, 3 Jun 2019 12:11:41 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Mon, 3 Jun 2019 12:11:40 -0400 From: Roman Danyliw To: "oauth@ietf.org" Thread-Topic: Second AD Review: draft-ietf-oauth-jwt-bcp-05 Thread-Index: AdUaJgtVO/GFpDkjR521ne31wNVvSw== Date: Mon, 3 Jun 2019 16:11:40 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B338252D@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] Second AD Review: draft-ietf-oauth-jwt-bcp-05 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 Jun 2019 16:11:51 -0000 Hi! As a document I inherited in the "IESG:: Waiting for Writeup Internet-Draft= s" , I conducted a second AD review. I have the following feedback: (1) Add additional references to the text (a) Section 2.1, bullet #2 - An "RS256" (RSA, 2048 bit) parameter value can be changed into "HS256" (HMAC, SHA-256), and some libraries would try to validate the signature using HMAC-SHA256 and using the RSA public key as the HMAC shared secret. Since this text seems to refer to a vulnerability in a real library. Can a= citation (CVE?) be provided? =20 (b) Section 2.3=20 This is not the case anymore, with the latest standard only allowing UTF-8. Add a reference to this "latest JSON format" -- [RFC8259] (c) Section 3.2 - Avoid all RSA-PKCS1 v1.5 encryption algorithms, preferring RSA- OAEP . Provide reference for "RSA-PKCS1 v1.5" (RFC 2313) and for "RSA OAEP" (Secti= on 7.1 of RFC8017) (d) Section 3.2 ECDSA signatures require a unique random value for every message that is signed. =20 Provide a reference for ECDSA -- [X9.62] American National Standards Instit= ute, "Public Key Cryptography for the Financial Services Industry: The Elli= ptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62-2005, November = 2005. (2) The symmetric between the threat being described in Section 2 and the c= orresponding mitigation in Section 3 is helpful. However, Sections 3.6 and= 3.10 are listed as mitigations but have no corresponding motivating threat= s for their usage in Section 2. The text in Section 3.6 explains part of t= he threat with references but for symmetry this should have been in Section= 2. Regards, Roman From nobody Mon Jun 3 09:54:59 2019 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 943A512067F for ; Mon, 3 Jun 2019 09:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 KYPL0-j95GTe for ; Mon, 3 Jun 2019 09:54:56 -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 5297612069E for ; Mon, 3 Jun 2019 09:54:56 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id f10so11980954wmb.1 for ; Mon, 03 Jun 2019 09:54:56 -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=KB21V2+CmqUc2ezlvACQs+bumc8TTHl7ydaOOcNg/Og=; b=JsHPPDr384vMBM1BerB5dN3bLH4dnvRLFTlChGrba1LfWYBkW7bH2IhYwqQlCaK3hP Sbfj9es4Ud7vgePshzy2dFyZFdJt1j+OGiFUa2UUV0EO/wHRm5zGYBKNzUVxkSkIajsc w3ZQCYsXR+t9KZQ5XSfXSxhBZ1PgC1kjhR+oVBzAXHKtMJyROXkcJziYIn1uc9Ttad9I P5OKQEYJZ/ptFm9tglVWXvfER6HP2sOiiQSrd+i8czrHlwTVCvzyoaV2uYjWH4yHct44 MT6qGyQWzQdAdRZ+QramK7B3tYqphVafhD0evQprxR6qX4ud+uPxqels9ZmXkOhRTFGq a0LA== 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=KB21V2+CmqUc2ezlvACQs+bumc8TTHl7ydaOOcNg/Og=; b=okOaZfy0A8FE5iHI9ZC+DZm6CONTvqrrE5CI97vo8Nk0gkLjjsKUz3yLlKYePH7a// IQmkzSGhefMu+rbXCLoCm2bdyL7RO9A624Ou0KEu89Y9qj7/irbpfRgjo6lK/hMEeQtA ErUYXH8E1OYekrmUC9YsdITICU6nzpwUb3mnKhFBNnK1/wCfgVG4jKcpfr2HhYd60wMV +dwj8uClDyea8/KMJd+tQrUbwZ8ASCKyyxe9vjN3LnohiORjLfaTpg/oWcsTh+rUktkf 1Z3H34z6Gp5TcBHsL5znBFvGVZ4sDczG9qlbxCwAu0dNG74R+PSFKma6jJvpKEZ5gg0v 5p/Q== X-Gm-Message-State: APjAAAUmN/HYN8RgJrXKQ9muFM/JEddsAwN4yS02yCOsX8LNHYiIFb0b iOrHnmzhiUflpA+XnyV+cvXyB7/9OqDRXdBT274ong== X-Google-Smtp-Source: APXvYqwB7zLW/bFmBUwwcMrD85N37J31MN6TRt69TsZyOrtGTHaNwR33wVsl7Efqp+kCn2MdxSI3JJAp0a7hLAtGduc= X-Received: by 2002:a1c:9813:: with SMTP id a19mr14816054wme.11.1559580894843; Mon, 03 Jun 2019 09:54:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Janak Amarasena Date: Mon, 3 Jun 2019 22:24:45 +0530 Message-ID: To: Joseph Heenan Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000003c5700058a6e3950" Archived-At: Subject: Re: [OAUTH-WG] Device Authorization Grant Interval 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 Jun 2019 16:54:59 -0000 --0000000000003c5700058a6e3950 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Joseph, Thank you for the information, this what I was also thinking. It would be nice if this can be defined in the specification itself, maybe as a recommendation as there can be wrongly written client applications or even if some party is trying to do a brute force attack. Best Regards, Janak On Sun, Jun 2, 2019 at 1:40 PM Joseph Heenan wrote: > Hi Janak, > > Interestingly this came up when discussing the CIBA specification (which > builds upon device authorization grant to some extent) recently: > https://bitbucket.org/openid/mobile/issues/135/token-endpoint-response-wh= en-client-polls > > The thought that group came up with is that returning =E2=80=98invalid_re= quest=E2=80=99 > would be appropriate - ideally appropriate error_description to make it > easy to understand what=E2=80=99s going on. > > Cheers, > > Joseph > > > > On 21 May 2019, at 06:21, Janak Amarasena wrote= : > > > > Hi all, > > > > In the OAuth2 Device Authorization Grant, what would be an appropriate > response if the client does not respect the set polling interval and keep= s > on polling with a lower interval? > > > > Thank you, > > Best Regards, > > > > Janak Amarasena > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > --0000000000003c5700058a6e3950 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Joseph,

Thank you for the infor= mation, this what I was also thinking. It would be nice if this can be defi= ned in the specification itself, maybe as a recommendation as there can be = wrongly written client applications or even if some party is trying to do a= brute force attack.

Best Regards,
Janak=

On Sun, Jun 2, 2019 at 1:40 PM Joseph Heenan <joseph@authlete.com> wrote:
Hi Janak,

Interestingly this came up when discussing the CIBA specification (which bu= ilds upon device authorization grant to some extent) recently: https://bitbucket.org/op= enid/mobile/issues/135/token-endpoint-response-when-client-polls

The thought that group came up with is that returning =E2=80=98invalid_requ= est=E2=80=99 would be appropriate - ideally appropriate error_description t= o make it easy to understand what=E2=80=99s going on.

Cheers,

Joseph


> On 21 May 2019, at 06:21, Janak Amarasena <janakama360@gmail.com> wrote:
>
> Hi all,
>
> In the OAuth2 Device Authorization Grant, what would be an appropriate= response if the client does not respect the set polling interval and keeps= on polling with a lower interval?
>
> Thank you,
> Best Regards,
>
> Janak Amarasena
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

--0000000000003c5700058a6e3950-- From nobody Mon Jun 3 10:04:26 2019 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 9C6B0120178 for ; Mon, 3 Jun 2019 10:04:24 -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, 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=parecki-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 CK4D5QagnzdS for ; Mon, 3 Jun 2019 10:04:22 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 04034120145 for ; Mon, 3 Jun 2019 10:04:22 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id k8so14956425iot.1 for ; Mon, 03 Jun 2019 10:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eIDjsikfZLYrn6uWFmzHu143GSMP0LRnK4wBxCWBzZc=; b=VUSNi1kgdgDfkTiVAEM/fAOtJa+wYGCBIvS2QcOR4XpQjYjkRv1nVEPTyg2tWd6ykP QWMaKlou7/IhINCeJfWwv5znM8V89DmEVujOo3Su5BQuayd6uzjnRGLGBMUFPseCzSqA EthS8g5nEeY1HylH/fSnbEouRs7YNe6ULqauVSeR6FvJTpnzD3HuC9RcY7hJX7xZmdRX QYKt3BvClxDLaTDzUuM+Isa0Iq/RuspB1skAsIE1qzsoc+A6yfBQw3/hcHV9mlIB1pQl KyYjQUhadGXhlOTBcQNt14NVzuj3/ucK1yjn9PtMShp1tgtSW5hQawRhevcR/54HULzs 66sQ== 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=eIDjsikfZLYrn6uWFmzHu143GSMP0LRnK4wBxCWBzZc=; b=j2sLWR1C3FsylAVcLFMFbh4KKyWCQgYKuNLIodtav3IDbgsczdBIzrqtiAknnt5/le EIjnyrhtphik3aUzsm0bsKcGHpi9T+59dF5DF/INZN9f9pOcGVZJeBNNAHFm8Ei9nhMb 0eAP/H30SmKlyKBxjLxXXUd71PZAX4J3i6t1X/DjB8zu16cgPB2etcF1qRN4HxNP/sGE oiGVqEN4zVL/gsRf+YMEZqa59Nm24k2QBSw4M5JSIltSm9BCZovWMNFsdYNSHe4FQilv bjIDjZ9QI+x2c57h00I0oEwkEe48V/ZEMrJ7FlY4etjVfxx++7ZEnZajvIWvZr6mAujP sJjg== X-Gm-Message-State: APjAAAX8SOFjY/ruMlwM18aHwE+HqjJ2jMkTOJOzyC09qyVmnV76x36A 1yK3nrc27cgBUVm8CZBvm0lgVvNp2co= X-Google-Smtp-Source: APXvYqyYe7efnSaTSPVt5GH23asHNfNuTK10VZ8chZB11a1nrRUuCh47HwTbBzQDGvfziJMBuPExVw== X-Received: by 2002:a5e:9401:: with SMTP id q1mr1143414ioj.276.1559581460996; Mon, 03 Jun 2019 10:04:20 -0700 (PDT) Received: from mail-it1-f172.google.com (mail-it1-f172.google.com. [209.85.166.172]) by smtp.gmail.com with ESMTPSA id 14sm6727223itl.1.2019.06.03.10.04.19 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jun 2019 10:04:20 -0700 (PDT) Received: by mail-it1-f172.google.com with SMTP id i21so8968530ita.5 for ; Mon, 03 Jun 2019 10:04:19 -0700 (PDT) X-Received: by 2002:a05:660c:8f:: with SMTP id t15mr930261itj.107.1559581459770; Mon, 03 Jun 2019 10:04:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Mon, 3 Jun 2019 10:04:08 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Janak Amarasena Cc: Joseph Heenan , OAuth WG Content-Type: multipart/alternative; boundary="000000000000e87419058a6e5a75" Archived-At: Subject: Re: [OAUTH-WG] Device Authorization Grant Interval 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 Jun 2019 17:04:25 -0000 --000000000000e87419058a6e5a75 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Is there something wrong with using the existing error code defined for this? > slow_down > A variant of "authorization_pending", the authorization request is > still pending and polling should continue, but the interval MUST > be increased by 5 seconds for this and all subsequent requests. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15#section-3.5 ---- Aaron Parecki aaronparecki.com @aaronpk On Mon, Jun 3, 2019 at 9:55 AM Janak Amarasena wrote: > Hi Joseph, > > Thank you for the information, this what I was also thinking. It would be > nice if this can be defined in the specification itself, maybe as a > recommendation as there can be wrongly written client applications or eve= n > if some party is trying to do a brute force attack. > > Best Regards, > Janak > > On Sun, Jun 2, 2019 at 1:40 PM Joseph Heenan wrote: > >> Hi Janak, >> >> Interestingly this came up when discussing the CIBA specification (which >> builds upon device authorization grant to some extent) recently: >> https://bitbucket.org/openid/mobile/issues/135/token-endpoint-response-w= hen-client-polls >> >> The thought that group came up with is that returning =E2=80=98invalid_r= equest=E2=80=99 >> would be appropriate - ideally appropriate error_description to make it >> easy to understand what=E2=80=99s going on. >> >> Cheers, >> >> Joseph >> >> >> > On 21 May 2019, at 06:21, Janak Amarasena >> wrote: >> > >> > Hi all, >> > >> > In the OAuth2 Device Authorization Grant, what would be an appropriate >> response if the client does not respect the set polling interval and kee= ps >> on polling with a lower interval? >> > >> > Thank you, >> > Best Regards, >> > >> > Janak Amarasena >> > _______________________________________________ >> > 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 > --000000000000e87419058a6e5a75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is there something wrong with using the existing erro= r code defined for this?

>=C2=A0 =C2=A0 slow_do= wn
>=C2=A0 =C2=A0 =C2=A0 A variant of "authorization_pending&q= uot;, the authorization request is
>=C2=A0 =C2=A0 =C2=A0 still pendin= g and polling should continue, but the interval MUST
>=C2=A0 =C2=A0 = =C2=A0 be increased by 5 seconds for this and all subsequent requests.
=

----
=
Aaron Parecki



On Mo= n, Jun 3, 2019 at 9:55 AM Janak Amarasena <janakama360@gmail.com> wrote:
Hi=C2=A0Joseph,

<= /div>
Thank you for the information, this what I was also thinking. It = would be nice if this can be defined in the specification itself, maybe as = a recommendation as there can be wrongly written client applications or eve= n if some party is trying to do a brute force attack.

<= div>Best Regards,
Janak

On Sun, Jun 2, 2019 at 1:40 PM Josep= h Heenan <josep= h@authlete.com> wrote:
Hi Janak,

Interestingly this came up when discussing the CIBA specification (which bu= ilds upon device authorization grant to some extent) recently: https://bitbucket.org/op= enid/mobile/issues/135/token-endpoint-response-when-client-polls

The thought that group came up with is that returning =E2=80=98invalid_requ= est=E2=80=99 would be appropriate - ideally appropriate error_description t= o make it easy to understand what=E2=80=99s going on.

Cheers,

Joseph


> On 21 May 2019, at 06:21, Janak Amarasena <janakama360@gmail.com> wrote:
>
> Hi all,
>
> In the OAuth2 Device Authorization Grant, what would be an appropriate= response if the client does not respect the set polling interval and keeps= on polling with a lower interval?
>
> Thank you,
> Best Regards,
>
> Janak Amarasena
> _______________________________________________
> 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
--000000000000e87419058a6e5a75-- From nobody Mon Jun 3 10:05:41 2019 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 6D5C01206CD for ; Mon, 3 Jun 2019 10:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.508 X-Spam-Level: X-Spam-Status: No, score=-17.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 jaHkypzM7rVc for ; Mon, 3 Jun 2019 10:05:32 -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 6A6BE12071C for ; Mon, 3 Jun 2019 10:05:29 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id d17so2574937oth.5 for ; Mon, 03 Jun 2019 10:05:29 -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=OPqA85ynSIsybwfeD4QGyuZJrswxAjRXuR446d/RBHw=; b=NDoe6mWNiqwzembDZb8eE+fOzBGOXpJMYahJNnXuaOJXAnI6Yh2RDQy2ndH0Dqz64b 2Yjl0PBjZJ6MHHE4zNnDV6lE6N3vaYtqJmPmIp6XQ+pVnHu28GrwiMssOAZaNVBEYPt1 g8tWg6mYrGBlhHLVsMXdetEX1u4BFWoE+TCX+kl/UlSFQ6HCsQvK9K51TDDz5gj9bZmv annDsxOV/Vy6vdShtp/wJPACwtZ5oVtocnlLri/DV5WEZvXMuin55hCPN0yghmkSdwuX NFGB5H0HpTvFqbfsQqCDJKkNQtCPIABZ/5YkjDyNZI0jeXnsWlW9M6oTH511BN2ccgqp VdZw== 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=OPqA85ynSIsybwfeD4QGyuZJrswxAjRXuR446d/RBHw=; b=VOsIwPt4Jm2Gqja/h8+6VdgDl4VbU5q8x2guN1tUHFhK/1ZQo1DI2sOJ8Tj1l4vhU2 IGxqnZIALPicFR8Rpeb9TCVg3KIz5OIS9CcDweenuXAwKTVe+zKIhJEsjl2O3kb6qvMm sCi+TSjbSjLm80E98kI/ADn0t7YDkn4moAqsUc1cDhNcVhyog1KIW+0e2VZkdi/W+v1I 8zqEuBCx/rLSJCHxOCNCIecA8o+U5ywEbRhux69F9fRVZTh+ajooFmGqPTPhotzcpRaf hVPOn7koBDHY3RSHvrGYypXEhZveFJtA8gmCNbNPEXqctlWRXeq+/tlu+UjA9FfANils CxHg== X-Gm-Message-State: APjAAAXyLhytgekewYiWKvxKiXWhjq4pMa0UZduRHwbCC3zrwRyky7jK 3n0aGMZTic/9QevnA5sAKsIvz1sBo6Di8kipTBZTkvwP6Fs= X-Google-Smtp-Source: APXvYqwfrUPrS4dA+jh1ctCtmchUiFnFGsDY7gRDFNc5+fRHbD5qJ1CqTpeif6wcgV9NAGg4xPCo4J964cxQ3ZTT5AY= X-Received: by 2002:a9d:3f37:: with SMTP id m52mr1851524otc.181.1559581528091; Mon, 03 Jun 2019 10:05:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: William Denniss Date: Mon, 3 Jun 2019 10:05:16 -0700 Message-ID: To: Janak Amarasena Cc: Joseph Heenan , oauth Content-Type: multipart/alternative; boundary="000000000000fb7b13058a6e5e17" Archived-At: Subject: Re: [OAUTH-WG] Device Authorization Grant Interval 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 Jun 2019 17:05:38 -0000 --000000000000fb7b13058a6e5e17 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The "slow_down" error response is defined for well-meaning clients. In my own client implementations, this has the effect of increasing the interval used . For a misbehaving client (one that doesn't honor "slow_down" and continues to poll too rapidly), a hard error as previously suggested seems appropriate. On Mon, Jun 3, 2019 at 9:55 AM Janak Amarasena wrote: > Hi Joseph, > > Thank you for the information, this what I was also thinking. It would be > nice if this can be defined in the specification itself, maybe as a > recommendation as there can be wrongly written client applications or eve= n > if some party is trying to do a brute force attack. > > Best Regards, > Janak > > On Sun, Jun 2, 2019 at 1:40 PM Joseph Heenan wrote: > >> Hi Janak, >> >> Interestingly this came up when discussing the CIBA specification (which >> builds upon device authorization grant to some extent) recently: >> https://bitbucket.org/openid/mobile/issues/135/token-endpoint-response-w= hen-client-polls >> >> The thought that group came up with is that returning =E2=80=98invalid_r= equest=E2=80=99 >> would be appropriate - ideally appropriate error_description to make it >> easy to understand what=E2=80=99s going on. >> >> Cheers, >> >> Joseph >> >> >> > On 21 May 2019, at 06:21, Janak Amarasena >> wrote: >> > >> > Hi all, >> > >> > In the OAuth2 Device Authorization Grant, what would be an appropriate >> response if the client does not respect the set polling interval and kee= ps >> on polling with a lower interval? >> > >> > Thank you, >> > Best Regards, >> > >> > Janak Amarasena >> > _______________________________________________ >> > 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 > --000000000000fb7b13058a6e5e17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The "slow_down" error response is defined for we= ll-meaning clients. In my own client implementations, this has the effect o= f increasi= ng the interval used.

For a misbehaving client (one = that doesn't honor "slow_down" and continues to poll too rapi= dly), a hard error as previously suggested seems appropriate.


On Mon, Jun 3, 2019 at 9:55 AM Janak Amarasena <janakama360@gmail.com> wrote:=
Hi=C2=A0Joseph,

Thank you for the information, this wh= at I was also thinking. It would be nice if this can be defined in the spec= ification itself, maybe as a recommendation as there can be wrongly written= client applications or even if some party is trying to do a brute force at= tack.

Best Regards,
Janak
On Sun, J= un 2, 2019 at 1:40 PM Joseph Heenan <joseph@authlete.com> wrote:
Hi Janak,

Interestingly this came up when discussing the CIBA specification (which bu= ilds upon device authorization grant to some extent) recently: https://bitbucket.org/op= enid/mobile/issues/135/token-endpoint-response-when-client-polls

The thought that group came up with is that returning =E2=80=98invalid_requ= est=E2=80=99 would be appropriate - ideally appropriate error_description t= o make it easy to understand what=E2=80=99s going on.

Cheers,

Joseph


> On 21 May 2019, at 06:21, Janak Amarasena <janakama360@gmail.com> wrote:
>
> Hi all,
>
> In the OAuth2 Device Authorization Grant, what would be an appropriate= response if the client does not respect the set polling interval and keeps= on polling with a lower interval?
>
> Thank you,
> Best Regards,
>
> Janak Amarasena
> _______________________________________________
> 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
--000000000000fb7b13058a6e5e17-- From nobody Mon Jun 3 10:24:16 2019 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 3C2171206E9 for ; Mon, 3 Jun 2019 10:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 JSr00-Ivxjd3 for ; Mon, 3 Jun 2019 10:24:13 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 858531206DE for ; Mon, 3 Jun 2019 10:24:13 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id t5so11944608wmh.3 for ; Mon, 03 Jun 2019 10:24: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=CTf9SpSFoNEE7EfqmX0CuTH+fIQL2EaGdSXqjofZINw=; b=ihTDAorNXxv8TGxVaEdmZzLdYq4OoYx+zHSBOC60qJKnJTiwoK16XPmF38NZM1N+ZE IWpWTMuLzYLxavJTzFWDUJZgibXXiUwpem4AErhz4A8QDFTKgQy+AIee43kZ1A8wQJEd 3o3J4+QhLM/ZQX/CvgaIfE4v9Iz1hDX+nyKmE7aG9C+ZHAdvDjrNyfwlTgJVywOco03B j7ieZ0BMZMlGCKV68KW1ibvYMI/vZqSeS54pcSWDRW8fB35iYotzKRl0wMQbpIfI1h5H rdQdCURBMM/+qse9mKDQlO6OTCQbfh9gzY40fJNvzREYxIOr34edY+hi7EHB+ZQngee5 vHIg== 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=CTf9SpSFoNEE7EfqmX0CuTH+fIQL2EaGdSXqjofZINw=; b=hYPV7eHLt10sovJ/BtUqT2WbpOYSAo5PfJ2kQnP14WEtKyuQjvli/D2RGOemr1/Nkx 0BiCVLcWO5R/ZEXLymjP1DQqWRLlYd65GbGIK0DqjUBNv83R0msKqOf17FGVCKjmidGu xJ9Id7X8zJmjmMApPaKzfsi2YiY0QZnJBqxxPSEb5sFWIxyhN6KotSe/9MIVbNTa4Ztc AolGFSCGBpPf6A4Tg5o4kcl8Bc0RcKUI14txYQeOC9CjnrmJX5+x5ovb5msQmz8CQzzA DAD60NK3rYEqqs7hQFKJ5Aj3Lz0AJoOdFCRB9vWDJTrkDjsGpwv0rynZ7r500epPqjqi 5TMA== X-Gm-Message-State: APjAAAVcNca8TgAKRQ0HqpODloU/VxaoUN/dB1aPH0Hs1XIv1lWCFCwh F1b5D9UHhznVQIuu3k613YHuV0xKol5mnCSgRFE= X-Google-Smtp-Source: APXvYqzg7uk6lhHSHzOZ9P6YIJu4jCVrpXH2TOMEDA0S8y6JMKYMyLeA6Ocmbg0+vlZROP37QvTm/+rKXXUQ8CFrjEE= X-Received: by 2002:a1c:c282:: with SMTP id s124mr3184293wmf.141.1559582652048; Mon, 03 Jun 2019 10:24:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Janak Amarasena Date: Mon, 3 Jun 2019 22:54:03 +0530 Message-ID: To: William Denniss Cc: Joseph Heenan , oauth Content-Type: multipart/alternative; boundary="000000000000f928c3058a6ea1ff" Archived-At: Subject: Re: [OAUTH-WG] Device Authorization Grant Interval 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 Jun 2019 17:24:15 -0000 --000000000000f928c3058a6ea1ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What William said was my understanding as well. Best Regards, Janak On Mon, Jun 3, 2019 at 10:35 PM William Denniss wrote= : > The "slow_down" error response is defined for well-meaning clients. In my > own client implementations, this has the effect of increasing the > interval used > > . > > For a misbehaving client (one that doesn't honor "slow_down" and continue= s > to poll too rapidly), a hard error as previously suggested seems > appropriate. > > > > On Mon, Jun 3, 2019 at 9:55 AM Janak Amarasena > wrote: > >> Hi Joseph, >> >> Thank you for the information, this what I was also thinking. It would b= e >> nice if this can be defined in the specification itself, maybe as a >> recommendation as there can be wrongly written client applications or ev= en >> if some party is trying to do a brute force attack. >> >> Best Regards, >> Janak >> >> On Sun, Jun 2, 2019 at 1:40 PM Joseph Heenan wrote= : >> >>> Hi Janak, >>> >>> Interestingly this came up when discussing the CIBA specification (whic= h >>> builds upon device authorization grant to some extent) recently: >>> https://bitbucket.org/openid/mobile/issues/135/token-endpoint-response-= when-client-polls >>> >>> The thought that group came up with is that returning =E2=80=98invalid_= request=E2=80=99 >>> would be appropriate - ideally appropriate error_description to make it >>> easy to understand what=E2=80=99s going on. >>> >>> Cheers, >>> >>> Joseph >>> >>> >>> > On 21 May 2019, at 06:21, Janak Amarasena >>> wrote: >>> > >>> > Hi all, >>> > >>> > In the OAuth2 Device Authorization Grant, what would be an appropriat= e >>> response if the client does not respect the set polling interval and ke= eps >>> on polling with a lower interval? >>> > >>> > Thank you, >>> > Best Regards, >>> > >>> > Janak Amarasena >>> > _______________________________________________ >>> > 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 >> > --000000000000f928c3058a6ea1ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What William said was my understanding as well.

Best Regards,
Janak

On Mon, Jun 3, 2019 at 10:35 PM= William Denniss <wdenniss@google= .com> wrote:
The "slow_down" error response is defined fo= r well-meaning clients. In my own client implementations, this has the effe= ct of increasing the interval used.

For a mi= sbehaving client (one that doesn't honor "slow_down" and cont= inues to poll too rapidly), a hard error as previously suggested seems appr= opriate.



On Mon, Jun 3, 2019 at 9:55 AM = Janak Amarasena <janakama360@gmail.com> wrote:
Hi=C2=A0Joseph,

Thank you for the information, this what I was also thinking. It would be= nice if this can be defined in the specification itself, maybe as a recomm= endation as there can be wrongly written client applications or even if som= e party is trying to do a brute force attack.

Best= Regards,
Janak

On Sun, Jun 2, 2019 at 1:40 PM Joseph Heenan= <joseph@authle= te.com> wrote:
Hi Janak,

Interestingly this came up when discussing the CIBA specification (which bu= ilds upon device authorization grant to some extent) recently: https://bitbucket.org/op= enid/mobile/issues/135/token-endpoint-response-when-client-polls

The thought that group came up with is that returning =E2=80=98invalid_requ= est=E2=80=99 would be appropriate - ideally appropriate error_description t= o make it easy to understand what=E2=80=99s going on.

Cheers,

Joseph


> On 21 May 2019, at 06:21, Janak Amarasena <janakama360@gmail.com> wrote:
>
> Hi all,
>
> In the OAuth2 Device Authorization Grant, what would be an appropriate= response if the client does not respect the set polling interval and keeps= on polling with a lower interval?
>
> Thank you,
> Best Regards,
>
> Janak Amarasena
> _______________________________________________
> 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
--000000000000f928c3058a6ea1ff-- From nobody Mon Jun 3 12:00:15 2019 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 4ACDE12075D for ; Mon, 3 Jun 2019 12:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSLSujOQQqQA for ; Mon, 3 Jun 2019 12:00:07 -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 426C012067C for ; Mon, 3 Jun 2019 12:00:07 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id e3so15216547ioc.12 for ; Mon, 03 Jun 2019 12:00:07 -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=W/FmHmFK4Zhu5iMH9LWksWTv7o4ub4gOU4fsGrOKePI=; b=GcctOnsq0avXzah73CLZWTnUNpSqkDrnV79gUshfVV7Hvc+B6MM1LFLzpOceOqOSwZ rJzJLnU2+sFCvJdLNYChoekfu0h6aNv7iP1hEDvg8PqzU+5FS35MdM5uakR1j2aFyLtZ gi3jqJPvYTrD+aNUoeo4d6c8CeJxdR3ptnEzLKHUKNZJQl56ZLPiH6LyRZoe9axleEAS exycsh6o2Jqybow4H8i1PvL4y5c/eEZe02/hEb/WgvIM+Wn+EhPijAbj8cFJR2H0xylk 3JppuCzZ8mo1owru1D2ab0rsa6ZjFIRY6yZku0bwYGgC4/G/EXKYLfS4Kcvoscxc4lxj dL5A== 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=W/FmHmFK4Zhu5iMH9LWksWTv7o4ub4gOU4fsGrOKePI=; b=Y+rEH0Z3PuodFTPj6h2xksDkc5j2ex/Mk6u9/k1EUZADXClXqLduuptxPdK4K/78dF SO6za0IyJbHYvkHKwcOFeKnpsQ75BFfLMGQuq7FsCoMuJjXVLTfZeEBbOgk4Irrax2w1 /dTIjdNqQes3Vc4ZGZsdh4uIqJlWNWV2xMfkrO1S+dms/OySq3Q1SuMSFlN3pWiXSimf WWvcX6aHba1XLs3tmPFM45zrU6P9Sa1jiEn8roDaHl3zgwHHFFRZ5AJYLnFHiNcsAPwL qOuUVJygrF+Xr9CHfPhKzWFteJ4jmxS0ipqCYu7kd3eR37jnfl2VzneDp0SvNEmujQa3 dI6A== X-Gm-Message-State: APjAAAVlrEx1EjSb0q6FojaSPx0rUActuL2pFjvlc41P7suEDt9F0loo VpYEZUMUW8r/bM5+dkXyvkqf9UdXx59FE48ECP/2IDLaYt+3OQ== X-Google-Smtp-Source: APXvYqxSThs6Lrzw0exHg3xO8dvR2ZQD6HfZD6aC4TP5QUsur4iO1nrd/eSkDL1d3bBlMBeJ+NH5uZSz0GaglOxHxPE= X-Received: by 2002:a6b:9257:: with SMTP id u84mr16686642iod.278.1559588406224; Mon, 03 Jun 2019 12:00:06 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Mon, 3 Jun 2019 14:59:55 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000f2ec9f058a6ff8a4" Archived-At: Subject: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-jwt-introspection-response-03 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 Jun 2019 19:00:14 -0000 --000000000000f2ec9f058a6ff8a4 Content-Type: text/plain; charset="UTF-8" All, The following is the shepherd write-up for the draft-ietf-oauth-jwt-introspection-response-03 document: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/shepherdwriteup/ Please, take a look and let us know if you have any comments. Regards, Rifaat --000000000000f2ec9f058a6ff8a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

The following is the shepherd write-up for the= draft-ietf-oauth-jwt-introspection-response-03 document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-intr= ospection-response/shepherdwriteup/

Please, take a look and let = us know if you have any comments.

Regards,
=C2=A0Rifaat
<= br>
--000000000000f2ec9f058a6ff8a4-- From nobody Mon Jun 3 19:10:36 2019 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 EBF53120161 for ; Mon, 3 Jun 2019 19:10:34 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 87bwnEmUfCqq for ; Mon, 3 Jun 2019 19:10:33 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0: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 F2B3C120018 for ; Mon, 3 Jun 2019 19:10:32 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id 20so9378207pgr.4 for ; Mon, 03 Jun 2019 19:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=JhXTZ3wkbh91UukZ3NnFvGiBf97wBM++297/p22Z4G4=; b=BX66eUCAC255DeunhjoHOh/cNTzkm+ZvfnAOLtctaCBUnbrZNML/c5jCQs1W2WNWxo iuGaqOzWeWkYq/crAW6FyJQYTz9CVGDRSM5VoR4O0XSol5lWym7D/ojFzqSDJclnEMUr gVRCcCXhjLTMwXbkTV3+/8+ghbtphX/ZyKDniJjchxAfWvQgt+uXWhM1or5r3+8R+wf7 ySzE0DeVPRzSbInSfy2uyXxnZ/pgaslHxJVgdQF8hA2etSL+pkgulN9O1pldNRFS8De2 vJkm5PWPEdP2BFjvKwG+cUaBoaxJpN6q/lvxEZmnIidobNTrfxAwdXnE5WmEQQt8vA07 /A/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JhXTZ3wkbh91UukZ3NnFvGiBf97wBM++297/p22Z4G4=; b=OqEHa+5XYWeuYOZzgQSLrU2zxDo1fLJPlI9tdb2DOWOKJN5eKIiVXu1iLr+GSU+pBq KNdc0Icu59EoEQLidaOAaPpot+ggd0CZKWIngSdfwSRAU4V2N1X1VxOv3s4AgfSGghjn 1mAjZXAR9LYEMSNh9P6FusbVOeVVDR5a96MG6jU6SMKm3L0emVhW7WJUGRUESkpDIhuA hIyi1hU+sYE0yyhHPZwQ7Ls95SpRcX+Wrz4HbWAS2V61zvvHKqKLpiewgJ3k27yTbGqU mA27pMWAcyrJh8TfSuLLhQ2c8qVgrc1T/rRADtaIdZiAQHPTviaTa5650V4BwrsEY5OK ClNA== X-Gm-Message-State: APjAAAWt0ETr9jAJDfvOAiyI9NWMZSeApW2EdF2XWd86zhpX2o1BnwSO 5v0UKkBjyi9ZzJZxj/srXLIOXBGyf1ZsEoFWmuiVjfGeFNWNuw== X-Google-Smtp-Source: APXvYqwZnf361gJ4v3wpX7gQcibnZrNIENejgnhtWhz0rSf1oxnFb2D6GomkqwnH41WL37OcfIfezpV4ZmyZjjTfPnI= X-Received: by 2002:a65:51c7:: with SMTP id i7mr32678873pgq.211.1559614231897; Mon, 03 Jun 2019 19:10:31 -0700 (PDT) MIME-Version: 1.0 From: Takahiko Kawasaki Date: Tue, 4 Jun 2019 11:10:21 +0900 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000477dc0058a75fc70" Archived-At: Subject: [OAUTH-WG] Client Authentication Method at Device Authorization Endpoint 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, 04 Jun 2019 02:10:35 -0000 --000000000000477dc0058a75fc70 Content-Type: text/plain; charset="UTF-8" Hello, Do you have any plan to define a rule as to which client authentication method should be used at the device authorization endpoint (which is defined in OAuth 2.0 Device Authorization Grant )? Section 4 of CIBA , which has incorporated some ideas/rules/parameters from Device Flow, says as follows. *The token_endpoint_auth_method indicates the registered authentication method for the client to use when making direct requests to the OP, including requests to both the token endpoint and the backchannel authentication endpoint.* This means that a backchannel authentication endpoint in CIBA (which corresponds to a device authorization endpoint in Device Flow) performs client authentication using the client authentication method specified by the token_endpoint_auth_method metadata of the client. I'd like to know if you have any plan to explicitly add a description like above into the specification of OAuth 2.0 Device Authorization Grant. Best Regards, Takahiko Kawasaki Authlete, Inc. --000000000000477dc0058a75fc70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Do you have any plan to define a= rule as to which client authentication method should be used at the device= authorization endpoint (which is defined in OAuth 2.0 Dev= ice Authorization Grant)?

Section 4 of CIBA, which has incorporated some ideas/rules/p= arameters from Device Flow, says as follows.

Th= e token_endpoint_auth_method indicates the registered authentication method= for the client to use when making direct requests to the OP, including req= uests to both the token endpoint and the backchannel authentication endpoin= t.

This means that a backchannel authentic= ation endpoint in CIBA (which corresponds to a device authorization endpoin= t in Device Flow) performs client authentication using the client authentic= ation method specified by the token_endpoint_auth_method metadata of the cl= ient.

I'd like to know if you have any plan to= explicitly add a description like above into the specification of OAuth 2.= 0 Device Authorization Grant.

Best Regards,
<= div>Takahiko Kawasaki
Authlete, Inc.

--000000000000477dc0058a75fc70-- From nobody Mon Jun 3 22:33:12 2019 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 8CA031200B4 for ; Mon, 3 Jun 2019 22:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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] 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 l011zp0NxANm for ; Mon, 3 Jun 2019 22:33:09 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 2AD81120059 for ; Mon, 3 Jun 2019 22:33:09 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id d17so5658497wmb.3 for ; Mon, 03 Jun 2019 22:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/UXO5GANSY+FYsiZMiuZ1+U2VG7tsC5cx4de77hc7Gw=; b=YRcq0xxPJubjvmB7wg+3wmHpJIyVFw7VIohbczHO/glJ8zsq3WcxEF1sj+CBBp1KpD HEGwXXqjVPwzuncLQf4QgNAlqRcZ5Kn3hOMLtt57XfgOrPkjZo0lOPy7OFUPfOhDk60M Nq1NEURZxKW7ukeTVRmYmswmS8bVDpuECNzb3A9P0/0Xgs32aCQWp2Qc59QNht8VREx5 RCTWyUSdTVBP0LD5uU1kxcd40zIdqlJgRQsGgiuimEV30hjzvLnCzI/oafjhzMIeAjcU 8xJbDboMGHNBUa1Roo8LoJYKOI8rK+mhtTGP/wWunEVBmBl4vvd2fkkBTwPo2WMrEYvC eaiw== 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=/UXO5GANSY+FYsiZMiuZ1+U2VG7tsC5cx4de77hc7Gw=; b=hGo/FxjTX+ZVV0fjFCT2Yen1xIP2ceH82hBplVzFXFhhotmXHckqqZMAnCKwgho+7+ 7ps5sJCFT6iXCAmxN1bGD4H6GgF0MvxdSrqGWucgZmdO0nHI5CMS7Fn9Ar44s5x4CKxh s0S/giClOiU0yaOoXSWibFWZ9U8VU5lgpHTk+aMBedbHVOO/UYAHCFdWH4V1YhUnERyB FVejFWlMKCpoJB9P2ybdl9LDEl1gYfcIkRsh29yiw5XwspwqaeoCojEaZxFg7ZF7ppyH JvLBAgEV+1x8gEn7pDHG2ITj04CxH6NhI3h1QkT1Fi7PiUBnUD+0TzqtFqJYCK5I9bYO deIg== X-Gm-Message-State: APjAAAU+dzxOOfRWynt1CQ1qAHAV44dMz4Mb93bZOaOScbWsXl0tJlEH jdOcFDorx4ULR7hpSw2HLyI2zjFsBQ== X-Google-Smtp-Source: APXvYqxhZb2GmLKuRcwA0Yt520E9swP3u3b3IV1yMloQ/4/3qJZ7CGaZuT33fJ01bEpkQKNrwPfUJA== X-Received: by 2002:a1c:e90c:: with SMTP id q12mr16718420wmc.128.1559626387246; Mon, 03 Jun 2019 22:33:07 -0700 (PDT) Received: from [192.168.0.178] (ip-78-45-222-80.net.upcbroadband.cz. [78.45.222.80]) by smtp.gmail.com with ESMTPSA id s8sm30455145wra.55.2019.06.03.22.33.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jun 2019 22:33:06 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C445AC63-4C5E-4C1A-BB71-29A5695CFD9A Mime-Version: 1.0 (1.0) From: Filip Skokan X-Mailer: iPhone Mail (16E227) In-Reply-To: Date: Tue, 4 Jun 2019 07:33:03 +0200 Cc: oauth Content-Transfer-Encoding: 7bit Message-Id: <17783579-0738-4F20-985E-6A6EDF847FC8@gmail.com> References: To: Takahiko Kawasaki Archived-At: Subject: Re: [OAUTH-WG] Client Authentication Method at Device Authorization Endpoint 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, 04 Jun 2019 05:33:12 -0000 --Apple-Mail-C445AC63-4C5E-4C1A-BB71-29A5695CFD9A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Takahiko, Such language already exists in second to last paragraph of section 3.1. Lik= e with CIBA the client=E2=80=99s regular token endpoint auth method is used a= t the device authorization endpoint.=20 > The client authentication requirements of Section 3.2.1 of [RFC6749] apply= to requests on this endpoint, which means that confidential clients (those t= hat have established client credentials) authenticate in the same manner as w= hen making requests to the token endpoint, and public clients provide the "c= lient_id" parameter to identify themselves. Odesl=C3=A1no z iPhonu 4. 6. 2019 v 4:10, Takahiko Kawasaki : > Hello, >=20 > Do you have any plan to define a rule as to which client authentication me= thod should be used at the device authorization endpoint (which is defined i= n OAuth 2.0 Device Authorization Grant)? >=20 > Section 4 of CIBA, which has incorporated some ideas/rules/parameters from= Device Flow, says as follows. >=20 > The token_endpoint_auth_method indicates the registered authentication met= hod for the client to use when making direct requests to the OP, including r= equests to both the token endpoint and the backchannel authentication endpoi= nt. >=20 > This means that a backchannel authentication endpoint in CIBA (which corre= sponds to a device authorization endpoint in Device Flow) performs client au= thentication using the client authentication method specified by the token_e= ndpoint_auth_method metadata of the client. >=20 > I'd like to know if you have any plan to explicitly add a description like= above into the specification of OAuth 2.0 Device Authorization Grant. >=20 > Best Regards, > Takahiko Kawasaki > Authlete, Inc. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-C445AC63-4C5E-4C1A-BB71-29A5695CFD9A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Takahiko,

Such lan= guage already exists in second to last paragraph of section 3.1. Like with C= IBA the client=E2=80=99s regular token endpoint auth method is used at the d= evice authorization endpoint. 

<=
font face=3D"UICTFontTextStyleBody">> The client authentication requir=
ements of Sect=
ion 3.2.1 of [RFC6749]
   apply to requests on this endpoint, which means that confidential
   clients (those that have established client credentials) authenticate
   in the same manner as when making requests to the token endpoint, and
   public clients provide the "client_id" parameter to identify
   themselves.

Odesl=C3=A1no z iPhonu

4. 6. 2019 v = ;4:10, Takahiko Kawasaki <taka@authl= ete.com>:

Hello,

Do you have any plan to define a rul= e as to which client authentication method should be used at the device auth= orization endpoint (which is defined in OAuth 2.0 Device Au= thorization Grant)?

Section 4 of CIBA, which has incorporated some ideas/rules/parameters= from Device Flow, says as follows.

The token_en= dpoint_auth_method indicates the registered authentication method for the cl= ient to use when making direct requests to the OP, including requests to bot= h the token endpoint and the backchannel authentication endpoint.

This means that a backchannel authentication endpoint= in CIBA (which corresponds to a device authorization endpoint in Device Flo= w) performs client authentication using the client authentication method spe= cified by the token_endpoint_auth_method metadata of the client.
<= br>
I'd like to know if you have any plan to explicitly add a desc= ription like above into the specification of OAuth 2.0 Device Authorization G= rant.

Best Regards,
Takahiko Kawasaki
Authlete, Inc.

________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-C445AC63-4C5E-4C1A-BB71-29A5695CFD9A-- From nobody Mon Jun 3 23:11:26 2019 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 B767A1200F1 for ; Mon, 3 Jun 2019 23:11:24 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 8X_-u1bd_YYf for ; Mon, 3 Jun 2019 23:11:22 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 0179A1200A4 for ; Mon, 3 Jun 2019 23:11:21 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id p1so7905960plo.2 for ; Mon, 03 Jun 2019 23:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aV2TSLlaXz+efC4yn8hLpWhAuwMD6vPp/Wg4zJso6cc=; b=SVR0zfHCAqNhpXAeGYlLuyGNkRVNLMhqMrWLcmAYWGdttjBFsLpeZLGBmIRLfXv6a1 M5bEG4/nGVEv6JLx1FLc7wjRPMa4sugqiwPFDU28kAgid9txZAS7qasJzQBifkL5upn7 I/bEbJVu40BqMTmz/L+wtY8UhuAXn58CtvEy+CQT1ZMmiu6q/9P8Ec/l6oKnCYKvhfY3 RsQ5TlFyOL2ZflLoDHEwXHGt6JtgDL4vX8vgu0cpKzuxuwBEIkOy0pKFiWlBVcoIngmE /pdBq7A1CCYR8F6qDuibDkICa1oTttB94Wgv1B63bdMAnN+Mjg8pmgF6oXafptEOkhgv J4Vw== 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=aV2TSLlaXz+efC4yn8hLpWhAuwMD6vPp/Wg4zJso6cc=; b=osccX4rrE0ZY44gQq66gw4LDsxSfZro45iA/Dsf1gzojcwbJBVfafMvoEcrNcYgW78 hLd+sB4s8sC13h4MHT9yDIO+Zu/6EKB2nesmEIpKCQcCnrF5aejEPFuSrp5W9T6eTW98 t+PVpnR5a4+QTVZYMxDj/64297fP9md/eXN6fMrpGgnVRAlTnjoqMDlEQ+YZglufwoiL 1X56lsBzef3VycmFSPJX3b3DVeFHm+zcvHLL2gxlVk833xRp6xgzoeb/A2qtmdNvb3JF h3/p1xWQfB6SK6rNaBLCvCbi9oJxPMavbCR7/r9HArTDq5rwiwFfSN0shGbT8F59SsIF hNyw== X-Gm-Message-State: APjAAAWzl+VG5vw2N8A2sjuTjTFadrZp2VjoIPWXsKW1XtQ+mvkWT+NG F+OFOEmrj7/rfGwjOyBC9mQMKHrjCTcB92rToNn7/w== X-Google-Smtp-Source: APXvYqxPXyakdw2hugEp9nocOvPK97lC6KgASwH6ezweIukNXgw+1gnUQP+swQ4imQea/3pThgc/8ZRxGMooBkCTtT0= X-Received: by 2002:a17:902:968b:: with SMTP id n11mr707342plp.120.1559628681398; Mon, 03 Jun 2019 23:11:21 -0700 (PDT) MIME-Version: 1.0 References: <17783579-0738-4F20-985E-6A6EDF847FC8@gmail.com> In-Reply-To: <17783579-0738-4F20-985E-6A6EDF847FC8@gmail.com> From: Takahiko Kawasaki Date: Tue, 4 Jun 2019 15:11:10 +0900 Message-ID: To: Filip Skokan Cc: oauth Content-Type: multipart/alternative; boundary="00000000000089610a058a79599a" Archived-At: Subject: Re: [OAUTH-WG] Client Authentication Method at Device Authorization Endpoint 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, 04 Jun 2019 06:11:25 -0000 --00000000000089610a058a79599a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Filip, Thank you for your comment. Historically, metadata related to client authentication methods have been defined for each endpoint such as token endpoint, introspection endpoint and revocation endpoint. When defining the CIBA specification, we discussed whether to define a new metadata for client authentication methods for the backchannel authentication endpoint. The final decision is "not define but reuse metadata defined for token endpoint". See Issue 102 "CIBA: Metadata for client auth at backchannel endpoint" of MODRNA WG for details. This is the reason the CIBA specification explicitly says as follows: *The token_endpoint_auth_method indicates the registered authentication method for the client to use when making direct requests to the OP, including requests to both the token endpoint and the backchannel authentication endpoint.* What I'm asking is whether to (1) allow authorization server implementations to auto-detect the client authentication method used by a device authorization request at runtime based on request parameters such as (a) client_id & client_secret (client_secret_post), (b) client_assertion & client_assertion_type (client_secret_jwt or private_key_jwt), (c) Authorization header (client_secret_basic) or (d) a client certificate (tls_client_auth or self_signed_tls_client_auth), or (2) use the pre-configured client authentication method only and reject/ignore other client authentication methods. For the latter case, one more point is whether to (1) define a new metadata that represents the client authentication method at the device authorization endpoint or (2) reuse the existing metadata defined for the token endpoint. Best Regards, Takahiko Kawasaki 2019=E5=B9=B46=E6=9C=884=E6=97=A5(=E7=81=AB) 14:33 Filip Skokan : > Hello Takahiko, > > Such language already exists in second to last paragraph of section 3.1. > Like with CIBA the client=E2=80=99s regular token endpoint auth method is= used at > the device authorization endpoint. > > > The client authentication requirements of Section 3.2.1 of [RFC6749] > apply to requests on this endpoint, which means that confidential > clients (those that have established client credentials) authenticate > in the same manner as when making requests to the token endpoint, and > public clients provide the "client_id" parameter to identify > themselves. > > > Odesl=C3=A1no z iPhonu > > 4. 6. 2019 v 4:10, Takahiko Kawasaki : > > Hello, > > Do you have any plan to define a rule as to which client authentication > method should be used at the device authorization endpoint (which is > defined in OAuth 2.0 Device Authorization Grant > > )? > > Section 4 of CIBA > , > which has incorporated some ideas/rules/parameters from Device Flow, says > as follows. > > > *The token_endpoint_auth_method indicates the registered authentication > method for the client to use when making direct requests to the OP, > including requests to both the token endpoint and the backchannel > authentication endpoint.* > > This means that a backchannel authentication endpoint in CIBA (which > corresponds to a device authorization endpoint in Device Flow) performs > client authentication using the client authentication method specified by > the token_endpoint_auth_method metadata of the client. > > I'd like to know if you have any plan to explicitly add a description lik= e > above into the specification of OAuth 2.0 Device Authorization Grant. > > Best Regards, > Takahiko Kawasaki > Authlete, Inc. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00000000000089610a058a79599a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Filip,

Thank you = for your comment. Historically, metadata related to client authentication m= ethods have been defined for each endpoint such as token endpoint, introspe= ction endpoint and revocation endpoint. When defining the CIBA specificatio= n, we discussed whether to define a new metadata for client authentication = methods for the backchannel authentication endpoint. The final decision is = "not define but reuse metadata defined for token endpoint". See <= a href=3D"https://bitbucket.org/openid/mobile/issues/102">Issue 102 "C= IBA: Metadata for client auth at backchannel endpoint" of MODRNA W= G for details. This is the reason the CIBA specification explicitly says as= follows:

The token_endpoint_auth_method indicates the re= gistered authentication method for the client to use when making direct req= uests to the OP, including requests to both the token endpoint and the back= channel authentication endpoint.

What I'm asking is whether to (1) allow authorization server= implementations to auto-detect the client authentication method used by a = device authorization request at runtime based on request parameters such as= (a) client_id & client_secret (client_secret_post), (b) client_asserti= on & client_assertion_type (client_secret_jwt or private_key_jwt), (c) = Authorization header (client_secret_basic) or (d) a client certificate (tls= _client_auth or self_signed_tls_client_auth), or (2) use the pre-configured= client authentication method only and reject/ignore other client authentic= ation methods. For the latter case, one more point is whether to (1) define= a new metadata that represents the client authentication method at the dev= ice authorization endpoint or (2) reuse the existing metadata defined for t= he token endpoint.

Best Regards,
Takahik= o Kawasaki

2019=E5=B9=B46=E6=9C=884=E6=97=A5(=E7=81=AB) 14:= 33 Filip Skokan <panva.ip@gmail.co= m>:
Hello Takahiko,

Such language already exist= s in second to last paragraph of section 3.1. Like with CIBA the client=E2= =80=99s regular token endpoint auth method is used at the device authorizat= ion endpoint.=C2=A0

> The client authentication requ=
irements of Section=C2=A03.2.1 of [RFC6749]
   apply to requests on this endpoint, which means that confidential
   clients (those that have established client credentials) authenticate
   in the same manner as when making requests to the token endpoint<=
u>, and
   public clients provide the "client_id" parameter to identify
   themselves.

Odesl=C3=A1no z=C2=A0iPhonu

4. 6. 2019 v=C2=A04:10, Takahiko Kawasaki <taka@authlete.com>:

Hello,
=
Do you have any plan to define a rule as to which client aut= hentication method should be used at the device authorization endpoint (whi= ch is defined in OAuth 2.0 Device Autho= rization Grant)?

Section 4 of CIBA, which has incorporated some idea= s/rules/parameters from Device Flow, says as follows.

<= div>The token_endpoint_auth_method indicates the registered authenticati= on method for the client to use when making direct requests to the OP, incl= uding requests to both the token endpoint and the backchannel authenticatio= n endpoint.

This means that a backchannel = authentication endpoint in CIBA (which corresponds to a device authorizatio= n endpoint in Device Flow) performs client authentication using the client = authentication method specified by the token_endpoint_auth_method metadata = of the client.

I'd like to know if you have an= y plan to explicitly add a description like above into the specification of= OAuth 2.0 Device Authorization Grant.

Best Regard= s,
Takahiko Kawasaki
Authlete, Inc.

_______= ________________________________________
OAuth mailing list=
OAuth@= ietf.org
https://www.ietf.org/mailman/listinfo/oauth=
--00000000000089610a058a79599a-- From nobody Tue Jun 4 06:06:24 2019 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 B95CF120041 for ; Tue, 4 Jun 2019 06:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.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 2zuCSFkcTpfR for ; Tue, 4 Jun 2019 06:06:20 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130055.outbound.protection.outlook.com [40.107.13.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C33120025 for ; Tue, 4 Jun 2019 06:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KyxAQU46hPRN/EKebzUb5YM+/G9xLwP9zieps2KaPxk=; b=Cgaa7LX99HfSGBUoc3qjR4aG9yz4Vj28wU2zqn72aa6Hfe9kzrLDR34bKciKZ5aGRcst7qEuHVqnxkrkToWA1e6+cyNkIIeiBawpEt283GHIP1Q9W1N6Sv2RyFdQkJKyBxqvx+b3XwH+N2oPJFXfCACI7/n6JUFPK8U8vUAMFaE= Received: from VI1PR08MB5360.eurprd08.prod.outlook.com (52.133.244.88) by VI1PR08MB4605.eurprd08.prod.outlook.com (20.178.13.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.17; Tue, 4 Jun 2019 13:06:16 +0000 Received: from VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::4014:31c8:2ea3:7afd]) by VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::4014:31c8:2ea3:7afd%2]) with mapi id 15.20.1943.018; Tue, 4 Jun 2019 13:06:16 +0000 From: Hannes Tschofenig To: "oauth@ietf.org" Thread-Topic: Virtual Interim Meeting: Doodle Poll Thread-Index: AdUVU6RjNye+1DF9QQKpneYB5r0XQAFggfvg Date: Tue, 4 Jun 2019 13:06:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: a4e0ebdd-3f1e-4d22-b83e-e7f207d6d646.0 x-checkrecipientchecked: true authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.119] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 11073572-4864-46f8-88aa-08d6e8ed6db8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR08MB4605; x-ms-traffictypediagnostic: VI1PR08MB4605: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0058ABBBC7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(376002)(346002)(136003)(366004)(199004)(189003)(40434004)(53754006)(102836004)(6916009)(9686003)(26005)(486006)(256004)(2351001)(55016002)(6306002)(6506007)(99286004)(6246003)(7696005)(446003)(11346002)(14444005)(186003)(76116006)(68736007)(4326008)(66476007)(64756008)(66946007)(53936002)(606006)(66556008)(476003)(66446008)(53546011)(76176011)(73956011)(54896002)(966005)(478600001)(71200400001)(25786009)(5660300002)(229853002)(14454004)(33656002)(8936002)(316002)(2501003)(2906002)(72206003)(1730700003)(81156014)(81166006)(236005)(66066001)(8676002)(7736002)(6436002)(6116002)(74316002)(5640700003)(71190400001)(5024004)(3846002)(86362001)(52536014)(790700001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR08MB4605; H:VI1PR08MB5360.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2nmtYxtuJgqt7fE4fNNrgy3CR96Ysuby675CAo6B59bB8aqwmQlKAH044BDL6AxMSZlBaA4XOQi7NO4jm9jJQV1NsjWW4GPGaqMr7lOp4ohHCl8FhvHAXAwztcEjRj2joVKaZS6kOIzEN4uHESlqelSrR+H4qNUK/NU9jY0XsSetWyWT5kkFFpbofR4dh9MZNwClJkHZZEqWzN8pOjBatLz9hZ97JjhsKhrdXC8GaRiYXf5Xq780vT3AFJEsQ+KF5QKIrUeMlTB+x7znoCXje+v9jKNR7smu3XuPXybseGsCl39aPshRtDIkSRZZMyNsMKqXoElZihItw4nBjkYwJYDjB0b64XHf/Rj0MX/c7LuR1KwVknz6EQKYs5gN7ABCPKRBXCWI5SNlNpngen9t1wXkM/yaRjqR3r/T0xsXtpI= Content-Type: multipart/alternative; boundary="_000_VI1PR08MB53607E83F6D4AB38A2D60B7EFA150VI1PR08MB5360eurp_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 11073572-4864-46f8-88aa-08d6e8ed6db8 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2019 13:06:16.3746 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Hannes.Tschofenig@arm.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB4605 Archived-At: Subject: Re: [OAUTH-WG] Virtual Interim Meeting: Doodle Poll 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, 04 Jun 2019 13:06:24 -0000 --_000_VI1PR08MB53607E83F6D4AB38A2D60B7EFA150VI1PR08MB5360eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Rifaat and I decided to cancel the virtual interim meeting. The main reason is that the UMA proponents are now re-thinking their plan t= o bring the UMA work to the OAuth working group. Until they have made a fin= al decision I believe it is premature to discuss potential work in the grou= p. Because the agenda of the meeting was announced upfront already we believe = we cannot change the agenda at this point in time anymore. We will still hold our regular OAuth WG office hour, if anyone wants to cha= t with Rifaat and myself about OAuth WG business. Ciao Hannes From: Hannes Tschofenig Sent: Dienstag, 28. Mai 2019 14:51 To: oauth@ietf.org Subject: Virtual Interim Meeting: Doodle Poll Hi all, at the Prague IETF meeting we ran a bit out of time during the working grou= p session and therefore we would like to schedule an interim meeting to con= tinue the conversation about UMA. Rifaat and I have set up a Doodle poll with two possible dates (1 hour slot= s at the bi-weekly OAuth WG office hour time slots). Please indicate your a= vailability by June 6th: https://doodle.com/poll/gde6z2t3ngwcesnc Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR08MB53607E83F6D4AB38A2D60B7EFA150VI1PR08MB5360eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Rifaat and I decided to cancel the virtual interim m= eeting.

 

The main reason is that the UMA proponents are now r= e-thinking their plan to bring the UMA work to the OAuth working group. Unt= il they have made a final decision I believe it is premature to discuss pot= ential work in the group.

Because the agenda of the meeting was announced upfr= ont already we believe we cannot change the agenda at this point in time an= ymore.

 

We will still hold our regular OAuth WG office hour,= if anyone wants to chat with Rifaat and myself about OAuth WG business.

 

Ciao

Hannes

 

From: Hannes Tschofenig
Sent: Dienstag, 28. Mai 2019 14:51
To: oauth@ietf.org
Subject: Virtual Interim Meeting: Doodle Poll

 

Hi all,

 

at the Prague IETF meeting we ran a bit out of time = during the working group session and therefore we would like to schedule an= interim meeting to continue the conversation about UMA.

 

Rifaat and I have set up a Doodle poll with two poss= ible dates (1 hour slots at the bi-weekly OAuth WG office hour time slots).= Please indicate your availability by June 6th:

https://doodle.com/poll/gde6z2t3ngwcesnc

 

 

Ciao

Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR08MB53607E83F6D4AB38A2D60B7EFA150VI1PR08MB5360eurp_-- From nobody Fri Jun 7 11:08:09 2019 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 DF2BA1200F9; Fri, 7 Jun 2019 11:07:59 -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: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <155993087979.27385.4828872823557366802@ietfa.amsl.com> Date: Fri, 07 Jun 2019 11:07:59 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bcp-06.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, 07 Jun 2019 18:08:00 -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 : JSON Web Token Best Current Practices Authors : Yaron Sheffer Dick Hardt Michael B. Jones Filename : draft-ietf-oauth-jwt-bcp-06.txt Pages : 16 Date : 2019-06-07 Abstract: JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-06 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bcp-06 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 Jun 7 11:17:43 2019 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 DFE2E1201A2 for ; Fri, 7 Jun 2019 11:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 9YaP0IVbfVK9 for ; Fri, 7 Jun 2019 11:17:39 -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 22E6912010E for ; Fri, 7 Jun 2019 11:17:39 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id w9so4613883wmd.1 for ; Fri, 07 Jun 2019 11:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=9/KaKT8GLoZ03fD8nzbjs1wRobyFI9KUHGaHU/ELcdE=; b=AYCTInS6V8zjXrDvKanrbZufptPtV/6sRH5H1msuN1AK5kqIlqiFxqbm7Zm6POf3mH p8d3xyBVLommG5I4LFiEo9a1tMYiu0+s2Od8w44tZ+cZMly+coAv87YrGkLdzV4Omk+A jlqquebRmmtFK3UBWUbbeFiJuc4AMDssxmasnfXgra4q2QifHEN12nfJUdCLqGqk7Ycj GoLQNUoP86GY276T8ZSg/fyfDX8IkAEP70Ya7ujybA2f2w534qqaA8YagsGJ6xNe/KHK j9TFPF/ZwRcQBhU6tMBkEEs7sW3LVuUrSzGqwSX6/AN9nRqJx41iCXbZnAJddlgIYPZ4 9rIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9/KaKT8GLoZ03fD8nzbjs1wRobyFI9KUHGaHU/ELcdE=; b=q60RYEqpzIif11iGFP/YcPxeeMieYPShbxCaQoDSIrP88R4uo5qw+L7G2NpaX/q98g SjtUZNR/EF8UlaTebczcKqmfA5WqDvuzFGRaZ2cDxzpAkydTb0PcNMg5NoiSDu6fNL46 WfhOoQNXxVYzaK2lVGcYXHUuKhxmw1Zg6eDM+opQr4DT0xSd2U6EUH9f/hp0BEg/zOXV BggvJfdJ4i+We68QHY/RkLMMfW0D/IaBOE4+SxZMRlWWOVZv/wxRy5+bM1Gt2OviQXF5 ESDPmlAZHyx2FIE9HQySVQRJ9tP64zNP+dA32rEBNuwysQHJ682QsUXXld0RPNu3qkXZ zlBw== X-Gm-Message-State: APjAAAUbek6KYAcNIzBfXI/064rFA9WTBIxuiWRclzZOVNgEW6BMB2Py 28X3yjaxnJf7NgJhkHyqR5haQToN X-Google-Smtp-Source: APXvYqwdtiKHY0PzJjC97DA8XbhUDmNg3WKelsLcZNSqRGYwCG/b4bcKgMCGaQprEhADNhKLuMI1zg== X-Received: by 2002:a1c:23c4:: with SMTP id j187mr4674176wmj.176.1559931457393; Fri, 07 Jun 2019 11:17:37 -0700 (PDT) Received: from [10.0.0.148] (bzq-109-67-95-113.red.bezeqint.net. [109.67.95.113]) by smtp.gmail.com with ESMTPSA id q20sm6134021wra.36.2019.06.07.11.17.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jun 2019 11:17:36 -0700 (PDT) References: <155993088012.27385.9526522170989488513.idtracker@ietfa.amsl.com> To: oauth From: Yaron Sheffer X-Forwarded-Message-Id: <155993088012.27385.9526522170989488513.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 7 Jun 2019 21:17:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <155993088012.27385.9526522170989488513.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-jwt-bcp-06.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, 07 Jun 2019 18:17:42 -0000 Dear WG members, Version -06 addresses Roman's AD comments, basically separating the rationale from the recommendations to maintain the document's internal consistency. We also removed one SHOULD-level recommendation, "Sensitive information, such as passwords, SHOULD be padded before being encrypted." While length hiding would be nice in principle, standard ciphers such as AES-GCM do not provide it out of the box. Thanks, Yaron -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-oauth-jwt-bcp-06.txt Date: Fri, 07 Jun 2019 11:08:00 -0700 From: internet-drafts@ietf.org To: Michael B. Jones , Dick Hardt , Yaron Sheffer , Michael Jones A new version of I-D, draft-ietf-oauth-jwt-bcp-06.txt has been successfully submitted by Yaron Sheffer and posted to the IETF repository. Name: draft-ietf-oauth-jwt-bcp Revision: 06 Title: JSON Web Token Best Current Practices Document date: 2019-06-07 Group: oauth Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwt-bcp-06.txt Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-06 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bcp-06 Abstract: JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs. 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. The IETF Secretariat From nobody Fri Jun 7 11:27:23 2019 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 9AD96120074 for ; Fri, 7 Jun 2019 11:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 nAJtc_Q9QENb for ; Fri, 7 Jun 2019 11:27:13 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 0190C1200D6 for ; Fri, 7 Jun 2019 11:27:11 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x57IRA4F030293; Fri, 7 Jun 2019 14:27:10 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x57IRA4F030293 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1559932030; bh=hz9T1qI39J+vJ+Q07wLDBoANCreV/0EJhOg/jMj19nQ=; h=From:To:Subject:Date:References:In-Reply-To:From; b=XI/C9owsHzvQ4l+u6JvIW9Kprc84fzh0IlT+cUFcpYz2H+i1Hm7IUTTJskHu/q74+ Cc+sjbvsGuJa7nc+6lpwF1+gnQb/leWOyjSnIRvbRM3PGx1ILjR+/O8mTs8Hmxy9A1 ejdnDKESnlunxn38UhkCfxfWclOmmfZDPhY1XAuU= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x57IR716042694; Fri, 7 Jun 2019 14:27:07 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Fri, 7 Jun 2019 14:27:06 -0400 From: Roman Danyliw To: Yaron Sheffer , oauth Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-jwt-bcp-06.txt Thread-Index: AQHVHV1WfdxJKPB+Dkm0hNLHJv+bnaaQglrQ Date: Fri, 7 Jun 2019 18:27:06 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B338896A@marathon> References: <155993088012.27385.9526522170989488513.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-jwt-bcp-06.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, 07 Jun 2019 18:27:16 -0000 Hi Yaron! Thanks for this quick update. It addresses my feedback. I'll advance the = document. Roman > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Yaron Sheffer > Sent: Friday, June 07, 2019 2:18 PM > To: oauth > Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth- > jwt-bcp-06.txt >=20 > Dear WG members, >=20 > Version -06 addresses Roman's AD comments, basically separating the > rationale from the recommendations to maintain the document's internal > consistency. >=20 > We also removed one SHOULD-level recommendation, "Sensitive > information, such as passwords, SHOULD be padded before being > encrypted." While length hiding would be nice in principle, standard ciph= ers > such as AES-GCM do not provide it out of the box. >=20 > Thanks, > Yaron >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for draft-ietf-oauth-jwt-bcp-06.txt > Date: Fri, 07 Jun 2019 11:08:00 -0700 > From: internet-drafts@ietf.org > To: Michael B. Jones , Dick Hardt > , Yaron Sheffer , Michael > Jones >=20 >=20 > A new version of I-D, draft-ietf-oauth-jwt-bcp-06.txt has been successful= ly > submitted by Yaron Sheffer and posted to the IETF repository. >=20 > Name: draft-ietf-oauth-jwt-bcp > Revision: 06 > Title: JSON Web Token Best Current Practices > Document date: 2019-06-07 > Group: oauth > Pages: 16 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwt-bcp-06.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp= / > Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-06 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwt-bcp-06 >=20 > Abstract: > JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security > tokens that contain a set of claims that can be signed and/or > encrypted. JWTs are being widely used and deployed as a simple > security token format in numerous protocols and applications, both in > the area of digital identity, and in other application areas. The > goal of this Best Current Practices document is to provide actionable > guidance leading to secure implementation and deployment of JWTs. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Jun 10 12:07:00 2019 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 29499120048; Mon, 10 Jun 2019 12:06:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Cc: rifaat.ietf@gmail.com, Rifaat Shekh-Yusef , iesg-secretary@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org Message-ID: <156019361816.14938.6761701749573600848.idtracker@ietfa.amsl.com> Date: Mon, 10 Jun 2019 12:06:58 -0700 Archived-At: Subject: [OAUTH-WG] Publication has been requested for draft-ietf-oauth-jwt-introspection-response-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 19:06:58 -0000 Rifaat Shekh-Yusef has requested publication of draft-ietf-oauth-jwt-introspection-response-03 as Proposed Standard on behalf of the OAUTH working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ From nobody Mon Jun 10 20:12:13 2019 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 74C5F12001A; Mon, 10 Jun 2019 20:12:12 -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: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156022273235.32294.5727474596944323698@ietfa.amsl.com> Date: Mon, 10 Jun 2019 20:12:12 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-19.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 03:12:12 -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 Filename : draft-ietf-oauth-jwsreq-19.txt Pages : 27 Date : 2019-06-10 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 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 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-19 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-19 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 david.sautter@web.de Mon Jun 10 01:06:17 2019 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 E87A11200C1 for ; Mon, 10 Jun 2019 01:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_FAIL=0.001, SPF_HELO_NONE=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 pE1CxLD8cNVz for ; Mon, 10 Jun 2019 01:06:16 -0700 (PDT) Received: from outgoing.selfhost.de (mordac.selfhost.de [82.98.82.6]) (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 241D5120096 for ; Mon, 10 Jun 2019 01:06:15 -0700 (PDT) Received: (qmail 14539 invoked from network); 10 Jun 2019 08:06:12 -0000 Received: from unknown (HELO ?192.168.1.185?) (postmaster@davidsautter.de@95.117.87.75) by mailout.selfhost.de with ESMTPA; 10 Jun 2019 08:06:12 -0000 To: oauth@ietf.org From: David Sautter Message-ID: Date: Mon, 10 Jun 2019 10:06:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: Avast (VPS 190609-4, 09.06.2019), Outbound message X-Antivirus-Status: Clean Archived-At: X-Mailman-Approved-At: Tue, 11 Jun 2019 08:01:41 -0700 Subject: [OAUTH-WG] Recommended OpenId Connect Flow for SPA with Microservices 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 Jun 2019 06:29:16 -0000 Hello, I'm trying to get my head around the current recommendation for using OpenId Connect with an SPA, that cannot directly communicate with a stateful backend for holding a session. First I thought the Implicit Flow would be the way to go, then I noticed that it isn't recommended anymore because of the broad support of CORS nowadays, instead one shall use the Authorization Code Flow. I think what confuses most people is, that the Authorization Code Flow can be implemented in two ways: With or without a backend service doing the token exchange for the frontend. I understood the following: Using a backend service for doing the exchange of the auth code for the token with the IdP is considered more secure, because one cannot trust the browser to store the tokens securely. The drawback is that you will have to create your own session state between your backend and your frontend SPA (e.g. using a cookie). I am in a scenario where I do not have "the one backend", but a bunch of microservices running on Kubernetes, so they could die and respawn at any given time. Do I need a API-Gateway for dealing with the Authorization Code Flow? Which ones would be recommended (standard compliant)? Or is the alternative of handling the complete Authorization Code Flow + PKCE in the Browser considered a safe scenario? I have been doing a lot of research but having trouble to clarify this. Thanks for your help! Regards, David --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr=C3=BCft. https://www.avast.com/antivirus From jmh205@cam.ac.uk Tue Jun 11 08:53:28 2019 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 79E6A120157 for ; Tue, 11 Jun 2019 08:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=universityofcambridgecloud.onmicrosoft.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 afa6urZysWGt for ; Tue, 11 Jun 2019 08:53:25 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110109.outbound.protection.outlook.com [40.107.11.109]) (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 1F89F1202D0 for ; Tue, 11 Jun 2019 08:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=UniversityOfCambridgeCloud.onmicrosoft.com; s=selector1-UniversityOfCambridgeCloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bPAIwgB9anAzE4qy7aksG8hsuwTi5PNPekz3FxmMGPY=; b=04au2A9FswkBwyjM6X4qtoryD1Ei76QgW27XplrXtu4jFb6W+XtjFofbx97ar+4qKXl2N2NDR0DiPdCBGz6za6YiqhtQzECvKv3iTdJ+9aE0e/NjZonowP2PD/m3H0m3skNnUcJzVWfwAQpWgkqabxGvbwM+RX3PYU0wUdBDPS4= Received: from CWLP265MB0884.GBRP265.PROD.OUTLOOK.COM (20.176.33.10) by CWLP265MB0177.GBRP265.PROD.OUTLOOK.COM (10.166.19.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.17; Tue, 11 Jun 2019 15:53:17 +0000 Received: from CWLP265MB0884.GBRP265.PROD.OUTLOOK.COM ([fe80::90cf:642d:3284:b973]) by CWLP265MB0884.GBRP265.PROD.OUTLOOK.COM ([fe80::90cf:642d:3284:b973%6]) with mapi id 15.20.1965.017; Tue, 11 Jun 2019 15:53:17 +0000 From: James Howe To: "oauth@ietf.org" Thread-Topic: Query on RFC 7009 Thread-Index: AdUgbQFSSrDVTXOdRA6xogTEG6OKNw== Date: Tue, 11 Jun 2019 15:53:16 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jmh205@cam.ac.uk; x-originating-ip: [129.169.142.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 879d351e-9259-44fd-913b-08d6ee84eb79 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CWLP265MB0177; x-ms-traffictypediagnostic: CWLP265MB0177: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 006546F32A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(396003)(39860400002)(366004)(199004)(189003)(2351001)(33656002)(68736007)(14454004)(476003)(99286004)(8936002)(1730700003)(81166006)(81156014)(14444005)(5660300002)(256004)(4744005)(486006)(6116002)(2501003)(3846002)(52536014)(786003)(86362001)(316002)(71200400001)(53936002)(71190400001)(66556008)(55016002)(66446008)(305945005)(7696005)(76116006)(66946007)(66476007)(64756008)(7116003)(102836004)(7736002)(9686003)(6916009)(74316002)(26005)(6436002)(186003)(73956011)(5640700003)(478600001)(74482002)(6506007)(25786009)(66066001)(2906002)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:CWLP265MB0177; H:CWLP265MB0884.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cam.ac.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: IZ5wNQ1HoRd8c7Lu3xBJiDyxMv9HhjXNAe28UH21sycS+PP6R6YLpOO1+oEisky8xE49arB1BpZ/vdI1Qid5fK0h3yFBCg+03KgHauj6n2kZHq98+fcE6oeXJaK9A7rhWQPOS+kz/R7j3GMiq81Fs6mpXOBA14nczjzPJzw1PelW3woDHMw8eBW4pN1kAezHy9y2TFJdvgBZeHeYACIxoK5QAn0aAPT54eeE8VGSHqHOLRoSAcREp+M3X27yc1wZMZKNbMkIJw9VRnTBFKIJRWFk8F9/dFKWiYcDQ/VTB5axntE2C9cW1Sq8gaio29bIX3a8tVEDrmGP8/53+CLsgTKfTviNNN9eoxWBexT+B+trvWB0cIRF5DH0g92N9heiEYD7ITGdDiaELeg2Mt/UhADNjrF0ERa5wpPmAKvJCiA= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: cam.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 879d351e-9259-44fd-913b-08d6ee84eb79 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2019 15:53:17.1711 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49a50445-bdfa-4b79-ade3-547b4f3986e9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jmh205@cam.ac.uk X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWLP265MB0177 Archived-At: X-Mailman-Approved-At: Tue, 11 Jun 2019 09:04:57 -0700 Subject: [OAUTH-WG] Query on RFC 7009 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 Jun 2019 15:55:19 -0000 VW5sZXNzIEknbSBtaXN0YWtlbiwgUkZDIDcwMDkgZG9lc24ndCBzcGVjaWZ5IHRoZSBlcnJvciBy ZXNwb25zZSB3aGVuIHRoZSByZXF1ZXN0IGlzIGZyb20gYSBkaWZmZXJlbnQgY2xpZW50IHRvIHRo ZSBpc3N1ZXIuDQoNClNlY3Rpb24gMi4xOg0KPiBJZiB0aGlzICB2YWxpZGF0aW9uIGZhaWxzLCB0 aGUgcmVxdWVzdCBpcyByZWZ1c2VkIGFuZCB0aGUgY2xpZW50IGlzIGluZm9ybWVkDQo+IG9mIHRo ZSBlcnJvciBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXMgZGVzY3JpYmVkIGJlbG93Lg0K DQpUaGUgb25seSByZWxldmFudCBkZXNjcmlwdGlvbiBiZWxvdyBJIGNhbiBzZWUgaXMgaW4gU2Vj dGlvbiAyLjIuMToNCj4gVGhlIGVycm9yIHByZXNlbnRhdGlvbiBjb25mb3JtcyB0byB0aGUgZGVm aW5pdGlvbiBpbiBTZWN0aW9uIDUuMiBvZiBbUkZDNjc0OV0uDQoNCkhvd2V2ZXIgbm9uZSBvZiB0 aGUgZXJyb3IgY29kZXMgdGhlcmUgc2VlbSB0byBiZSBhcHBsaWNhYmxlLg0KdW5hdXRob3JpemVk X2NsaWVudCBhcHBlYXJzIHRvIGJlIHRoZSBjbG9zZXN0LCBhbHRob3VnaCB0aGVyZSBpcyBubyBn cmFudCB0eXBlIGludm9sdmVkLg0KPiBUaGUgYXV0aGVudGljYXRlZCBjbGllbnQgaXMgbm90IGF1 dGhvcml6ZWQgdG8gdXNlIHRoaXMgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlLg0KDQpXaGF0IGlz IHRoZSBpbnRlbnRpb24gaGVyZT8NCg0KLS0tLQ0KSmFtZXMgSG93ZQ0KU2VuaW9yIElUIERldmVs b3Blcg0KRGVwYXJ0bWVudCBvZiBFbmdpbmVlcmluZw0KVW5pdmVyc2l0eSBvZiBDYW1icmlkZ2UN Cis0NCAxMjIzIDc0ODUzNg0KDQo= From nobody Tue Jun 11 19:01:30 2019 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 2F63F12007A for ; Tue, 11 Jun 2019 19:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oBeCpeSqrd_4 for ; Tue, 11 Jun 2019 19:01:27 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id B196912002F for ; Tue, 11 Jun 2019 19:01:27 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:461:b22c:577:5eb1] (unknown [IPv6:2601:282:202:b210:461:b22c:577:5eb1]) by alkaline-solutions.com (Postfix) with ESMTPSA id E23D2315C9; Wed, 12 Jun 2019 02:01:26 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3554.18.2\)) From: David Waite In-Reply-To: Date: Tue, 11 Jun 2019 20:01:26 -0600 Cc: oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <503669B0-8DCD-4811-8B69-0CE0F4E0D8B0@alkaline-solutions.com> References: To: David Sautter X-Mailer: Apple Mail (2.3554.18.2) Archived-At: Subject: Re: [OAUTH-WG] Recommended OpenId Connect Flow for SPA with Microservices 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 Jun 2019 02:01:30 -0000 On Jun 10, 2019, at 2:06 AM, David Sautter wrote: > I understood the following: Using a backend service for doing the = exchange of the auth code for the token with the IdP is considered more = secure, because one cannot trust the browser to store the tokens = securely. The drawback is that you will have to create your own session = state between your backend and your frontend SPA (e.g. using a cookie). Security-wise your risks include both token exfiltration and arbitrary = code execution. A proxying backend that holds the token might prevent = XSS from exfiltrating the token, but by default does not limit the = impact of someone driving the user=E2=80=99s browser directly instead. There can certainly be other implementation/architectural benefits of = this approach, however. You can limit actions taken by the SPA, provide = a bridge to a remote domain for an API that doesn=E2=80=99t advertise = CORS support, enforce rate limiting of APIs which may be charged = upstream, and so on. You could also use this to enforce a common = processing layer across user-facing components. > I am in a scenario where I do not have "the one backend", but a bunch = of microservices running on Kubernetes, so they could die and respawn at = any given time. Do I need a API-Gateway for dealing with the = Authorization Code Flow? Which ones would be recommended (standard = compliant)? The standards mostly focus on the protocols between client, AS/IDP, and = protected resource. The products which say help you implement just the = client don=E2=80=99t necessarily have standards to leverage between your = code and theirs. Leveraging OIDC for web access is mostly pain free for = traditional applications, but SPA applications are more like API clients = and take some of the passive browser behaviors that you would leverage = here (such as potentially redirecting for authentication on new page = request). > Or is the alternative of handling the complete Authorization Code Flow = + PKCE in the Browser considered a safe scenario? This is what we are recommending by default for = https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps=20 Content Security Policy is recommended for preventing XSS in that = document. Subresource integrity isn=E2=80=99t explicitly called out, but = is also invaluable. To prevent exfiltration, the options are limited.=20 - Token Binding will work, but only currently has support in Edge. - Mutual TLS will work, but has a poor experience unless you are = deploying alongside group policy. - DPoP was written specifically for the browser use case (such as = letting you use WebCrypto for non-exportable tokens). It is an early = draft but has some initial implementations already. You can also have risk and fraud analsyis against both. XSS would need = to be detected by usage behavior, while Exfiltration could use = environmental detection like address and user agent changes. >=20 > I have been doing a lot of research but having trouble to clarify = this. Thanks for your help! Hope this helps! -DW= From amereii@rooyekhat.co Wed Jun 12 03:12:38 2019 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 EBD89120113 for ; Wed, 12 Jun 2019 03:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 TWMdZ9uAWY_0 for ; Wed, 12 Jun 2019 03:12:37 -0700 (PDT) Received: from linux.rooyekhat.co (linux.rooyekhat.co [185.81.41.14]) (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 0279312007A for ; Wed, 12 Jun 2019 03:12:37 -0700 (PDT) Received: from [185.238.95.254] (helo=[10.11.12.248]) by linux.rooyekhat.co with esmtpa (Exim 4.92) (envelope-from ) id 1hb0F8-00054v-BP for oauth@ietf.org; Wed, 12 Jun 2019 14:42:34 +0430 To: oauth@ietf.org From: Asghar Amereii Message-ID: <7a59ac2c-a9c7-a188-77e1-94b5dc4b8799@rooyekhat.co> Date: Wed, 12 Jun 2019 14:42:34 +0430 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------3DDC8EEA089E9CF96B4C39F6" Content-Language: en-US X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-Authenticated-Id: amereii@rooyekhat.co Archived-At: Subject: [OAUTH-WG] OAuth Unsuccessful Response 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 Jun 2019 10:15:14 -0000 This is a multi-part message in MIME format. --------------3DDC8EEA089E9CF96B4C39F6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit According tohttps://www.oauth.com/oauth2-servers/access-tokens/access-token-response/ Error responses are returned with an HTTP 400 status code (unless specified otherwise), with error and error_description parameters. The error parameter will always be one of the values listed below. * invalid_request * invalid_client * invalid_grant * invalid_scope * unauthorized_client * unsupported_grant_type Can I have custom error like "invalid_captcha" or "captcha_required"? I want , if some one send wrong credentials for 3 times , I send "captcha_required" error and for next time must send valid captcha code My question is: 1. Is it allowed to define custom error codes in OAuth ? 2. Is there alternative way to solve my problem? --------------3DDC8EEA089E9CF96B4C39F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

According to https://www.oauth.com/oauth2-servers/access-tokens/access-token-response/

Error responses are returned with an HTTP 400 status code (unless
specified otherwise), with error and error_description parameters. The
error parameter will always be one of the values listed below.

  • invalid_request
  • invalid_client
  • invalid_grant
  • invalid_scope
  • unauthorized_client
  • unsupported_grant_type

Can I have custom error like "invalid_captcha" or "captcha_required"?

I want , if some one send wrong credentials for 3 times , I send "captcha_required" error and for next time must send valid captcha code

My question is:

  1. Is it allowed to define custom error codes in OAuth ?
  2. Is there alternative way to solve my problem?
--------------3DDC8EEA089E9CF96B4C39F6-- From nobody Thu Jun 13 13:50:12 2019 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 DD6BD120801 for ; Thu, 13 Jun 2019 13:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=oracle.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 fC2owVWy87N8 for ; Thu, 13 Jun 2019 13:49:59 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 420C8120800 for ; Thu, 13 Jun 2019 13:49:58 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5DKnvZf146888 for ; Thu, 13 Jun 2019 20:49:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : content-type : mime-version : subject : message-id : date : to; s=corp-2018-07-02; bh=7TccSu6rtZx8cyHQdIJO4L7nKCvZr6xfPy+TdWyiolI=; b=T6z5VjuDL8z4GdnDq4BUIDYGs88PKbWb48scF+GjyPgqiASol9MgkZNxkqiL9bFERUpL sa5ty8xcrNWBjMFveE/edPvymKah49umva49UWraZdCeMe9gYTQT/ZVgFQK719dyscwO KHJ7HNMkm+IFdL9wQW5Yo+JpTQRIFIwD8t1MLLzbISWvjeLSyrjBJhyDXB2OhHRZEfet qhNCkvMabZVW76IQ7ixPdxY3aet4nEsyqSNO5wHgUaGQkr+FSD4ofZofrJvl3rq/tZ1v bdhIgLxCOmCH+EmFhTtipG6ik4zzJNxiqs6ilxAgfV0nP3VRahpTH+BM39I4zet4h/pk iA== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2t05nr40av-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 13 Jun 2019 20:49:57 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5DKn5W4088990 for ; Thu, 13 Jun 2019 20:49:56 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 2t04j0prvs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 13 Jun 2019 20:49:56 +0000 Received: from abhmp0022.oracle.com (abhmp0022.oracle.com [141.146.116.28]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x5DKntlU020548 for ; Thu, 13 Jun 2019 20:49:55 GMT Received: from [10.0.1.16] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Jun 2019 13:49:55 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_F1E9EC2F-1601-4A32-AF3B-4A13391E9578" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Thu, 13 Jun 2019 13:49:54 -0700 To: IETF oauth WG X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9287 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906130156 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9287 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906130156 Archived-At: Subject: [OAUTH-WG] Token Binding looking for info on browser support 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 Jun 2019 20:50:10 -0000 --Apple-Mail=_F1E9EC2F-1601-4A32-AF3B-4A13391E9578 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Has anyone heard of any updates on browser support for Token Binding? Does MS Edge still have it? Most of the information out there seems to = end with Chromiums decision to back out. I=E2=80=99m still a big believer in thes specs as they provide clean = application API separation from security. It=E2=80=99s a nice complement = to our MTLS Token Binding approach as well. Thanks, Phil Hunt | Cloud Security and Identity Architect Oracle Corporation, Oracle Cloud Infrastructure @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_F1E9EC2F-1601-4A32-AF3B-4A13391E9578 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Has = anyone heard of any updates on browser support for Token Binding?

Does MS Edge still have = it?  Most of the information out there seems to end with Chromiums = decision to back out.

I=E2=80=99m still a big believer in thes specs as they = provide clean application API separation from security. It=E2=80=99s a = nice complement to our MTLS Token Binding approach as well.

Thanks,

Phil Hunt | Cloud Security and Identity Architect
Oracle Corporation, Oracle Cloud Infrastructure
@independentid






= --Apple-Mail=_F1E9EC2F-1601-4A32-AF3B-4A13391E9578-- From nobody Thu Jun 13 19:12:41 2019 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 6A8031200EF; Thu, 13 Jun 2019 19:12:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Carpenter via Datatracker To: Cc: draft-ietf-oauth-jwt-bcp.all@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Brian Carpenter Message-ID: <156047835427.12308.12676323646131055737@ietfa.amsl.com> Date: Thu, 13 Jun 2019 19:12:34 -0700 Archived-At: Subject: [OAUTH-WG] Genart telechat review of draft-ietf-oauth-jwt-bcp-06 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, 14 Jun 2019 02:12:35 -0000 Reviewer: Brian Carpenter Review result: Ready Gen-ART telechat review of draft-ietf-oauth-jwt-bcp-06 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-oauth-jwt-bcp-06.txt Reviewer: Brian Carpenter Review Date: 2019-06-14 IETF LC End Date: 2019-04-08 IESG Telechat date: 2019-06-27 Summary: Ready -------- Comments: --------- Thank you for handling my Last Call comments. From nobody Thu Jun 20 15:33:08 2019 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 BEF0C120183 for ; Thu, 20 Jun 2019 15:33:06 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 CcrPTUdhqp5Q for ; Thu, 20 Jun 2019 15:33:04 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905691200D8 for ; Thu, 20 Jun 2019 15:33:04 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id d4so6882957edr.13 for ; Thu, 20 Jun 2019 15:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=r0Qh19kjLwbOhLasCEZEwiEtDMMidhcTmz8p9WEsbkY=; b=zq0Luyl/+962ViPF+di4Da4LenzrtUVuy+sR7/UhodipulaUxw0Mn4R793sT+QZrOY uGDEGQwLJ+Rj7E3loI1+L1sMKOi0HNNDgh4v62sQaEF+NxYrZ9O7jF297JN2wX3gm+Fp mHeDnBCgEuTWfAbsnpwNTbcgOVnGuJO5Vk8Klt7h/9SJqA3B0bXNSYMrQ8+4pws8dJ8O 0tmRjhzHlOc9bvYPz0k3LqUOJt0UZ1J/RAkDo7flGw5LO+ZMWVfcDPrln0oKVxlzi2AH k8fTJHb01jLySzAzX+cyMJatrTcByDzjvLlsAnTXO4pK17gy6+MisVRlPX2nzj99MGpO vKPg== 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=r0Qh19kjLwbOhLasCEZEwiEtDMMidhcTmz8p9WEsbkY=; b=WaRuTi3clNyAshcXhnr4/N2RYR3ZKJpOFO/+VOmkJfeSyfF2ymNAhQZA9DAnNHEiDI 2ekWaOKBJCjzuArz3v4TpdtxkWl7/cxTaOiiUThQdC3DzfzL18oprU5CDcoOzV+vc2yl RtEFSKD7AIXXCbYwdUiczoj/BeL3HvsqrVz2qec0ngG0qLxr8UTJxcOdZbh1xZyyAeex LykgWYeiv65J4GQDuVG7HTy2cTWFWhlPDz7WTVW1SGN6L24Jto/FfxRkzh/55gc9rHJn 5iFB7o80+6qruo2KSO28+iN8luexy0dA6JUbO2XnIdZbg0aJAgTGhFC5dtEPkxMvnEup KP/A== X-Gm-Message-State: APjAAAVr9OVdZxEZ3OQSt2DJ/cgu9a50TPTgPWCv8DJ6fOaxws0h64xl uurbFb14NceRwM6WfVfV3uJdaj0tDzGDe5jAGnIkLX8QjNM= X-Google-Smtp-Source: APXvYqwLlsDxApyceP80X0YI8RVxCBCYzfgRvRMaQQ12J7xnl8ZvhpuDI3gvLim0x7SwIw/uCjhurn9ZjiV5/MeyUec= X-Received: by 2002:a50:a544:: with SMTP id z4mr5199387edb.71.1561069982840; Thu, 20 Jun 2019 15:33:02 -0700 (PDT) MIME-Version: 1.0 From: Takahiko Kawasaki Date: Thu, 20 Jun 2019 18:32:51 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000cc0d2a058bc8ed03" Archived-At: Subject: [OAUTH-WG] ID Token by Device Flow 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 Jun 2019 22:33:07 -0000 --000000000000cc0d2a058bc8ed03 Content-Type: text/plain; charset="UTF-8" Hello, Do you have any plan to update the specification of Device Flow to support issue of ID tokens? OAuth 2.0 Device Authorization Grant https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/?include_text=1 Best Regards, Takahiko Kawasaki --000000000000cc0d2a058bc8ed03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Do you have any plan to update t= he specification of Device Flow to support issue of ID tokens?
OAuth 2.0 Device Authorization Grant

Best Regards,
Takahik= o Kawasaki

--000000000000cc0d2a058bc8ed03-- From nobody Sat Jun 22 11:29:03 2019 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 ED25E120170 for ; Sat, 22 Jun 2019 11:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 IcaBzowwg7nv for ; Sat, 22 Jun 2019 11:28:59 -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 E7EC61200C1 for ; Sat, 22 Jun 2019 11:28:58 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x5MISvwj031781 for ; Sat, 22 Jun 2019 14:28:57 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x5MISvwj031781 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1561228137; bh=5S4KGgb3cEtRPewXf30KbIBFy/4B6211qmEJTnodT1Y=; h=From:To:Subject:Date:From; b=J2g7+9Mm0mZKBn6dulyJsCmKYbymUTROFQPcxt2Ra8JBL7+LtRmj0uHA6EMBSaL0H RxqUc0gvP2kZzcnTfZPNjjCZwgC1pSPqmWnAKdQxeuybspR8nur1h+5rq3P9iB0l7Y /rJk8cWH9DYLO/9YpjwIj9bgpJ+HEo8ALMIdNGA4= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x5MISvjG021381 for ; Sat, 22 Jun 2019 14:28:57 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Sat, 22 Jun 2019 14:28:56 -0400 From: Roman Danyliw To: oauth Thread-Topic: Second AD Review: draft-ietf-oauth-mtls Thread-Index: AdUpJ/vy5dvAfF1OT6Ob3fhIFPK/8w== Date: Sat, 22 Jun 2019 18:28:56 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33A25D2@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls 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, 22 Jun 2019 18:29:01 -0000 Hi! I conducted as second AD review of draft-ietf-oauth-mtls per the AD hand-of= f. I have the following additional feedback: ** Per ekr's earlier review at https://mozphab-ietf.devsvcdev.mozaws.net/D3= 657, paraphrasing: -- Section 2.1.2, How is these metadata parameters being obtained? -- Section 3.2, Figure 3. In this example, what new information is the aut= h server providing to the relying party here? ** Section 2.0. What is the expected behavior if the presented certificate= doesn't match expected client_id? How is this signaled? ** Section 2.2. Per the sentence "As pre-requisite, the client registers i= ts X.509 certificate ... or a trusted source for its X.509 certificates ...= with the authorization server. -- Editorial: s/As pre-requisite/As a prerequisite/ -- What's a "trusted source" in this case? Is that just a jwks_uri? If so= , maybe s/a trusted source/a reference to a trust source/. If not, can you= please elaborate. A few editorial nits: ** Section 2.2.2. Typo. s/sec 4.7/Section 4.7/ ** Section 3.1 Cite DER encoding as: [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 2015. ** Section 5. Typo. s/metatdata/metadata/ ** Section 6. Typo. s/The the/The/ ** Section 7.2. Typo. s/the the/the/ ** Appendix. Cite the figures numbers (#5 - 7) in the text describing the c= ontents of the section. The shepherd write-up is in good shape. Thank you. Regards, Roman From nobody Mon Jun 24 01:50:25 2019 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 267511200F4; Mon, 24 Jun 2019 01:50:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwt-bcp@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <156136621710.17780.17903670930450500176.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2019 01:50:17 -0700 Archived-At: Subject: [OAUTH-WG] Barry Leiba's Yes on draft-ietf-oauth-jwt-bcp-06: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 08:50:17 -0000 Barry Leiba has entered the following ballot position for draft-ietf-oauth-jwt-bcp-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Nice work on this; thanks. -- Section 1 -- Readers are advised to seek out any errata or updates that apply to this document. Excellent. I note that this is a really nice opportunity to include, here, a URI to a page in the working group wiki or github that you can now create and that will be used to post updates (that might not qualify as errata) before they're incorporated into published updates. Other than that, I just have some editorial comments: -- Section 1.1 -- - Implementers of JWT libraries (and the JWS and JWE libraries used by them), Nit: Does "them" refer to the implementers or the libraries? Please re-phrase to clarify. -- Section 2.4 -- Nit: "and thus, the ciphertext, depends" should be "and, thus, the ciphertext depend" (note moved comma and plural verb). -- Section 2.6 -- Nit: "However older implementations" needs a comma: "However, older implementations" -- Section 2.7 -- I find the paragraph to be somewhat awkward, and suggest a slight rewording, thus: NEW There are attacks in which one recipient will be given a JWT that was intended for it, and will attempt to use it at a different recipient for which that JWT was not intended. For instance, if an OAuth 2.0 [RFC6749] access token is legitimately presented to an OAuth 2.0 protected resource which it is intended, that protected resource might then present that same access token to different protected resource for which the access token is not intended, in an attempt to gain access. If such situations are not caught, this can result in the attacker gaining access to resources that it is not entitled to access. END As to the title of this section, this doesn't seem to be a "substitution". I'm not sure what to call it (maybe it's a form of replay attack, but maybe not really), but "substitution" doesn't seem right. -- Section 2.9 -- Nit: In "operations, e.g. database and LDAP searches," you need a comma after "e.g." Or, better still, just change "e.g." to "such as", and avoid the Latin. -- Section 3.4 -- Nit: "(see e.g. [Valenta], Sec. 7.1)" needs commas: "(see, e.g., [Valenta], Sec. 7.1)" And in the next sentence, because of the "or both!" at the end I would remove the "Either" at the beginning. -- Section 3.6 -- It is RECOMMENDED to avoid any compression of data before encryption since such compression often reveals information about the plaintext. The passive voice doesn't work in this construct; "it is recommended to avoid" doesn't seem like proper English. Also, it's not the compression that reveals information, but the resultant compressed data, right? How about this?: NEW Compression of data SHOULD NOT be done before encryption, because such compressed data often reveals information about the plaintext. END -- Section 3.11 -- Confusion of one kind of JWT for another can be prevented by having all the kinds of JWTs that could otherwise potentially be confused include an explicit JWT type value and include checking the type value in their validation rules. I find the sentence awkward, and suggest a slight rewrite: NEW Sometimes, one kind of JWT can be confused for another. If a particular kind of JWT is subject to such confusion, that JWP can include an explicit JWT type value, and the validation rules can specify checking the type. This mechanism can prevent such confusion. END From nobody Mon Jun 24 09:13:15 2019 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 895A71204AF for ; Mon, 24 Jun 2019 09:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 GYfhyAjTvYTI for ; Mon, 24 Jun 2019 09:13:11 -0700 (PDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (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 7213A1204AB for ; Mon, 24 Jun 2019 09:13:11 -0700 (PDT) Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id x5OGD8TG009660; Mon, 24 Jun 2019 12:13:09 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 24 Jun 2019 12:13:03 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 24 Jun 2019 12:13:05 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Mon, 24 Jun 2019 12:13:05 -0400 From: Justin Richer To: Takahiko Kawasaki CC: oauth Thread-Topic: [OAUTH-WG] ID Token by Device Flow Thread-Index: AQHVJ7glC2tReDX+3U6qshw8U7J6KKarQwaA Date: Mon, 24 Jun 2019 16:13:05 +0000 Message-ID: <846314DA-2A9F-41EE-BD21-61EC1CCB80ED@mit.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [69.140.126.174] Content-Type: multipart/alternative; boundary="_000_846314DA2A9F41EEBD2161EC1CCB80EDmitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] ID Token by Device Flow 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 Jun 2019 16:13:14 -0000 --_000_846314DA2A9F41EEBD2161EC1CCB80EDmitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGFrYSwNCg0KTXkgcmVhZGluZyBpcyB0aGF0IHRoZSBkZXZpY2UgZmxvdywgbGlrZSBvdGhlciBP QXV0aCBmbG93cywgZG9lcyBub3QgcHJvaGliaXQgZXh0ZW5zaW9uLCBpbmNsdWRpbmcgcGFzc2lu ZyBiYWNrIGlkZW50aXR5IGFzc2VydGlvbnMgbGlrZSB0aGUgSUQgVG9rZW4uIFNpbmNlIGl0IGlu aGVyaXRzIHRoZSB0b2tlbiByZXNwb25zZSBmcm9tIGNvcmUgT0F1dGggMiwgdGhlIElEIFRva2Vu IGNvdWxkIGJlIGlzc3VlZCBhbG9uZyBzaWRlIHRoZSBhY2Nlc3MgdG9rZW4ganVzdCBsaWtlIGlu IHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZmxvdy5UaGUgdXNlciBpcyBwcmVzZW50IGFuZCBpbnRl cmFjdGluZyBhdCB0aGUgQVMgaW4gYm90aCBjYXNlcy4gSW4gZmFjdCwgSeKAmWQgc2F5IHRoYXQg dGhlcmUgYXJlIGVub3VnaCBzaW1pbGFyaXRpZXMgYmV0d2VlbiB0aGUgdHdvIHRoYXQgZm9yIHRo ZSBtb3N0IHBhcnQgaXQgc2hvdWxkIOKAnGp1c3Qgd29ya+KAnSBhbmQgZml0IHRoZSBhc3N1bXB0 aW9ucyBvZiBtb3N0IGNsaWVudHMuIFRoYXQgc2FpZCwgaXTigJlzIHRlY2huaWNhbGx5IHRydWUg dGhhdCB0aGVyZSBpcyBubyBkZWZpbmVkIHByb2ZpbGUgZm9yIHRoZSBjb21iaW5hdGlvbiBvZiB0 aGUgZGV2aWNlIGZsb3cgYW5kIE9JREMsIGJ1dCBpZiBzb21ldGhpbmcgbGlrZSB0aGF0IHdlcmUg dG8gYmUgd3JpdHRlbiBpdCB3b3VsZCBiZSBiZXR0ZXIgZml0IHRvIHRoZSBPcGVuSUQgRm91bmRh dGlvbi4NCg0K4oCUIEp1c3Rpbg0KDQpPbiBKdW4gMjAsIDIwMTksIGF0IDY6MzIgUE0sIFRha2Fo aWtvIEthd2FzYWtpIDx0YWthQGF1dGhsZXRlLmNvbTxtYWlsdG86dGFrYUBhdXRobGV0ZS5jb20+ PiB3cm90ZToNCg0KSGVsbG8sDQoNCkRvIHlvdSBoYXZlIGFueSBwbGFuIHRvIHVwZGF0ZSB0aGUg c3BlY2lmaWNhdGlvbiBvZiBEZXZpY2UgRmxvdyB0byBzdXBwb3J0IGlzc3VlIG9mIElEIHRva2Vu cz8NCg0KT0F1dGggMi4wIERldmljZSBBdXRob3JpemF0aW9uIEdyYW50DQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWRldmljZS1mbG93Lz9pbmNsdWRl X3RleHQ9MQ0KDQpCZXN0IFJlZ2FyZHMsDQpUYWthaGlrbyBLYXdhc2FraQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0 DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_846314DA2A9F41EEBD2161EC1CCB80EDmitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <4B966AE3DE5513478BF07246795C3C1D@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRha2EsDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5NeSByZWFkaW5nIGlzIHRoYXQgdGhlIGRldmlj ZSBmbG93LCBsaWtlIG90aGVyIE9BdXRoIGZsb3dzLCBkb2VzIG5vdCBwcm9oaWJpdCBleHRlbnNp b24sIGluY2x1ZGluZyBwYXNzaW5nIGJhY2sgaWRlbnRpdHkgYXNzZXJ0aW9ucyBsaWtlIHRoZSBJ RCBUb2tlbi4gU2luY2UgaXQgaW5oZXJpdHMgdGhlIHRva2VuIHJlc3BvbnNlIGZyb20gY29yZSBP QXV0aCAyLCB0aGUgSUQgVG9rZW4gY291bGQgYmUgaXNzdWVkIGFsb25nIHNpZGUNCiB0aGUgYWNj ZXNzIHRva2VuIGp1c3QgbGlrZSBpbiB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGZsb3cuVGhlIHVz ZXIgaXMgcHJlc2VudCBhbmQgaW50ZXJhY3RpbmcgYXQgdGhlIEFTIGluIGJvdGggY2FzZXMuIElu IGZhY3QsIEnigJlkIHNheSB0aGF0IHRoZXJlIGFyZSBlbm91Z2ggc2ltaWxhcml0aWVzIGJldHdl ZW4gdGhlIHR3byB0aGF0IGZvciB0aGUgbW9zdCBwYXJ0IGl0IHNob3VsZCDigJxqdXN0IHdvcmvi gJ0gYW5kIGZpdCB0aGUgYXNzdW1wdGlvbnMNCiBvZiBtb3N0IGNsaWVudHMuIFRoYXQgc2FpZCwg aXTigJlzIHRlY2huaWNhbGx5IHRydWUgdGhhdCB0aGVyZSBpcyBubyBkZWZpbmVkIHByb2ZpbGUg Zm9yIHRoZSBjb21iaW5hdGlvbiBvZiB0aGUgZGV2aWNlIGZsb3cgYW5kIE9JREMsIGJ1dCBpZiBz b21ldGhpbmcgbGlrZSB0aGF0IHdlcmUgdG8gYmUgd3JpdHRlbiBpdCB3b3VsZCBiZSBiZXR0ZXIg Zml0IHRvIHRoZSBPcGVuSUQgRm91bmRhdGlvbi4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCuKAlCBKdXN0aW48L2Rp dj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVuIDIwLCAyMDE5LCBhdCA2OjMyIFBNLCBUYWth aGlrbyBLYXdhc2FraSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRha2FAYXV0aGxldGUuY29tIiBjbGFz cz0iIj50YWthQGF1dGhsZXRlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJB cHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRy IiBjbGFzcz0iIj5IZWxsbywNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkRvIHlvdSBoYXZlIGFueSBwbGFuIHRvIHVwZGF0ZSB0aGUgc3BlY2lmaWNh dGlvbiBvZiBEZXZpY2UgRmxvdyB0byBzdXBwb3J0IGlzc3VlIG9mIElEIHRva2Vucz88L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk9BdXRo IDIuMCBEZXZpY2UgQXV0aG9yaXphdGlvbiBHcmFudDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLW9hdXRoLWRldmljZS1mbG93Lz9pbmNsdWRlX3RleHQ9MSIgY2xhc3M9IiI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1kZXZpY2UtZmxvdy8/ aW5jbHVkZV90ZXh0PTE8L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CZXN0IFJlZ2FyZHMsPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPlRha2FoaWtvIEthd2FzYWtpPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFz cz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgY2xhc3M9IiI+T0F1dGhAaWV0 Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_846314DA2A9F41EEBD2161EC1CCB80EDmitedu_-- From nobody Mon Jun 24 10:17:43 2019 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 042AF1201CE for ; Mon, 24 Jun 2019 10:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 DvsjtWaRfnHC for ; Mon, 24 Jun 2019 10:17:39 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 5073412016A for ; Mon, 24 Jun 2019 10:17:39 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id w25so3264217ioc.8 for ; Mon, 24 Jun 2019 10:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ieY7lDqFLVyynWBfI2p6fIVan6ze6ikYTObQ8RkMVt0=; b=SDKkJX4y5ctitG8E+l4eF3aNTE6jbn0/1wq0cDJYU+YGpvFHR0tKWt7SJktz1OBlgy +vtPCudOD5v+eK3DHWEtsTIrY5uSRRvqSdLsNmcXf4cdlBKvrXVZP1MDIcWeG15jKYNy OwBXcNfICwC1ANjnblj4VCyta4YrjEZAyEvA8= 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=ieY7lDqFLVyynWBfI2p6fIVan6ze6ikYTObQ8RkMVt0=; b=UJnnD3UGQOwrGmhJHgjSJQDpJ1GQRV+v3JQUEgW9V8LNZqDRdgZ4SHaKdF5O7ZFA2p KWPZRAN9eHqLagPXCdiImCbX7mjvTLGyhyJ1Rx+3N2oWzhJBz3iM4iL1VUwQTX+dxBpd BL1JkHMvrj6M5xUqZ7PLWgGa2OBAVSEq5zj+Dr+UorQid+BPoq6hC33QwL4uVZUsIcr3 WXqFFyskVklpgf2UXrxPPiQUK3l3TRSxuPsdIiderpsXbhGl6yHcXcmyggP4NDsD/tji efNUrdC4iyXeTHcYKUyKrrD329BG0UP1fIVA3Kf7eF91Qw4uOaO7AuwQBgrysAJZpEq2 z8Pw== X-Gm-Message-State: APjAAAUnTD2pMHbC3RJSuY42hCtBzuB+q0RYBW/ecVHyr0n5kKqb9HUN uo8wUVlnLNSdmxu9xGnTCvGAkpbZiphS+7d8dz8n6hxwRDsjf/lzZ2UNn50VtRzUD9QoxQ6W75g qMDNhrUw8r1rAnPVb X-Google-Smtp-Source: APXvYqxrMbR5WHiT59dei6YJF8OA3PuohllT0IJ2LE0MiZQu5DZK45RPXYVpitaHNWtw7Ox/QoiG12OCyXur/yk486w= X-Received: by 2002:a02:a90a:: with SMTP id n10mr114583414jam.61.1561396658435; Mon, 24 Jun 2019 10:17:38 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B33A25D2@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33A25D2@marathon> From: Brian Campbell Date: Mon, 24 Jun 2019 11:17:25 -0600 Message-ID: To: Roman Danyliw Cc: oauth Content-Type: multipart/alternative; boundary="0000000000002e9d7b058c14fdba" Archived-At: Subject: Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls 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 Jun 2019 17:17:42 -0000 --0000000000002e9d7b058c14fdba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the additional review, Roman. I feel lucky, it's not often one gets *two* AD reviews :) Please see below for replies inline with a few followup questions. On Sat, Jun 22, 2019 at 12:29 PM Roman Danyliw wrote: > Hi! > > I conducted as second AD review of draft-ietf-oauth-mtls per the AD > hand-off. I have the following additional feedback: > > ** Per ekr's earlier review at > https://mozphab-ietf.devsvcdev.mozaws.net/D3657, paraphrasing: > -- Section 2.1.2, How is these metadata parameters being obtained? > The authorization server can obtain client metadata via the Dynamic Client Registration Protocol [RFC7591], which is referenced in the top of that section. Also the metadata defined by RFC7591, and registered extensions to it, implies a general data model for clients that is used by most authorization server implementations even when the Dynamic Client Registration Protocol isn't in play. Such implementations typically have some sort of user interface available for managing client configuration. Dose that answer your question? Do you believe more should be said in the document to better explain or clarify that? -- Section 3.2, Figure 3. In this example, what new information is the > auth server providing to the relying party here? > The new info here (and in Section 3.1 too) is the hash of the client certificate to which the access token is bound, which is in the "cnf" confirmation method at the bottom as the "x5t#S256" member. > > ** Section 2.0. What is the expected behavior if the presented > certificate doesn't match expected client_id? How is this signaled? > With a normal OAuth 2.0 error response using the "invalid_client" error code per https://tools.ietf.org/html/rfc6749#section-5.2 Do you think that needs to be stated more explicitly in this document? > > ** Section 2.2. Per the sentence "As pre-requisite, the client registers > its X.509 certificate ... or a trusted source for its X.509 certificates > ... with the authorization server. > -- Editorial: s/As pre-requisite/As a prerequisite/ > done > -- What's a "trusted source" in this case? Is that just a jwks_uri? If > so, maybe s/a trusted source/a reference to a trust source/. If not, can > you please elaborate. > Yes, it's just a jwks_uri. I'll change that. > > A few editorial nits: > ** Section 2.2.2. Typo. s/sec 4.7/Section 4.7/ > fixed > > ** Section 3.1 Cite DER encoding as: > [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: > Specification of Basic Encoding Rules (BER), Canonical > Encoding Rules (CER) and Distinguished Encoding Rules > (DER)", ITU-T Recommendation X.690, 2015. > will do > ** Section 5. Typo. s/metatdata/metadata/ > yup > ** Section 6. Typo. s/The the/The/ > got it > > ** Section 7.2. Typo. s/the the/the/ > done > > ** Appendix. Cite the figures numbers (#5 - 7) in the text describing the > contents of the section. > will do > > The shepherd write-up is in good shape. Thank you. > > Regards, > Roman > > _______________________________________________ > 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._ --0000000000002e9d7b058c14fdba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the add= itional review, Roman. I feel lucky, it's not often one gets *two* AD r= eviews :)=C2=A0 Please see below for replies inline with a few followup que= stions.



On Sat, Jun 22, 2019 at 12:2= 9 PM Roman Danyliw <rdd@cert.org> wrote:
Hi!

I conducted as second AD review of draft-ietf-oauth-mtls per the AD hand-of= f.=C2=A0 I have the following additional feedback:

** Per ekr's earlier review at https:/= /mozphab-ietf.devsvcdev.mozaws.net/D3657, paraphrasing:
-- Section 2.1.2, How is these metadata parameters being obtained?

The authorization server can obtain client meta= data via the Dynamic Client Registration Protocol [RFC7591], which is refer= enced in the top of that section. Also the metadata defined by RFC7591, and= registered extensions to it, implies a general data model for clients that= is used by most authorization server implementations even when the Dynamic= Client Registration Protocol isn't in play. Such implementations typic= ally have some sort of=C2=A0 user interface available for managing client c= onfiguration.

Dose that answer your question?= Do you believe more should be said in the document to better explain or cl= arify that?


-- Section 3.2, Figure 3.=C2=A0 In this example, what new information is th= e auth server providing to the relying party here?
The new info here (and in Section 3.1 too) is the hash of the c= lient certificate to which the access token is bound, which is in the "= ;cnf" confirmation method at the bottom as the "x5t#S256" me= mber.

=C2=A0

** Section 2.0.=C2=A0 What is the expected behavior if the presented certif= icate doesn't match expected client_id?=C2=A0 How is this signaled?
=

With a normal OAuth 2.0 error response usi= ng the "invalid_client" error code per http= s://tools.ietf.org/html/rfc6749#section-5.2

Do you think that needs to be stated more explicitly in this document? =

=C2=A0

** Section 2.2.=C2=A0 Per the sentence "As pre-requisite, the client r= egisters its X.509 certificate ... or a trusted source for its X.509 certif= icates ... with the authorization server.
-- Editorial: s/As pre-requisite/As a prerequisite/
done
=C2=A0
-- What's a "trusted source" in this case?=C2=A0 Is that just= a jwks_uri?=C2=A0 If so, maybe s/a trusted source/a reference to a trust s= ource/.=C2=A0 If not, can you please elaborate.

Yes, it's just a jwks_uri. I'll change that.
=C2=A0

A few editorial nits:
** Section 2.2.2.=C2=A0 Typo.=C2=A0 s/sec 4.7/Section 4.7/
=

fixed
=C2=A0

** Section 3.1=C2=A0 Cite DER encoding as:
=C2=A0 =C2=A0 [X690]=C2=A0 =C2=A0 =C2=A0ITU-T, "Information Technology= -- ASN.1 encoding rules:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Specification of Basic Enc= oding Rules (BER), Canonical
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Encoding Rules (CER) and D= istinguished Encoding Rules
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (DER)", ITU-T Recomme= ndation X.690, 2015.

will do
=
=C2=A0
** Section 5.=C2=A0 Typo. s/metatdata/metadata/

yup


** Section 6.=C2=A0 Typo.=C2=A0 s/The the/The/

got it
=C2=A0

** Section 7.2. Typo.=C2=A0 s/the the/the/

<= div>done
=C2=A0

** Appendix. Cite the figures numbers (#5 - 7) in the text describing the c= ontents of the section.

will do
=C2=A0

The shepherd write-up is in good shape.=C2=A0 Thank you.

Regards,
Roman

_______________________________________________
OAuth mailing list
OAut= h@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. --0000000000002e9d7b058c14fdba-- From nobody Mon Jun 24 12:16:47 2019 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 9B938120152 for ; Mon, 24 Jun 2019 12:16:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 o1nNri_6keUn for ; Mon, 24 Jun 2019 12:16:44 -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 EA75E120137 for ; Mon, 24 Jun 2019 12:16:43 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id z25so23287986edq.9 for ; Mon, 24 Jun 2019 12:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C206NIdxexdFd98bnX3vpFg2wbR1P0iXXDa03rq1G6E=; b=MoIdEEb20tgTqmAmwgTdH/ENiKdJRJt8s1y5K8MGeyWFJNV9X5J5M5hIksz83MfPr/ CKshjBI3cTTpfs23/bsbnQqJfR+yUShVYgWaH+99vKS69B46edkwWv9H1eygPc1hdn+x ylttXpcd0kg0gg4q9GojLgNZcUOBSftPwBYtrgSReu4YRD64M9sCPH69g/+/22aYa+5v VF3EX5qAZK3uW25V9gPtnAPYu25KXJQa2Pp5SVcQZy3yAc+9ucIkMJQuBgjKY/YO/AtF 8j1U1TC4lzTjxb10x2ph+N7ba1ErIUEHFmqo//BtthEPEqjGaajSYsGHzqRhcSuImaW0 zZTw== 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=C206NIdxexdFd98bnX3vpFg2wbR1P0iXXDa03rq1G6E=; b=L+VqNNGshX7cu2YGJahdoQRTwwjuQBzfRyG7YafT5w5/mMRP0oRx8A3PNPP46l7NKG 6gv7wpK6NVNWmK4xcRP3ilT66hsewVtQW4GuLU6UXzb3qX7VB/mn/lATrtFZ0KbDZaFG WKbVUtLgIirpzFsIooMh8hkxFVP/qtRzaUJllzdtOiMTQWsmW7O0I9VJpZS/CecF1gKj xjfVM8+NNGLVGVlO04ZXDFsjuuc8h3jWDDkS5sJQXrlTtKHIe/BAFa0Gv3KFL3KK4XYd i7DBjYt3c+6F0myVnQznG0YHoIF4uxPs8Qu3jjpy6pdARNYxFNeAd/rYpKOFz0abihlB bQIA== X-Gm-Message-State: APjAAAV9zLmG0696YbGXCnextMBUGwKZCWu3Ku0g5/ctbuvDSSdYZkRf 5L3jckR06qujU4c2gReS75lvuyy75WernHvpnp1zdQ== X-Google-Smtp-Source: APXvYqwxu60Uy1kt/y4mup5l8HLPCiOxkPE0cYk12NSvCGRnk7xpUeFWVaTPiBjSe0YgYMe7SGnRp1BmWQv1u+VxbpU= X-Received: by 2002:a05:6402:1459:: with SMTP id d25mr51870266edx.235.1561403802415; Mon, 24 Jun 2019 12:16:42 -0700 (PDT) MIME-Version: 1.0 References: <846314DA-2A9F-41EE-BD21-61EC1CCB80ED@mit.edu> In-Reply-To: <846314DA-2A9F-41EE-BD21-61EC1CCB80ED@mit.edu> From: Takahiko Kawasaki Date: Tue, 25 Jun 2019 04:16:31 +0900 Message-ID: To: Justin Richer Cc: oauth Content-Type: multipart/alternative; boundary="000000000000fe8db9058c16a61d" Archived-At: Subject: Re: [OAUTH-WG] ID Token by Device Flow 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 Jun 2019 19:16:46 -0000 --000000000000fe8db9058c16a61d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, Thank you. Consensus will be that "openid" in the "scope" request parameter should trigger generation of an ID token. I'm wondering if the WG plans to mention it explicitly in the spec and add "acr_values" request parameter. Best Regards, Taka 2019=E5=B9=B46=E6=9C=8825=E6=97=A5(=E7=81=AB) 1:13 Justin Richer : > Taka, > > My reading is that the device flow, like other OAuth flows, does not > prohibit extension, including passing back identity assertions like the I= D > Token. Since it inherits the token response from core OAuth 2, the ID Tok= en > could be issued along side the access token just like in the authorizatio= n > code flow.The user is present and interacting at the AS in both cases. In > fact, I=E2=80=99d say that there are enough similarities between the two = that for > the most part it should =E2=80=9Cjust work=E2=80=9D and fit the assumptio= ns of most > clients. That said, it=E2=80=99s technically true that there is no define= d profile > for the combination of the device flow and OIDC, but if something like th= at > were to be written it would be better fit to the OpenID Foundation. > > =E2=80=94 Justin > > On Jun 20, 2019, at 6:32 PM, Takahiko Kawasaki wrote: > > Hello, > > Do you have any plan to update the specification of Device Flow to suppor= t > issue of ID tokens? > > OAuth 2.0 Device Authorization Grant > > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/?include_te= xt=3D1 > > Best Regards, > Takahiko Kawasaki > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --000000000000fe8db9058c16a61d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,

Thank you. Consensus will be= that "openid" in the "scope" request parameter should = trigger generation of an ID token. I'm wondering if the WG plans to men= tion it explicitly in the spec and add "acr_values" request param= eter.

Best Regards,
Taka

<= /div>

2019=E5=B9=B46=E6=9C=8825=E6=97=A5(=E7=81=AB) 1:13 Justin Richer <<= a href=3D"mailto:jricher@mit.edu">jricher@mit.edu>:
Taka,

My reading is that the device flow, like other OAuth flows, does not p= rohibit extension, including passing back identity assertions like the ID T= oken. Since it inherits the token response from core OAuth 2, the ID Token = could be issued along side the access token just like in the authorization code flow.The user is pres= ent and interacting at the AS in both cases. In fact, I=E2=80=99d say that = there are enough similarities between the two that for the most part it sho= uld =E2=80=9Cjust work=E2=80=9D and fit the assumptions of most clients. That said, it=E2=80=99s technically true that there is no= defined profile for the combination of the device flow and OIDC, but if so= mething like that were to be written it would be better fit to the OpenID F= oundation.=C2=A0

=E2=80=94 Justin

On Jun 20, 2019, at 6:32 PM, Takahiko Kawasaki <taka@authlete.com> wrote:

Hello,

Do you have any plan to update the specification of Device Flow to sup= port issue of ID tokens?

OAuth 2.0 Device Authorization Grant

Best Regards,
Takahiko Kawasaki

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

--000000000000fe8db9058c16a61d-- From nobody Mon Jun 24 12:58:54 2019 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 2C948120091; Mon, 24 Jun 2019 12:58:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwt-bcp@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, hannes.tschofenig@arm.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <156140633210.17492.7242545711409551999.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2019 12:58:52 -0700 Archived-At: Subject: [OAUTH-WG] Alissa Cooper's Yes on draft-ietf-oauth-jwt-bcp-06: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 19:58:52 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-oauth-jwt-bcp-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 1 = Many of the recommendations in this document will actually be about implementation and use of the cryptographic mechanisms underlying JWTs that are defined by JSON Web Signature (JWS) [RFC7515], JSON Web Encryption (JWE) [RFC7516], and JSON Web Algorithms (JWA) [RFC7518]. Others will be about use of the JWT claims themselves. s/will actually be/are/ s/will be/are/ = Section 3.12 = Are all of the recommended strategies listed targeted at application developers specifically? It might be useful to note that if so. From nobody Mon Jun 24 13:00:03 2019 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 0A36112001B; Mon, 24 Jun 2019 12:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Cxvy/Nb5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nOaL8JK4 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 hugrDOJpzDjK; Mon, 24 Jun 2019 12:59:49 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A83120139; Mon, 24 Jun 2019 12:59:46 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 4961F545; Mon, 24 Jun 2019 15:59:45 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 24 Jun 2019 15:59:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=O QD1ZjJu+Rkz1+qLsW3RQ5I1tLtkvKDIjbNuJRlYDCU=; b=Cxvy/Nb5tF0rdLWbp kHoWKelSAKahB9oKNjzOPs3f35JCNxOp3oB3JVE8YMirxODWq8zO88LZUXi0WBxs kbD+DiT4r7cq2cmXvYPSkHjWrk8qTfwFrJEK3CmU2bGlWiVEH9GW+cWLUSoNcSVQ sq4zn69vuv6BOl1R0Ch2asdRzCa5vLiS3wo7ntBNbQiD+AL95z1tFZDKah3ZOOW5 Pn/FWY8WZV/pwag/vdfaA7h5Un2gK9XCZMBwtB8aWCAmxd/a4w+nODuCvCDOnJoD Z3fpXpwMCPcJHGBLLVFv1Sqq/FjPFTi9xGZRqr9Nbjeqqg3Vn8+mIIYQwW2Cly5S i8Yyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=OQD1ZjJu+Rkz1+qLsW3RQ5I1tLtkvKDIjbNuJRlYD CU=; b=nOaL8JK4McsLBnQClT9svxM5osxGn01a66u+2kAGxevGDEUZDM+eTeD0A wRIAb7AL6O45xNqsGONabYt32qxbSyhgPQBA8R8eNVod4LryE0lV56ARy8KOlXAw X/MeC1bpfAY0yek3qv5YPUQKRFl6GOf9A51S/P1NyQb2oqeGb58KF1CUA7M4aCd2 uUbQovUhM7Qw9pU0KLBI5+MdYKlyaXSdbYQTWaLzwdbZMofGjtwORrgtJwyNQp0w xIYmzrMamS8uk8T4NuxTCRHMtLf3cIXf+shIkOLUGmXA6n9B0UyqhPVtqaFkonR6 WaYNOE179OGC/CtqRqL8f9zHlHGjQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddvgddugeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrkedunecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-vpn4-1540.cisco.com (unknown [173.38.117.81]) by mail.messagingengine.com (Postfix) with ESMTPA id 0AF7880061; Mon, 24 Jun 2019 15:59:43 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <156047835427.12308.12676323646131055737@ietfa.amsl.com> Date: Mon, 24 Jun 2019 15:59:42 -0400 Cc: gen-art@ietf.org, draft-ietf-oauth-jwt-bcp.all@ietf.org, oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <85708AAA-F63E-42DF-BE2C-9937C6E08C66@cooperw.in> References: <156047835427.12308.12676323646131055737@ietfa.amsl.com> To: Brian Carpenter X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [OAUTH-WG] [Gen-art] Genart telechat review of draft-ietf-oauth-jwt-bcp-06 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 Jun 2019 19:59:52 -0000 Brian, thanks for your reviews of this document. Yaron, thanks for = addressing Brian=E2=80=99s comments. I entered a Yes ballot. Alissa > On Jun 13, 2019, at 10:12 PM, Brian Carpenter via Datatracker = wrote: >=20 > Reviewer: Brian Carpenter > Review result: Ready >=20 > Gen-ART telechat review of draft-ietf-oauth-jwt-bcp-06 >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at > . >=20 > Document: draft-ietf-oauth-jwt-bcp-06.txt > Reviewer: Brian Carpenter > Review Date: 2019-06-14 > IETF LC End Date: 2019-04-08 > IESG Telechat date: 2019-06-27 >=20 > Summary: Ready > -------- >=20 > Comments:=20 > --------- >=20 > Thank you for handling my Last Call comments. >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Mon Jun 24 13:14:26 2019 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 1E2611200F1 for ; Mon, 24 Jun 2019 13:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ERX4vxdvgeHP for ; Mon, 24 Jun 2019 13:14:21 -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 260D412002E for ; Mon, 24 Jun 2019 13:14:21 -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 x5OKEKa9002029; Mon, 24 Jun 2019 16:14:20 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x5OKEKa9002029 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1561407260; bh=ubP5wXQU5fXULpgQBww2SAiAylHyNf115L7L12AOCYU=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ltLjPryhJ80gvBh5oxwyHfGncokobA8wunBVx8JA0K6RzYv2CJ9GEKwRCOarhzS28 1gb6CMZDxYCKuZ4LOo3o+NjjhzQ2L9gyRbe6V2i6C0JzBtRe0fTqSQFVlUMGAOR9td VHx2vtbvDO4+UfzsDa3+s4mo9DsC7esEki0tl3BM= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x5OKEGKo012919; Mon, 24 Jun 2019 16:14:16 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Mon, 24 Jun 2019 16:14:15 -0400 From: Roman Danyliw To: Brian Campbell CC: oauth Thread-Topic: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls Thread-Index: AdUpJ/vy5dvAfF1OT6Ob3fhIFPK/8wBqjwmAAAMI8cA= Date: Mon, 24 Jun 2019 20:14:14 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33A3BFC@marathon> References: <359EC4B99E040048A7131E0F4E113AFC01B33A25D2@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01B33A3BFCmarathon_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls 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 Jun 2019 20:14:24 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC01B33A3BFCmarathon_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4hDQoNCk15IHJlc3BvbnNlIGlzIGlubGluZSAuLi4NCg0KRnJvbTogQnJpYW4gQ2Ft cGJlbGwgW21haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NClNlbnQ6IE1vbmRheSwg SnVuZSAyNCwgMjAxOSAxOjE3IFBNDQpUbzogUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPg0K Q2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFNlY29u ZCBBRCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtbXRscw0KDQpUaGFua3MgZm9yIHRoZSBhZGRp dGlvbmFsIHJldmlldywgUm9tYW4uIEkgZmVlbCBsdWNreSwgaXQncyBub3Qgb2Z0ZW4gb25lIGdl dHMgKnR3byogQUQgcmV2aWV3cyA6KSAgUGxlYXNlIHNlZSBiZWxvdyBmb3IgcmVwbGllcyBpbmxp bmUgd2l0aCBhIGZldyBmb2xsb3d1cCBxdWVzdGlvbnMuDQoNCltSb21hbl0gKmNodWNrbGUqDQoN Ck9uIFNhdCwgSnVuIDIyLCAyMDE5IGF0IDEyOjI5IFBNIFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0 Lm9yZzxtYWlsdG86cmRkQGNlcnQub3JnPj4gd3JvdGU6DQpIaSENCg0KSSBjb25kdWN0ZWQgYXMg c2Vjb25kIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLW10bHMgcGVyIHRoZSBBRCBoYW5k LW9mZi4gIEkgaGF2ZSB0aGUgZm9sbG93aW5nIGFkZGl0aW9uYWwgZmVlZGJhY2s6DQoNCioqIFBl ciBla3IncyBlYXJsaWVyIHJldmlldyBhdCBodHRwczovL21venBoYWItaWV0Zi5kZXZzdmNkZXYu bW96YXdzLm5ldC9EMzY1NywgcGFyYXBocmFzaW5nOg0KLS0gU2VjdGlvbiAyLjEuMiwgSG93IGlz IHRoZXNlIG1ldGFkYXRhIHBhcmFtZXRlcnMgYmVpbmcgb2J0YWluZWQ/DQoNClRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBjYW4gb2J0YWluIGNsaWVudCBtZXRhZGF0YSB2aWEgdGhlIER5bmFtaWMg Q2xpZW50IFJlZ2lzdHJhdGlvbiBQcm90b2NvbCBbUkZDNzU5MV0sIHdoaWNoIGlzIHJlZmVyZW5j ZWQgaW4gdGhlIHRvcCBvZiB0aGF0IHNlY3Rpb24uIEFsc28gdGhlIG1ldGFkYXRhIGRlZmluZWQg YnkgUkZDNzU5MSwgYW5kIHJlZ2lzdGVyZWQgZXh0ZW5zaW9ucyB0byBpdCwgaW1wbGllcyBhIGdl bmVyYWwgZGF0YSBtb2RlbCBmb3IgY2xpZW50cyB0aGF0IGlzIHVzZWQgYnkgbW9zdCBhdXRob3Jp emF0aW9uIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgZXZlbiB3aGVuIHRoZSBEeW5hbWljIENsaWVu dCBSZWdpc3RyYXRpb24gUHJvdG9jb2wgaXNuJ3QgaW4gcGxheS4gU3VjaCBpbXBsZW1lbnRhdGlv bnMgdHlwaWNhbGx5IGhhdmUgc29tZSBzb3J0IG9mICB1c2VyIGludGVyZmFjZSBhdmFpbGFibGUg Zm9yIG1hbmFnaW5nIGNsaWVudCBjb25maWd1cmF0aW9uLg0KDQpEb3NlIHRoYXQgYW5zd2VyIHlv dXIgcXVlc3Rpb24/IERvIHlvdSBiZWxpZXZlIG1vcmUgc2hvdWxkIGJlIHNhaWQgaW4gdGhlIGRv Y3VtZW50IHRvIGJldHRlciBleHBsYWluIG9yIGNsYXJpZnkgdGhhdD8NCg0KW1JvbWFuXSAgSXQg ZG9lcyBjbGVhciBpdCB1cC4gIFRoYW5rcy4gIEkgdGhpbmsgaXTigJlzIHdvcnRoIGEgc2hvcnQg c3RhdGVtZW50IGFib3V0IGhvdyB0aGUgQVMgd291bGQgZ2V0IHRoZSBmaWVsZHMuDQoNCg0KLS0g U2VjdGlvbiAzLjIsIEZpZ3VyZSAzLiAgSW4gdGhpcyBleGFtcGxlLCB3aGF0IG5ldyBpbmZvcm1h dGlvbiBpcyB0aGUgYXV0aCBzZXJ2ZXIgcHJvdmlkaW5nIHRvIHRoZSByZWx5aW5nIHBhcnR5IGhl cmU/DQoNClRoZSBuZXcgaW5mbyBoZXJlIChhbmQgaW4gU2VjdGlvbiAzLjEgdG9vKSBpcyB0aGUg aGFzaCBvZiB0aGUgY2xpZW50IGNlcnRpZmljYXRlIHRvIHdoaWNoIHRoZSBhY2Nlc3MgdG9rZW4g aXMgYm91bmQsIHdoaWNoIGlzIGluIHRoZSAiY25mIiBjb25maXJtYXRpb24gbWV0aG9kIGF0IHRo ZSBib3R0b20gYXMgdGhlICJ4NXQjUzI1NiIgbWVtYmVyLg0KDQpbUm9tYW5dICBNYWtlcyBzZW5z ZS4gIFRvIG1ha2UgdGhlIGV4YW1wbGUgY2xlYXJlciwgSeKAmWQgY2FsbCBvdXQgdGhpcyBvdXQg aW4gdGhlIHByb3NlIGludHJvZHVjaW5nIHRoZSBleGFtcGxlLg0KDQoNCioqIFNlY3Rpb24gMi4w LiAgV2hhdCBpcyB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IgaWYgdGhlIHByZXNlbnRlZCBjZXJ0aWZp Y2F0ZSBkb2Vzbid0IG1hdGNoIGV4cGVjdGVkIGNsaWVudF9pZD8gIEhvdyBpcyB0aGlzIHNpZ25h bGVkPw0KDQpXaXRoIGEgbm9ybWFsIE9BdXRoIDIuMCBlcnJvciByZXNwb25zZSB1c2luZyB0aGUg ImludmFsaWRfY2xpZW50IiBlcnJvciBjb2RlIHBlciBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNjc0OSNzZWN0aW9uLTUuMg0KDQpEbyB5b3UgdGhpbmsgdGhhdCBuZWVkcyB0byBiZSBz dGF0ZWQgbW9yZSBleHBsaWNpdGx5IGluIHRoaXMgZG9jdW1lbnQ/DQoNCltSb21hbl0gWWVzLCBJ 4oCZZCBleHBsaWNpdCBzdGF0ZSBpdCB3aXRoIHRoYXQgY2l0YXRpb24sIGVzcGVjaWFsbHkgc2lu Y2UgU2VjdGlvbiAzIGRpc2N1c3NlcyBvZiBob3cgZXJyb3JzIGFyZSByZXR1cm5lZC4NCg0KDQoq KiBTZWN0aW9uIDIuMi4gIFBlciB0aGUgc2VudGVuY2UgIkFzIHByZS1yZXF1aXNpdGUsIHRoZSBj bGllbnQgcmVnaXN0ZXJzIGl0cyBYLjUwOSBjZXJ0aWZpY2F0ZSAuLi4gb3IgYSB0cnVzdGVkIHNv dXJjZSBmb3IgaXRzIFguNTA5IGNlcnRpZmljYXRlcyAuLi4gd2l0aCB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIuDQotLSBFZGl0b3JpYWw6IHMvQXMgcHJlLXJlcXVpc2l0ZS9BcyBhIHByZXJlcXVp c2l0ZS8NCg0KZG9uZQ0KDQotLSBXaGF0J3MgYSAidHJ1c3RlZCBzb3VyY2UiIGluIHRoaXMgY2Fz ZT8gIElzIHRoYXQganVzdCBhIGp3a3NfdXJpPyAgSWYgc28sIG1heWJlIHMvYSB0cnVzdGVkIHNv dXJjZS9hIHJlZmVyZW5jZSB0byBhIHRydXN0IHNvdXJjZS8uICBJZiBub3QsIGNhbiB5b3UgcGxl YXNlIGVsYWJvcmF0ZS4NCg0KWWVzLCBpdCdzIGp1c3QgYSBqd2tzX3VyaS4gSSdsbCBjaGFuZ2Ug dGhhdC4NCg0KDQpBIGZldyBlZGl0b3JpYWwgbml0czoNCioqIFNlY3Rpb24gMi4yLjIuICBUeXBv LiAgcy9zZWMgNC43L1NlY3Rpb24gNC43Lw0KDQpmaXhlZA0KDQoNCioqIFNlY3Rpb24gMy4xICBD aXRlIERFUiBlbmNvZGluZyBhczoNCiAgICBbWDY5MF0gICAgIElUVS1ULCAiSW5mb3JtYXRpb24g VGVjaG5vbG9neSAtLSBBU04uMSBlbmNvZGluZyBydWxlczoNCiAgICAgICAgICAgICAgU3BlY2lm aWNhdGlvbiBvZiBCYXNpYyBFbmNvZGluZyBSdWxlcyAoQkVSKSwgQ2Fub25pY2FsDQogICAgICAg ICAgICAgIEVuY29kaW5nIFJ1bGVzIChDRVIpIGFuZCBEaXN0aW5ndWlzaGVkIEVuY29kaW5nIFJ1 bGVzDQogICAgICAgICAgICAgIChERVIpIiwgSVRVLVQgUmVjb21tZW5kYXRpb24gWC42OTAsIDIw MTUuDQoNCndpbGwgZG8NCg0KKiogU2VjdGlvbiA1LiAgVHlwby4gcy9tZXRhdGRhdGEvbWV0YWRh dGEvDQoNCnl1cA0KDQoNCioqIFNlY3Rpb24gNi4gIFR5cG8uICBzL1RoZSB0aGUvVGhlLw0KDQpn b3QgaXQNCg0KDQoqKiBTZWN0aW9uIDcuMi4gVHlwby4gIHMvdGhlIHRoZS90aGUvDQoNCmRvbmUN Cg0KDQoqKiBBcHBlbmRpeC4gQ2l0ZSB0aGUgZmlndXJlcyBudW1iZXJzICgjNSAtIDcpIGluIHRo ZSB0ZXh0IGRlc2NyaWJpbmcgdGhlIGNvbnRlbnRzIG9mIHRoZSBzZWN0aW9uLg0KDQp3aWxsIGRv DQoNCg0KVGhlIHNoZXBoZXJkIHdyaXRlLXVwIGlzIGluIGdvb2Qgc2hhcGUuICBUaGFuayB5b3Uu DQoNClJlZ2FyZHMsDQpSb21hbg0KDQoNCltSb21hbl0gVGhhbmtzIGZvciBhbGwgb2YgdGhlIGFi b3ZlLg0KDQpSb21hbg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0 aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN Cg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNj bG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBm aWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0K --_000_359EC4B99E040048A7131E0F4E113AFC01B33A3BFCmarathon_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBCcmlhbiEN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9N YWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+TXkgcmVzcG9uc2UgaXMgaW5saW5lIC4uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJy aWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gTW9uZGF5LCBKdW5lIDI0LCAyMDE5IDE6MTcgUE08YnI+DQo8Yj5Ubzo8L2I+ IFJvbWFuIERhbnlsaXcgJmx0O3JkZEBjZXJ0Lm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRo ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X R10gU2Vjb25kIEFEIFJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1tdGxzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rcyBmb3IgdGhlIGFkZGl0aW9uYWwgcmV2aWV3LCBSb21hbi4gSSBmZWVsIGx1Y2t5 LCBpdCdzIG5vdCBvZnRlbiBvbmUgZ2V0cyAqdHdvKiBBRCByZXZpZXdzIDopJm5ic3A7IFBsZWFz ZSBzZWUgYmVsb3cgZm9yIHJlcGxpZXMgaW5saW5lIHdpdGggYSBmZXcgZm9sbG93dXAgcXVlc3Rp b25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W1JvbWFuXSAqY2h1Y2tsZSo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNh dCwgSnVuIDIyLCAyMDE5IGF0IDEyOjI5IFBNIFJvbWFuIERhbnlsaXcgJmx0OzxhIGhyZWY9Im1h aWx0bzpyZGRAY2VydC5vcmciIHRhcmdldD0iX2JsYW5rIj5yZGRAY2VydC5vcmc8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpITxicj4NCjxicj4NCkkgY29uZHVjdGVkIGFzIHNlY29uZCBBRCByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1vYXV0aC1tdGxzIHBlciB0aGUgQUQgaGFuZC1vZmYuJm5ic3A7IEkgaGF2ZSB0 aGUgZm9sbG93aW5nIGFkZGl0aW9uYWwgZmVlZGJhY2s6PGJyPg0KPGJyPg0KKiogUGVyIGVrcidz IGVhcmxpZXIgcmV2aWV3IGF0IDxhIGhyZWY9Imh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rl di5tb3phd3MubmV0L0QzNjU3IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL21venBoYWItaWV0 Zi5kZXZzdmNkZXYubW96YXdzLm5ldC9EMzY1NzwvYT4sIHBhcmFwaHJhc2luZzo8YnI+DQotLSBT ZWN0aW9uIDIuMS4yLCBIb3cgaXMgdGhlc2UgbWV0YWRhdGEgcGFyYW1ldGVycyBiZWluZyBvYnRh aW5lZD88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBjYW4gb2J0YWluIGNsaWVudCBtZXRh ZGF0YSB2aWEgdGhlIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBQcm90b2NvbCBbUkZDNzU5 MV0sIHdoaWNoIGlzIHJlZmVyZW5jZWQgaW4gdGhlIHRvcCBvZiB0aGF0IHNlY3Rpb24uIEFsc28g dGhlIG1ldGFkYXRhIGRlZmluZWQgYnkgUkZDNzU5MSwgYW5kIHJlZ2lzdGVyZWQgZXh0ZW5zaW9u cyB0byBpdCwgaW1wbGllcyBhDQogZ2VuZXJhbCBkYXRhIG1vZGVsIGZvciBjbGllbnRzIHRoYXQg aXMgdXNlZCBieSBtb3N0IGF1dGhvcml6YXRpb24gc2VydmVyIGltcGxlbWVudGF0aW9ucyBldmVu IHdoZW4gdGhlIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBQcm90b2NvbCBpc24ndCBpbiBw bGF5LiBTdWNoIGltcGxlbWVudGF0aW9ucyB0eXBpY2FsbHkgaGF2ZSBzb21lIHNvcnQgb2YmbmJz cDsgdXNlciBpbnRlcmZhY2UgYXZhaWxhYmxlIGZvciBtYW5hZ2luZyBjbGllbnQgY29uZmlndXJh dGlvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Eb3NlIHRoYXQgYW5zd2VyIHlvdXIgcXVlc3Rpb24/IERvIHlvdSBiZWxpZXZlIG1vcmUg c2hvdWxkIGJlIHNhaWQgaW4gdGhlIGRvY3VtZW50IHRvIGJldHRlciBleHBsYWluIG9yIGNsYXJp ZnkgdGhhdD8NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5bUm9tYW5dJm5ic3A7IEl0IGRvZXMgY2xlYXIgaXQgdXAuJm5ic3A7IFRoYW5rcy4mbmJzcDsg SSB0aGluayBpdOKAmXMgd29ydGggYSBzaG9ydCBzdGF0ZW1lbnQgYWJvdXQgaG93IHRoZSBBUyB3 b3VsZCBnZXQgdGhlIGZpZWxkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t LSBTZWN0aW9uIDMuMiwgRmlndXJlIDMuJm5ic3A7IEluIHRoaXMgZXhhbXBsZSwgd2hhdCBuZXcg aW5mb3JtYXRpb24gaXMgdGhlIGF1dGggc2VydmVyIHByb3ZpZGluZyB0byB0aGUgcmVseWluZyBw YXJ0eSBoZXJlPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIG5ldyBpbmZvIGhlcmUgKGFuZCBpbiBTZWN0aW9uIDMuMSB0b28p IGlzIHRoZSBoYXNoIG9mIHRoZSBjbGllbnQgY2VydGlmaWNhdGUgdG8gd2hpY2ggdGhlIGFjY2Vz cyB0b2tlbiBpcyBib3VuZCwgd2hpY2ggaXMgaW4gdGhlICZxdW90O2NuZiZxdW90OyBjb25maXJt YXRpb24gbWV0aG9kIGF0IHRoZSBib3R0b20gYXMgdGhlICZxdW90O3g1dCNTMjU2JnF1b3Q7IG1l bWJlci4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5b Um9tYW5dJm5ic3A7IE1ha2VzIHNlbnNlLiZuYnNwOyBUbyBtYWtlIHRoZSBleGFtcGxlIGNsZWFy ZXIsIEnigJlkIGNhbGwgb3V0IHRoaXMgb3V0IGluIHRoZSBwcm9zZSBpbnRyb2R1Y2luZyB0aGUg ZXhhbXBsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCioqIFNlY3Rpb24gMi4wLiZuYnNwOyBXaGF0IGlzIHRo ZSBleHBlY3RlZCBiZWhhdmlvciBpZiB0aGUgcHJlc2VudGVkIGNlcnRpZmljYXRlIGRvZXNuJ3Qg bWF0Y2ggZXhwZWN0ZWQgY2xpZW50X2lkPyZuYnNwOyBIb3cgaXMgdGhpcyBzaWduYWxlZD88bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldpdGggYSBub3JtYWwgT0F1dGggMi4wIGVycm9yIHJlc3BvbnNlIHVzaW5nIHRoZSAmcXVvdDtp bnZhbGlkX2NsaWVudCZxdW90OyBlcnJvciBjb2RlIHBlcg0KPGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi01LjIiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTUuMjwvYT4NCjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB5b3UgdGhp bmsgdGhhdCBuZWVkcyB0byBiZSBzdGF0ZWQgbW9yZSBleHBsaWNpdGx5IGluIHRoaXMgZG9jdW1l bnQ/DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltSb21hbl0gWWVzLCBJ4oCZZCBleHBsaWNp dCBzdGF0ZSBpdCB3aXRoIHRoYXQgY2l0YXRpb24sIGVzcGVjaWFsbHkgc2luY2UgU2VjdGlvbiAz IGRpc2N1c3NlcyBvZiBob3cgZXJyb3JzIGFyZSByZXR1cm5lZC48L3NwYW4+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KKiogU2VjdGlvbiAyLjIuJm5ic3A7IFBlciB0aGUg c2VudGVuY2UgJnF1b3Q7QXMgcHJlLXJlcXVpc2l0ZSwgdGhlIGNsaWVudCByZWdpc3RlcnMgaXRz IFguNTA5IGNlcnRpZmljYXRlIC4uLiBvciBhIHRydXN0ZWQgc291cmNlIGZvciBpdHMgWC41MDkg Y2VydGlmaWNhdGVzIC4uLiB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci48YnI+DQotLSBF ZGl0b3JpYWw6IHMvQXMgcHJlLXJlcXVpc2l0ZS9BcyBhIHByZXJlcXVpc2l0ZS88bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRvbmU8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LS0gV2hhdCdzIGEgJnF1b3Q7dHJ1c3RlZCBzb3VyY2UmcXVvdDsgaW4gdGhpcyBjYXNlPyZu YnNwOyBJcyB0aGF0IGp1c3QgYSBqd2tzX3VyaT8mbmJzcDsgSWYgc28sIG1heWJlIHMvYSB0cnVz dGVkIHNvdXJjZS9hIHJlZmVyZW5jZSB0byBhIHRydXN0IHNvdXJjZS8uJm5ic3A7IElmIG5vdCwg Y2FuIHlvdSBwbGVhc2UgZWxhYm9yYXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBpdCdzIGp1c3QgYSBqd2tzX3VyaS4g SSdsbCBjaGFuZ2UgdGhhdC4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkEgZmV3IGVkaXRvcmlhbCBuaXRzOjxicj4NCioq IFNlY3Rpb24gMi4yLjIuJm5ic3A7IFR5cG8uJm5ic3A7IHMvc2VjIDQuNy9TZWN0aW9uIDQuNy88 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPmZpeGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCioqIFNlY3Rpb24gMy4xJm5ic3A7IENpdGUgREVSIGVuY29kaW5n IGFzOjxicj4NCiZuYnNwOyAmbmJzcDsgW1g2OTBdJm5ic3A7ICZuYnNwOyAmbmJzcDtJVFUtVCwg JnF1b3Q7SW5mb3JtYXRpb24gVGVjaG5vbG9neSAtLSBBU04uMSBlbmNvZGluZyBydWxlczo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU3BlY2lm aWNhdGlvbiBvZiBCYXNpYyBFbmNvZGluZyBSdWxlcyAoQkVSKSwgQ2Fub25pY2FsPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEVuY29kaW5nIFJ1 bGVzIChDRVIpIGFuZCBEaXN0aW5ndWlzaGVkIEVuY29kaW5nIFJ1bGVzPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IChERVIpJnF1b3Q7LCBJVFUt VCBSZWNvbW1lbmRhdGlvbiBYLjY5MCwgMjAxNS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndpbGwgZG8gPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPioqIFNlY3Rpb24g NS4mbmJzcDsgVHlwby4gcy9tZXRhdGRhdGEvbWV0YWRhdGEvPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj55dXA8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KKiog U2VjdGlvbiA2LiZuYnNwOyBUeXBvLiZuYnNwOyBzL1RoZSB0aGUvVGhlLzxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Z290IGl0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCioqIFNlY3Rpb24gNy4yLiBUeXBvLiZuYnNwOyBzL3RoZSB0aGUvdGhlLzxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZG9u ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQoqKiBBcHBlbmRpeC4gQ2l0ZSB0aGUgZmlndXJlcyBudW1iZXJzICgjNSAtIDcp IGluIHRoZSB0ZXh0IGRlc2NyaWJpbmcgdGhlIGNvbnRlbnRzIG9mIHRoZSBzZWN0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ d2lsbCBkbyA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KVGhlIHNoZXBoZXJkIHdyaXRlLXVwIGlzIGluIGdvb2Qgc2hhcGUu Jm5ic3A7IFRoYW5rIHlvdS48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NClJvbWFuPGJyPg0KPGJy Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+W1JvbWFuXSBUaGFua3MgZm9yIGFsbCBvZiB0aGUgYWJvdmUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Sb21hbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRl cjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJ Q0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1h dGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4NCiBB bnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11 bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBi eSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMg ZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_359EC4B99E040048A7131E0F4E113AFC01B33A3BFCmarathon_-- From nobody Mon Jun 24 14:04:32 2019 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 8CCC1120146 for ; Mon, 24 Jun 2019 14:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 DcyZoht1-Yy8 for ; Mon, 24 Jun 2019 14:04:28 -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 9080F120139 for ; Mon, 24 Jun 2019 14:04:28 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id k20so1805082ios.10 for ; Mon, 24 Jun 2019 14:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wuOXkCcZhlZrhKDTL56D97ppWpDyAKSAtknQb55V8wQ=; b=jJY/lgUjnbCNZQbtVPDmy/XO8n+PaNlb/CfqS3GQYY89x3tn0LTOjA8Wrbm4hrHxOP vXKU1bxICJR29L52wcB/twE3oJ4lRcX20mD8hWdCVdTpO8IhYKXLdMjZ5O5XEHVRJpiM yfApDAkovyGU0+d0cJlS0zZM9npnew8NmCsFk= 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=wuOXkCcZhlZrhKDTL56D97ppWpDyAKSAtknQb55V8wQ=; b=cF3UhCTX/1EDUyd8Ed5iPNvz5QFlLnInxy6tyvG9srOO1Z7COnEwfA7Cl6tcP9JTWm 9XnSNfkhE/GAylvpKQPNVoBmjOnFqCXlI+tYeWtWG0LLeGZFLCEO5DUp6/33WpXWGvxW agR//XpO99wOo7sAaU4O6hcXIA7bUfSyWRA0gX4uwQzfjs/uPxnFBXq+MNx5/Aw1kft4 8RLIVK8FJ5ZoibOb+s8USGAUamU+CTC8vAuqB7DszHAr3tXplM1SuAXN6YwkqLFfGidc PHyyDTbwjk92XeSe73dNO5+qC5QpPtbT4RR+mN+VuDoYrp5hw3cT0q6Dwh4W6DAx7GWU 5P/Q== X-Gm-Message-State: APjAAAUbnGvSZsQX2ATl9JytbfMzmx7uqSF7uGWZeYgwaRT1tctWFUbO r4jhl2wuAEaAwuFms5/0LhWa5JYiwqf1wdL24dROmbkwZp9Lyj92Uf+S9SL6ZQ9DzIt0D9h0e4d 00TSjMsG/IIHA2g== X-Google-Smtp-Source: APXvYqzjBSl6FCrhBnmr+pWKF3m/7hBfA+93hOrbo2PwHcIoX6LexH6ux2Tdq/UJ9oBhd2qc7f9jCXMGGs+ry7EWHL0= X-Received: by 2002:a6b:ce19:: with SMTP id p25mr34645064iob.201.1561410267741; Mon, 24 Jun 2019 14:04:27 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B33A25D2@marathon> <359EC4B99E040048A7131E0F4E113AFC01B33A3BFC@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33A3BFC@marathon> From: Brian Campbell Date: Mon, 24 Jun 2019 15:04:01 -0600 Message-ID: To: Roman Danyliw Cc: oauth Content-Type: multipart/alternative; boundary="0000000000005b9bd9058c182822" Archived-At: Subject: Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls 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 Jun 2019 21:04:31 -0000 --0000000000005b9bd9058c182822 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Roman, I'll work to incorporate those suggestions into the next revision before the impending I-D submission cutoff date. On Mon, Jun 24, 2019 at 2:14 PM Roman Danyliw wrote: > Hi Brian! > > > > My response is inline ... > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Monday, June 24, 2019 1:17 PM > *To:* Roman Danyliw > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls > > > > Thanks for the additional review, Roman. I feel lucky, it's not often one > gets *two* AD reviews :) Please see below for replies inline with a few > followup questions. > > > > [Roman] *chuckle* > > > > On Sat, Jun 22, 2019 at 12:29 PM Roman Danyliw wrote: > > Hi! > > I conducted as second AD review of draft-ietf-oauth-mtls per the AD > hand-off. I have the following additional feedback: > > ** Per ekr's earlier review at > https://mozphab-ietf.devsvcdev.mozaws.net/D3657, paraphrasing: > -- Section 2.1.2, How is these metadata parameters being obtained? > > > > The authorization server can obtain client metadata via the Dynamic Clien= t > Registration Protocol [RFC7591], which is referenced in the top of that > section. Also the metadata defined by RFC7591, and registered extensions = to > it, implies a general data model for clients that is used by most > authorization server implementations even when the Dynamic Client > Registration Protocol isn't in play. Such implementations typically have > some sort of user interface available for managing client configuration. > > > > Dose that answer your question? Do you believe more should be said in the > document to better explain or clarify that? > > > > [Roman] It does clear it up. Thanks. I think it=E2=80=99s worth a shor= t > statement about how the AS would get the fields. > > > > > > -- Section 3.2, Figure 3. In this example, what new information is the > auth server providing to the relying party here? > > > > The new info here (and in Section 3.1 too) is the hash of the client > certificate to which the access token is bound, which is in the "cnf" > confirmation method at the bottom as the "x5t#S256" member. > > > > [Roman] Makes sense. To make the example clearer, I=E2=80=99d call out = this out > in the prose introducing the example. > > > > > ** Section 2.0. What is the expected behavior if the presented > certificate doesn't match expected client_id? How is this signaled? > > > > With a normal OAuth 2.0 error response using the "invalid_client" error > code per https://tools.ietf.org/html/rfc6749#section-5.2 > > > > Do you think that needs to be stated more explicitly in this document? > > > > [Roman] Yes, I=E2=80=99d explicit state it with that citation, especially= since > Section 3 discusses of how errors are returned. > > > > > ** Section 2.2. Per the sentence "As pre-requisite, the client registers > its X.509 certificate ... or a trusted source for its X.509 certificates > ... with the authorization server. > -- Editorial: s/As pre-requisite/As a prerequisite/ > > > > done > > > > -- What's a "trusted source" in this case? Is that just a jwks_uri? If > so, maybe s/a trusted source/a reference to a trust source/. If not, can > you please elaborate. > > > > Yes, it's just a jwks_uri. I'll change that. > > > > > A few editorial nits: > ** Section 2.2.2. Typo. s/sec 4.7/Section 4.7/ > > > > fixed > > > > > ** Section 3.1 Cite DER encoding as: > [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: > Specification of Basic Encoding Rules (BER), Canonical > Encoding Rules (CER) and Distinguished Encoding Rules > (DER)", ITU-T Recommendation X.690, 2015. > > > > will do > > > > ** Section 5. Typo. s/metatdata/metadata/ > > > > yup > > > > > ** Section 6. Typo. s/The the/The/ > > > > got it > > > > > ** Section 7.2. Typo. s/the the/the/ > > > > done > > > > > ** Appendix. Cite the figures numbers (#5 - 7) in the text describing the > contents of the section. > > > > will do > > > > > The shepherd write-up is in good shape. Thank you. > > Regards, > Roman > > > > [Roman] Thanks for all of the above. > > > > Roman > > > > > _______________________________________________ > 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 sende= r > immediately by e-mail and delete the message and any file attachments fro= m > 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._ --0000000000005b9bd9058c182822 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Roman, I'll work to incorporat= e those suggestions into the next revision before the impending I-D submiss= ion cutoff date.

On Mon, Jun 24, 2019 at 2:14 PM Roman Danyliw <rdd@cert.org> wrote:

Hi Brian!

<= span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col= or:rgb(31,73,125)">=C2=A0

My response is inline ...=

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingidentity= .com]
Sent: Monday, June 24, 2019 1:17 PM
To: Roman Danyliw <rdd@cert.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls

=C2=A0

Thanks for the additional review, Roman. I feel luck= y, it's not often one gets *two* AD reviews :)=C2=A0 Please see below f= or replies inline with a few followup questions.

=C2=A0

[Roman] *chuckl= e*

=C2=A0

On Sat, Jun 22, 2019 at 12:29 PM Roman Danyliw <<= a href=3D"mailto:rdd@cert.org" target=3D"_blank">rdd@cert.org> wrote= :

Hi!

I conducted as second AD review of draft-ietf-oauth-mtls per the AD hand-of= f.=C2=A0 I have the following additional feedback:

** Per ekr's earlier review at https://mozphab-ietf.devsvcdev.mozaws.net/D3657, paraphrasing:
-- Section 2.1.2, How is these metadata parameters being obtained?

=C2=A0

The authorization server can obtain client metadata = via the Dynamic Client Registration Protocol [RFC7591], which is referenced= in the top of that section. Also the metadata defined by RFC7591, and regi= stered extensions to it, implies a general data model for clients that is used by most authorization server i= mplementations even when the Dynamic Client Registration Protocol isn't= in play. Such implementations typically have some sort of=C2=A0 user inter= face available for managing client configuration.

=C2=A0

Dose that answer your question? Do you believe more = should be said in the document to better explain or clarify that?

=C2=A0

[Roman]=C2=A0 It does clear it u= p.=C2=A0 Thanks.=C2=A0 I think it=E2=80=99s worth a short statement about h= ow the AS would get the fields.

=C2=A0

=C2=A0

-- Section 3.2, Figure 3.=C2=A0 In this example, wha= t new information is the auth server providing to the relying party here?

=C2=A0

The new info here (and in Section 3.1 too) is the ha= sh of the client certificate to which the access token is bound, which is i= n the "cnf" confirmation method at the bottom as the "x5t#S2= 56" member.

=C2=A0

[Roman]=C2=A0 Makes sense.=C2=A0= To make the example clearer, I=E2=80=99d call out this out in the prose in= troducing the example.

=C2=A0


** Section 2.0.=C2=A0 What is the expected behavior if the presented certif= icate doesn't match expected client_id?=C2=A0 How is this signaled?<= /u>

=C2=A0

With a normal OAuth 2.0 error response using the &qu= ot;invalid_client" error code per https://tools.ietf.org/html/rfc6749#section-5.2

=C2=A0

Do you think that needs to be stated more explicitly= in this document?

=C2=A0

[Roman] Yes, I= =E2=80=99d explicit state it with that citation, especially since Section 3= discusses of how errors are returned.=C2=A0

=C2=A0


** Section 2.2.=C2=A0 Per the sentence "As pre-requisite, the client r= egisters its X.509 certificate ... or a trusted source for its X.509 certif= icates ... with the authorization server.
-- Editorial: s/As pre-requisite/As a prerequisite/

=C2=A0

done

=C2=A0

-- What's a "trusted source" in this c= ase?=C2=A0 Is that just a jwks_uri?=C2=A0 If so, maybe s/a trusted source/a= reference to a trust source/.=C2=A0 If not, can you please elaborate.

=C2=A0

Yes, it's just a jwks_uri. I'll change that.=

=C2=A0


A few editorial nits:
** Section 2.2.2.=C2=A0 Typo.=C2=A0 s/sec 4.7/Section 4.7/

=C2=A0

fixed

=C2=A0


** Section 3.1=C2=A0 Cite DER encoding as:
=C2=A0 =C2=A0 [X690]=C2=A0 =C2=A0 =C2=A0ITU-T, "Information Technology= -- ASN.1 encoding rules:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Specification of Basic Enc= oding Rules (BER), Canonical
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Encoding Rules (CER) and D= istinguished Encoding Rules
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (DER)", ITU-T Recomme= ndation X.690, 2015.

=C2=A0

will do

=C2=A0

** Section 5.=C2=A0 Typo. s/metatdata/metadata/

=C2=A0

yup

=C2=A0


** Section 6.=C2=A0 Typo.=C2=A0 s/The the/The/

=C2=A0

got it

=C2=A0


** Section 7.2. Typo.=C2=A0 s/the the/the/

=C2=A0

done

=C2=A0


** Appendix. Cite the figures numbers (#5 - 7) in the text describing the c= ontents of the section.

=C2=A0

will do

=C2=A0


The shepherd write-up is in good shape.=C2=A0 Thank you.

Regards,
Roman

=C2=A0

[Roman] Thanks for all of the ab= ove.

=C2=A0

Roman

=C2=A0


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


CONFIDENTI= ALITY NOTICE: This email may contain confidential and privileged material f= or the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed.=C2=A0 If you have received this communication in error, please notify t= he sender immediately by e-mail and delete the message and any file attachm= ents 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. --0000000000005b9bd9058c182822-- From nobody Mon Jun 24 16:20:24 2019 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 BD7E61201A8; Mon, 24 Jun 2019 16:20:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwt-bcp@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, hannes.tschofenig@arm.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156141841569.17730.5307482163620594441.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2019 16:20:15 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-bcp-06: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 23:20:16 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-bcp-06: Discuss 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-jwt-bcp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for assembling this document; it will be very valuable to the community. I intend to ballot Yes once the following items are resolved: Section 2.6 notes: Previous versions of the JSON format such as the obsoleted [RFC7159] allowed several different character encodings: UTF-8, UTF-16 and UTF- 32. This is not the case anymore, with the latest standard [RFC8259] only allowing UTF-8. [...] The actual situation is a bit more subtle than this text makes it seem; interoperable JSON can only use non-UTF-8 with explicit mutual prearrangement in a closed ecosystem. So, while this statement is true for Internet JWT usage, it may not be true for *all* JWT usage. (I do see that in Section 3.7 of this document we do mandate UTF-8 for JWT, which makes things unambiguous, even if this text here is not correct.) Section 3.2 notes: JWT libraries SHOULD NOT generate JWTs using "none" unless explicitly requested to do by the caller. I couldn't find anywhere where we have matching guidance about "SHOULD NOT consume JWTs using 'none' unless explicitly requested"; this seems important enough to get called out explicitly. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I also have some non-Discuss-level substantive comments in the section-by-section notes, in addition to the usual editorial nits. Section 1 and/or encrypted. The JWT specification has seen rapid adoption because it encapsulates security-relevant information in one, easy to protect location, and because it is easy to implement using widely- nit: "one easy-to-protect location". Section 2.2 I'd consider rewording the text here to make it more poignant; perhaps: In addition, some applications use a keyed MAC algorithm such as "HS256" to sign tokens, but supply a weak symmetric key with insufficient entropy (such as a human memorable password). Such keys are vulnerable to offline brute-force or dictionary attacks once an attacker possesses such a token. Section 2.4 I'd suggest noting that the compression attacks are particularly powerful when there is attacker-controlled data in the same compression space as secret data. Section 3.2 Therefore, applications MUST only allow the use of cryptographically current algorithms that meet the security requirements of the application. This set will vary over time as new algorithms are introduced and existing algorithms are deprecated due to discovered cryptographic weaknesses. Applications MUST therefore be designed to enable cryptographic agility. This seems to have high overlap with BCP 201; a reference is probably in order. Section 3.4 Some cryptographic operations, such as Elliptic Curve Diffie-Hellman key agreement ("ECDH-ES") take inputs that may contain invalid values, such as points not on the specified elliptic curve or other invalid points (see e.g. [Valenta], Sec. 7.1). Either the JWS/JWE library itself must validate these inputs before using them or it must use underlying cryptographic libraries that do so (or both!). side note: A phrasing like "JWS/JWE libraries MUST ensure that such input validation occurs" would leave the same wiggle room for the validation to occur at the underlying crypto layer, while leaving it crystal clear what entity is responsible for ensuring that the checks occur". But since I don't expect a change of this nature to actually cause different behavior by implementors, I'm not very tied to it. Section 3.8 When we say "[o]ther applications may use different means of binding keys to issuers", is there any value in noting that certification by a trusted authority is a common way to perform this binding (in some contexts)? Section 3.9 If the same issuer can issue JWTs that are intended for use by more than one relying party or application, the JWT MUST contain an "aud" (audience) claim that can be used to determine whether the JWT is being used by an intended party or was substituted by an attacker at an unintended party. Furthermore, the relying party or application MUST validate the audience value and if the audience value is not present or not associated with the recipient, it MUST reject the JWT. (grammar nit?) Is the "Furthermore" sentence supposed to still be scoped to the case where the issuer can issue JWTs for more than one audience? If not, it seems like we're requiring the rejection of all "aud"-less JWTs but not requiring "aud" to be present when generating them. Section 3.10 Applications should protect against such attacks, e.g., by matching the URL to a whitelist of allowed locations, and ensuring no cookies are sent in the GET request. This could probably be a SHOULD (or even a MUST?). Section 3.11 When applying explicit typing to a Nested JWT, the "typ" header parameter containing the explicit type value MUST be present in the inner JWT of the Nested JWT (the JWT whose payload is the JWT Claims Set). The same "typ" header parameter value MAY be present in the outer JWT as well, to explicitly type the entire Nested JWT. This is an interesting recommendation, as it is in some sense *introducing* type confusion by using the same type name for JWTs with different structures (the inner and outer JWTs)! My sense is that it is not practical to change current usage, though, so I think this should be treated as a side note and not an actionable recommendation. Section 3.12 - Use different keys for different kinds of JWTs. Then the keys used to validate one kind of JWT will fail to validate other kinds of JWTs. It might be worth calling back an analogy to RFC 8037's security considerations (where we advise to keep an association between key material and key algorithm), in effect extending the scope of "algorithm" to include application usage. Given the broad diversity of JWT usage and applications, the best combination of types, required claims, values, header parameters, key usages, and issuers to differentiate among different kinds of JWTs will, in general, be application specific. For new JWT applications, the use of explicit typing is RECOMMENDED. This last recommendation seems to duplicate one from the end of Section 3.11. While it's important and worth reiterating, we do usually try to avoiding using normative RFC 2119 language when repeating ourselves, to make it very clear which requirement is the binding one. From nobody Mon Jun 24 17:17:28 2019 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 D1C6B12016C for ; Mon, 24 Jun 2019 17:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 JD7BbAMJ-BFE for ; Mon, 24 Jun 2019 17:17:23 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0: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 5121D1200B6 for ; Mon, 24 Jun 2019 17:17:23 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id e8so15399068otl.7 for ; Mon, 24 Jun 2019 17:17:23 -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=5oAZgzq/qFNe19AvEFG59U/enlru6Nr5210d8PLSjPw=; b=sYGwCHfuJw4Tb8fOqJQnCUTjpti3Z75zivCCYb1+0Z8b6Y343EsTljrxdtqAWN/ouh NXzz+23KwM28GB5kEzOaYeMVXWlYYn3wvQyFNWPgUl6wdxH3y3GE6Uxx6CijAsOcUX0T /sVCGXT7dv62B7agTf0gn2A4pVI5iwG+vfJSjXfwVYHUON8CFDRCdpk9dZ7XFnIV8TEX S7MxPGfJ2sMz37AVyEEPu2rQcCOrgP3U74M2c0AAXlRgj/US2DZqHrdJ2N1WxiLhOdz7 u0/v8Lv98OVtvMUuO2fpn8PKVzJh6mmdgW/Dib6ilaEnDh2e3e96uXihO7u8Smqpkyi5 k7mw== 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=5oAZgzq/qFNe19AvEFG59U/enlru6Nr5210d8PLSjPw=; b=myQyU3rXQ1oan+V4slVpgemKcdbe9KXl7UoAdk1hp+A4+mfBJcDJWGACTGsw7+uqzb rIAp/bhJaolm8WFxerIVU91LjISh/Br/58IC08NRaarXUVBhP8QcdFp/uj1W3dQK4Zlw aWamtETLIx0GIy3j3JxwVT5/ZBtmdU98UvH7+USLQHqL74EkMJq0hJEQ3Asl1hq/exhz wJIXy9vDFGMGa5XElskuEU0SZBZwFih8Dw+wAltzihCu4kibfMPkv6Sd9D88C/LzaHSv h/2onLprjVW0+3SUOUxTH4qmR1U5zH559bTcKmzY4EmCh0NLwuj4iVs24FcJ0fDnBP3g iW6A== X-Gm-Message-State: APjAAAXFk54bcF3mwe/NWSJmKF17oBB4UWYMztVFpL8Wh4u7FGLIDo5D +3P4n3i59BFkkHmI3xO3Uajr8CadfsuEpg+duz4eGQ== X-Google-Smtp-Source: APXvYqxK2oBJfDHAzrhpzX4sy3l8BEL3ypc3ya6qJ7i9qVLeDOHcd71NPDO5sWAxyjHhsbqdL6qWw9+8I3ZFuVNyGxI= X-Received: by 2002:a05:6830:14c:: with SMTP id j12mr13330238otp.181.1561421842218; Mon, 24 Jun 2019 17:17:22 -0700 (PDT) MIME-Version: 1.0 References: <846314DA-2A9F-41EE-BD21-61EC1CCB80ED@mit.edu> In-Reply-To: From: William Denniss Date: Mon, 24 Jun 2019 17:17:13 -0700 Message-ID: To: Takahiko Kawasaki Cc: Justin Richer , oauth Content-Type: multipart/alternative; boundary="0000000000004067d0058c1adac0" Archived-At: Subject: Re: [OAUTH-WG] ID Token by Device Flow 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 Jun 2019 00:17:27 -0000 --0000000000004067d0058c1adac0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Taka, On Mon, Jun 24, 2019 at 12:16 PM Takahiko Kawasaki wrote: > Hi Justin, > > Thank you. Consensus will be that "openid" in the "scope" request > parameter should trigger generation of an ID token. > +1, and the last time I checked, that=E2=80=99s how Google's implementation behaved. I'm wondering if the WG plans to mention it explicitly in the spec and add > "acr_values" request parameter. > No plans to do this. The spec is in the edit queue so such a change can't be made and as Justin said it may be more appropriate in OpenID Foundation, if it's needed. Best, William > Best Regards, > Taka > > > 2019=E5=B9=B46=E6=9C=8825=E6=97=A5(=E7=81=AB) 1:13 Justin Richer : > >> Taka, >> >> My reading is that the device flow, like other OAuth flows, does not >> prohibit extension, including passing back identity assertions like the = ID >> Token. Since it inherits the token response from core OAuth 2, the ID To= ken >> could be issued along side the access token just like in the authorizati= on >> code flow.The user is present and interacting at the AS in both cases. I= n >> fact, I=E2=80=99d say that there are enough similarities between the two= that for >> the most part it should =E2=80=9Cjust work=E2=80=9D and fit the assumpti= ons of most >> clients. That said, it=E2=80=99s technically true that there is no defin= ed profile >> for the combination of the device flow and OIDC, but if something like t= hat >> were to be written it would be better fit to the OpenID Foundation. >> >> =E2=80=94 Justin >> >> On Jun 20, 2019, at 6:32 PM, Takahiko Kawasaki wrote= : >> >> Hello, >> >> Do you have any plan to update the specification of Device Flow to >> support issue of ID tokens? >> >> OAuth 2.0 Device Authorization Grant >> >> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/?include_t= ext=3D1 >> >> Best Regards, >> Takahiko Kawasaki >> >> _______________________________________________ >> 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 > --0000000000004067d0058c1adac0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Taka,

On Mon, Jun 24, 2019 at 12:16 PM = Takahiko Kawasaki <taka@authlete.co= m> wrote:
H= i Justin,

Thank you. Consensus will be that "openid= " in the "scope" request parameter should trigger generation= of an ID token.

+1, and the last time I checked, that=E2=80=99s how Google'= ;s implementation behaved.=C2=A0

I'm wondering if the WG pla= ns to mention it explicitly in the spec and add "acr_values" requ= est parameter.

No plans to do this. The spec is in the edit queue so such a chan= ge can't be made and as Justin said it may be more appropriate in OpenI= D Foundation, if it's needed.=C2=A0

Best,
William

=
Best Regards,
Taka


<= div class=3D"gmail_quote">
2019=E5=B9= =B46=E6=9C=8825=E6=97=A5(=E7=81=AB) 1:13 Justin Richer <jricher@mit.edu>:
Taka,

My reading is that the device flow, like other OAuth flows, does not p= rohibit extension, including passing back identity assertions like the ID T= oken. Since it inherits the token response from core OAuth 2, the ID Token = could be issued along side the access token just like in the authorization code flow.The user is pres= ent and interacting at the AS in both cases. In fact, I=E2=80=99d say that = there are enough similarities between the two that for the most part it sho= uld =E2=80=9Cjust work=E2=80=9D and fit the assumptions of most clients. That said, it=E2=80=99s technically true that there is no= defined profile for the combination of the device flow and OIDC, but if so= mething like that were to be written it would be better fit to the OpenID F= oundation.=C2=A0

=E2=80=94 Justin

On Jun 20, 2019, at 6:32 PM, Takahiko Kawasaki <taka@authlete.com> wrote:

Hello,

Do you have any plan to update the specification of Device Flow to sup= port issue of ID tokens?

OAuth 2.0 Device Authorization Grant

Best Regards,
Takahiko Kawasaki

_______________________________________________
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
--0000000000004067d0058c1adac0-- From nobody Mon Jun 24 21:03:33 2019 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 88B841204AD for ; Mon, 24 Jun 2019 21:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 h6KNU2Oesc1H for ; Mon, 24 Jun 2019 21:03:25 -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 E196E120220 for ; Mon, 24 Jun 2019 21:03:24 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id u8so1351630wmm.1 for ; Mon, 24 Jun 2019 21:03: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:content-transfer-encoding; bh=zkmkXLRLMraP/LMoeNSiHFQ93Z7A7vjnXgQ9vv9L9bg=; b=esKe5WaeV8J0xL/vGTRkx5NY7vYeppT5Nge6adaY+YzhoOKtXBWzO9gTwovl6VHxl9 3BSDIUw9l/ELBZw7HKR0TTYE28gVjTNPf2+JHgnKstYGBQR/jyC26B3/MQ1xyeZ938yf u+n7kw6FFKKeDAfcirXM+pTPsAbm7PgvKTpdZIp8iz1qewFv2cQ2xlL37RutQxtBpDVg ClX4wdm8nHEG4Q4K8BPx7fO1l2T6zWQ8paCNoOWINxMtx4gBubNh2gfu2EstpoAyi6Jx uVdMbArYeclsWupB9m8JWy29/Vppo/NSYBA9W0+nnJYCpB+sv9xc8xFVXTJRoypb1I9U EV4g== 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:content-transfer-encoding; bh=zkmkXLRLMraP/LMoeNSiHFQ93Z7A7vjnXgQ9vv9L9bg=; b=mr7SC/bkFYUWp7P/+lG4sndVNGpCnYhFa5xpVrYeoHiyhgWNFyHuidcXcLvfbHU0Xr Hb7qeYF4nHAkZNLlktOH8ehCzPepftwOzrg5bbDVgPNYFdLiIsz7HiS2gwxsvcddwYGh 5TJi/yvsN5NNKLJ/1qd/erTFNawxuVBaA1cIbOgFFhdASO+4t3rUla1NdojKjnXQvs6e ZTaYoOZ9ylx60dSpZ7Gm3GhMAcNUOiBhpK/Ed2ATONckcowKt58RqD6bQGmlwz4E5X49 7BfKTravnvFIF0Q/cHpNGzrj3/0aJjbxV0eVokq0PmC/IJKu5ooIDp2CMqLUpxyrWOPI nihw== X-Gm-Message-State: APjAAAVi4CtwzSJabtWdcyTzrMeFxrb8gm+XHSRz661FP4XHkWZ+ZQ3c Db86KdpDTxG/NMSZuJijIjovzlp+2PzlK90kEXQ= X-Google-Smtp-Source: APXvYqwe0xlureN7oUudau4Ss+vMpj3BBcrBsMN5yQhr8zt2XoVt4QT/RkujOpR8bhWHhzKhcs8U9GKlZ9iM1j+F7oI= X-Received: by 2002:a1c:2dd2:: with SMTP id t201mr5658932wmt.109.1561435402758; Mon, 24 Jun 2019 21:03:22 -0700 (PDT) MIME-Version: 1.0 References: <846314DA-2A9F-41EE-BD21-61EC1CCB80ED@mit.edu> In-Reply-To: From: Nat Sakimura Date: Tue, 25 Jun 2019 00:03:12 -0400 Message-ID: To: William Denniss Cc: Takahiko Kawasaki , oauth Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] ID Token by Device Flow 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 Jun 2019 04:03:32 -0000 If you are willing to draft one, it should be able to be done reasonably quickly at OIDF. On Mon, Jun 24, 2019 at 8:17 PM William Denniss wrote: > > Hi Taka, > > On Mon, Jun 24, 2019 at 12:16 PM Takahiko Kawasaki wr= ote: >> >> Hi Justin, >> >> Thank you. Consensus will be that "openid" in the "scope" request parame= ter should trigger generation of an ID token. > > > +1, and the last time I checked, that=E2=80=99s how Google's implementati= on behaved. > >> I'm wondering if the WG plans to mention it explicitly in the spec and a= dd "acr_values" request parameter. > > > No plans to do this. The spec is in the edit queue so such a change can't= be made and as Justin said it may be more appropriate in OpenID Foundation= , if it's needed. > > Best, > William > >> >> Best Regards, >> Taka >> >> >> 2019=E5=B9=B46=E6=9C=8825=E6=97=A5(=E7=81=AB) 1:13 Justin Richer : >>> >>> Taka, >>> >>> My reading is that the device flow, like other OAuth flows, does not pr= ohibit extension, including passing back identity assertions like the ID To= ken. Since it inherits the token response from core OAuth 2, the ID Token c= ould be issued along side the access token just like in the authorization c= ode flow.The user is present and interacting at the AS in both cases. In fa= ct, I=E2=80=99d say that there are enough similarities between the two that= for the most part it should =E2=80=9Cjust work=E2=80=9D and fit the assump= tions of most clients. That said, it=E2=80=99s technically true that there = is no defined profile for the combination of the device flow and OIDC, but = if something like that were to be written it would be better fit to the Ope= nID Foundation. >>> >>> =E2=80=94 Justin >>> >>> On Jun 20, 2019, at 6:32 PM, Takahiko Kawasaki wrot= e: >>> >>> Hello, >>> >>> Do you have any plan to update the specification of Device Flow to supp= ort issue of ID tokens? >>> >>> OAuth 2.0 Device Authorization Grant >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/?include_= text=3D1 >>> >>> Best Regards, >>> Takahiko Kawasaki >>> >>> _______________________________________________ >>> 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 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From nobody Mon Jun 24 22:04:56 2019 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 441BE12004D; Mon, 24 Jun 2019 22:04:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwt-bcp@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, hannes.tschofenig@arm.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <156143908719.24005.13391480103830414058.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2019 22:04:47 -0700 Archived-At: Subject: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-jwt-bcp-06: (with DISCUSS and 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, 25 Jun 2019 05:04:47 -0000 Adam Roach has entered the following ballot position for draft-ietf-oauth-jwt-bcp-06: Discuss 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-jwt-bcp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for everyone who worked to get this document out the door. I found it to be well-organized and easy to read. --------------------------------------------------------------------------- This is a process discuss for Roman to handle, and I plan to clear it during the IESG formal telechat. This document is intended for BCP status. It has a normative reference to RFC 8017, which is an informational document. Checking the last call text (https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/edit/lastcalltext/), there is no mention of RFC 8017, nor does RFC 8017 appear in the downref registry (https://datatracker.ietf.org/doc/downref/). Thanks to RFC 8067, we are not required to run this document through IETF LC again (and, given that RFC 8017's predecessor, RFC 3447, is in the registry, we probably don't want to). However, we'll need to minute that the point was raised and addressed. There is also at least one additional requirement imposed by section 2 of RFC 8067 that needs to be satisfied (see the last sentence in that section). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- §3.2: > That said, if a JWT is cryptographically protected by a transport > layer, such as TLS using cryptographically current algorithms, there > may be no need to apply another layer of cryptographic protections to > the JWT. It may be helpful to distinguish between end-to-end TLS encryption (such as that seen in HTTPS, even in the presence of proxies) and hop-by-hop TLS encryption (such as that seen in SIPS when proxies are present). In the latter case, intermediaries may perform attacks that would otherwise only be possible to mount by the endpoints. My concrete suggestion is to modify the above text to read "...protected end-to-end by a transport layer, such as..." --------------------------------------------------------------------------- §3.2: > - Avoid all RSA-PKCS1 v1.5 [RFC2313] encryption algorithms, > preferring RSA-OAEP ([RFC8017], Sec. 7.1). It's not clear to me what this recommendation intends to say regarding the algorithms in RFC 2437 and RFC 3447. One might infer that they're deprecated as well. If this is the intention, please be explicit. From nobody Tue Jun 25 01:40:17 2019 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 58F66120274 for ; Tue, 25 Jun 2019 01:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jkxLjAM7NZJ for ; Tue, 25 Jun 2019 01:40:13 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0: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 0C7131200E9 for ; Tue, 25 Jun 2019 01:40:13 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id e8so16407226otl.7 for ; Tue, 25 Jun 2019 01:40:13 -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=PhTPsTpdJz+83Mg6WdYfm7yyhIvlT1HD/JMc5/f1GSI=; b=U9Ct6VJTLQYVnruZMG9fMLXL+K4835+QC77rHduVLBrLw7tdha2x1FbSlz6IqBBvSx tChcP3oYGMXcsW/Z+QpP5ZtTmR2NZKTuRvcjm0/wLuuvY+Bbunst9KWGeCU3KtHayK2/ dFWJYeFUbN6dpq2d3RQWsI/H7yZOV9iroQbVRM3mIApGpgL7q3uXLXFbZHY32hdNzft4 +HHZolAmH5bvdjyl6Ax0Y7a8txpIJdxwON8pj8qDW7wzoqVNe85rkK6/7dGk3T35nZLu CbU5aLKE9c/H7MTugoJv3RwiX6zCOmil1B9yBBuJTc2MF+Yn00ul/IKtrl59n40H+hB5 CVMA== 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=PhTPsTpdJz+83Mg6WdYfm7yyhIvlT1HD/JMc5/f1GSI=; b=TnnufzPn7202SOvyf4rCwRrtSs9tUsHbIqrqli9wHwgSCddTxJGD2AKr1pe7yac7iC im+/QP8B5aNbSz7BJ+OgUwjZsLCUgfM6Sul+hn/OKl34GEu+V0LDOKLx9zTMXapUdQkH cyk0+wmIfwwYswPwBUNWAkAl07S62ELc29roVN6iy4L7N8x+/1yRgpxJcvEF9eUgz9DY K6Hoh+EPgreeS6QZx1sAp0r6BNcCLDJfU3A5Pw+Fn85a604AtClaz7N6+KAjHRs1XnoD q4AGZ/KiSCQy2+mt6l73r1aALf+AXo+PjG6hzu56do9DwHaDLzkEI40rjgKjx8DF+imF n5ww== X-Gm-Message-State: APjAAAXtlK6tAXSmWKk2Wc5YvpUiw/6fay4srDNivDUmU/pLaT1Xw3rA w1lmkfgVbPZhCCkJtEo5ol5Jxlzj6sPIny3sLiG2u50h9w== X-Google-Smtp-Source: APXvYqz6gNsRjV6pgrUInEbcnZqtlc1eLnKtrAdo3vRO9UWsI5m45a0oXrDSyWwbqMnwFVGf+iptN+CH+pQ0pquWEso= X-Received: by 2002:a9d:3d64:: with SMTP id a91mr96534530otc.258.1561452012034; Tue, 25 Jun 2019 01:40:12 -0700 (PDT) MIME-Version: 1.0 From: Filip Skokan Date: Tue, 25 Jun 2019 10:40:00 +0200 Message-ID: To: oauth , "Richard Backman, Annabelle" , Torsten Lodderstedt Content-Type: multipart/alternative; boundary="00000000000082e041058c21e0c0" Archived-At: Subject: [OAUTH-WG] MTLS discovery - mtls_endpoint_aliases and _endpoint_auth_methods_supported 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 Jun 2019 08:40:15 -0000 --00000000000082e041058c21e0c0 Content-Type: text/plain; charset="UTF-8" Hello everyone, This is a follow to IETF 104 Thursday, March 28, 2019 OAuth meeting where we discussed the MTLS update. In the meeting we discussed the mtls_endpoint_aliases discovery property that exposes mutual-TLS enabled endpoints in addition to ones that don't have mutual-TLS enabled. We're doing this so that there are no cert selection popups for end-users when AS supports a mix of mtls and non-mtls interactions at e.g. the token endpoint. Annabelle brought up an issue on this list and in the meeting about the *_endpoint_auth_methods_supported discovery properties - about "this" endpoint which is now potentially in two places. I believe we have reached a compromise in the meeting to also allow these properties in the aliases but I cannot find a message about this neither on the list nor in the meeting notes. An example of such discovery document can be found here (aliases at the end of the document), notice that self_signed_tls_client_auth is not present in the root *_endpoint_auth_methods_supported properties but is present in the aliases. There have been no published updates to the MTLS draft since and i'm wondering if this is going to make it in the next revision. I also do not wish this point to get forgotten, hence this message. Best, *Filip* --00000000000082e041058c21e0c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

This is a fo= llow to IETF 104=C2=A0Thursday, March 28, 2019 OAuth meeting where we discu= ssed the MTLS update.

In the meeting we discussed = the mtls_endpoint_aliases discovery property that exposes mutual-TLS enable= d endpoints in addition to ones that don't have mutual-TLS enabled. We&= #39;re doing this so that there are no cert selection popups for end-users = when AS supports a mix of mtls and non-mtls interactions at e.g. the token = endpoint.

Annabelle brought up an issue on this li= st and in the meeting about the *_endpoint_auth_methods_supported discovery= properties - about "this" endpoint which is now potentially in t= wo places. I believe we have reached a compromise in the meeting to also al= low these properties in the aliases but I cannot find a message about this = neither on the list nor in the meeting notes.

An e= xample of such discovery document can be found here=C2=A0(aliases at the end of t= he document), notice that=C2=A0self_signed_tls_client_auth is not present i= n the root *_endpoint_auth_methods_supported properties but is present in t= he aliases.

There have been no published updates t= o the MTLS draft since and i'm wondering if this is going to make it in= the next revision. I also do not wish this point to get forgotten, hence t= his message.

Best,
Filip
--00000000000082e041058c21e0c0-- From nobody Tue Jun 25 06:39:14 2019 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 A5E4912003F; Tue, 25 Jun 2019 06:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 03ii-UQ0o985; Tue, 25 Jun 2019 06:39:05 -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 6AF0312008F; Tue, 25 Jun 2019 06:39:05 -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 x5PDcxaY036555; Tue, 25 Jun 2019 09:39:00 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x5PDcxaY036555 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1561469940; bh=XTS/ABMLA8RnguzQ6193i/OV/QqyeP7qthmlT5cbL5A=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=OF7SdWg3f+fdZw3bXNhBPHv78LS61Cs0Zsx0pmCboUd5/R3Pgh8Qoq5UrUbc9BL3h ITYdGEE7l9VWc2tBuwH/1osOaCYYVcs7eIZ5mIGhA3foAfQ3L5dE3jPUC/HRBksXB5 1HA1dOGbEb4jqgxBlJE4Xgff1VC/5Rlxp9+pHTKQ= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x5PDctfj013447; Tue, 25 Jun 2019 09:38:55 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Tue, 25 Jun 2019 09:38:55 -0400 From: Roman Danyliw To: Adam Roach , The IESG CC: "draft-ietf-oauth-jwt-bcp@ietf.org" , "hannes.tschofenig@arm.com" , "oauth-chairs@ietf.org" , "oauth@ietf.org" Thread-Topic: Adam Roach's Discuss on draft-ietf-oauth-jwt-bcp-06: (with DISCUSS and COMMENT) Thread-Index: AQHVKxOLsQtgotl85EeK8iOCnVL3HKasWjKw Date: Tue, 25 Jun 2019 13:38:54 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33A4F04@marathon> References: <156143908719.24005.13391480103830414058.idtracker@ietfa.amsl.com> In-Reply-To: <156143908719.24005.13391480103830414058.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-jwt-bcp-06: (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, 25 Jun 2019 13:39:08 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaWVzZyBbbWFpbHRvOmll c2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkYW0gUm9hY2ggdmlhDQo+IERhdGF0 cmFja2VyDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMjUsIDIwMTkgMTowNSBBTQ0KPiBUbzogVGhl IElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iY3BAaWV0 Zi5vcmc7IGhhbm5lcy50c2Nob2ZlbmlnQGFybS5jb207IG9hdXRoLQ0KPiBjaGFpcnNAaWV0Zi5v cmc7IG9hdXRoQGlldGYub3JnDQo+IFN1YmplY3Q6IEFkYW0gUm9hY2gncyBEaXNjdXNzIG9uIGRy YWZ0LWlldGYtb2F1dGgtand0LWJjcC0wNjogKHdpdGggRElTQ1VTUw0KPiBhbmQgQ09NTUVOVCkN Cj4gDQo+IEFkYW0gUm9hY2ggaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRp b24gZm9yDQo+IGRyYWZ0LWlldGYtb2F1dGgtand0LWJjcC0wNjogRGlzY3Vzcw0KPiANCj4gV2hl biByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVw bHkgdG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxp bmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeQ0KPiBwYXJhZ3JhcGgsIGhv d2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9p ZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRp b24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBU aGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZv dW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt b2F1dGgtand0LWJjcC8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBUaGFua3MgZm9yIGV2ZXJ5b25lIHdobyB3b3JrZWQgdG8g Z2V0IHRoaXMgZG9jdW1lbnQgb3V0IHRoZSBkb29yLiBJIGZvdW5kDQo+IGl0IHRvIGJlIHdlbGwt b3JnYW5pemVkIGFuZCBlYXN5IHRvIHJlYWQuDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g DQo+IFRoaXMgaXMgYSBwcm9jZXNzIGRpc2N1c3MgZm9yIFJvbWFuIHRvIGhhbmRsZSwgYW5kIEkg cGxhbiB0byBjbGVhciBpdCBkdXJpbmcgdGhlDQo+IElFU0cgZm9ybWFsIHRlbGVjaGF0Lg0KPiAN Cj4gVGhpcyBkb2N1bWVudCBpcyBpbnRlbmRlZCBmb3IgQkNQIHN0YXR1cy4gSXQgaGFzIGEgbm9y bWF0aXZlIHJlZmVyZW5jZSB0bw0KPiBSRkMgODAxNywgd2hpY2ggaXMgYW4gaW5mb3JtYXRpb25h bCBkb2N1bWVudC4gQ2hlY2tpbmcgdGhlIGxhc3QgY2FsbCB0ZXh0DQo+IChodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWp3dC0NCj4gYmNwL2VkaXQvbGFz dGNhbGx0ZXh0LyksDQo+IHRoZXJlIGlzIG5vIG1lbnRpb24gb2YgUkZDIDgwMTcsIG5vciBkb2Vz IFJGQyA4MDE3IGFwcGVhciBpbiB0aGUgZG93bnJlZg0KPiByZWdpc3RyeSAoaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZG93bnJlZi8pLg0KPiANCj4gVGhhbmtzIHRvIFJGQyA4MDY3 LCB3ZSBhcmUgbm90IHJlcXVpcmVkIHRvIHJ1biB0aGlzIGRvY3VtZW50IHRocm91Z2ggSUVURg0K PiBMQyBhZ2FpbiAoYW5kLCBnaXZlbiB0aGF0IFJGQyA4MDE3J3MgcHJlZGVjZXNzb3IsIFJGQyAz NDQ3LCBpcyBpbiB0aGUgcmVnaXN0cnksDQo+IHdlIHByb2JhYmx5IGRvbid0IHdhbnQgdG8pLiBI b3dldmVyLCB3ZSdsbCBuZWVkIHRvIG1pbnV0ZSB0aGF0IHRoZSBwb2ludA0KPiB3YXMgcmFpc2Vk IGFuZCBhZGRyZXNzZWQuIFRoZXJlIGlzIGFsc28gYXQgbGVhc3Qgb25lIGFkZGl0aW9uYWwgcmVx dWlyZW1lbnQNCj4gaW1wb3NlZCBieSBzZWN0aW9uIDIgb2YgUkZDIDgwNjcgdGhhdCBuZWVkcyB0 byBiZSBzYXRpc2ZpZWQgKHNlZSB0aGUgbGFzdA0KPiBzZW50ZW5jZSBpbiB0aGF0IHNlY3Rpb24p Lg0KDQpHb29kIGNhdGNoLiAgVGhpcyBpcyBteSBmYXVsdC4gIFRoZSBjYXV0aW9uIG9mIHRoZSBk b3ducmVmIHdhcyBpbiB0aGUgc2hlcGhlcmQgd3JpdGUtdXAgKHRoYW5rcyBIYW5uZXMpLg0KDQpJ IHNoYXJlIHlvdXIgdmlldyB0aGF0IHNpbmNlIFJGQzgwMTcgKG5vdCBpbiBkb3ducmVmIHJlZ2lz dHJ5IGJ1dCByZWZlcmVuY2VkIGhlcmUpIG9ic29sZXRlcyBSRkMzNDQ3IChpbiB0aGUgZG93bnJl ZiByZWdpc3RyeSksIHdlIGRvbid0IG5lZWQgdG8gcmUtcnVuIHRoZSBMQyAocGVyIFNlY3Rpb24g MiBvZiBSRkM4MDY3KS4gIElzIHRoZXJlIGNvbmNlcm4gd2l0aCB0aGlzIGNvdXJzZSBvZiBhY3Rp b24/DQoNClJvbWFuDQoNCg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IA0KPiDCpzMuMjoNCj4gDQo+ID4gIFRoYXQgc2FpZCwgaWYgYSBKV1QgaXMg Y3J5cHRvZ3JhcGhpY2FsbHkgcHJvdGVjdGVkIGJ5IGEgdHJhbnNwb3J0DQo+ID4gbGF5ZXIsIHN1 Y2ggYXMgVExTIHVzaW5nIGNyeXB0b2dyYXBoaWNhbGx5IGN1cnJlbnQgYWxnb3JpdGhtcywgdGhl cmUNCj4gPiBtYXkgYmUgbm8gbmVlZCB0byBhcHBseSBhbm90aGVyIGxheWVyIG9mIGNyeXB0b2dy YXBoaWMgcHJvdGVjdGlvbnMgdG8NCj4gPiB0aGUgSldULg0KPiANCj4gSXQgbWF5IGJlIGhlbHBm dWwgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBlbmQtdG8tZW5kIFRMUyBlbmNyeXB0aW9uIChzdWNo IGFzDQo+IHRoYXQgc2VlbiBpbiBIVFRQUywgZXZlbiBpbiB0aGUgcHJlc2VuY2Ugb2YgcHJveGll cykgYW5kIGhvcC1ieS1ob3AgVExTDQo+IGVuY3J5cHRpb24gKHN1Y2ggYXMgdGhhdCBzZWVuIGlu IFNJUFMgd2hlbiBwcm94aWVzIGFyZSBwcmVzZW50KS4gSW4gdGhlIGxhdHRlcg0KPiBjYXNlLCBp bnRlcm1lZGlhcmllcyBtYXkgcGVyZm9ybSBhdHRhY2tzIHRoYXQgd291bGQgb3RoZXJ3aXNlIG9u bHkgYmUNCj4gcG9zc2libGUgdG8gbW91bnQgYnkgdGhlIGVuZHBvaW50cy4NCj4gDQo+IE15IGNv bmNyZXRlIHN1Z2dlc3Rpb24gaXMgdG8gbW9kaWZ5IHRoZSBhYm92ZSB0ZXh0IHRvIHJlYWQgIi4u LnByb3RlY3RlZA0KPiBlbmQtdG8tZW5kIGJ5IGEgdHJhbnNwb3J0IGxheWVyLCBzdWNoIGFzLi4u Ig0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiDCpzMuMjoNCj4gDQo+ID4gIC0gIEF2 b2lkIGFsbCBSU0EtUEtDUzEgdjEuNSBbUkZDMjMxM10gZW5jcnlwdGlvbiBhbGdvcml0aG1zLA0K PiA+ICAgICBwcmVmZXJyaW5nIFJTQS1PQUVQIChbUkZDODAxN10sIFNlYy4gNy4xKS4NCj4gDQo+ IEl0J3Mgbm90IGNsZWFyIHRvIG1lIHdoYXQgdGhpcyByZWNvbW1lbmRhdGlvbiBpbnRlbmRzIHRv IHNheSByZWdhcmRpbmcgdGhlDQo+IGFsZ29yaXRobXMgaW4gUkZDIDI0MzcgYW5kIFJGQyAzNDQ3 LiBPbmUgbWlnaHQgaW5mZXIgdGhhdCB0aGV5J3JlIGRlcHJlY2F0ZWQNCj4gYXMgd2VsbC4gSWYg dGhpcyBpcyB0aGUgaW50ZW50aW9uLCBwbGVhc2UgYmUgZXhwbGljaXQuDQo+IA0KDQo= From nobody Tue Jun 25 09:35:51 2019 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 CAA6A120322; Tue, 25 Jun 2019 09:35:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-oauth-jwt-bcp@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, hannes.tschofenig@arm.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156148054377.31241.8707184103893993321.idtracker@ietfa.amsl.com> Date: Tue, 25 Jun 2019 09:35:43 -0700 Archived-At: Subject: [OAUTH-WG] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dr?= =?utf-8?q?aft-ietf-oauth-jwt-bcp-06=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: Tue, 25 Jun 2019 16:35:44 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-oauth-jwt-bcp-06: 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-jwt-bcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm by far no expert here but I don't really understand all attacks described. Maybe it's just me, however, especially 2.7 and 2.8 seem quite high level to me and I'm wondering if it is possible to be more concrete or provide an example or something. Anyway, the more important part is section 3, so no need to worry too much about this. I'm wondering if it would make sense for this document to update RFC7519. I know there is no direct change but it complements RFC7519 and using the update mechanism makes I easy/easier for readers of RFC7519 two find this doc. From nobody Wed Jun 26 07:27:30 2019 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 56E36120044; Wed, 26 Jun 2019 07:27:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwt-bcp@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, hannes.tschofenig@arm.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Vigoureux Message-ID: <156155924331.20056.18009078917506280190.idtracker@ietfa.amsl.com> Date: Wed, 26 Jun 2019 07:27:23 -0700 Archived-At: Subject: [OAUTH-WG] Martin Vigoureux's No Objection on draft-ietf-oauth-jwt-bcp-06: (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, 26 Jun 2019 14:27:23 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-oauth-jwt-bcp-06: 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-jwt-bcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hello, thank you for this document. I wonder whether [nist-sp-800-56a-r3] should be a normative reference. Thanks -m From nobody Fri Jun 28 16:02:50 2019 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 CAB561209BE; Fri, 28 Jun 2019 15:58:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rdd@cert.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176268182.11015.16531714838028792945.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:58:01 -0700 Archived-At: Subject: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 105 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, 28 Jun 2019 22:58:16 -0000 Dear Rifaat Shekh-Yusef, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. oauth Session 1 (1:30 requested) Tuesday, 23 July 2019, Afternoon Session II 1520-1650 Room Name: Van Horne size: 130 --------------------------------------------- oauth Session 2 (1:30 requested) Friday, 26 July 2019, Morning Session I 1000-1200 Room Name: Duluth size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/oauth.ics Request Information: --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Rifaat Shekh-Yusef Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: acme tls rats sipcore anima Second Priority: ace secevent teep suit core tokbind saag People who must be present: Roman Danyliw Hannes Tschofenig Rifaat Shekh-Yusef Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jun 30 02:06:32 2019 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 6B718120073 for ; Sun, 30 Jun 2019 02:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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 iS0oyXXisE6w for ; Sun, 30 Jun 2019 02:06:28 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0: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 749A1120071 for ; Sun, 30 Jun 2019 02:06:28 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id m206so7563491oib.12 for ; Sun, 30 Jun 2019 02:06:28 -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=f4VSGSZhuxJEkvkmWIgyfi9yxwSxAmCBLEUt18D5BkU=; b=lcagUKISwiEdudffaLOQpmajH8w3xP6aAThMrO4L/Rmm5JmUl4sxHLaOBnpgMeMpvz xg39SV25S1tU1zBgYs3Is4vuLu1pb4YnXpN0OLde0HQwXObgWfyre9CUKzqHUs0X5J9Z ybBdmgvjgTmdEgXXQUFXMvbtLaOu5hC0eKSSjc7mImkt16hfZ24Vo6mr5iSfVAnyo1CN /5CqahQoifbx54m6VONoFHUZAhBZh+e0Tl5t3rjlbbkdYnWnmCqCmqI1+EcfB7lClTac mifMELQOQdoe4ZJc5FWX3o6OK6+p13QpH1yYCjG7ojHf9Vk9EGP1JG2xrq1euPTJbAyc LN/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=f4VSGSZhuxJEkvkmWIgyfi9yxwSxAmCBLEUt18D5BkU=; b=fu/er9uNWEhHw9WdUNAgZa/LhazvTqKNoNX/ue5w0vTYE6UF15p6CN7h3sIWz0vq/r rmsp6VPtJnS1ECe3IlHSHrFbZhOWiTFgz1rD0qIjSnlHp8WE8nYlNNV7Fkbz6wAg050J uzuIMIe6iTxm4TIZdNjbFDEENMY54BweGvgPekf10KSZj/Cf8jT/P4eujvvWjl2qm4hN 0PXCYqh6Q7N//d8IMqiy9C5sEk0JLYP9lgFnnaFloQelYHjQSx31pyEDhwdrhl1EL/bV 6lq9xZ4rfJ2JzcBUla3d84YmqB65cDoUBsKST+TKq3LbItD8S8tB0NnSpmroT7eehriA 5mQQ== X-Gm-Message-State: APjAAAVcxROi+AQbJJIDg0H0LUoL+G/47Jzu8R5lBbshDp5C7yJ3TB6U HvO4oZC6YmBvak4rjj51frvx1NDvdR76WTHH07S8LkU= X-Google-Smtp-Source: APXvYqwv15xwk0tqbw83jKZiJO3FuzpA0r6ggks9cwJuPLXvomOcgK3Yz9TJh7A9eeTNQgl3wKbyNCrqP+FqeovE4fw= X-Received: by 2002:aca:f1c4:: with SMTP id p187mr3281738oih.149.1561885587487; Sun, 30 Jun 2019 02:06:27 -0700 (PDT) MIME-Version: 1.0 From: Filip Skokan Date: Sun, 30 Jun 2019 11:06:16 +0200 Message-ID: To: oauth , Brian Campbell , John Bradley Content-Type: multipart/alternative; boundary="0000000000009f4df4058c86d39c" Archived-At: Subject: [OAUTH-WG] Client Metadata for Resource Indicators for OAuth 2.0 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 Jun 2019 09:06:30 -0000 --0000000000009f4df4058c86d39c Content-Type: text/plain; charset="UTF-8" Dear John, Brian, everyone, I'd like to forward a request from several developers using my AS software to have defined client metadata property similar to scope in section 2 of RFC 7591 but for "resources a client must stay within the bounds of". My answer to these developer is that they are able to configure their AS with custom client metadata with defined validations executed *but since this is a re-occurring request I wonder if it would be worth to define and register a property in the resource indicators specification itself that would promote interoperability and would allow its readers to know what to look for in available client metadata.* The format can either be an array of resource values or just like with scope a space-delimited string of resource values. Best, *Filip Skokan* --0000000000009f4df4058c86d39c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear John, Brian, everyone,

= I'd like to forward a request from several developers using my AS softw= are to have defined client metadata property similar to scope=C2=A0in section 2 of RFC 7591=C2=A0but for "resourc= es a client must stay within the bounds of".

= My answer to these developer is that they are able to configure their AS wi= th custom client metadata with defined validations executed but since th= is is a re-occurring request I wonder if it would be worth to define and re= gister a property in the resource indicators specification itself that woul= d promote interoperability and would allow its readers to know what to look= for in available client metadata.

The format = can either be an array of resource values or just like with scope a space-d= elimited string of resource values.

Best,
Filip Skokan
--0000000000009f4df4058c86d39c--